Troubleshooting Interfaces

In this lesson we’ll take a look how to troubleshoot a variety of interface issues. Let’s walk through a couple of scenarios…

Duplex / speed issues

I will use the following topology:

host 1 switch 1 host 2

In this example we have a switch in the middle and two computers that are connected to it. Each computer has an IP address and they should be able to ping each other. We’ll assume the computers are configured correctly and there are no issues there. Let’s try a ping:

C:Documents and SettingsH1>ping 192.168.1.2

Pinging 192.168.1.2 with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 192.168.1.2:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Unfortunately our pings are not working. What’s the first thing we should check? Our interfaces of course!

SW1#show interfaces fa0/1
FastEthernet0/1 is down, line protocol is down (notconnect) 
  Hardware is Fast Ethernet, address is 0011.bb0b.3603 (bia 0011.bb0b.3603)
  MTU 1900 bytes, BW 100000 Kbit, DLY 100 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Half-duplex, Auto-speed, media type is 10/100BaseTX
  input flow-control is off, output flow-control is unsupported 
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:26:47, output 00:19:17, 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
     3457 packets input, 309301 bytes, 0 no buffer
     Received 2407 broadcasts (1702 multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 1702 multicast, 0 pause input
     0 input packets with dribble condition detected
     42700 packets output, 8267872 bytes, 0 underruns
     0 output errors, 0 collisions, 1 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

FastEthernet 0/1 is showing down. This could indicate a layer 1 problem like a broken cable, wrong cable (crossover instead of straight-through) or maybe a bad NIC. Note that this interface is running in half duplex. If you are lucky you might get a duplex message through CDP that tells you that there is a duplex mismatch. If you are unlucky it’s possible that your interface goes down. Keep in mind that a Gigabit interface doesn’t support half-duplex. Let’s set duplex to auto:

SW1(config)#interface fa0/1
SW1(config-if)#duplex auto

I’ll change the interface to duplex auto so the switch can figure it out by itself.

SW1#
%LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to up

That’s looking better! Let’s try another ping (maybe we get lucky):

C:Documents and SettingsH1>ping 192.168.1.2

Pinging 192.168.1.2 with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.

Ping statistics for 192.168.1.2:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Too bad, the ping is not working. Let’s check the interface that connects to H2:

SW1#show interfaces fa0/3
FastEthernet0/3 is down, line protocol is down (notconnect) 
  Hardware is Fast Ethernet, address is 0011.bb0b.3605 (bia 0011.bb0b.3605)
  MTU 1900 bytes, BW 10000 Kbit, DLY 1000 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Auto-duplex, 10Mb/s, media type is 10/100BaseTX
  input flow-control is off, output flow-control is unsupported 
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:38:09, output 00:01:42, 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
     1908 packets input, 181819 bytes, 0 no buffer
     Received 858 broadcasts (826 multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 826 multicast, 0 pause input
     0 input packets with dribble condition detected
     46861 packets output, 9365341 bytes, 0 underruns
     0 output errors, 0 collisions, 1 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

Interface Fa0/3 that is connected to H2 is also down. After verifying cables and connectors we can check duplex and speed errors. Duplex is on auto so that shouldn’t be a problem. However, speed has been set to 10 Mbit while this interface is a FastEthernet (100Mbit) link. Let’s set it to auto:

SW1(config)#interface fa0/3
SW1(config-if)#speed auto

This is what we see:

SW1#
%LINK-3-UPDOWN: Interface FastEthernet0/3, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/3, changed state to up

It seems the speed mismatch caused the interface to go down. Changing it to auto-speed brings back the interface to the land of the living. Let’s check if all interfaces are up:

SW1#show ip interface brief 
Interface             IP-Address      OK? Method Status              Protocol
FastEthernet0/1       unassigned      YES unset  up                    up      
FastEthernet0/3       unassigned      YES unset  up                    up   

This is what we are looking for. The interfaces that I’m working with are both showing up/up. At least we now know that there are no cable, speed or duplex errors. Let’s try that ping again:

C:Documents and SettingsH1>ping 192.168.1.2

Pinging 192.168.1.2 with 32 bytes of data:

Reply from 192.168.1.2: bytes=32 time<1ms TTL=128
Reply from 192.168.1.2: bytes=32 time<1ms TTL=128
Reply from 192.168.1.2: bytes=32 time<1ms TTL=128
Reply from 192.168.1.2: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.1.2:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

Now our ping is working.

Lesson learned: Check your interfaces for speed and duplex issues and see if they show as up/up.

Port-security issues

The next issue is about port-security, we’ll use the same topology:

host 1 switch 1 host 2

Same topology but there’s a different problem here. Let’s try a ping:

C:Documents and SettingsH1>ping 192.168.1.2

Pinging 192.168.1.2 with 32 bytes of data:

Request timed out.
Request timed out.

Ping statistics for 192.168.1.2:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

H1 is unable to ping H2. We’ll start by checking the interfaces:

SW1#show ip interface brief 
Interface           IP-Address      OK? Method Status                Protocol
FastEthernet0/1     unassigned      YES unset  down                  down    
FastEthernet0/3     unassigned      YES unset  up                    up

FastEthernet 0/3 is looking fine but something is wrong with FastEthernet 0/1. Let’s take a closer look at it:

SW1#show interfaces fa0/1
FastEthernet0/1 is down, line protocol is down (err-disabled)

Hmm it says err-disabled. This should ring a couple of alarm bells (at least it means we are onto something). Let’s see why it is disabled:

SW1#show interfaces status err-disabled 

Port  Name               Status       Reason               Err-disabled Vlans
Fa0/1                    err-disabled psecure-violation

Use the show interfaces status err-disabled command to see why the interface got into error-disabled mode. It’s telling me port-security is the reason. Let’s check it out:

SW1#show port-security interface fa0/1
Port Security              : Disabled
Port Status                : Secure-shutdown
Violation Mode             : Shutdown
Aging Time                 : 0 mins
Aging Type                 : Absolute
SecureStatic Address Aging : Disabled
Maximum MAC Addresses      : 1
Total MAC Addresses        : 1
Configured MAC Addresses   : 1
Sticky MAC Addresses       : 0
Last Source Address:Vlan   : 000c.2928.5c6c:1
Security Violation Count   : 1

We can look at the port security configuration and we see that only 1 MAC address is allowed. The last MAC address seen on the interface is 000c.2928.5c6c. Let’s see what MAC address has been configured for port-security:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You’ve Ever Spent on Your Cisco Career!
  • Full Access to our 799 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

561 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags:


Forum Replies

  1. Hi,My concern is I am looking for the topic ‘Configuring Ethernet switch’(Telnet,console and SSH). Can you please tell me where did you discussed this topic

  2. Hi,

    Here’s an example for the console and SSH:

    Configuring Cisco router for the first time

    Here’s an example to enable telnet server on your router or switch:

    R1(config)#line vty 0 4
    R1(config-line)#transport input telnet
    R1(config-line)#password cisco123
    R1(config-line)#transport input 
    R1(config-line)#login
    

    The configuration above will only ask for the password (cisco123). It’s also possible to use usernames/passwords instead:

    R1(config)#username admin password cisco123
    
    R1(config)#line vty 0 4
    R1(config-line)#login local
    

    And you can protect it with an acce

    ... Continue reading in our forum

  3. What main items check when troubleshooting fiber based interface

  4. Hello Syedwaqas.

    When troubleshooting fibre based interfaces, there are some specific items that you should check:

    First of all, all of the issues brought up by Rene in this lesson are applicable to fibre optic connections as well. Additionally, you should keep the following in mind when troubleshooting fibre based interfaces:

    1. Check the SFP or GBIC status by issuing the show inter status command. Here is an example from a production 3750 production switch that I have:
    3750_DC_1#show inter status
    Gi1/0/1   ***VOICE_SERVERS** connected    901        a-full a-
    ... Continue reading in our forum

  5. Hi Laz,
    According to point 3 as I understand …
    If the SFP Module is Single Mode (Like GLC-LH-SM1 SFP-GE-L2) then we have to use Single Mode Fiber or vice versa , right ?? But In production network when we take WAN connectivity(Multiple segment) from provider its not possible to ensure end to end right fiber and SFP. Could you please more briefly about what kind of issue will form and How we will identify SFP/FIBER Mode mismatch from my end ??

    br//zaman

23 more replies! Ask a question or join the discussion by visiting our Community Forum