There is a lot of information contained in a routing table. In this video, you’ll learn about the details in a routing table, FHRP, and subinterfaces.
The job of a router is to evaluate incoming traffic, determine what the destination might be for that traffic, and then send it out the appropriate interface. The router is effectively determining what direction a packet might go to depending on the knowledge it has about the rest of the network. To be able to make this decision about where traffic goes, we need a routing table. And fortunately, most devices have a routing table.
The workstation that you’re using has a routing table. The servers that you’re accessing have routing tables. And, of course, the routers themselves maintain their own routing tables as well. For the router to be able to make the right decision on what the best route would be to a destination, it refers to this routing table. So everything that we do when we’re troubleshooting a router will begin and end with the information contained within that routing table.
One thing you might even find with a router is that there may be multiple ways to get to a location, and there will be a tie as to which route a router might choose. Fortunately, there are ways to break the tie within the router, and in this video, we’ll look at a number of ways that that tie-breaking process might occur.
Let’s look at a routing table. This is a routing table I pulled from a Cisco router, but it’s almost identical in form and function to routing tables that you would find in a workstation, in a server, or in any other manufacturer’s router.
In this particular example, this routing table was built based on a number of networks that were directly connected and routes that were received using the RIP dynamic routing protocol, specifically RIP version 2. If we look at the routing table, the top part of this routing table is a legend that gives us more information about the codes that are used within the routing table itself.
In the bottom is the routing table, and you can see that the first set of letters on each one of these lines corresponds back to a different set of codes that are shown in that legend. For example, you can see the first line of this routing table starts with the letter C, which means that that particular route is directly connected to this router. If we want to see the route that was added using RIP version 2, then we need to find a line that starts with an R.
And indeed, there is a line that has an R, which means that everything on this line was created because of information that was received by this router using the RIP version 2 dynamic routing protocol. And you can see there is a lot of information contained within this line. We can make out some IP addresses. There are different values, such as 120/1. And it does appear there are even counters here along with information about specific interfaces.
Let’s break out just this line of information to determine what is contained within this line of a routing table. Let’s break out this line of information to see which each one of these provides. We know that that first R at the beginning of the line is the route code. And if we refer back to the R in the list of codes, it does say that this was received using the RIP protocol.
The next one is 10.0.30.0/24. This is the destination subnet that has been added into the routing table along with a prefix length of /24. We also have the 120/1. This is actually two different values. The 120 is an administrative distance. We’ll learn more about administrative distance in a moment. And the next is a metric. We’ll also talk about metrics in this video.
You can also see that it’s via 10.10.50.2. This would be the next hop, or the destination that we would be sending this traffic if we needed to go to this particular location. We also have this time value. This is a timestamp that tells us how long this route has been active inside of this routing table. And in this case, this route has only been active for 14 seconds.
And lastly, you can see the outgoing interface that would be used. Sometimes this interface is included, sometimes it’s optional depending on the routing protocol or the router that you’re using. But it’s sometimes nice to see that this particular next hop is one that we would reach by going out a specific physical interface in that router.
So when the router is making its routing decision on where traffic should go, it’s evaluating everything in this routing table to determine if this would be the best possible route to use to forward this traffic along to the next hop.
One of the first things that a router is going to evaluate is where this particular traffic is destined. We need to be able to look at the destination IP address and compare that to the subnet IDs and prefix links that are contained within the routing table. If there’s a match, then we’ll know where to forward this traffic.
This means that this IP address range and prefix length becomes an important consideration when we begin to forward traffic. We need to look at both of those together to determine if this is the best possible route for this traffic. And if you were to look at a routing table, you may find that there are multiple routes listed to a particular subnet, but there might be different prefix lengths in each one of those lines. So you might need to evaluate each individual line of a routing table to determine which one is the most specific for this particular route.
For example, let’s say that you need to communicate with a device that’s located at 192.168.1.6, and your routing table has three different routes that would match that particular IP address. One of them is 192.168.0.0/16, the other is 192.168.1.0/24, and the third is 192.168.1.6/32. All of these would be valid routes to that particular destination, but only one is the most specific. We need to evaluate not just the subnet ID, but also the prefix length to determine which one of these is the most specific for that particular destination.
And if we were to look at 192.168.1.6, we would know that 192.168.1.6/32 would be the most specific route. In fact, that is the most specific route because a /32 is specific to an individual IP address, in this case, 192.168.1.6.
Now, if this route was not in our routing table, we would have to choose between 192.168.0.0/16 and 192.168.1.0/24. The /24 is the more specific route than the /16. So we would choose the middle route if we had a choice between those two locations.
This can get even more complicated if your routing table happens to have identical routes to a location that go to different next hops. How do you know which next hop would be the correct one if everything else was identical? And the one way that you would be able to make that determination is by examining the administrative distance.
Different routing protocols are assigned different administrative distances within the router itself. This allows the router to pick the best route based on the type of protocols or the type of information that it has received. For example, if this is a local connection, it is physically connected to the router, this is the best possible way to get to that subnet. So it has an administrative distance of 0. As you can see here, the lower the administrative distance, the better the route might be.
If you have manually configured a static route, the router assumes that you must be the most knowledgeable person for that particular route. So static routes have an administrative distance of 1. If this route was added to the routing table using EIGRP, the administrative distance is 90, and if you receive this route via OSPF, the administrative distance is 110. You can see that other dynamic routing protocols and methods are listed in this table with the appropriate administrative distance for a Cisco router.
In some cases, the routing protocol itself may be in a position where there might be duplicate routes to a particular location, and the routing protocol has to make a decision on where the best route might be. In that case, we will want to look at the routing metric to be able to break that tie.
Routing metrics are an internal value that are used by the routing protocol itself. So BGP has its own set of routing metrics, OSPF has a completely different set of routing metrics, and EIGRP uses its own set of routing metrics as well. This means that you can’t compare routing metrics across different routing protocols. The routing metrics used for BGP are very different than the routing metrics used for EIGRP, and there’s no way to compare or contrast those routing metrics across routing protocols.
But similar to an administrative distance, BGP might create its own set of routing metrics to a particular site, and then it can determine what the best route might be based on its own internal set of routing metrics. For example, the routing metrics for BGP might be 1 or 2. It will choose the route for 1 because that is the lowest routing metric.
Let’s look at our routing table for RIP version 2 again. We have that one line in the routing table, the 10.10.30.0/24. It has an administrative distance of 120 because it is RIP version 2, and it has a routing metric of 1. RIP uses the number of hops to a location as its routing metric. So we know that this particular destination is one hop away. To be able to reach that particular network, we would go to 10.10.50.2, and we would get to that particular location by sending this traffic out Serial0/3/1 on this router.
If you were to use a different routing protocol, for example, EIGRP, you would have a very different routing metric. Here is the same routing table to the same location, but we’ve enabled EIGRP instead of RIP 2. You can see this line in the routing table was created with the code D, and if we refer back to our legend, we can see that D does refer to EIGRP.
Everything in this line is very similar to what we saw with RIP version 2, although you’ll notice the administrative distance is different. It’s a 90 because EIGRP has a higher priority in its administrative distance than RIP version 2. But you’ll notice that the routing metric that is determined by EIGRP is very different than the routing metric that we saw for RIP version 2. RIP version 2 uses the number of hops, whereas EIGRP has a completely different calculation that it uses to determine what the best route might be. As you work more with routing tables and begin evaluating these routes on the fly, you’ll become much more comfortable with determining where the best next hop might be for a particular packet.
One of the challenges we have when working with routers is that there’s only one best route to a different location. If you were to look at the IP configuration of your device, you’ll notice that you have a default gateway. That default gateway is your local router that allows you to communicate outside of your local IP subnet. But you’ll notice that there is only one IP address available to list as the default gateway. You can’t list multiple gateways in that list. And this brings up a challenge, especially when you’d like to have redundant routers on a single network.
One way to provide redundancy, even though you only have places for a single default gateway, is to create a virtual IP address for the router that’s in use. We refer to this virtual IP as a VIP, and the idea is that if the primary router disappears, we can move that virtual IP to another router on the subnet so that you don’t have to change everyone’s workstation to maintain the uptime and availability of the network.
This means you, as the end user, may have no idea how many different redundant routers might be on your local subnet. And if the primary router on your network was to fail and the virtual IP address was to move, you would seamlessly continue to have connectivity using that redundant router.
Here’s how this would work. You, as the end user, would communicate to a router or a default gateway on your network, and that default gateway gives you access to other subnets or allows you to communicate out to the internet. In this particular example, we’re going to use the first hop redundancy protocol, or FHRP, in conjunction with a virtual IP address that we’ve associated with router 1. This is our active router.
Also on this same subnet is a standby or backup router. That’s our router 2. Our default gateway is going to be associated with the virtual IP address that we’ve got associated with router 1, and that means that all of our traffic will flow out of our network through router 1. If router 1 was to fail, there would need to be some type of method to failover to router 2. But router 2 has a completely different IP address. In this configuration, router 1 and router 2 are always in communication with each other.
But if router 2 suddenly realizes that it’s not able to communicate with the active router, it then removes that as the active router and becomes the active router itself. Then it takes control of that virtual IP address so that everyone on the network is now able to communicate out to the internet through router 2 using that original virtual IP address. All of the traffic will flow just as it normally did, and the end user has no idea that it’s now using a completely different router to be able to perform that communication.
Another interesting characteristic of switches and routers is that you can assign multiple interfaces to a single physical interface. We refer to these as subinterfaces. So even though there might be a single ethernet interface on a router, we can take that single ethernet interface and separate it into multiple virtual interfaces.
For example, we might have a trunk connection that has multiple IP subnets connecting to a single physical connection, but we may need to reference each individual VLAN in a trunk with a separate IP address on our router. We do that by assigning that physical interface with an additional parameter called a subinterface. So although the physical interface on that router is referred to as ethernet1/1, we would have separate subinterfaces within that physical interface that might be called ethernet1/1.10, ethernet1/1.20, and ethernet1/1.100. This means that we can set different configurations for each of these subinterfaces so that we can reference them with the appropriate IP address for that VLAN.
Here’s how this would look on a network configuration. You can see there are three devices. All three of these devices are in separate VLANs. There’s the red VLAN, the green VLAN, and the blue VLAN, and, of course, they’re connecting two separate physical interfaces on a switch. The switch then has a single cable between the switch and the router, and it’s trunking each individual VLAN within that single gigabit connection.
On the router side, we’ve configured three subinterfaces for that ethernet connection, subinterface g0/0.1, .2, and .3. And then we can assign IP addresses, subnet masks, and have completely different routing tables for each of these individual subinterfaces as if they were physical interfaces on that router.