Jump to content
Sadikhov IT Certification forums
Sign in to follow this  
Darby Weaver

UDLD versus UDLD Aggressive by Darby Weaver

Recommended Posts

Let me point something out... very imprtant detail:

 

 

I've done these tests and observations on a trunk port, not a point-to-point interface....

 

Careful what you read lest you be told and think you udnerstand by rumor - a bad thing.

 

See why you have to test yourself yet?

Share this post


Link to post
Share on other sites

Sw3(config)#do sh int f0/24 | i Full

Full-duplex, 100Mb/s, media type is 10/100BaseTX

Sw3(config)#

 

Sw4(config)#do sh int f0/24 | i Full

Full-duplex, 100Mb/s, media type is 10/100BaseTX

Sw4(config)#

Share this post


Link to post
Share on other sites

Sw4(config)#do sh udld f0/24

 

Interface Fa0/24

---

Port enable administrative configuration setting: Disabled

Port enable operational state: Disabled

Current bidirectional state: Unknown

Sw4(config)#int f0/24

Sw4(config-if)#udld port agg

Sw4(config-if)#

TS4#9

[Resuming connection 9 to s3 ... ]

 

Sw3(config)#int f0/24

Sw3(config-if)#udld port aggr

Sw3(config-if)#do sh udld f0/24

 

Interface Fa0/24

---

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

Cache Device index: 1

Current neighbor state: Bidirectional

Device ID: CAT0709X0U6

Port ID: Fa0/24

Neighbor echo 1 device: CAT0738X1S8

Neighbor echo 1 port: Fa0/24

 

Message interval: 15

Time out interval: 5

CDP Device name: Sw4

Sw3(config-if)#

Share this post


Link to post
Share on other sites

Sw3(config-if)#

2d15h: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/24, changed state to down

Sw3(config-if)#

2d15h: %LINK-3-UPDOWN: Interface FastEthernet0/24, changed state to down

Sw3(config-if)# do sh int f0/24 | i Fast

FastEthernet0/24 is down, line protocol is down (notconnect)

Hardware is Fast Ethernet, address is 000d.ed2f.e598 (bia 000d.ed2f.e598)

Sw3(config-if)#

 

Sw3(config-if)#do sh run int f0/24

Building configuration...

 

Current configuration : 91 bytes

!

interface FastEthernet0/24

switchport mode dynamic desirable

udld port aggressive

end

 

Sw3(config-if)#

TS4#10

[Resuming connection 10 to s4 ... ]

 

*Mar

Sw4(config-if)#do sh run int f0/24

Building configuration...

 

Current configuration : 91 bytes

!

interface FastEthernet0/24

switchport mode dynamic desirable

udld port aggressive

end

 

Sw4(config-if)#

Share this post


Link to post
Share on other sites

Before everyone gets all worked up... we just verified that UDLD will not Err-Disable a "dis-connected" port. However, disconnect and "mis-connected" are two different words with two different meanings...

 

So we must "interpret" them as such.

 

Here's what the UDLD Overview has to say:

 

Understanding UDLD

UDLD is a Layer 2 protocol that enables devices connected through fiber-optic or twisted-pair Ethernet cables to monitor the physical configuration of the cables and detect when a unidirectional link exists. All connected devices must support UDLD for the protocol to successfully identify and disable unidirectional links. When UDLD detects a unidirectional link, it administratively shuts down the affected port and alerts you. Unidirectional links can cause a variety of problems, including spanning-tree topology loops.

 

Modes of Operation

UDLD supports two modes of operation: normal (the default) and aggressive. In normal mode, UDLD can detect unidirectional links due to misconnected interfaces on fiber-optic connections. In aggressive mode, UDLD can also detect unidirectional links due to one-way traffic on fiber-optic and twisted-pair links and to misconnected interfaces on fiber-optic links.

 

In normal and aggressive modes, UDLD works with the Layer 1 mechanisms to determine the physical status of a link. At Layer 1, autonegotiation takes care of physical signaling and fault detection. UDLD performs tasks that autonegotiation cannot perform, such as detecting the identities of neighbors and shutting down misconnected interfaces. When you enable both autonegotiation and UDLD, the Layer 1 and Layer 2 detections work together to prevent physical and logical unidirectional connections and the malfunctioning of other protocols.

 

A unidirectional link occurs whenever traffic sent by a local device is received by its neighbor but traffic from the neighbor is not received by the local device.

 

In normal mode, UDLD detects a unidirectional link when fiber strands in a fiber-optic interface are misconnected and the Layer 1 mechanisms do not detect this misconnection. If the interfaces are connected correctly but the traffic is one way, UDLD does not detect the unidirectional link because the Layer 1 mechanism, which is supposed to detect this condition, does not do so. In case, the logical link is considered undetermined, and UDLD does not disable the interface.

 

When UDLD is in normal mode, if one of the fiber strands in a pair is disconnected and autonegotiation is active, the link does not stay up because the Layer 1 mechanisms did not detect a physical problem with the link. In this case, UDLD does not take any action, and the logical link is considered undetermined.

 

In aggressive mode, UDLD detects a unidirectional link by using the previous detection methods. UDLD in aggressive mode can also detect a unidirectional link on a point-to-point link on which no failure between the two devices is allowed. It can also detect a unidirectional link when one of these problems exists:

 

•On fiber-optic or twisted-pair links, one of the interfaces cannot send or receive traffic.

 

•On fiber-optic or twisted-pair links, one of the interfaces is down while the other is up.

 

•One of the fiber strands in the cable is disconnected.

 

In these cases, UDLD shuts down the affected interface.

 

In a point-to-point link, UDLD hello packets can be considered as a heart beat whose presence guarantees the health of the link. Conversely, the loss of the heart beat means that the link must be shut down if it is not possible to re-establish a bidirectional link.

 

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 bidirectionally between the correct neighbors. This check cannot be performed by autonegotiation because autonegotiation operates at Layer 1.

Share this post


Link to post
Share on other sites

Now if you are me... and I am me... this means I am going to install some GBICs in my 3550's and I am going to proceed to test UDLD again.

 

This time over my fiber-optic links - Gi0/1 and/or Gi0/2.

 

See the difference.

 

It looked like UDLD was enabled before everything started so we'll test this 100% too.

 

We'll also try to invoke a spanning-tree loop and demonstrate why loopguard is helpful.

Share this post


Link to post
Share on other sites

darby

you'll pretty much need 4 gbics (3 as absolute minimum) and simplex cables. than hook it up tx1 -> rx2, tx2 -> rx3, tx3 -> rx1. only than you'll see it work

Share this post


Link to post
Share on other sites

How about using a hub in the middle of any two switches?

 

- The concept being that each switch connected to the hub itself would have a direct L1 connection and when one link to the hub is disconnected, then and only then would the other Ethernet physically connected side notice a fault condition (Layer 1) that would Err-Disable the interface in question.

 

 

Why 4 switches? The UDLD is configured between two physically adjacent switches?

 

Curious not judgemental.

 

 

Another idea would be to use an RJ-45 cable and disable one side (either rx or tx) to inject the error condition at Layer and induce the fault.

 

I'm prepared for the GBICs and the Simplex Fiber Cables and I have a 100MB hub still laying around from the very old days (10+ years ago) to work with for my next round of testing before putting this one to rest.

Share this post


Link to post
Share on other sites

Chrcel,

 

I think you mean to say I'd need to have 2 GBICs with Duplex Fiber SC connected in a cross-over fashion - I've used this in production and I have the pieces available in my lab to create this scenario. I also have SC to ST and I have the ST couplings to cross-connect those cables and to more easily induce the same fault that we are talking about.

 

Simplex would be a single cable and would be as difficult as ethernet to induce the fault I'm seeking.

 

I used to work in a rather large fully fiber network - quite the spiderweb of fiber.

 

 

 

 

Simplex fiber is a single fiber available in single mode, multimode, or polarization maintaining.

 

Duplex fibers consist of two fibers, either single mode or multimode, and are used in applications where data needs to be transferred bi-directionally. One fiber transmits data one direction; the other fiber transmits data in the opposite direction.

Share this post


Link to post
Share on other sites

Darby,

I really meant simplex. The "problem" with duplex cables is that you always have your rx/tx pair and this is something you do not want for UDLD test. Because when you unplug on fiber strand you loose the link on one or the other end of the link and line protocol would go down immediately. the ST/ST couplings will work nicely. I would be really curious about the hub scenario.

Another way to test udld might be optical switch something like ONS switch.

Share this post


Link to post
Share on other sites

I know.

 

I lack the ONS Switch. Maybe I get my cable names mixed up but if I use multimode (orange cables - usually not always) and SC/SC or SC/ST<->SC/ST then I can unplug either rx or tx. I think of simplex as a single-mode fiber cabling and duplex such as this:

 

http://cgi.ebay.com/Dual-ST-SC-Duplex-Multi-Mode-MM-fiber-optic-cable-1M-/180684845762?pt=LH_DefaultDomain_0&hash=item2a11a7f2c2

 

So if I remove one leg of the fiber, I'll have induced a layer 1 fault.

 

I was pretty busy today and tonight so no time to test yet thoroughly.

 

It's 2am my time and I'm knocking out something else at the moment.

 

Perhaps tomorrow will leave me some time to complete this theme.

 

I'll test the hub too - I want to see the RF-45 actually fail at just layer 1.

 

 

 

 

UDLD is off by default for Copper interfaces and on by default for fiber settings as my findings above showed.

 

 

These tests are probably nearly impossible to test on a virtual switch so I'd hope someone finds this level of scrutiny and curiosity worthwhile.

Share this post


Link to post
Share on other sites

ah okay that explain is. by simplex I meant not full duplex. Still interested how you end up with it. The most interesting would be the test with hub.

Share this post


Link to post
Share on other sites

Agreed. Per my research the hub should allow me to test Copper Ethernet and UDLD - hard to test otherwise. My theory is that one link will stay lit and the other will not so this may Err-Disable the interface (one or both?).

 

It'll be fun.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

×