CompTIA Network+ N10-008 – Module 17 – Troubleshooting Networks Part 3

4. 17.3 Network Appliance Commands

In this video, let’s take a look at some commands we can use to verify and troubleshoot a network appliance and CompTIA on their network plus exam. Blueprint is not specific about which network appliance we should be working with. If you take a look at the criteria listed in the Blueprint, it seems to be a great match for a Cisco iOS router, a very popular routing platform.

That’s what we’re going to take a look at in this video. Currently we’re on router R three, and you see our three here. In this topology, we’re running OSPF as our routing protocol and every interface on every router has both an IP version four and an IPV six address. And even though we don’t need to know how to configure a Cisco router for this exam, let’s say we wanted to take a look at the configuration. One command is simply show config and this shows the configuration of this router.

However, we need to distinguish between the running config and the startup config. If I just say show config, that’s showing me the startup config, that’s the configuration that’s stored in nonvolatile Ram in VRAM. In other words, when I reboot the router, it’s non volatile. It’s going to load up the configuration in NV Ram.

However, if I go in and make a change, that change is not immediately written to NVRAM. That change is going to be in my running config. That’s what the router is currently executing. So I can be very specific. I could say show running Hyphen config and that’s going to show me what’s running on the router right now. Or I could say show startup Hyphen config and this shows me the same output as the show config command did. This is what’s in my NVRAM.

This is the configuration the router is going to execute at boot up. And after I do make a change to the running config, I probably want to copy it over to the startup config. So I’ll say copy running config, startup Hyphen config. That’s what I’ll typically do after making a configuration change. And a shortcut way of saying that copy run Star, which is short for copy running config to the startup config. Now let’s take a look at the routing tables that this router has learned. We’re routing using OSPF for both IP version four and for IP version six. If I want to see the IPV four routes that we know about, I can say show IP route and this is going to be our IP version four routing table.

And these are the networks that we have learned. And we see the subnet mask. Ten one, 10, size 24. We’re talking about a 24 bit subnet mask, but you’ll notice these different codes. We have an O, OIA, a C and an L. What’s going on here? Well, the L is going to be the IP address of an interface on this router. Ten two, 2132, that’s an IP address and it’s assigned to an interface. On this router, I’m connected to the network of Ten 2224, and because I’m directly connected to it specifically on Gigabit Ethernet two, we see a C for this code. That’s how I learned it. I learned about the loopback IP address on router R two, which is two.

I learned it via OSPF. We see that indicated with the O code. I learned about the loopback IP address on router R one one also via OSPF, but it came from a different OSPF area. So instead of just an O, it’s an OIA, which means OSPF inter area. It came to me from a different area. Now, these are IP version four routes. And again, the command I gave was show IP route.

If I want to see the IP version six routes, I could say show IPV six route and we’ll get a list of IP version six routes with the same codes we saw before. Now let’s focus in on a router interface and some of the different information we can glean from an interface. If I first want to get just a high level snapshot view of what interfaces this router has, I can do a Show IP interface brief command, and this is going to show me that I’ve got these three interfaces, specifically three physical interfaces, and then one logical loopback interface.

I’m using Gigabit 0102 and loopback zero, and you see the IP addresses, if any, assigned to these interfaces. Now let’s zoom in on interface Gigabit zero slash one. I can say show interface gigabit zero slash one. And there’s a lot of information we’re presented with. Let me point out a few of the highlights. First, notice it says gigabit zero one is up, line protocol is up. This means that the physical interface is up and operational, and the line protocol, which is Ethernet, it’s also up.

We typically refer to this as an UPUP state. We also see that we’re operating in full duplex mode and our speed is one gigabit per second. Now, this port is capable of running at one gigabit per second as it is now. However, it’s able to negotiate to a lower speed if a device at the other end of this Ethernet link wants to operate at that lower speed. And we can do that if we set the speed to auto. Right now, it’s hard coded to be a speed of one gigabit per second, however, and the duplex tells us if we can have this port simultaneously transmitting and receiving, that would be full duplex. Or if this port can only send or receive at any one time, not both at the same time, that would be half duplex.

Now, half duplex was very common back in the Ethernet hub days, but today, with Ethernet switches, almost all Ethernet connections, they’re operating in full duplex, as we have here. We also see some packet and byte counts here we see we’ve had 35,401 packets input. That means we’ve received those packets on gigabit zero one, and those total up to about 5. 9 megabytes. We can also see how much traffic we’ve transmitted. It looks like we’ve sent 76,911 packets, which totals up to about 8. 4 megabytes. And if we’re doing troubleshooting, we can check for different errors. Let’s check out a few zero CRC. The interface here is checking for errors that occurred that corrupted a packet, and it’s going to maintain this CRC counter.

And CRC stands for Cyclic Redundancy check. Specifically, it’s checking to see if the checksum value generated by the sender. And we’ve just received this frame. We’re checking to see if that checksum value is the same as the one we calculated as we receive the traffic. If they’re the same, that’s a good indication that we have not had an error. And that’s our case here. We have zero CRC errors. That’s good news. We also have zero giants. A giant is another kind of error we could have where a frame is larger than the frames MTU or the maximum transmission unit. Now, by default, on an Ethernet interface like this, the maximum transmission unit for an IP packet is 1500 bytes. But then we add on the 18 bytes for the Ethernet header.

That gives us a frame, a layer two frame MTU of 1518 bytes. So a giant, first of all, is going to be a frame greater than 1518 bytes. Oh, by the way, as a side note, you can set up some Ethernet interfaces to support jumbo frames, where the maximum packet size can be not 1500 bytes, it can be 9000 bytes. So if you’ve got this configured for jumbo frames, any valid jumbo frame will not generate an error here. But that’s only one part of being a giant. You got to be too big. But in addition to being too big, the frame also must have an FCS error. An FCS. Stands for frame check sequence. Now, what’s the difference between a CRC error and an FCS error? Well, basically nothing.

The frame check sequence uses the CRC algorithm. So an FCS is essentially the CRC algorithm applied to a data frame as opposed to applying it to something else. Now, at the opposite end of the spectrum from a giant is a runt, and we’ve had zero runs, a giant frame. We said it’s too big and it has an FCS error. Now, a runt is a frame that’s too small, specifically for this Ethernet interface, that would be less than 64 bytes for an Ethernet frame. The good news is this interface has not seen any runs, and CompTIA says we also need to know about encapsulation errors. And you’ll notice in this output we don’t have anything labeled as an encapsulation error counter. However, if this interface receives a packet that it cannot forward or reply to, that might be an encapsulation error.

How do we see that, though? We can see that as part of a debug output. A debug command allows us to examine traffic at the packet level as it flows through an interface for troubleshooting purposes. Here’s a big caution, though. Using the debug command is very processor intensive. You should only use it when you absolutely need to, and you don’t want to debug more information than you need. If you said to debug all IP packets, you’re probably going to lock up your router.

I’ve done that in the past. I’ve done too big of a debug for a remote site that I was maintaining, and I lost connectivity. I had to make the call of shame where I said, can you go turn that router off and then turn it back on? I locked it up by doing too much debugging. But here in this lab environment, let me do a quick debug command, just debugging a little bit of information. We’ll take a look at the debug output for OSPF hello messages, just so you get a sense for what debug output might look like.

Let’s do a debug OSPF hello, and any OSPF hello message that is sent or received on this interface, it’s going to generate some output. So if we wait just a few seconds there, we received one. And if we want to get out of this output, or we just sent one, if I want to get out this debug, I can say undebug all. Or we could just say you all for short. And that’s a look at some common commands that we could use for monitoring and troubleshooting a network appliance like a cisco router.

5. 17.4 Device Metrics and Sensors

Many of our networking appliances have internal sensors, so remotely we can check out what’s going on. Is it getting too hot in the room where this device is? I can monitor the temperature sensor. Maybe the HVAC system has gone out. Maybe I’m running all in memory or I’m texting the processor. Well, CompTIA tells us on the network plus exam Blueprint that we should understand temperature, memory and CPU you device sensors and the way we get that information from a device is going to vary widely depending on the device. But as an example, I thought I would show you how to glean that information from a Cisco Catalyst switch.

This is an Ethernet switch and if I want to see the temperature, this particular networking appliance is not going to tell me what the temperature is. It’s just going to tell me if it’s okay or not. Is it within an acceptable operating range? And I can say show E and V for environment temperature and it says it is okay. What if I’m concerned that I may be running out of memory? I can say show processes memory and I’ve got different memory pools. I have one for the processor for the I O subsystem for driver text, which supports add on things like Flash memory. But let’s take a look at the processor memory pool. I have a total of about 71.

1 meg and we see that I have about 30 meg that is currently used and a little over 40 meg that is free. So that’s looking pretty good. If I were running low, this output would show me that. What about the CPU? I could say show processes CPU and this is going to give me some CPU statistics, including my average CPU utilization over 5 seconds, over 1 minute or over five minutes. Now here it says over 5 seconds. I’m averaging a CPU utilization of 5%.

That doesn’t seem bad, but then there’s a slash 0%. What’s that about? Well, you might remember in a previous video where we did a debug command and I warned you that it was very processor intensive. Well, the reason I said that is the debug command uses a device’s processor to analyze every packet. And anytime we use a router or a switch processor that’s going to be reflected in this number over 1 minute, we have a 5% CPU utilization and same thing for five minutes. And again, the way you’re going to get this information from your device, if it’s even available on a specific device you’re working on, it’s going to vary. But this is a look at how to get temperature, memory and CPU information from the device sensors and a Cisco Catalyst to switch.

• Category: Uncategorized