Switch management and interface troubleshooting

Giving a switch a management address

A layer 2 switch forwards frames without needing any IP address. But you want to log in to it remotely (with SSH), back up its configuration and monitor it. For that the switch itself needs an IP address. On a layer 2 switch you put that address on an SVI, usually in a dedicated management VLAN, and tell the switch where its router is.

SW1(config)# vlan 99
SW1(config-vlan)# name MGMT
SW1(config-vlan)# exit
SW1(config)# interface vlan 99
SW1(config-if)# ip address 10.99.0.11 255.255.255.0
SW1(config-if)# no shutdown
SW1(config-if)# exit
SW1(config)# ip default-gateway 10.99.0.1

Why ip default-gateway and not a default route? A layer 2 switch does not route (ip routing is off), so it uses ip default-gateway, exactly like a PC uses its gateway. A layer 3 switch with ip routing on uses a normal default route instead (ip route 0.0.0.0 0.0.0.0 next-hop).

Reading interface status

SW1# show interfaces status

Port      Name               Status       Vlan       Duplex  Speed Type
Fa0/1     Reception PC       connected    10         a-full  a-100 10/100BaseTX
Fa0/2                        notconnect   10           auto   auto 10/100BaseTX
Fa0/3     CCTV cam 3         err-disabled 30           auto   auto 10/100BaseTX
Fa0/4                        disabled     1            auto   auto 10/100BaseTX
Gi0/1     Uplink to R1       connected    trunk        full   1000 10/100/1000BaseTX

The Name column comes from the description command. connected means it works; notconnect means no cable or the other end is off; disabled means an administrator shut it down; err-disabled means the switch shut it down itself because of a problem it detected.

Routers and switches also report two words for each interface, for example in show ip interface brief or the first line of show interfaces: the line status (layer 1, the physical link) and the protocol status (layer 2, the data link).

Error counters

A port can be up/up and still perform badly. show interfaces shows counters of bad frames since the counters were last cleared.

SW1# show interfaces fastEthernet 0/1
FastEthernet0/1 is up, line protocol is up (connected)
  ...
  Half-duplex, 100Mb/s, media type is 10/100BaseTX
  ...
     12 runts, 0 giants, 0 throttles
     87 input errors, 75 CRC, 0 frame, 0 overrun, 0 ignored
  ...
     0 output errors, 152 collisions, 1 interface resets
     0 babbles, 23 late collision, 0 deferred

• Runts: frames smaller than 64 bytes, the minimum Ethernet size. Often the broken pieces of collisions.
• Giants: frames bigger than the maximum size (1518 bytes for a normal untagged frame). Often an MTU setting mismatch.
• CRC errors: the frame check sequence did not match, so the frame was damaged on the way. Bad cable, electrical noise, or a duplex mismatch.
• Late collisions: collisions after the first 64 bytes were sent. On a modern switched network these almost always mean a duplex mismatch.
• Input errors: the total of several input error types, including runts, giants and CRC.

Speed, duplex and the duplex mismatch

Duplex says whether a link can send and receive at the same time (full duplex) or must take turns (half duplex). Both ends must agree. Normally both use autonegotiation and agree on the best speed and full duplex. The trouble starts when one end is hard-coded and the other is on auto: the auto side can still sense the speed, but it cannot learn the duplex, so at 10 or 100 Mbps it falls back to half duplex.

Result: one side sends whenever it likes (full), the other thinks it is a collision and backs off (half). The full-duplex side sees CRC errors and runts; the half-duplex side sees late collisions. The link works, but it is slow and drops packets, which users describe as "the network is slow only at this desk".

SW1(config)# interface fastEthernet 0/1
SW1(config-if)# description Reception PC
SW1(config-if)# speed auto
SW1(config-if)# duplex auto
SW1(config-if)# end
SW1# clear counters fastEthernet 0/1