01-18-2023 03:30 AM
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 .
Solved! Go to Solution.
01-19-2023 12:10 AM
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
01-18-2023 03:32 AM
good day sir, @Peter Paluch . Could you please help me with my issue.
01-18-2023 03:58 AM
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
01-18-2023 04:41 AM - edited 01-18-2023 04:42 AM
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
01-18-2023 06:53 AM
Aggressive mode
01-18-2023 04:46 AM - edited 01-18-2023 04:47 AM
-------------------------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
01-18-2023 04:37 PM
Neighbor fast-hello configuration setting: Enabled <<- try disable the fast-hello
and I will more check the whole config again
01-18-2023 05:37 PM
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.
01-19-2023 12:10 AM
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
01-19-2023 02:10 AM
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
01-19-2023 02:11 AM
Could you please suggest another solutions to simulate UDLD
01-19-2023 03:04 AM
Hello,
odd. Is the interface you have applied this MAC ACL on a layer 2 interface ?
01-19-2023 03:13 AM - edited 01-19-2023 03:24 AM
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.
01-19-2023 05:05 AM
Thank you very much, I found the solution I :
mac access-list extended uruk
deny any any
!
interface ...
mac access-group uruk out
01-19-2023 05:10 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide