UDLD Simulation

cisco_trooper

For those interested:

I was going over some BCMSN stuff from several months ago and couldn't remember how I simulated a UDLD detection without breaking a cable. I finally dug up an old lab I had and the lights went on.

Use a MAC ACL applied to the interface where you want to simulate the UDLD activity. If you recall, UDLD works by sending traffic to 0100.0ccc.cccc. Here are the relevent portions of my config:

!
udld enable
!
mac access-list extended filter.udld
deny any host 0100.0ccc.cccc
permit any any
!
interface GigabitEthernet1/0/25
mac access-group filter.udld in
!

One thing I will note is that I was not able to apply the mac filter to the interface when it was in layer 3 mode. UDLD is globally enabled on this switch.

Hope someone finds this useful.

cisco_trooper

OK, according to the BCMSN book as follows:

Excerpt wrote:

UDLD has two modes of operation:

Normal mode— When a unidirectional link condition is detected, the port is allowed to continue its operation. UDLD merely marks the port as having an undetermined state and generates a syslog message.

Aggressive mode— When a unidirectional link condition is detected, the switch takes action to re-establish the link. UDLD messages are sent out once a second for 8 seconds. If none of those messages is echoed back, the port is placed in the errdisable state so that it cannot be used.

I am working on two 3750s with the newest IOS. Placing both UDLD ports in normal mode and then filtering UDLD traffic on one of the interfaces to simulate a UDLD condition generated the syslog as expected, but it also err-disabled the far end interface. I thought only aggressive mode err-disabled the interface. Anyone else have any experience with this? Is the BCMSN book wrong, or is there a bug in this particular IOS? I didn't intend to spend a bunch of time on UDLD, but if I have conflicting information I don't have much choice.....

cisco_trooper

I see no notable difference in debug output between normal and aggressive modes. Looking for bug updates for this IOS: c3750-advipservicesk9-mz.122-46.SE.bin

EdTheLad

What is your port config, you are blocking the well known cisco mac address which could cause loop-guard to kick in if configured.
The funny thing is i'm thinking i saw the same results while i was testing udld last month, cant remember 100% as my customer was using aggressive mode and i wasnt too interested in normal mode.Currently on holidays so i cant check the results.
Check out my recent udld thread in the ccie section for some extra info, my testing was done on 3550 & 3750.

cisco_trooper

Ed, no loop guard, root guard, or any other spanning tree related configurations exist on these two interfaces. But check this out.

In normal mode and aggressive mode, when I was filtering the 0100.0ccc.cccc MAC address going in to switch one interface, the switch two interface became err-disabled after 3 x Message Interval expired.

BUT,
when I used your approach of disabling the speed and duplex negotiations and then pulling one side of the fiber, the results were different. (Perhaps there is more to this than Cisco tells us.. I'm really baffled at why filtering traffic to the MAC didn't work... )

Normal mode does just as the book says and the far end enters an unknown state:
3750-2#sho udld gi1/0/26

Interface Gi1/0/26
---
Port enable administrative configuration setting: Enabled
Port enable operational state: Enabled
Current bidirectional state: Bidirectional
Current operational state: Advertisement - Single neighbor detected
Message interval: 15
Time out interval: 5

Entry 1
---
Expiration time: 1
Device ID: 1
Current neighbor state: Bidirectional
Device name: FOC1120Y2VF
Port ID: Gi1/0/25
Neighbor echo 1 device: FOC1012Y2T1
Neighbor echo 1 port: Gi1/0/26

Message interval: 15
Time out interval: 5
CDP Device name: 3750-1

3750-2#sho udld gi1/0/26

Interface Gi1/0/26
---
Port enable administrative configuration setting: Enabled
Port enable operational state: Enabled
Current bidirectional state: Unknown - Interface enters an unknown UDLD state and continues forwarding traffic
Current operational state: Link up
Message interval: 7
Time out interval: 5
No neighbor cache information stored

Aggressive mode also does as expected, check it out:
3750-2#sho udld gi1/0/26

Interface Gi1/0/26
---
Port enable administrative configuration setting: Enabled / in aggressive mode
Port enable operational state: Enabled / in aggressive mode
Current bidirectional state: Bidirectional
Current operational state: Advertisement - Single neighbor detected
Message interval: 15
Time out interval: 5

Entry 1
---
Expiration time: 1
Device ID: 1
Current neighbor state: Bidirectional
Device name: FOC1120Y2VF
Port ID: Gi1/0/25
Neighbor echo 1 device: FOC1012Y2T1
Neighbor echo 1 port: Gi1/0/26

Message interval: 15
Time out interval: 5
CDP Device name: 3750-1
3750-2#sho udld gi1/0/26

Interface Gi1/0/26
---
Port enable administrative configuration setting: Enabled / in aggressive mode
Port enable operational state: Enabled / in aggressive mode
Current bidirectional state: Unknown
Current operational state: Link up - Interface not disabled yet, aggressive attempts to recover the link
Message interval: 7
Time out interval: 5
No neighbor cache information stored
3750-2#sho udld gi1/0/26

Interface Gi1/0/26
---
Port enable administrative configuration setting: Enabled / in aggressive mode
Port enable operational state: Enabled / in aggressive mode
Current bidirectional state: Unknown
Current operational state: Disabled port - Interface disabled, recovery attempt failed
Message interval: 7
Time out interval: 5
No neighbor cache information stored

cisco_trooper

Anyway, hope that helps someone out....

I was going to provide the debug output, but it honestly wasn't that informative or interesting. Certainly not interesting enough for the amount of space it would have taken up in the thread.