cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
31948
Views
19
Helpful
8
Replies

Switch down due to udld link

mahesh18
Level 6
Level 6

hi

we have cisco 4000 switch connected to router.

it went down today.

check the logs on router

Nov 5 09:38:46.901 EST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet8/2, changed state to down

Nov 5 09:38:46.897 EST: %UDLD-SP-4-UDLD_PORT_DISABLED: UDLD disabled interface Gi8/2, unidirectional link detected

Nov 5 09:38:46.897 EST: %PM-SP-4-ERR_DISABLE: udld error detected on Gi8/2, putting Gi8/2 in err-disable state

Nov 5 09:38:46.957 EST: %LINK-3-UPDOWN: Interface GigabitEthernet8/2, changed state to down

Nov 5 09:38:46.917 EST: %LINEPROTO-SP-5-UPDOWN: Line protocol on Interface GigabitEthernet8/2, changed state to down

Nov 5 09:38:46.957 EST: %LINK-SP-3-UPDOWN: Interface GigabitEthernet8/2, changed state to down

Nov 5 09:38:47.005 EST: %PM-SP-STDBY-4-ERR_DISABLE: udld error detected on Gi8/2, putting Gi8/2 in err-disable state

any help?

why this happened

mahesh

1 Accepted Solution

Accepted Solutions

Thats part of explanation, there are some operating characteristics you need to be aware of.

For example, if the switch on either end of a UDLD aggressive link experience high CPU, the link will have a high risk of dropping as UDLD messages will be missed.

In this manner, it works almost like a heartbeat. This may or may not be desireable, you'll see this happen if a switch flakes out and introduces an STP loop, CPU's will spike, and UDLD will drop links in response. Note this has nothing to do with unidirectional links.

I see recommendations here for error timeouts. Be careful with these, this is a feature that cuts both ways. 1) it can restore and error disabled port for you automatically, but 2) it can restore a port that may have error'ed out for a good reason and should not be re-introduced into the network without a human looking at the link firt...simply, putting it back may do more harm.

View solution in original post

8 Replies 8

Amit Singh
Cisco Employee
Cisco Employee

Mahesh,

You had UDLD enabled on the switch and its has just detected a unidirectional link on the Gig 8/2, which could be a a bad fiber cable or GBIC tranceiver, which might potentially cause spanning-tree loops or interfere with connectivity. The cause is likely to be hardware related, either due to a bad port, a bad cable, or a misconfigured cableTry changing both of them one by one and see when it comes up.

You can try re-enabling the ports :

1 Either by doing " shut" and "no shut " on the interface.

2. Or running command " err-disable recovery cause udld " in the global config mode.

-amit singh

thanks for reply amit

how we can check if udld is enabled on port

of switch or not ?

also why we use udld on switch port?

i bounce the switch port on router then port came back up

from router side

sh int gi 8/2

GigabitEthernet8/2 is up, line protocol is up (connected)

Hardware is C6k 1000Mb 802.3, address is 0014.f289.7b99 (bia 0014.f289.7b99)

MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 1000Mb/s, media type is SX

input flow-control is off, output flow-control is on

Clock mode is auto

ARP type: ARPA, ARP Timeout 04:00:00

Last input 00:00:25, output 00:00:45, output hang never

Last clearing of "show interface" counters never

Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 10000 bits/sec, 15 packets/sec

5972238 packets input, 1172289401 bytes, 0 no buffer

Received 2334300 broadcasts (522661 multicasts)

0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

0 watchdog, 0 multicast, 0 pause input

0 input packets with dribble condition detected

102807096 packets output, 11078670748 bytes, 0 underruns

0 output errors, 0 collisions, 4 interface resets

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier, 0 PAUSE output

0 output buffer failures, 0 output buffers swapped out

Hi amit

thi sis switch side

sh int gi1/2

GigabitEthernet1/2 is up, line protocol is up (connected)

Hardware is Gigabit Ethernet Port, address is 0013.c405.d001 (bia 0013.c405.d001)

MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 1000Mb/s, link type is auto, media type is 1000BaseSX

input flow-control is on, output flow-control is off

ARP type: ARPA, ARP Timeout 04:00:00

Last input 00:00:00, output never, output hang never

Last clearing of "show interface" counters never

Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 11000 bits/sec, 15 packets/sec

5 minute output rate 1000 bits/sec, 3 packets/sec

3133235812 packets input, 257820797453 bytes, 0 no buffer

Received 1939597599 broadcasts (1630795765 multicast)

0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

0 input packets with dribble condition detected

2214051241 packets output, 3012109299202 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier

0 output buffer failures, 0 output buffers swapped out

hi amit,

alos we have udld enabled on both switch and router.

route rside

switchport

switchport trunk encapsulation dot1q

switchport trunk native vlan 999

switchport trunk allowed vlan 1,12,63,89,999

switchport mode trunk

no ip address

logging event link-status

udld port aggressive

switch side

interface GigabitEthernet1/1

switchport trunk encapsulation dot1q

switchport trunk native vlan 999

switchport trunk allowed vlan 1,12,63,89,999

switchport mode trunk

udld port aggressive

is there a way that we can tell which one side is passing traffic when udld err disables th eport?

thanks

magesg

hi all,

can someone explain me how udld works in fibre connections

many thanks

The UDLD protocol allows devices connected through fiber-optic cables connected to LAN/WAN ports to monitor the physical configuration of the cables and detect when a unidirectional link exists. When a unidirectional link is detected, UDLD shuts down the affected LAN port and alerts the user. Unidirectional links can cause a variety of problems, including spanning tree topology loops.

UDLD is a Layer 2 protocol that works with the Layer 1 protocols 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 LAN ports. When you enable both autonegotiation and UDLD, 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 transmitted by the local device over a link is received by the neighbor but traffic transmitted from the neighbor is not received by the local device. If one of the fiber strands in a pair is disconnected, as long as autonegotiation is active, the link does not stay up. In this case, the logical link is undetermined, and UDLD does not take any action. If both fibers are working normally at Layer 1, then UDLD at Layer 2 determines whether those fibers 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.

Hi Francisco

thanks for reply.

Thats part of explanation, there are some operating characteristics you need to be aware of.

For example, if the switch on either end of a UDLD aggressive link experience high CPU, the link will have a high risk of dropping as UDLD messages will be missed.

In this manner, it works almost like a heartbeat. This may or may not be desireable, you'll see this happen if a switch flakes out and introduces an STP loop, CPU's will spike, and UDLD will drop links in response. Note this has nothing to do with unidirectional links.

I see recommendations here for error timeouts. Be careful with these, this is a feature that cuts both ways. 1) it can restore and error disabled port for you automatically, but 2) it can restore a port that may have error'ed out for a good reason and should not be re-introduced into the network without a human looking at the link firt...simply, putting it back may do more harm.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card