I am in the process of deploying an Aruba CX 8360v2 (JL719C) VSX Stack as a streched Core.

In want to use a dedicated 1G MMF Link for VSX KeepAlive. Naturaly i've configured UDLD on the LWL Link, but UDLD keeps blocking it. My guess is, because the Interface is configured as a Layer 3 (routing) UDLD as a Layer 2 protocoll does not work?

Firmware: 10.16.1020 (LL.10.16.1020)

If so, why does the firmware allow this configuration? Oversight or Bug?

EDIT: without UDLD enabled, the Link / KeepAlive works fine.

Config 

vsx

    role primary
    keepalive peer 192.168.0.2 source 192.168.0.1 vrf keepalive

vrf keepalive

interface 1/1/48
    description VSX keepalive
    no shutdown
    vrf attach keepalive
    ip address 192.168.0.1/30
    udld
    apply fault-monitor profile all
    exit

UDLD Status

# show udld interface 1/1/48

Interface 1/1/48
 Config: enabled
 State: active
 Substate: blocked
 Link: block
 Version: hpe anw
 Mode: forward then verify
 Interval: 7000 milliseconds
 Retries: 4
 Tx: 210 packets
 Rx: 0 packets, 0 discarded packets, 0 dropped packets
 Port transitions: 1

UDLD has to be running on both ends, and your counters say it isn't. Tx 210 with Rx 0 means you're transmitting and getting nothing back, so the far end either doesn't have udld configured or isn't processing it. Post show udld from the peer and that settles it in one command.

On your L3 theory, the docs don't answer it cleanly either way. UDLD lives in the layer 2 bridging guide and is described as detecting unidirectional behaviour of a layer 2 link, and HPE's own config example uses no routing on the member ports. But there's no statement anywhere that it's unsupported on a routed or VRF attached interface, so I wouldn't read the CLI accepting it as proof of much.

Worth noting the VSX best practices guide builds the keepalive exactly like yours, dedicated L3 link in its own VRF, and doesn't put UDLD on it at all. Between your fault-monitor profile and the keepalive's own timers, a dead link there is already covered.

------------------------------
Dustin Burns

@Worldcom Exchange, Inc.


If my post was useful accept solution and/or give kudos
------------------------------