Understanding UDLD

thorsten.steffen · ‎07-06-2007

Hi,

to prevent stp loops in our cisco network I am evaluating udld.

I already read the two documents "Understanding and Configuring UDLD" (http://cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a008009477b.shtml) and "Configuring UDLD" (http://cisco.com/en/US/customer/products/hw/switches/ps708/products_configuration_guide_chapter09186a0080160a5d.html).

I took two Cat3560G with IOS 12.2(25)SEE3 and did some tests.

Now I have several questions concerning UDLD, it would be fine if somebody could help me.

1. If I use the "normal" mode udld recognizes an unidirectional link but the switchport still changes from blocking to forwarding when it stops receiving bpdus. So there is still a stp loop created, is this correct? If yes, what is the gain of using the normal mode?

Only using agressive mode deactivated the switchport after 8s trying to reestablish the udld connection after the timeout.

2. When I used errordisable recovery in agressive mode, after 30s the port went up again. udld again tried 8s to reestablish the udld connection but timed out because the link was still unidirectional. After the timeout the port went up and in stp forwarding mode which formed a stp loop, is this behaviour correct?

3. I use RSTP on the two switches. If there is a blocking port which stops receiving bpdus because of a unidirectional link failure, it takes ca. 36s until this port changes to forwarding state (6s "maxage" + 15s "listening" + 15s learning). With default timers of udld (interval 15s, timeout 45s) it takes 53s (45s + 8s agressive mode) to deactivate the port. So for the duration of ca. 17s there would be a stp loop. Does anybody know if there is a recommendation which udld message interval to use with rstp?

4. How do udld packets be sent?

Does any switch send the packets independently or is every sent packet an answer to a received packet? Must the message intervals of the both switches be equal? Do both switches need to use the same mode (normal/aggressive)?

5. The output of the "show udld <interface>"-command looked like

Interface Gi0/1

---

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: 7

Time out interval: 5

Entry 1

---

Expiration time: 25

Device ID: 1

Current neighbor state: Bidirectional

Device name: FOC1118Z2PX

Port ID: Gi0/1

Neighbor echo 1 device: FOC1118Z2N8

Neighbor echo 1 port: Gi0/1

Message interval: 10

Time out interval: 5

CDP Device name: switch-1

Does anybody know what the "Time out interval: 5" is standig for?

If you need further information, please give me a short feedback.

Many thanks in advance,

Thorsten

vishwancc · ‎07-08-2007

Hey Thorsten,

1.When UDLD was released initially,its main aim was to tell that the network is facing problem because of the unidirectional link.

But in normal mode since there is nothing done to stop this the Aggrisive mode came into picture,which shut down the port.

2.Here i am not sure but what i will say is UDLD was developed to detect the unidirectional link and with aggressive we set the time so that the port autorecover,there is always that risk and that is why you should take care when you set this feature.

3.Well i am not sure here because ideally the total time should be 20+15+15 (maxage+lis+learn)since in ideal situation the max age time should always be greter then the listening and learning.

I am not sure if i get the question right.

4.The packet are send on per port basis,which could be both the reply as well as checking the link.Well the message interval

as far as i think it will not make any difference,since the UDLD message are send independently of the other switch,the switch which send the UDLD echo

request wait for the echo reply for that time.Again mode will also not make any difference since it is also port based.

thorsten.steffen · ‎07-19-2007

Hello Vishwa,

thank you for the answer and sorry for the delay.

Meanwhile I did some more tests and I found out that also after manual recovery of an errordisabled port via shut/no shut udld does not work if the link is still unidirectional.

So I wonder how I should use udld recovery in practise:

If udld errordisables a port because of some error first I would do some troubleshooting (e.g. changing cables).

Then I would test by re-enabling the switchport. But after re-enabling udld wouldn't work if the link is still unidirectional and so stp would go to forwarding and creating a loop.

Is there any recommendation how to test if the link works fine before putting it back online in normal switching work.

Best Regards,

Thorsten

nkhwaja · ‎07-20-2007

Port errdisables, you change cables and renable the port. UDLD kicks in again to check if the port is unidirectional. If its still so, port will errdisable again.

thorsten.steffen · ‎07-23-2007

Hi Nusrat,

what you say is what I expected but my practical tests showed a different result:

I tested that on two 3560G with IOS Version 12.2(25)SEE3(c3560-ipservices-mz.122-25.SEE3.bin) which were connected to each other with two links:

- One normal fiber link

- One normal copper cable (capable to simulate a unidirectional link)

The copper port correctly went to stp blocking on one switch to prevent forming a loop.

After connecting the switches the copper link went up and udld packets were exchanged and an udld neighborship formed. Then I changed the link to unidirectional. Both switched detected that because of missing incoming udld packets and consequently errdisabled the port -> errdisabling = shutdown = no link.

After that I just reenabled the two ports via shut / no shut. The link went up, the udld status of both ports to "undetermined" and the stp status to forwarding -> which formed now a loop!

In some cisco documents concerning udld I read that udld only works after establishing a correct udld neighborship. In the above case after the ports were errdisabled and the link went down, from the switches point of view the link was considered disconnected. And after reenabling the ports they tried to establish a new udld neighborship which was not possible and so udld did not start working because there "never" hat been an established udld neighborship since the link went up.

I hope I described the problem in an understandable way.

vishwancc · ‎07-22-2007

hi Thorsen,

Wellthat is how UDLD is supposed to work,if the link is unidirectionl the port should be disabled,since it will not we receiving echo replies,

And when u say that loop is there because the link is unidirectionl,if UDLD is configured the link will not come up and so STP

loop will not form,have you tried the step and found STP loop in this case ?

If possible try for your network loop guard along with UDLD,

UDLD provide no protection againgt software failure due to which the designated switch not send BPDU,but loop guard provide the

protection,there are some other difference,i will suggest to use both feature to be safe.

check this link

http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a0080094640.shtml

thorsten.steffen · ‎07-23-2007

Hello Vishwa,

also see my above new posting.

UDLD correctly errdisabled the switchports.

But after shut/no shut udld did not recognize that the link was still unidirectional and went to "undetermined" state, and the link went to up!

This formed a loop because the bpdus weren't received on one side and so both sides went to stp forwarding.