Cisco switch interface Up but Line Protocol Down?

It is pretty unusual to find an Ethernet interface on a Cisco device which looks like it is working at Layer 1, so you get a Green link light on the Cisco device, but where it is not working at Layer 2 – so you can see no incoming Ethernet packets.

Of course I had just such an instance yesterday when VOIP phones were not picking up an IP address from the DHCP server running on a Cisco switch. Other devices clearly where, including same make/model VOIP phones in other parts of the network.

What was common was that all the phones with problems were connected eventually back to port G1/0/12 on the Cisco switch which had the DHCP server. This had a link light…

I looked at the interface:

Switch#sh int g1/0/12
GigabitEthernet1/0/12 is up, line protocol is down (monitoring)
  Hardware is Gigabit Ethernet, address is 5017.ff29.9c0c (bia 5017.ff29.9c0c)
  MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 100Mb/s, media type is 10/100/1000BaseTX
  input flow-control is off, output flow-control is unsupported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input never, output 04:41:16, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/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 0 bits/sec, 0 packets/sec
     0 packets input, 0 bytes, 0 no buffer
     Received 0 broadcasts (0 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

So this interface has Line Protocol down, why?

I didn’t really focus on the word ‘monitoring’. Maybe it was a duplex or speed issue causing the non-passage of packets – but the negotiated value (Full-duplex, 100Mb/s) was right.

Maybe it was the cable. I decided to do a TDR test, because this was a modern day IOS and I could!

Switch#test cable-diagnostics tdr int g1/0/12
TDR test started on interface Gi1/0/12
A TDR test can take a few seconds to run on an interface
Use 'show cable-diagnostics tdr' to read the TDR results.

Switch#show cable-diagnostics tdr int g1/0/12
TDR test last run on: September 22 15:28:12

Interface Speed Local pair Pair length        Remote pair Pair status
--------- ----- ---------- ------------------ ----------- --------------------
Gi1/0/12  100M  Pair A     N/A                N/A         Not Completed
                Pair B     N/A                N/A         Not Completed
                Pair C     N/A                N/A         Not Completed
                Pair D     N/A                N/A         Not Completed

Okay, err, so no results. So I wondered whether I had used this switch for something else and forgotten to reset it – sometimes I do this when I need a couple of ports to monitor something. So I did a search in the config:


Switch#sh run | inc moni
monitor session 1 source interface Gi1/0/1
monitor session 1 destination interface Gi1/0/12

Bingo!

So I switched this off:

Switch#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Switch(config)#no monitor session 1
Switch(config)#exit

Switch#sh run | inc moni
Switch#

and immediately the line protocol came up.

Sep 22 15:38:33.746: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/12, changed state to up
Sep 22 15:38:33.750: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/12, line protocol is up (connected)

which was easily confirmed by looking at the interface again:


Switch#sh int g1/0/12
  Hardware is Gigabit Ethernet, address is 5017.ff29.9c0c (bia 5017.ff29.9c0c)
  MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 100Mb/s, media type is 10/100/1000BaseTX
  input flow-control is off, output flow-control is unsupported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:05, output 00:00:00, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 3000 bits/sec, 3 packets/sec
  5 minute output rate 4000 bits/sec, 3 packets/sec
     268 packets input, 33790 bytes, 0 no buffer
     Received 44 broadcasts (4 multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 4 multicast, 0 pause input
     0 input packets with dribble condition detected
     94229 packets output, 75993256 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets
     1 unknown protocol drops
     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

Lesson – always factory reset switches before you use them for some other purpose.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: