ICND2 200-105

ICND2 200-105

Verification of Physical Connectivity Issue

So up to this point, our end-to-end connectivity if you've been following along was really successful, it was. So we wouldn't have to troubleshoot any further from there. But let's pretend that connectivity wasn't successful. What else could we look at now? Well physical connectivity issues, that might be a problem. And that really takes us back to ICND1, troubleshooting those physical connections. So what do we want to look at first?

IPv4 physical connectivity issues

Well I really like a few commands that we won't see here listed. But if I'm on a switch, I'm going to do show interface status to get a good listing of my interfaces. And I might see that ports are in error disabled and I could all see you, as to see, if my ports are up/up. Same with show IP interface brief. We're thinking about that command to be a good first test. But let's say we got an up/up interface. But we believe that there's still something wrong with that up/up interface at layer 2. That physical connectivity is not looking so hot from a behavioral standpoint. I'm not getting the throughput, I'm getting dropped packets my ping is showing me that. So what am I going to be looking at here? I'm going to dive into the weeds now - that's where we're going.

R1#sh int GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
  Hardware is CN Gigabit Ethernet, address is 7081.0597.ca61 (bia 7081.0597.ca61)
  MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation 802.1Q Virtual LAN, Vlan ID  1., loopback not set
  Keepalive set (10 sec)
  Full Duplex, 1Gbps, media type is RJ45
  output flow-control is unsupported, input 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 12w0d
  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 37000 bits/sec, 20 packets/sec
  5 minute output rate 411000 bits/sec, 110 packets/sec
     999378058 packets input, 4069851291 bytes, 0 no buffer
     Received 2611278 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 2611278 multicast, 0 pause input
     2530578182 packets output, 1756092984 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     242987 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

We're going to that area of statistics in regards to an interface. So if we type in show interface and then the specific interface, we want to look at and we scroll down about halfway down the output and then more towards the bottom. We'll find all these different numbers related to - input queues, output queues, the number of dropped packets, any type of input and output errors, that we might find. And folks at this point now, we are really diving into the statistics in regards to whether our CPU has the ability to process those particular packets. If values are high and it's a cause for concern, we should be investigating why our CPU can't process those packets? Why are those particular packets being dropped instead of being forwarded? Are they stuck in our queues because of congestion?

We might have input errors or output errors, we might be experiencing cyclic redundancy check, or CRC errors. So our packets and frames might be damaged as they're being transmitted through the network. So really folks, as we're diving into these statistics, we're really, as I said, diving into the weeds. And we're looking for those numbers that might be beyond normal in regards to the normal operation of our devices.

But when it comes to our switches, let's remember something here. Speed and duplex. Do they or do they not have to match? That's important. It's really important. You have the end station connected to a switch, you have a switch connected to another switch or a switch connected to a router. The speed has to match. Oh yeah, definitely it does. If speed doesn't match, we have no connectivity. So as I'm looking at the output of show interfaces on that interface number, same output we just looked at, I can verify the speed and I want to make sure the speed is the same on both ends. And then duplex doesn't have to match. Let's remember that it doesn't have to match but if it doesn't match what's the result of that? Well by definition, we have a duplex mismatch and we're going to have our horrendous, at least slow connection. It's going to be bad because the half duplex side will constantly be reset when it's sending frames, believing they cannot send and receive at the same time. You see a lot of late collisions when that happens and CRC errors when that happens. When those two occur at the same time - CRC errors, late collisions, we have a duplex mismatch. And we have to make sure that our environment is free from any duplex mismatches. This is not a sustainable state for our network.

So even though I said, it doesn't have to match, let's be careful with that. Don't take that statement to the bank because as we said, full duplex and half duplex, no, yeah you have connectivity that's fine. But it's the slowest possible connectivity you could really experience in the network. So make sure it matches in the real world or else you'll have end users complaining that the network is slow.