If I’m going to start with layer 3 routing, I might as well start at the beginning. While static routing might seem to be too basic for someone studying for their CCIE, I’d have to disagree. There’s actually quit a bit to it and things that I actually didn’t know before tackling the CCIE. Let’s start with a basic topology…
In a scenario like this, each router will know about it’s directly connected peers the instant you enable IP routing on the router…
That’s pretty easy to understand since the other router’s interface exists on the subnet that router1’s interface is on as well. So at this point, router1 can’t ping the 10.64.32.0/24 network that’s hanging off of router 3. To fix this with static routing, the obvious solution is to add static routes for each subnet pointing at the directly connected next hop for each router. Let’s do that, but let’s add a couple of more advanced static routing features in when we do that…
Add these routes on router1
ip route 10.0.0.24 255.255.255.252 10.0.0.30
ip route 10.0.0.24 255.255.255.252 10.0.0.22 50
ip route 10.64.32.0 255.255.255.0 10.0.0.26
Add these routes on router2
ip route 10.0.0.20 255.255.255.252 10.0.0.29
ip route 10.64.32.0 255.255.255.0 10.0.0.26
Add these routes on router3
ip route 10.0.0.28 255.255.255.252 10.0.0.25
ip route 10.0.0.28 255.255.255.252 10.0.0.21
All of these should make pretty good sense but you might have a few questions about the routes we added on router1. Namely, we added a route to the 10.64.32.0 /24 network that doesn’t list a directly connected next hop! Sin! I recall when I started in networking that this was a rule of thumb that someone gave me. Your next hop should ALWAYS be directly connected. That’s not the case, and while its not super common with static routes, it is VERY common with BGP. So let’s take a look at the recursion in action…
In the first red box we can see that the ping to the 10.64.32.1 address works. In the second box, we can see that a route lookup points to the 10.0.0.26 address which is not directly connected to router1. In the last red box, we see that CEF knows this, and knows that it needs to go to 10.0.0.30 in order to get to 10.0.0.26. A very basic example of recursion but I just wanted to show that it was possible with static routes.
The second weird thing I did with the router1 configuration was two routes to the 10.0.0.24/30 network. Note that the second route has a ‘50’ appended to the end of the command. This is what is referred to as a ‘floating’ static route. Here we are saying that the admin distance for this route should be 50 rather than 1. So what does that do?…
The router picks the one with the lowest admin distance which in this case is the route pointing to 10.0.0.30. So what’s the point of putting in a floating static? Let’s shutdown the interface on router1 that is connected to the 10.0.0.28/30 network and see…
Since router1 can no longer reach 10.0.0.30, the router has to take that route out of the FIB. When it does that, it sees that it had another route to that prefix pointing to 10.0.0.22 so it puts that in the FIB instead. You can see the admin distance of the route as the 50 piece of the ‘[50/0]’ output. Floating routes can be handy for this exact purpose. Also as a nice backup stacked on top of a dynamic routing protocol.
The last piece of static routes I want to talk about is the interface option. For instance, let’s take all of the routes off of router1 and repoint them all just out of it’s .29 interface…
no ip route 10.0.0.24 255.255.255.252 10.0.0.30
no ip route 10.0.0.24 255.255.255.252 10.0.0.22 50
no ip route 10.64.32.0 255.255.255.0 10.0.0.26
ip route 10.0.0.24 255.255.255.252 fa0/0.100
ip route 10.0.0.24 255.255.255.252 fa0/0.100
ip route 10.64.32.0 255.255.255.0 fa0/0.100
As you’ve probably guessed, it is possible to just list the egress interface a router can use rather than an actual next hop. However, when you do this, something unexpected occurs. Let’s try a series of pings and see what happens…
So here I’m pinging all of the non-directly connected interfaces. Now, let’s check our ARP table…
Notice that it has ARP entries for each and every one of the IPs that we tried pinging and that each of the entries lists the 0021.a009.993c address as the destination MAC address. Can anyone guess why?
Cisco routers have proxy-arp enabled by default. Since we aren’t telling the router exactly how to get to the those destination prefixes, rather just where to go, the router has to ARP for the destination. In this case, router2 is replying back with it’s MAC address and performing a proxy-arp. This can cause problems and is generally recommended not to be used by itself.
So there you have it, that’s static routing!