cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
7551
Views
45
Helpful
9
Replies

UDLD Normal Question

wpalumbo06
Level 1
Level 1

Hi all,

I need some clarification on UDLD please.  I have always used UDLD aggressive mode and understand that with no issues.  What I am not clear on is exactly what UDLD does in normal mode.  According to the Cisco documentation,

"In normal mode, if the link state of the port was determined to be bi-directional and the UDLD information times out, no action is taken by UDLD. The port state for UDLD is marked as undetermined.  The port behaves according to its STP state."

If no action is taken in normal mode, is there any value in using it?

Thanks,

Bill

1 Accepted Solution

Accepted Solutions

Hi Bill,

The UDLD is sadly underdocumented in several sources, and even the informational RFC does not contain all the necessary information to properly understand UDLD modes.

The truth is, according to U.S. Patent 6765877, that there are two ways in UDLD of detecting an unidirectional link: an explicit and an implicit method. To understand the explicit method, it is important to keep in mind that each switch indicates its own [Device ID, Port ID] tuple as the sender information in an UDLD message, and echoes back the [Device ID, Port ID] tuples received from its neighbors in an echo portion of the message. In other words, each UDLD message carries a device and port identity of its sender, and contains an echo list of all neighbors and their ports whose UDLD messages have been received on the port that sends out this UDLD message itself.

An unidirectional link is detected explicitly if one or more of the following events occur during the neighbor detection and linkup phase:

  • UDLD messages received from a neighbor do not contain the tuple that matches the receiving switch and port in their echo portion. This would indicate a split fiber or a truly unidirectional link.
  • UDLD messages received from a neighbor contain the same sender as the receiving switch and its port. This would indicate a self-looped port.
  • UDLD message received from a neighbor contain a different list of entries in the echo portion (i.e. a different set of neighbors) than the set of neighbors heard by this switch on this port. This would indicate a shared segment with a partial impaired connectivity between connected switches.

Whenever any of these three events is observed during an UDLD neighborship buildup with a neighboring switch, the link is declared unidirectional and subsequently disabled. Once again, this is called explicit unidirectional link detection. The setting of aggressive or normal mode has no effect on explicit detection.

An implicit unidirectional link detection refers to the event when UDLD messages arriving from the neighbor device suddenly cease to be received, without the port actually going down. This is where the aggressive or normal UDLD modes make a difference. In the normal mode, you simply age out the neighbor and do nothing, hoping that if there was a physical unidirectional fault on the link, the physical and link-layer mechanism would have brought the link down anyway. In aggressive mode, you assume that the physical layer has no capability of detecting and dealing with the unidirectional link condition itself, and when UDLD messages stop arriving, you err-disable the port just to be safe.

So the difference between the normal and aggressive modes relates to the difference in handling an implicit uni-directional link event. If an uni-directional link is detected explicitly, the port will always be err-disabled, regardless of the normal/aggressive mode.

The related U.S. Patent is a good, albeit tiresome, reading on this, especially the Figure 7 with the decision diagram; check out this thread:

https://supportforums.cisco.com/thread/2179927

Best regards,
Peter

View solution in original post

9 Replies 9

Reza Sharifi
Hall of Fame
Hall of Fame

Hi Bill,

Normal mode is an informational mode vs the aggressive mode will put the port in error disable in case there is any issue with the fiber.

normal

UDLD message time interval

global configuration command). Upon

receiving the probe, the UDLD protocol attempts to synchronize the devices by sending echo

messages to the peer port and waiting for answer during the detection window. If the unidirectional

traffic is detected when the port link is still up (port B no longer sends traffic to port A), port B enters

errdisable mode. Port A is marked Undetermined but does not enter errdisable mode. It continues

to operate under its current STP status because this mode is informational only; it is potentially less

disruptive although it does not prevent STP loops.

link:

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-2/31sga/configuration/guide/config/udld.pdf

HTH

Correct - so UDLD normal mode provides nothing more than information, right?  If so, then why would it be used?  Aggressive mode makes sense and I have had good success with it - normal mode just isn't making any sense to me...

Hi Bill,

The UDLD is sadly underdocumented in several sources, and even the informational RFC does not contain all the necessary information to properly understand UDLD modes.

The truth is, according to U.S. Patent 6765877, that there are two ways in UDLD of detecting an unidirectional link: an explicit and an implicit method. To understand the explicit method, it is important to keep in mind that each switch indicates its own [Device ID, Port ID] tuple as the sender information in an UDLD message, and echoes back the [Device ID, Port ID] tuples received from its neighbors in an echo portion of the message. In other words, each UDLD message carries a device and port identity of its sender, and contains an echo list of all neighbors and their ports whose UDLD messages have been received on the port that sends out this UDLD message itself.

An unidirectional link is detected explicitly if one or more of the following events occur during the neighbor detection and linkup phase:

  • UDLD messages received from a neighbor do not contain the tuple that matches the receiving switch and port in their echo portion. This would indicate a split fiber or a truly unidirectional link.
  • UDLD messages received from a neighbor contain the same sender as the receiving switch and its port. This would indicate a self-looped port.
  • UDLD message received from a neighbor contain a different list of entries in the echo portion (i.e. a different set of neighbors) than the set of neighbors heard by this switch on this port. This would indicate a shared segment with a partial impaired connectivity between connected switches.

Whenever any of these three events is observed during an UDLD neighborship buildup with a neighboring switch, the link is declared unidirectional and subsequently disabled. Once again, this is called explicit unidirectional link detection. The setting of aggressive or normal mode has no effect on explicit detection.

An implicit unidirectional link detection refers to the event when UDLD messages arriving from the neighbor device suddenly cease to be received, without the port actually going down. This is where the aggressive or normal UDLD modes make a difference. In the normal mode, you simply age out the neighbor and do nothing, hoping that if there was a physical unidirectional fault on the link, the physical and link-layer mechanism would have brought the link down anyway. In aggressive mode, you assume that the physical layer has no capability of detecting and dealing with the unidirectional link condition itself, and when UDLD messages stop arriving, you err-disable the port just to be safe.

So the difference between the normal and aggressive modes relates to the difference in handling an implicit uni-directional link event. If an uni-directional link is detected explicitly, the port will always be err-disabled, regardless of the normal/aggressive mode.

The related U.S. Patent is a good, albeit tiresome, reading on this, especially the Figure 7 with the decision diagram; check out this thread:

https://supportforums.cisco.com/thread/2179927

Best regards,
Peter

Peter,

Thank you very much for the detailed response - excellent information!  I now have a pretty good understanding of UDLD.  I find it odd that there is so much disparity between the Cisco documentation on this important topic but perhaps that's just a result of different writing styles.  Understanding this topic is good, but seeing is believing, so I had to break UDLD to see what would happen.  In addition to self looping the fiber to break UDLD, I found that you can also block the MAC address that UDLD uses (0100.0ccc.cccc) on switch 'A' to cause UDLD normal mode to err-disable the interface on switch 'B'.  Here is the config I used just in case anyone wants to test UDLD for themselves:

mac access-list extended UDLD

deny   host 0100.0ccc.cccc any

!

!

interface GigabitEthernet0/2

switchport trunk encapsulation dot1q

switchport mode trunk

udld port

mac access-group UDLD in

00:29:33.559: %UDLD-4-UDLD_PORT_DISABLED: UDLD disabled interface Gi0/1, unidirectional link detected

00:29:33.559: %PM-4-ERR_DISABLE: udld error detected on Gi0/1, putting Gi0/1 in err-disable state

00:29:34.563: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to down

Hi Bill,

Sorry for responding late - it's been a busy week.

Thank you very much for the detailed response - excellent information!

It has been a pleasure.

I find it odd that there is so much disparity between the Cisco  documentation on this important topic but perhaps that's just a result  of different writing styles.

I think it is more than that but I can not explain why. For some reason, all UDLD information has been purely superficial, and besides the obvious, documents available to me never went truly deep. Only after digging into the patent, I started to realize what is truly happening inside UDLD.

In addition to self looping the fiber to break UDLD, I found that you  can also block the MAC address that UDLD uses (0100.0ccc.cccc) on switch  'A' to cause UDLD normal mode to err-disable the interface on switch  'B'.  

If you want to truly test UDLD on a self-looped port, also make sure you use the no keepalive command on the switchport. Cisco switches use the Ethernet LOOP frames as yet another mechanism of detecting a self-looped port. If a self-looped port is err-disabled, it may be either because of the LOOP frames, or thanks to the UDLD, so if you want to be sure it is UDLD in action, deactivate the LOOP frames using the no keepalive per-interface command.

Regarding the blocking of UDLD messages using ACL - yes, that is exactly what I do as well to show the UDLD behavior Just notice your ACL does not contain any permit line, effectively behaving as deny any - but that's just a nitpicking remark. Regarding the fact the link got err-disabled, this conforms to the first event in my previous reply: switch B was receiving UDLD messages from switch A but these messages were missing the tuple of B, so B did not see a matching entry in the echo list, and so, after a while, it err-disabled the port.

Best regards,

Peter

Thanks Peter,

It was one of those crazy late-night lab marathons and I copied the wrong config - ACL should have looked like this:

mac access-list extended UDLD

deny any host 0100.0ccc.cccc

permit any any

NOT

mac access-list extended UDLD

deny   host 0100.0ccc.cccc any

In addition to the missing permit any any, the UDLD mac address needs to be specified as the destination and not the source

Bill

Peter,

I have to say this is he best ever explanation of UDLD Normal mode I have ever found.

 

Thank you

-----

Mario

Mario,

I am honored - and even more glad I could be of help. Thank you!

Best regards,
Peter

gsidhu
Level 3
Level 3

Hi

 

In normal mode according to the documentation

 

'In normal mode, if the link state of the port was determined to be bi−directional and the UDLD information times out, no action is taken by UDLD. The port state for UDLD is marked as undetermined. The port behaves according to its STP state.'

 

http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/10591-77.pdf

 

I'm assuming that 'according to its STP state' means that if the port was in the STP blocking state the port will continue to be in STP blocking state (and hence prevent an STP loop if the upstream designated switch stops sending BPDUs).

 

Has anybody tested this and able to confirm?
 

.....otherwise I don't see any point of using UDLD normal mode if it lets the blocking port transition to forwarding state

 

The N7k design guide (page 68) mentions that UDLD normal mode will 'error-disable the port' which contradicts the above statement

 

http://www.cisco.com/c/dam/en/us/td/docs/switches/datacenter/sw/design/vpc_design/vpc_best_practices_design_guide.pdf

 

'UDLD has two modes of operation:
● Normal mode: UDLD detects the link error by examining the incoming UDLD packets from the peer port. These error conditions are: Empty Echo packet, Unidirection, TX/RX loop, and Neighbor Mismatch. UDLD will then error-disable the port.


● Aggressive mode: Same behavior as in Normal mode, but UDLD also sets the port to the error-disable state in case of sudden cessation of UDLD packets in both directions. By default, the port is put in err-disable mode if no UDLD packets are received for (3 X hello-time) + 5 sec =50 seconds'

 

Needless to say I am very confused

 

 

 

 

 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: