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 660 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

507 Sign Ups in the last 30 days

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

Forum Replies

  1. Thanks alot Rene, these lessons are very helpful.
    Keep up the good work.

  2. Hi Hans,

    Best to do it on both sides. Your switch(es) will complain when you receive traffic for VLANs that are not allowed on the trunk. It’s best practice to ensure that both ends of the trunk have the same configuration.

    Rene

  3. Hello Rodrigo

    There are various ways to show the status of interfaces and each command provides different information and in different formats. The command initially chosen by Rene is the show ip interface brief will show the status and protocol of all the interfaces in a list, so you get a general picture of all interfaces with one command. If any of those interfaces are configured with IP addresses, those are also displayed.

    The show interface fa0/x switchport command will show the switchport configuration of a single port in detail. This can be used when

    ... Continue reading in our forum

  4. Are you familiar with the switch error - %sw_matm-4-macflap_notif. What causes them? What is flapping?

  5. Hi Jason,

    This message shows up when your switch receives a frame with the same source MAC address on two different interfaces.

    Do you see this for one MAC address or multiple? If you see multiple MAC address, you might have a L2 loop. If you only see one source MAC address, it’s probably a misconfiguration. Track it down like this:

    SW1#show mac address-table dynamic address 0017.94a5.a618 
              Mac Address Table
    -------------------------------------------
    
    Vlan    Mac Address       Type        Ports
    ----    -----------       --------    -----
     200    0017
    ... Continue reading in our forum

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