udld config

[anitachoi3]

Hi all,

Below please find the related configuration of udld and some fibre interfaces for your reference. Grateful if anyone would advice on the following questions as below:

1. the udld is configrated as "aggressive", this setting is covered the port channel between both 4509s. what happen for the TG2/5 and TG 2/6?

2. do I config the "udld enable" under all interfaces with fibre connections? if so, the switch behavoir is in "aggressive" mode or in "normal" mode? for what situation, I need to config "udld enable" on fibre interfaces?

3. I check with other document, udld would bring down both interfaces of port channel if one of them is malfunction (or cable disconnect). It is not my expectation. Any work around to keep the port channel to be working normal even through one of port is trigger udld?

! Primay 4509

!

spanning-tree mode rapid-pvst

!

udld aggressive

!

interface Port-channel 30

Description inter-connect with second 4509 switch on 23/F data center

switchport

switchport trunk

switchport mode trunk

!

interface TenGigabitEthernet1/1

description, connect to 1st 10G port of sup6E  of secondary 4509 (UTP)

switchport trunk

switchport mode trunk

channel-group 30 mode active

!

interface TenGigabitEthernet1/2

description, connect to 2nd 10G port of sup6E  secondary 4509 (UTP)

switchport trunk

switchport mode trunk

channel-group 30 mode active

!

interface TenGigabitEthernet2/5

description connected to 8/F, sale department

switchport trunk

switchport mode trunk

!

interface TenGigabitEthernet2/6

description connected to 5/F, HQ

switchport trunk

switchport mode trunk

!

!seconday 4509

!

spanning-tree mode rapid-pvst

!

udld aggressive

!

interface Port-channel 30

Description inter-connect with primary 4509 switch on 23/F data center

switchport

switchport trunk

switchport mode trunk

!

interface TenGigabitEthernet1/1

description, connect to 1st 10G port of sup6E  of primary 4509 (UTP)

switchport trunk

switchport mode trunk

channel-group 30 mode active

!

interface TenGigabitEthernet1/2

description, connect to 2nd 10G port of sup6E  of primary 4509 (UTP)

switchport trunk

switchport mode trunk

channel-group 30 mode active

!

interface TenGigabitEthernet2/5

description connected to 8/F, sale department

switchport trunk

switchport mode trunk

!

interface TenGigabitEthernet2/6

description connected to 5/F, HQ

switchport trunk

switchport mode trunk

!

rdgs

Anita

[manju.cisco]

Hi,

You need to configure udld directly on the physical interface , i.e. not on the port channel........

And also keep the global udld mode to enable instead of aggresive., and then we shall configure specific physical interfaces for udld aggressiev mode.

!

udld enable

!

int Tengig x/x

udld port aggressive

!

When you configure udld aggressive on physical interfaces, those interfaces which detects uni-direction signal makes only that specific physical interface to go into error disable state and so the port-channel will not go down & port channel will remain up if other interfaces in the portchannel are up and functioning..

---------------

In your configs case it will be as below:

! Primay 4509

!

spanning-tree mode rapid-pvst

!

udld enable

!

interface Port-channel 30  !!!! DO NOT CONFIGURE UDLD ON PORT CHANNEL

Description inter-connect with second 4509 switch on 23/F data center

switchport

switchport trunk

switchport mode trunk

!

interface TenGigabitEthernet1/1

description, connect to 1st 10G port of sup6E  of secondary 4509 (UTP)

switchport trunk

switchport mode trunk

udld port aggressive

channel-group 30 mode active

!

interface TenGigabitEthernet1/2

description, connect to 2nd 10G port of sup6E  secondary 4509 (UTP)

switchport trunk

switchport mode trunk

udld port aggressive
channel-group 30 mode active

!

interface TenGigabitEthernet2/5

description connected to 8/F, sale department

switchport trunk

switchport mode trunk

udld port aggressive
!

interface TenGigabitEthernet2/6

description connected to 5/F, HQ

switchport trunk

switchport mode trunk

udld port aggressive
!

!seconday 4509

!

spanning-tree mode rapid-pvst

!

udld enable

!

interface Port-channel 30

Description inter-connect with primary 4509 switch on 23/F data center

switchport

switchport trunk

switchport mode trunk

!

interface TenGigabitEthernet1/1

description, connect to 1st 10G port of sup6E  of primary 4509 (UTP)

switchport trunk

switchport mode trunk

udld port aggressive
channel-group 30 mode active

!

interface TenGigabitEthernet1/2

description, connect to 2nd 10G port of sup6E  of primary 4509 (UTP)

switchport trunk

switchport mode trunk

udld port aggressive
channel-group 30 mode active

!

interface TenGigabitEthernet2/5

description connected to 8/F, sale department

switchport trunk

switchport mode trunk

udld port aggressive
!

interface TenGigabitEthernet2/6

description connected to 5/F, HQ

switchport trunk

switchport mode trunk

udld port aggressive
!

[Peter Paluch]

Hello Manju,

And also keep the global udld mode to enable instead of aggresive

I believe this recommendation does not make much sense. Configuring UDLD globally will start the UDLD only on fiber ports. Configuring UDLD directly on a port allows you to start it both on fiber and metallic ports. In addition, configuring the UDLD directly on a port overrides the global UDLD setting for that port. Therefore, if you suggest configuring the UDLD on a per-port basis, I see no reason to also configure it in global configuration (and even in a different operation mode).

Best regards,

Peter

[anitachoi3]

Dear Peter,

Thanks for your comments. If the global setting is configured on udld, it does not need to config udld on each interfaces.

So, do I config "enable" for udld in global setting for both 4509s and the port channel to be treated as two individual ports to achieve the requirement?

If so, what benefit of "aggressive" of udld could not be obtained from it after the "enable" is replaced in the gloabl setting? I check with cisco web site but I cannot apprehend the different of them.

Furthermore, is it the normal approach to config udld on the inter-connect with two 4509s in the same rack?

rdgs

Anita

[Peter Paluch · Accepted solution]

Hi Anita,

Thanks for your comments. If the global setting is configured on udld, it does not need to config udld on each interfaces. 

True if your interfaces to be protected are fiber interfaces. Configuring UDLD globally does not run UDLD on copper interfaces.

So, do I config "enable" for udld in global setting for both 4509s and  the port channel to be treated as two individual ports to achieve the  requirement?

No, you do not enable it on the Port-channel interface itself. The UDLD commands are not even available on Port-channel interfaces. You can either configure it globally, and it will automatically run on all fiber interfaces, both those which are under some Port-channel interfaces and those which are running individually, or you activate it on a per-port basis and do not care for globally configuring it.

UDLD is always activated only on physical interfaces, never on Port-channel interfaces.

If so, what benefit of "aggressive" of udld could not be obtained from  it after the "enable" is replaced in the gloabl setting? I check with  cisco web site but I cannot apprehend the different of them.

The aggreesive mode was created primarily for those fiber interfaces which had not the ability to detect a unidirectional link condition. Assume that the Tx fiber from you to your neighbor breaks. The neighbor does not hear you anymore, however, you still hear it. The question is, how shall the neighbor tell you using Layer1 means that it lost contact with you?

Some fiber interfaces did not have this ability. Later, a technique called Far End Fault Indication (FEFI) came to 100 Mbps fiber Ethernets that actually allowed this kind of detection. Its idea is based on the fact that if two fiber interfaces do not have any frames to send to each other, they continually exchange so-called IDLE symbols to keep their synchronization. If the far end detects a loss of signal, it changes the IDLE symbol to a different symbol signifying this event. The local end then understand that this is a unidirectinal condition, and will bring down the port.

There is the difference between the normal and aggressive UDLD mode. The normal mode relies on the Layer1 capabilities to detect and deactivate unidirectional links. The UDLD here primarily verifies if there is no split fiber (the Tx fiber going to a different device than the Rx fiber). If the optical interfaces do not support FEFI or similar mechanisms, the UDLD aggressive mechanism is appropriate: after a loss of a certain count of UDLD messages from the other party (as a result of broken fiber), UDLD will err-disable the port.

Most optical interfaces should actually be able to perform FEFI or similar type of unidirectional link discovery, thus, the normal UDLD mode should be safe on them. On the other hand, the aggressive mode is a safe bet. Therefore, I would personally go with aggressive mode on all interfaces.

Furthermore, is it the normal approach to config udld on the inter-connect with two 4509s in the same rack? 

Same rack or not - the fiber can still get damaged or misconnected. I would activate the UDLD regardless of whether the fiber is 1m or 100km long.

Best regards,

Peter

[manju.cisco]

Hi Peter

What you have pointed is valid....but i had another view with respect to udld on port channel which has fiber ports if udld is enabled globally.....

Assuming we have "udld aggressive" configured in global mode, then the port channel goes down if any one of the bundled interface goes error-disabled due to unidirectional link., as the configs was having "udld aggressive' mode, i just thought to make it to enable instead of aggressive. Though without using it also would be fine as you pointed...

[Peter Paluch]

Manju,

Assuming we have "udld aggressive" configured in global mode, then the  port channel goes down if any one of the bundled interface goes  error-disabled due to unidirectional link.

Hmmm, I do not recall seeing such a behavior. Are you absolutely sure about this? That would make the UDLD protection of EtherChannel ports pretty unusable...

An err-disabled state of a physical member port of an EtherChannel should not propagate up to the Port-channel interface itself, regardless of the normal/aggresive UDLD mode and regardless where/how is the UDLD enabled. The normal/aggressive modes differ in their approach to the loss of UDLD messages from the other side - the normal mode leaves the port in an undetermined state and lets the Layer1 detect the unidirectional link while the aggressive mode reacts with err-disabling such port without relying on the Layer1 capabilities to detect an unidirectional link.

In particular, the normal/aggressive modes do not say that the entire Port-channel should be disabled.

Do you have a different experience? If so, I will have to lab it up tomorrow

Best regards,

Peter

[manju.cisco]

Hi again Peter

what i wrote was what i had read in some forum some months back, i have never experienced it or had tested it.

I would be greatefull if you can set up that (like the one that day you setup for bpdu guards received on edged ports(port-fast)), i have no lab here to set it up

Thanks Peter

[Peter Paluch]

Manju,

You owe me a beer for labbing this up

Alright: two C3560 connected via Fa0/1-2, bundled in LACP EtherChannel.

Sw1:

hostname Sw1
!
udld aggressive
!
interface Port-channel1
 switchport trunk encapsulation dot1q
 switchport mode trunk
!
interface FastEthernet0/1
 switchport trunk encapsulation dot1q
 switchport mode trunk
 udld port aggressive
 channel-group 1 mode active
!
interface FastEthernet0/2
 switchport trunk encapsulation dot1q
 switchport mode trunk
 udld port aggressive
 channel-group 1 mode active
!

Sw2:

hostname Sw2
!
udld aggressive
!
interface Port-channel1
 switchport trunk encapsulation dot1q
 switchport mode trunk
!
interface FastEthernet0/1
 switchport trunk encapsulation dot1q
 switchport mode trunk
 udld port aggressive
 channel-group 1 mode active
!
interface FastEthernet0/2
 switchport trunk encapsulation dot1q
 switchport mode trunk
 udld port aggressive
 channel-group 1 mode active
!

On Sw1:

Sw1#show ether sum
Flags:  D - down        P - bundled in port-channel
        I - stand-alone s - suspended
        H - Hot-standby (LACP only)
        R - Layer3      S - Layer2
        U - in use      f - failed to allocate aggregator
        M - not in use, minimum links not met
        u - unsuitable for bundling
        w - waiting to be aggregated
        d - default port
Number of channel-groups in use: 1
Number of aggregators:           1
Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------------------------
1      Po1(SU)         LACP      Fa0/1(P)    Fa0/2(P)
Sw1#show udld neigh
Port     Device Name   Device ID     Port ID    Neighbor State
----     -----------   ---------     -------    --------------
Fa0/1    FDO1244X102     1            Fa0/1      Bidirectional
Fa0/2    FDO1244X102     1            Fa0/2      Bidirectional

On Sw2:

Sw2#show ether sum
Flags:  D - down        P - bundled in port-channel
        I - stand-alone s - suspended
        H - Hot-standby (LACP only)
        R - Layer3      S - Layer2
        U - in use      f - failed to allocate aggregator
        M - not in use, minimum links not met
        u - unsuitable for bundling
        w - waiting to be aggregated
        d - default port
Number of channel-groups in use: 1
Number of aggregators:           1
Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------------------------
1      Po1(SU)         LACP      Fa0/1(P)    Fa0/2(P)
Sw2#show udld nei
Port     Device Name   Device ID     Port ID    Neighbor State
----     -----------   ---------     -------    --------------
Fa0/1    CAT1012Z62P     1            Fa0/1      Bidirectional
Fa0/2    CAT1012Z62P     1            Fa0/2      Bidirectional

As you can see, both switches are configured for UDLD aggressive mode both in the global config and on the ports. The EtherChannel is up and running.

Now, I create an apparent unidirectional link condition by filtering out the UDLD messages on Sw2 Fa0/2:

mac access-list extended BlockUDLD
 deny   any any 0x111 0x0
 permit any any
!
interface FastEthernet0/2
 switchport trunk encapsulation dot1q
 switchport mode trunk
 udld port aggressive
 mac access-group BlockUDLD in
 channel-group 1 mode active

Sw1 determines that the link is unidirectional (apparently, it expects to hear about itself from the Sw2 but the Sw2 does not hear it so it stops telling Sw1 that it can hear it) and brings down the Fa0/2 port:

Sw1#show logging
! Shortened for readability
Log Buffer (4096 bytes):
*Mar  1 02:31:29.173: %UDLD-4-UDLD_PORT_DISABLED: UDLD disabled interface Fa0/2, unidirectional link detected
*Mar  1 02:31:29.173: %PM-4-ERR_DISABLE: udld error detected on Fa0/2, putting Fa0/2 in err-disable state
*Mar  1 02:31:30.180: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/2, changed state to down
*Mar  1 02:31:31.187: %LINK-3-UPDOWN: Interface FastEthernet0/2, changed state to down
Sw1#

However, the EtherChannel is still up:

Sw1#show ether sum
Flags:  D - down        P - bundled in port-channel
        I - stand-alone s - suspended
        H - Hot-standby (LACP only)
        R - Layer3      S - Layer2
        U - in use      f - failed to allocate aggregator
        M - not in use, minimum links not met
        u - unsuitable for bundling
        w - waiting to be aggregated
        d - default port
Number of channel-groups in use: 1
Number of aggregators:           1
Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------------------------
1      Po1(SU)         LACP      Fa0/1(P)    Fa0/2(D)
Sw1#show int status
Port      Name               Status       Vlan       Duplex  Speed Type
Fa0/1                        connected    trunk      a-full  a-100 10/100BaseTX
Fa0/2                        err-disabled 1            auto   auto 10/100BaseTX
! Shortened for readability
Po1                          connected    trunk      a-full  a-100

Note that the EtherChannel is still up (running currently over Fa0/1 only), the Fa0/2 is err-disabled and Po1 is up just like Fa0/1.

So even having an UDLD aggressive mode configured both on global and interface level does not cause the Port-channel to go entirely down. As I indicated earlier - the aggressive mode is merely about reaction to the loss of UDLD messages from the other party, however, it is not about the scope of reaction once the UDLD decides to react. UDLD is always limited to a single physical port when err-disabling it.

Best regards,

Peter

[manju.cisco]

Thanks Peter... +5 again........this was really another good teaching for me

and sorry for my misleading post earlier.......

guess what, in my current office networks, they have used udld enable in global mode whereas on port level they have used udld aggressive...........now i know the reason but still i am not able to convince them about the unnecesary of udld enable command on the global mode if we are using aggresive mode on individual port level.........

Thanks again peter

[Kamil Sheriff]

Hello Peter,
That was a really wonderful way of teaching. I was searching randomly for the issues related to UDLD and this post help me a lot... Cheers..!!

[Chipula89]

If UDLD aggressive is configured on one switch but not on the other, would that err disable the port since it isn't receiving messages but it is sending them?

[gkelly]

Hi Peter,

We have almost exactly this scenario currently with 2 VSS pairs of 6509s in different data centres where each 6509 has udld aggressive mode on the physical interfaces only and when we have a VSS switchover (for reasons yet to be determined), the pair at the alternate data centre put one port into err-disable mode. When the first chassis has finished it's switchover, it retains both ports as enabled and the end result is traffic does not actually flow across this link at all. We have to shut / no shut the offending port to bring it back again. We're still investigating but if you (or anyone) has any inspiration as to why it might behave like this, would be most grateful

Cheers

GK

[Peter Paluch]

Hello,

I do not feel entirely competent to answer this, as I do not have practical experiences with redundant platforms including VSS. I can only speculate that during the switchover,  the port either stops hearing UDLD messages from the other party, or the other party suddenly drops the Bidir UDLD state and starts over, and the current port considers it an expression of unidirectional link condition and reacts. But that is just a speculation, and sadly, I do not have equipment to verify it.

Jon, Edison, Jerry, Amit and others - please, would you mind voicing your opinions here? Thank you so much!

Best regards,

Peter

[Mohamed Sobair]

I agree with Peter,

such behaviour would solely eleminate the benefit of etherchannel, the Etherchannel (Portchannel Interface) should be active even if any member of its binded physical interfaces goes down due to err-disable or any physical problem.

However, In all cases, I would strongly recommend having (UDLD aggressive mode) applied on all physical fiber interfaces, as it could easily lead to spanning-tree loops if not when a unidirectional link failure detected and the port on the other end is not err-disabled or shutted.

Regards,

Mohamed