UDLD ?

CCIE_2011

Morning,
I was playing with udld aggressive yesterday. I enable it on both links. commed the show udld, got the expected results. I disabled it on one side, hopping a port to be put in errdisable state, CUZ now only one side is sending udld msgs and it was activated. But I got nothing, the udld enabled ports are still active. .... really confused me ?

PS: I'm not using fiber port. Hence i activate udld on the port level Plus in the global config.

dtlokee

You actually need a unidirectional link to see it work, turning off udld on one side will disable udld on the other. udld isn't just about the switch sending and receiving heartbeat frames from the other side, but a combination of L1 and L2 elements. Shutting it down on one side will just cause the udld bidirectional pair to be destroyed.

http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_25_see/configuration/guide/swudld.html

Paul Boz

Echoing dtlokee's sentiment, just unplug your switchport and watch the magic.

mikej412

How Unidirectional Link Detection Protocol Works

UDLD is a Layer 2 (L2) protocol that works with the Layer 1 (L1) mechanisms to determine the physical status of a link. At Layer 1, auto-negotiation takes care of physical signaling and fault detection. UDLD performs tasks that auto-negotiation cannot perform, such as detecting the identities of neighbors and shutting down misconnected ports. When you enable both auto-negotiation and UDLD, Layer 1 and Layer 2 detections work together to prevent physical and logical unidirectional connections and the malfunctioning of other protocols.

UDLD works by exchanging protocol packets between the neighboring devices. In order for UDLD to work, both devices on the link must support UDLD and have it enabled on respective ports.

If you don't have layer 1, there's no need for UDLD to even worry about layer 2.

dtlokee

The way I made it work was by taking the 2 fiber links from one switchport (TX/RX) and plugging the RX side into the TX side of a port on another switch, then plugged the TX side into the RX side of a different interface than the one I plugged the RX into on the other switch. I guess you could simulate something like this with a copper connection by placing a non Cisco switch in between the two Cisco switches and then unplugging one of them from the non-Cisco switch.

kryolla

The only place I have seen here at work is on OC3 & OC12 point to point links that do not have redundancy built in no working and protect on the same catalyst but have a A & B cat as redundancy.

APA

If you have fiber access, you just have to unplug the TX side from one of the fiber links and then you have a Uni-directional link.

I'm not sure if you could replicate this with copper....... As the Cisco switch still connected wouldn't become uni-directional when you unplug it from the non-cisco switch? The Cisco switch still connected to the non-cisco will be transmitting bi-directional still to the non-cisco right?

It will just have no connectivty to the other switch as obviously it has been taken offline........ Much like shutting down the interface as previously mentioned?

cisco_trooper

A.P.A wrote:

If you have fiber access, you just have to unplug the TX side from one of the fiber links and then you have a Uni-directional link.

I'm not sure if you could replicate this with copper....... As the Cisco switch still connected wouldn't become uni-directional when you unplug it from the non-cisco switch? The Cisco switch still connected to the non-cisco will be transmitting bi-directional still to the non-cisco right?

It will just have no connectivty to the other switch as obviously it has been taken offline........ Much like shutting down the interface as previously mentioned?

Could always make your own cable, without the TX pins in one side...

APA

cisco_trooper wrote:

Could always make your own cable, without the TX pins in one side...

Well that's what I call thinkin outside the square (with extreme)......

dtlokee

A.P.A wrote:

cisco_trooper wrote:

Could always make your own cable, without the TX pins in one side...

Well that's what I call thinkin outside the square (with extreme)......

The port will become active without an electrical connection, like when the cable is bad there's no link light. No connection and you don't have L1 which means no L2 which is where UDLD works.

I think the only way to pull this off is to put a L1 device like a repeater (or possibly a L2 device like a non-Cisco switch) in between the 2 Cisco switches and wait for the UDLD peer to be created then unplug one side.

Another thought would be to create a cable that is connected to one RJ-45 on one side and is correctly wired, then connect the TX pins on that one to the RX pins on another RJ-45 and then take the RX pins from the correct one to another RJ-45's TX pins. In effect creating a "Y" shaped cable.

I'm not bored enough ATM to test it.

darkuser

i thought udld was mainly for detecting unidirectional links over fiber
i actually had an intestering problem a while ago where a lot of links were being reconfigured
from isl to dot1q and fiber re-routed.
we ended up with an accidental trunk mismatch
isl on one end dot1q on the other
resulting in a st loop.
interestingly i couldn't fiind the problem until I enabled aggressive mode and it detected the problem and shut the link.
and i was pointed directly to the error.
cisco was stumped and we actually had a couple people from penn plaza in house.

k

jf1111

really, really late to the game here, but this is one of the only threads i've seen discussing this subject.

i was searching for a way to test udld myself, so i started looking at ways of blocking layer 2. i had success testing udld aggressive mode using a vlan filter.

you can either set both ports in access mode or use the native vlan on dot1q trunks. assuming you're doing this on test equipment, simply drop traffic on that vlan on one side, and if both sides are in aggressive mode, one will err-disable.

vlan access-map vl-x 10
action drop
vlan filter vl-x vlan-list <vlan>

you could probably get even more specific blocking the 01-00-0c-cc-cc-cc mac address, but why bother if you're just testing.