Understanding Static Routing

In computer networking, few commands are as powerful and directly impactful to the functionality of a network as a static route. You can use them to override the routing decisions of a dynamic protocol or just as easily make them a backup route when that protocol fails. Use them to redistribute into a routing protocol or use it as a pseudo filter. Attach an SLA to one and you can add dynamic features to the route.

dev-box-2#sh run int Loopback0
interface Loopback0
 ip address 192.168.10.1 255.255.255.0
end

dev-box-2#sh ip route 192.168.10.1
Routing entry for 192.168.10.1/32
  Known via "connected", distance 0, metric 0 (connected)
  Routing Descriptor Blocks:
  * directly connected, via Loopback0
      Route metric is 0, traffic share count is 1

In its most minimalist form, a static route is simply a destination subnet and an outgoing interface. You may not realize this, but your router is putting this route into the routing table whenever you configure an IP address on an interface. These are connected routes (called Local routes in NXOS). Connected routes are used for looking up traffic destined to local subnets, but they're also used in the recursive route lookups when you create routes with a next-hop address configured.

This will work but creates an entry in Router A’s ARP table for every address in the 10.1.1.0/24 network that it forwards traffic to. Using a next-hop address for Router B’s G0/1 IP address reduces this to a single ARP entry on Router A for any network beyond Router B.

While these routes are very useful for locally connected subnets, they are inefficient for networks that are multiple hops away. In the case of the destination subnet being further than directly connected, the local router will ARP for the destination IP address and if the next-hop router is configured to allow proxy-arp, it will get an ARP response from that router. While this works, it doesn't scale well and creates overly large ARP tables. Routers that rely on proxy-arp for a large number of destination IP addresses could end up exhausting the TCAM tables.

If the interface specified as the outgoing interface of a route is shut down either manually or by a failure of the interface, the route is removed from the routing table.

dev-box-2(config)#ip route 10.1.1.0 255.255.255.0 GigabitEthernet0/1

dev-box-2#sh ip route 10.1.1.0
Routing entry for 10.1.1.0/24
  Known via "static", distance 1, metric 0 (connected)
  Routing Descriptor Blocks:
  * directly connected, via GigabitEthernet1
      Route metric is 0, traffic share count is 1

Let’s take a look at the routing entry that was created by that static route with the command, “show ip route 10.1.1.0”:

Next-Hop Routes

Next, we have the route that most people are familiar with and that's one with a next-hop IP address. We tell the route, “Here’s the destination subnet and then send it to this IP address." Of course, these routes can't function without a connected route to look up that next-hop IP address. If this recursion fails, the route can't be placed into the routing table.

There's no rule that says that the next-hop IP address has to be locally connected, however. It could be configured as an address that's multiple hops away and the local router will just recurse its routing table to find the outgoing interface. This does not however guarantee that the packet will get to the next-hop router specified in the static route as this is dependent on the routing lookup of the next-hop router.

dev-box-2(config)#ip route 10.1.1.0 255.255.255.0 10.2.2.2

We can check the effect that this has on the routing table with the command, “show ip route”. The pro move though is to specify that we only want to look at statically configured routes. We can specify static only routes with the commmand, “show ip route static”:

dev-box-2#sh ip route static
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is 10.10.20.254 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 10.10.20.254, GigabitEthernet1
      169.254.0.0/24 is subnetted, 1 subnets
S        10.1.1.0 [1/0] via 10.2.2.2

Take a moment to familiarize yourself with the route codes at the top of that output. Occasionally while troubleshooting you’ll find a route that you expected to be in the routing table but it’s not coming from the routing source that you expected it to come from.

Being Specific

The most important rule to remember throughout all of this is that the most specific route will always win when it comes to the route lookup. It doesn’t matter if you’ve got a static route for a /16 network if there’s a /24 route being learned from RIP. Be specific if you need to be.

dev-box-2(config)#ip route 10.10.0.0 255.255.0.0 10.2.2.2
dev-box-2(config)#ip route 10.10.10.0 255.255.255.0 10.1.1.1 254

In the config example above, traffic destined to 10.10.10.5 is going to be forwarded to 10.1.1.1 rather than 10.2.2.2 even though I’ve set the administrative distance on the second route statement to be significantly worse than the first. This applies to routes learned from any dynamic routing protocol as well. Specificity always wins.

Administrative Distance

Administrative Distance is a metric by which a router ranks the importance of a source of routing information. Refer to this table to see the default administrative distance that Cisco assigns to each routing protocol. By default, Cisco routers give static routes an administrative distance of 1.

Static routes, by default, take precedence over any dynamic routing protocol. This is a handy way to force a particular router to override a routing decision made by dynamic processes. If, however, you wanted to have a backup route in your routing table that is statically configured, we can configure what's known as a "floating static route". This means simply that we configure the static route with an adminstrative distance higher than that of our dynamic routing process and it will be placed into the routing table if there is no route learned by any other means.

A scenario that this might be useful is if we have two redundant internet circuits and we would like to prefer one circuit over the other. As soon as the primary circuit fails, the floating static route takes over. As soon as the interface used for recursion on the first route goes down, the route with the next highest AD will take over. In this case, the route with the next highest AD is the route to 10.0.1.2. In this scenario, the 1.1.1.1 interface would need to transition to down for the backup route to work. Merely being inaccessible isn’t enough to trigger a failover. Floating static routes can be used as backup routes to BGP, EIGRP, OSPF, IS-IS, or RIP.

dev-box-2(config)#ip route 0.0.0.0 0.0.0.0 1.1.1.1
dev-box-2(config)#ip route 0.0.0.0 0.0.0.0 10.0.1.2 254

Using Static Routes to Prevent Advertisements in EIGRP

Using one of the fundamental rules of EIGRP, we can use a static route to prevent further advertisement of a particular prefix. Simply put, EIGRP will not readvertise a route to its neighbors that was not the best route.

Given the scenario that a router was learning a default route via EIGRP and had one statically configured, the EIGRP route would be filtered out of updates and progress no further through the network. This can act as a pseudo-filter for routes. It may not appear to be as intentional as filtering routes by another method but it's just as effective.