There are some standard troubleshooting steps that are common when working on modern networks. In this video, you’ll learn about configuration reviews, routing tables, interface status messages, VLAN assignments, and more.
Whenever we run into some type of network problem– this might be affecting one or many devices on our network– we want to try to resolve this problem as quickly as possible. Before we start modifying any type of configuration, it’s best to understand exactly what we’re working with. So you may want to log into your switch, your router, or whatever device is having a problem, and look at the configuration of that device.
You may do this through a web-based console or there might be a command line that you use via SSH. If this is a device that’s involved in a change control or you’re performing some type of upgrade or modification, it might be useful to gather this information prior to the event. That way you know exactly what you’re working with when you sit down to make those changes.
I’ve just logged in to the web-based frontend of one of the switches on my network. There’s also a command line with SSH that I could use to view the configuration and make changes. But I thought it would be easy to see all of this in the web-based frontend.
You can see the system summary tells me exactly how this device has been configured. It’s in a layer 3 mode because this switch acts as both a switch and a router. I can also look at firmware version. So this device is using firmware version 1.3.7.18. It also has a separate firmware version because I did upgrade this device from 1.3.0.62.
This makes it easy to revert back to a previous version if I run into a problem. So I can upgrade to the latest version, and then if this happens to have some other type of bug that I wasn’t expecting, I can easily revert back to the previous config.
If you’re working with layer 3 devices, then you’re dealing a lot with routing tables. Routing tables are a way that your device knows where it should be sending traffic. As traffic is inbound to this layer 3 device, the destination IP address will be examined and compared against the routing table. That routing table will then either forward that traffic to the next hop or drop that traffic because there was no entry for that destination in the routing table.
If you have a lot of routers on your network, you may want to build a map, so you know exactly where a packet should go whenever it needs to get to a destination network. Sometimes these routes are created automatically through the use of dynamic routing protocols. Or you may be manually configuring those routes in every device.
If you have a lot of routers on your network, you might want to create a map that shows exactly where the paths are for each individual subnet. This way you’ll be able to map out where traffic should go, and you can confirm that based on the routing tables in each of those routers.
This is a key troubleshooting step if you’re running into a routing problem. You not only need to track every router as the traffic is outbound, you also need to make sure that your routing tables are correct for the inbound traffic as well. If you’re configuring static routes in a device, it’s very easy to accidentally create a loop.
You might tell router A to send all traffic to router B, and then you might accidentally tell router B to send all traffic to router A. And then that traffic, simply, loops around until the time-to-live is expired, and those packets are dropped from the network. You also want to be sure you’re not missing any routes, so make sure that you not only map the outbound routes but also all of the inbound routes.
Let’s look again at this switch that I’m running in my studio, which also acts in layer 3 as a router. I see three individual static routes in this device. We have a network 10.1.10.0 and a network 10.1.20.0 that are locally connected to this device, so no route is needed.
But I did add a static route for everything else. This is the default route of 0.0.0.0, which means anything that doesn’t match all of the other destinations in this routing table would be routed to the next hop, which is 10.1.10.1.
Let’s say that I’m at my desk and I need to communicate to a network that’s located at 10.10.10.1. You can see that 10.10.10.0 is not listed in this network list, which means it’s going to follow the default route of 0.0.0.0. That means I’ll need to look at the routing table that’s at 10.1.10.1 to see what the next hop might be.
Here is the Comcast Business gateway that acts as my 10.1.10.1 network. And you can see there is a list in its static routing table of 10.10.10.0, which is my house network. And you can see that the gateway IP, or next hop address for that network, is 10.1.10.211.
Now, I would go to that next hop along the way to determine where the proper routes would be from that device. You would follow this path through all of the routers on your network to confirm that all of your static routes are configured properly.
If you’re having problems with a single device communicating on the network, then it might be useful to understand how that single interface is configured on your switch or on your router. So you may need to refer to all of the different settings for that individual interface on that device.
The first obvious step is to check for connectivity. Is there a link light? Is traffic passing through the device? And if it is, you can then look at the individual configuration settings for that device and make sure there’s not a duplex mismatch or an issue with the speed settings.
Here’s a list of some of the devices that are plugged into this interface. I can select any of these interfaces. This one happens to be up and enabled. But if I move to the Edit option, I can see all of the different configuration settings for SNMP, auto negotiation, auto advertisement, flow control, and other settings. This allows me to confirm that what I’ve configured on the switch matches the configuration setting that I’ve configured on the device.
If you’ve connected a device to a switch and you find that it’s DHCP address is not in the subnet that you expected, or it simply can’t communicate to any other devices on the network, then it may have an incorrect VLAN configuration. Every interface on the switch is configured as an access interface, which would be for an individual device, or it’s a trunk interface that’s designed to transport mini VLANs across a single link.
So the first step would be to look at the configuration of your switch, identify the interface where you’re plugged in, and then identify what VLAN is configured on that interface. If I connect it to interface four, I would be on VLAN 100. If I connected on interface three, I would be on VLAN 254.
You can see how easy it might be to plug into the wrong interface and, suddenly, be assigned to the wrong VLAN. So this would be an easy check to make sure that you’ve either plugged into the correct interface or that you’ve configured the correct VLAN on the interface for that device.
Sometimes problems can occur over a long period of time, so it might be useful to see a series of trends or a baseline of information to see if you can recognize where problems might be occurring. This may allow you to see what the overall utilization of the network might be at certain times of the day. Or you may be able to drill down into a specific device, so you can see exactly what that user may be doing.
Your organization may already be collecting this information. It may be taking logs and consolidating all of those logs in a SIEM, or you may have NetFlow or some other type of collection mechanism to be able to see statistics over a long period of time. From here, you can look at certain times of the day, you can identify what protocols may be traversing the network, and you can look for any errors or problems associated with those conversations.