UDLD Problem

[kalzigitovadil]

Hello , can someone help me with my problem,  I have 9500 switches with udld aggressive on each interface , but i have some issues when i try to test it. If i disconnect one of the fiber optic ( TX or RX) interface just go down(not connected) , but it should be err-disabled by UDLD . 

[kalzigitovadil]

good day sir, @Peter Paluch . Could you please help me with my issue.

[Georg Pauwen]

Hello,

I think simply disconnecting the interface does not actually trigger UDLD. I remember there was a way to simulate this (short of physically breaking a strand of the cable), I think you had to apply a MAC access list to a layer 2 interface, as described in the post below:

https://community.infosecinstitute.com/discussion/35572/udld-simulation

[MHM Cisco World]

what mode you run UDLD ?
there are two mode 
Understand and Configure the UDLD Protocol Feature - Cisco

check this link 
UDLD Modes of Operation | INE

[kalzigitovadil]

Aggressive mode 

[kalzigitovadil]

-------------------------Core switch
#show udld

Interface Twe1/0/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: 15000 ms
Time out interval: 5000 ms

Port fast-hello configuration setting: Disabled
Port fast-hello interval: 0 ms
Port fast-hello operational state: Disabled
Neighbor fast-hello configuration setting: Disabled
Neighbor fast-hello interval: Unknown

Entry 1
---
Expiration time: 36900 ms
Cache Device index: 1
Current neighbor state: Bidirectional
Device ID: 98A2C02D2080
Port ID: Gi1/1/1
Neighbor echo 1 device: 5C31924BD0
Neighbor echo 1 port: Twe1/0/1

TLV Message interval: 15 sec
No TLV fast-hello interval
TLV Time out interval: 5

-------------------------------Access switch

Interface Gi1/1/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: 15000 ms
Time out interval: 5000 ms

Port fast-hello configuration setting: Disabled
Port fast-hello interval: 0 ms
Port fast-hello operational state: Disabled
Neighbor fast-hello configuration setting: Enabled
Neighbor fast-hello interval: 200 ms

Entry 1
---
Expiration time: 37100 ms
Cache Device index: 1
Current neighbor state: Bidirectional
Device ID: 5C31924BD0
Port ID: Twe1/0/1
Neighbor echo 1 device: 8F3FB5EC980
Neighbor echo 1 port: Gi1/1/1

TLV Message interval: 15 sec
TLV fast-hello interval: 200 ms
TLV Time out interval: 5

[MHM Cisco World]

Neighbor fast-hello configuration setting: Enabled <<- try disable the fast-hello 

and I will more check the whole config again 

[fatimaibtesam90]

If both fiber strands in a cable are working normally from a Layer 1 perspective, UDLD in aggressive mode determines whether those fiber strands are connected correctly and whether traffic is flowing bidirectional between the correct neighbors. This check cannot be performed by auto negotiation because auto negotiation operates at Layer 1.

further if you are interested in doing gym work & like weightlifting , so i found very comfortable & cool weightlifting straps, you can check it here.

[Peter Paluch · Accepted solution]

Hello @kalzigitovadil ,

I agree with @Georg Pauwen - with today's fiber optics interfaces, UDLD won't react to you pulling the Rx or Tx fiber even if you use aggressive mode. Here's why.

The aggressive mode in UDLD is designed to handle the rather special situation when the A->B fiber between two neighbors, A and B, gets damaged in a way that makes it impossible to pass data from A to B - but A still keeps its port up. With today's optic interfaces, this is practically impossible to emulate by pulling the A->B fiber: As soon as B detects the loss of light from A, it informs A over the B->A fiber about the fault condition; there are mechanisms such as FEFI (Far End Fault Indication) for that. As a result, both A and B bring down their interfaces and there's nothing for UDLD to do more here.

Aggressive mode in UDLD reacts to the situation when the interface stays up but the UDLD messages stop arriving from the neighbor. Rather than just expiring the information about the neighbor (which is what normal mode would do in this case), the aggressive mode will err-disable the interface. However, the condition is that the interface stays up long enough for the neighbor to expire.

As Georg mentioned, you can only test this by using a MAC ACL on one of the neighbors to temporarily block the incoming UDLD messages. It won't be possible to test the UDLD by pulling one fiber because that will bring both interconnected interfaces down anyway.

Best regards,
Peter

[kalzigitovadil]

Thanks for your response , but i have tested UDLD by using MAC ACL on one of devices. But interfaces still working fine , and dont go to err-disable state.

mac access-list extended uruk
deny any host 0100.0ccc.cccc
permit any any
mac access-group uruk in

[kalzigitovadil]

Could you please suggest another solutions to simulate UDLD

[Georg Pauwen]

Hello,

odd. Is the interface you have applied this MAC ACL on a layer 2 interface ?

[Peter Paluch]

Hi @kalzigitovadil ,

For the sake of simplicity, just let's create a MAC ACL that denies everything, and let's see if that one does the trick. So something like this:

mac access-list extended uruk
 deny any any
!
interface ...
 mac access-group uruk in

Sure, it will break many protocols, but my hope is that it'll cause UDLD to act. Also, you will need to wait for up to one minute or so after applying the MAC ACL to the interface for UDLD to kick in.

[kalzigitovadil]

Thank you very much, I found the solution I :

mac access-list extended uruk
 deny any any
!
interface ...
 mac access-group uruk out

[MHM Cisco World]

the mac access-list support only IN direction not OUT. 

I check your case 
can you check log, I think the UDLD is work, you can confirm that the UDLD put the port into err-disable and then the SW put the to down state, can you confirm that?

what I think is 0100.0ccc.cccc is mac use by many protocol I think one of them is shutdown the port not UDLD