11-05-2008 06:59 AM - edited 03-06-2019 02:19 AM
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
Solved! Go to Solution.
11-09-2008 12:48 PM
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.
11-05-2008 07:17 AM
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
11-05-2008 09:25 AM
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
11-05-2008 09:28 AM
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
11-05-2008 09:47 AM
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
11-07-2008 07:16 AM
hi all,
can someone explain me how udld works in fibre connections
many thanks
11-07-2008 07:28 AM
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.
11-07-2008 03:14 PM
Hi Francisco
thanks for reply.
11-09-2008 12:48 PM
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.
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: