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/1GigabitEthernet0/1 is up, line protocol is upHardware 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/255Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not setKeepalive set (10 sec)Full Duplex, 1Gbps, media type is RJ45output flow-control is unsupported, input flow-control is unsupportedARP type: ARPA, ARP Timeout 04:00:00Last input 00:00:05, output 00:00:00, output hang neverLast clearing of “show interface” counters 12w0dInput queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0Queueing strategy: fifoOutput queue: 0/40 (size/max)5 minute input rate 37000 bits/sec, 20 packets/sec5 minute output rate 411000 bits/sec, 110 packets/sec999378058 packets input, 4069851291 bytes, 0 no bufferReceived 2611278 broadcasts (0 IP multicasts)0 runts, 0 giants, 0 throttles0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored0 watchdog, 2611278 multicast, 0 pause input2530578182 packets output, 1756092984 bytes, 0 underruns0 output errors, 0 collisions, 0 interface resets242987 unknown protocol drops0 babbles, 0 late collision, 0 deferred0 lost carrier, 0 no carrier, 0 pause output0 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.
Our Recommended Premium CCNA Training Resources
These are the best CCNA training resources online:
Click Here to get the Cisco CCNA Gold Bootcamp, the most comprehensive and highest rated CCNA course online with a 4.8 star rating from over 30,000 public reviews. I recommend this as your primary study source to learn all the topics on the exam.
Want to take your practice tests to the next level? AlphaPreps purpose-built Cisco test engine has the largest question bank, adaptive questions, and advanced reporting which tells you exactly when you are ready to pass the real exam. Click here for your free trial.
