Configuring a router incorrectly can cause a number of network issues. In this video, you’ll learn about routing tables, the gateway of last resort, address pool exhaustion, and troubleshooting duplicate IP addresses.
If you’re the administrator of routers, then you’re certainly familiar with the importance of routing tables. We use routing tables to determine what the best next hop will be when we’re forwarding traffic through the router. So if you need to know how to get from point A to point B, we ask the router the best direction. And then it sends the information on its way.
The routing information builds a map of where data will be forwarded within that router. So you can look at default gateways. So you can look at default gateway configurations or routes that have been statically added to the router. It would certainly help if you had a map of the network. That way, you could look at the routing table, compare that to a map, and make sure that data is being forwarded out the correct interface.
Normally, when troubleshooting routing problems, you should look at the routing table of every router along that path, not only the route to get from one end of the network to the other, but you also have to confirm that you have proper routes to get back to the original workstation. This routing table is important. We need to be sure that we have a route for every possible location. And if we don’t have a route inside of our routing table, the router will simply drop that traffic. Sometimes the router will send back a message to the station that sent the traffic, called an ICMP host unreachable message. So you may be informed that that information was not able to make its way through the network because of this issue with the routing table.
So the network we have here has a laptop on one side of the network and a laptop on the other side of the network. And separating those two networks are three separate routers. Between each router, of course, is a switch that allows us to connect those together. So we would need to check the routing table in router 1 and make sure that it had a route for the destination network we were trying to reach.
So you might want to check the router 1 routing table and make sure that it had a route to the network that the laptop is connected to, which, in this case, is 10.4.10.0/24. So in this example, we’re trying to ping 10.3.10.2 from our laptop on this side of the network. You can see that that 10.3.10.2 address is located right here on the other side of router 2. So we would need to have a route to this particular subnet, which is 10.3.10.0/24.
We would go to router 1, look at the routing table in router 1, and confirm that it had a route to that particular network. If it doesn’t, we’ll receive a message like this when we try to ping that says the destination host is unreachable.
As you can imagine, on a large network, you may have a very large routing table. But often, the router can be configured in a way that summarizes these routes into one central default route. This would be our gateway of last resort. If there’s no other route in the routing table that matches the destination of the traffic that we’re sending, we could choose to have one final route that’s used as the default if none of those other routes exist.
This is usually added as a static route. So you would administratively configure that route in your router configuration. And if there’s nothing in the routing table that matches that destination, we can always use that static route as our gateway of last resort. If you have a gateway of last resort in your router, the destination is probably 0.0.0.0/0. That encompasses every host on every network. This way, if nothing else matches within that routing table, we know that this final gateway of last resort will match all other traffic.
Here’s a routing table from a router that shows a number of directly connected routes. You can see 10.10.10.0/24. We’ve also got 10.10.40.0/24 and 10.10.50/24. All of these are directly connected to this particular router.
There are also some routes that have been added with a static route to 10.10.20.0/24 and another route that has been learned through RIP. This is 10.10.30.0/24. We don’t have any other route in this particular router to tell us where to go if we don’t match any of these existing routes. In fact, you’ll see that it says that the gateway of last resort is not set for this particular router.
To add this gateway of last resort, we’ll add a static route that has a destination 0.0.0.0/0. And if you want to go to that gateway of last resort, you need to leave via 10.10.50.2. If nothing matches in this routing table, then it will use the gateway of last resort and send all traffic out 10.10.50.2 the next router down the line.
If you’ve turned on your computer and you did not receive a DHCP address and instead your system was configured with an APIPA, this could be a case where we have run out of addresses on our DHCP server. If the address pool has been exhausted, then we’ll receive an automatic private IP address in IP version 4. Although an APIPA address allows you to communicate to other devices on your local subnet, it is a nonroutable address. And you would not be able to communicate outside of your local subnet.
We would certainly check the DHCP server and see if it has available IP addresses. And if we need to add additional addresses to that, then we can do that on the DHCP server itself. Many organizations will have a management console for all of their DHCP servers. This is an IP Address Management device, or IPAM, where you can monitor and view all of the available addresses. You can look at the pools of addresses and the availability on each DHCP server.
If this network is one where people are only there for a short period of time before leaving, you might want to decrease your lease time so that there’s no more address pool exhaustion. This means we’ll be able to free up more IP addresses in a shorter period of time and therefore minimize the chance of an address pool exhaustion.
Usually, IP address information is configured and defined by the network administrator. They’ll add it to a DHCP server. And you’ll receive those parameters when you connect to the network. However, sometimes you might receive incorrect information. There might be the wrong IP address, subnet mask, or default gateway.
So you might want to check with the network administrator and confirm that the IP address values that you’ve received are correct for the interface that you’re connected to. Sometimes you can perform a packet capture to see what other devices on your local subnet might be configured as. And that might give you an idea as to the IP address or subnet mask for a particular network.
You could also try looking at other devices that are on the same network. If you’re configuring a router and there’s a different router already connected to this network, you might want to look at that configuration and see what IP address it’s been assigned. And for normal troubleshooting, we would normally start with pinging our local address. And if that works, we would ping our default gateway. And if that works, we would try an IP address on the other side of the default gateway.
If we step through this process using ping and traceroute, we should be able to put together a map of where we are in this network. And based on that information, we should be able to determine if we’ve been assigned an IP address that’s correct for the interface that we’re connected to.
Even with all the work that goes into configuring these DHCP servers, we will occasionally still see a duplicate IP address. Often, this is from a device that has been manually configured. And it’s using an IP address that exists in an existing DHCP pool. Or perhaps you’ve configured multiple DHCP servers, but you’ve accidentally overlapped those pools between the servers. And each one of those is giving out duplicate addresses.
And sometimes a device is added to the network with DHCP turned on by default, and it starts handing out IP addresses that are different than the IP addresses that you would expect on your network. With older operating systems, we would have the two devices fight over which one has priority on the network, usually based on the MAC address table of a switch. But in most modern operating systems, this duplicate IP address is discovered when a device first connects to the network. And it prevents any type of duplication. You’ll see an error message on the screen. And from there, you can decide what to do next to troubleshoot this duplicate problem.
If this is a manually configured device, you’ll want to look at the configuration you’ve been given. Check the IP address, the subnet mask, and the default gateway. If you have a different workstation that you can test with, you might want to try pinging that IP address before statically configuring it inside of a device. If you receive a response and you haven’t configured the device yet, then adding that system to the network would certainly cause a conflict.
If you do receive a response to a ping and you weren’t expecting that IP address to be on the network, then you’ll have to hunt down where that workstation happens to be. An easy way to do this is to ping the IP address and then check the ARP table. If this device is on your local broadcast domain, then you now have the MAC address of that device. And you should be able to go to the MAC address table of your switch to see which interface this device is plugged into. And if this problem is associated with two DHCP servers handing out the same address, you might want to perform a packet capture to see exactly what these DHCP servers are offering.