UDLD Enable and UDLD Aggressive - What is the difference?

astanislaus · ‎08-22-2007

I have read at least 6 links on Cisco Systems to try and really understand the difference between UDLD Enable and UDLD Aggressive. The more I read the more I am confused. My final understanding is as follows and I wish someone to correct me if my understanding is correct.

UDLD Enable just detects if a link becomes Unidirectional - that is - it can send UDLD frames but cannot receive UDLD frames, but takes no action when this happens.

UDLD Aggressive on the other hand shuts down the interface when it can send UDLD frames but cannot receive them and hence called aggressive because this shuts down the interface.

But then I go and read another URL and I find that UDLD Enable also will shut down the interface when it can transmit UDLD frames but cannnot receive UDLD frames from teh other end.

It would be hard to simulate this in the lab because if we unplug one fibre cable from switch A to switch B the interface state goes to LINE DOWN / PROTOCOL DOWN on both switches and we cannot see UDLD playing any role at all - be it UDLD Enable or UDLD Aggressive.

To simulate it, we would have to some how keep the Interface in LINE UP / PROTOCOL UP state on both switches but somehow stop UDLD frames from switch A being received by switch B.

Or is there any other easy way of simulating this in the lab to see the difference between UDLD Enable and UDLD Aggressive behaviours.

astanislaus · ‎08-22-2007

http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/122sx/swcg/udld.htm#wp1027627

For example look at the above link and you will see it says the following which says UDLD Enable and UDLD Aggressive both will shut the port down and hence my initial understanding is wrong:

=============================================

UDLD Aggressive Mode

UDLD aggressive mode is disabled by default. Configure UDLD aggressive mode only on point-to-point links between network devices that support UDLD aggressive mode. With UDLD aggressive mode enabled, when a port on a bidirectional link that has a UDLD neighbor relationship established stops receiving UDLD packets, UDLD tries to reestablish the connection with the neighbor. After eight failed retries, the port is disabled.

To prevent spanning tree loops, nonaggressive UDLD with the default interval of 15 seconds is fast enough to shut down a unidirectional link before a blocking port transitions to the forwarding state (with default spanning tree parameters).

When you enable UDLD aggressive mode, you receive additional benefits in the following situations:

?One side of a link has a port stuck (both Tx and Rx)

?One side of a link remains up while the other side of the link has gone down

In these cases, UDLD aggressive mode disables one of the ports on the link, which prevents traffic from being discarding.

lmcruzhsa · ‎03-08-2010

Hi,

We have the same problem here.

UDLD is not clear for us.

We have deployed "udld enable" and we saw today this problem:

interface GigabitEthernet1/0/19
description A - 00 - PacketShaperEu - Inside
switchport trunk encapsulation dot1q
switchport trunk native vlan 99
switchport trunk allowed vlan 21,61,75,94,95,99
switchport mode trunk
switchport nonegotiate
speed 1000
duplex full
udld port
spanning-tree guard root
end

But today we saw this in the log:

000986: Mar 8 10:16:04.407 GMT: %UDLD-4-UDLD_PORT_DISABLED: UDLD disabled interface Gi1/0/19, unidirectional link detected
000987: Mar 8 10:16:04.407 GMT: %PM-4-ERR_DISABLE: udld error detected on Gi1/0/19, putting Gi1/0/19 in err-disable state
000988: Mar 8 10:16:05.515 GMT: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/19, changed state to down
000989: Mar 8 10:16:06.521 GMT: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/19, changed state to down
000990: Mar 8 10:16:31.050 GMT: %PM-4-ERR_RECOVER: Attempting to recover from udld err-disable state on Gi1/0/19
000991: Mar 8 10:16:34.414 GMT: %SPANTREE-5-TOPOTRAP: Topology Change Trap for vlan 21
000992: Mar 8 10:16:35.504 GMT: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/19, changed state to up
000993: Mar 8 10:16:36.511 GMT: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/19, changed state to up
000994: Mar 8 10:17:03.631 GMT: %SPANTREE-5-TOPOTRAP: Topology Change Trap for vlan 99
000995: Mar 8 10:17:52.412 GMT: %UDLD-4-UDLD_PORT_DISABLED: UDLD disabled interface Gi1/0/19, unidirectional link detected
000996: Mar 8 10:17:52.412 GMT: %PM-4-ERR_DISABLE: udld error detected on Gi1/0/19, putting Gi1/0/19 in err-disable state
000997: Mar 8 10:17:53.519 GMT: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/19, changed state to down
000998: Mar 8 10:17:54.526 GMT: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/19, changed state to down
000999: Mar 8 10:18:19.742 GMT: %PM-4-ERR_RECOVER: Attempting to recover from udld err-disable state on Gi1/0/19
001000: Mar 8 10:18:23.173 GMT: %SPANTREE-5-TOPOTRAP: Topology Change Trap for vlan 21
001001: Mar 8 10:18:24.138 GMT: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/19, changed state to up
001002: Mar 8 10:18:25.144 GMT: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/19, changed state to up

So, it is supposed that "udld enable" dont shutdown the port but... according to the log it put the port in err-disabled!

Platform: 3750G

IOS: 12.2(35)SE5

Any idea?

The CCIE book we have here tells us that both modes can shutdown a port, which is not clear for according to the online web pages from cisco and the lan switching fundamentals book.

jorge.calvo · ‎08-09-2010

Hello,

I faced the same problem today in an interface with the same configuration as yours that has been running fine for years but suddendly that err-disable message due to UDLD appeared.

The solution I did was setting the port speed to AUTO with the "no speed" command. This solved the problem.

Hope this helps.

lmcruzhsa · ‎08-09-2010

Estaré fuera de la oficina hasta el 10/8/2010, en el intervalo puede contactar con Juan Carlos Martin (jcmartin@hispasat.es).

Si tiene alguna incidencia con el servicio pongase en contacto a traves del telefono + 34 902 34 44 00 (opción 3)

I wil be out of the office until 10/8/2010, in the meantime, if you need support you can contact Juan Carlos Martin (jcmartin@hispasat.es)

If you have an issue with a service you should call the phone +34 902 34 44 00 (option 3)

>>> "jorge.calvo" 9/8/2010 11:53 >>>

luis cruz,

A new message was posted in the Discussion thread "UDLD Enable and UDLD Aggressive - What is the difference?":

https://supportforums.cisco.com/message/3152740#3152740

Author : jorge.calvo

Profile : https://supportforums.cisco.com/people/jorge.calvo

Message:

RedNectar · ‎01-18-2012

On reading

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/udld.html (Quote 1) and

http://tools.ietf.org/html/rfc5171 (Quote 2), it would seem that your solution 'setting the port speed to AUTO with the "no speed" command.' was the correct approach.

Quote 1:

When you enable both autonegotiation and UDLD, Layer 1 and Layer 2 detections work together to prevent physical and logical unidirectional connections and the malfunctioning of other protocols.

Qoute 2:

   UDLD is meant to be a Layer 2 detection protocol that works on top of
   the existing Layer 1 detection mechanisms defined by the IEEE
   standards.

RedNectar aka Chris Welsh.
Forum Tips: 1. Paste images inline - don't attach. 2. Always mark helpful and correct answers, it helps others find what they need.

jimmysands73_2 · ‎01-18-2012

You can always simulate it....disconnect one, and only one, fiber connect (say you have ST or SC), disconnected one led.

Of if its smaller, like LC, you can cut the cable so only one input is working (vs both).

brianforget · ‎12-13-2016

This is an old one, but just to update it because it is the top google hit for this topic:

Both normal "enable" and "aggressive" modes of UDLD will shut a port when configured on that port. But "aggressive" mode will try 8 times (once per second) to bring the port back up before sending it to error disable.

Source:
http://www.cisco.com/c/en/us/td/docs/routers/7600/ios/15S/configuration/guide/7600_15_0s_book/udld.html

As a side note, Copper ports shouldn't be effected by the global UDLD configuration. They would need per port config to enable the feature.

Second side note: "Why enable UDLD on a copper port?" Well sometimes you've got some protocol running on those ports that you want to ensure takes the right path, but for whatever reason spanning tree doesn't seem like the way to go, like you're routing on that link, or maybe you're stuck on old/ slow STP. UDLD can detect that a link is not communicating in both directions and bring that port down for you in a timely manner.

Hope this helps :-D

bkattan · ‎09-07-2017

According to: https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-2/54sg/configuration/guide/config/udld.html

Another distinction is that Normal mode will only block one port, whereas aggressive mode wil block both ports forming the unidirectional link.

Peter Paluch · ‎09-08-2017

Hi all,

Indeed, this topic is confusing.

One of the key points to understand is that UDLD performs a series of checks, not just a single one. These checks are:

Unidirectional connectivity. A switch receiving UDLD packets received from a neighbor must see its own switch and port identifiers in the ECHO part of the UDLD packet. If the UDLD packets are arriving, but the receiving switch cannot find its own switch and port IDs in the ECHO part, UDLD will declare a unidirectional link error, and the port will be err-disabled. This also includes the special case when the UDLD packets received from the neighbor have the ECHO part entirely empty.
Tx/Rx loop. If a switch receives back its own UDLD packets, meaning that the sender switch and port ID match the IDs of the switch that receives the UDLD packet, UDLD will declare a Tx/Rx loop, and the port will be err-disabled.
Neighbor mismatch. If a switch detects only a single UDLD neighbor on a port, but the neighbor's UDLD packets contain multiple neighbor entries in their ECHO section, it identifies a state of partial visibility on a shared segment, as the receiving switch can only see a subset of all switches on the segment. In this case, UDLD will declare a neighbor mismatch, and will err-disable a port.

These three checks are performed in both normal and aggressive UDLD mode, and should any of these checks fail, UDLD will err-disable the port unconditionally - yes, even in UDLD normal mode.

The aggressive UDLD mode adds a single additional check: If UDLD packets from a former bidirectional neighbor suddenly stop being received altogether, UDLD aggressive will declare the link as unidirectional and will err-disable the port. UDLD normal mode would simply expire that neighbor and do nothing.

The bottom line is: Both normal and aggressive UDLD perform the three explicit checks as listed above, and err-disable the port if any of those checks fail. In addition, aggressive UDLD mode also err-disables the port if UDLD packets from a former bidirectional UDLD neighbor stop being received without the link going down. The difference between normal and aggressive UDLD modes is only in the reaction to the sudden loss of received UDLD packets from a bidirectional neighbor.

Best regards,
Peter

Apostolos · ‎01-23-2018

According to official certification guide for 300-115 exam (CCNP switch) 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 reestablish 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 hope you find this info helpful.

Peter Paluch · ‎01-23-2018

Hi Apostolos,

Thank you for sharing that info!

The CCNP OCG you have mentioned is not wrong - but it does not cover the whole truth. I have tried to describe all the tests UDLD performs in my previous post in this thread. UDLD is a sadly underdocumented protocol, and information about it is often imprecise or incomplete. Hopefully, the information I've shared earlier helps to clarify some of the doubts.

Best regards,
Peter