Controlling RIP with Offset-Lists and Administrative Distance

This blog is coming from sunny and humid Jacksonville, Florida.  Today, we will look at controlling the RIP routing domain using Offset-Lists and Administrative Distance. We must remember that RIP is a distance-vector routing protocol with no idea what the network topology looks like.  With this, we can trick RIP into thinking a network is further away than it is and poison the route from being advertised or accepted from a specific interface.  The same can be said for the Administrative Distance.  RIP, by default, has an administrative distance of 120 and uses hop counts as its metric; we can take either of these two variables and influence RIPs routing decisions.

The topology we are going to use is below (the link between R2 and R3 is shut until the last scenario)

If we look at the routing table at the hub, we will see that RIP routes to 2.2.2.2 and 22.22.22.22 are being learned over both the frame-relay and point-to-point links, but CEF prefers the point-to-point link,

Verification before the configuration change

HUB_NYC#show ip route 2.2.2.2
Routing entry for 2.2.2.2/32
 Known via "rip", distance 120, metric 1
 Redistributing via rip
 Last update from 172.16.0.2 on Serial1/0, 00:00:01 ago
 Routing Descriptor Blocks:
 * 172.16.12.2, from 172.16.12.2, 00:00:09 ago, via Serial1/2
     Route metric is 1, traffic share count is 1
   172.16.0.2, from 172.16.0.2, 00:00:01 ago, via Serial1/0
     Route metric is 1, traffic share count is 1
HUB_NYC#show ip route 22.22.22.22
Routing entry for 22.22.22.22/32
  Known via "rip", distance 120, metric 1
  Redistributing via rip
  Last update from 172.16.0.2 on Serial1/0, 00:00:04 ago
  Routing Descriptor Blocks:
  * 172.16.12.2, from 172.16.12.2, 00:00:12 ago, via Serial1/2
       Route metric is 1, traffic share count is 1
    172.16.0.2, from 172.16.0.2, 00:00:04 ago, via Serial1/0
       Route metric is 1, traffic share count is 1
HUB_NYC#show ip cef exact-route 1.1.1.1 2.2.2.2
1.1.1.1 -> 2.2.2.2 => IP adj out of Serial1/0, addr 172.16.0.2
HUB_NYC#show ip cef exact-route 1.1.1.1 22.22.22.22
1.1.1.1 -> 22.22.22.22 => IP adj out of Serial1/0, addr 172.16.0.2

What if we only want 2.2.2.2 and 22.22.22.22 to be learned over the frame-relay.  But in a failure of the frame-relay to go over the point-to-point?  We can configure an offset-list on NYC_HUB.  Along with configuring a prefix-list to match on the routes 2.2.2.2/32 and 22.22.22.22/32 and configuring an offset-list to raise the metric

Configuration

HUB_NYC(config)#ip access-list standard OFFSET_JAX_SPOKE
HUB_NYC(config-std-nacl)#permit 2.2.2.2 0.0.0.0
HUB_NYC(config-std-nacl)#permit 22.22.22.22 0.0.0.0
HUB_NYC(config-std-nacl)#router rip
HUB_NYC(config-router)#offset-list OFFSET_JAX_SPOKE in 7 serial 1/2
HUB_NYC(config-router)#end

Once we clear the routing process and let it reconverge, we will learn 2.2.2.2/32 and 22.22.22.22/32 over the frame-relay link.

Verification after the configuration change

HUB_NYC#sh ip route 2.2.2.2
Routing entry for 2.2.2.2/32
  Known via "rip", distance 120, metric 1
  Redistributing via rip
  Last update from 172.16.0.2 on Serial1/0, 00:00:24 ago
  Routing Descriptor Blocks:
    * 172.16.0.2, from 172.16.0.2, 00:00:24 ago, via Serial1/0
        Route metric is 1, traffic share count is 1
HUB_NYC#sh ip route 22.22.22.22
Routing entry for 22.22.22.22/32
  Known via "rip", distance 120, metric 1
  Redistributing via rip
  Last update from 172.16.0.2 on Serial1/0, 00:00:03 ago
  Routing Descriptor Blocks:
    * 172.16.0.2, from 172.16.0.2, 00:00:03 ago, via Serial1/0
        Route metric is 1, traffic share count is 1
HUB_NYC#show ip cef exact-route 1.1.1.1 2.2.2.2
1.1.1.1 -> 2.2.2.2 => IP adj out of Serial1/0, addr 172.16.0.2
HUB_NYC#show ip cef exact-route 1.1.1.1 22.22.22.22
1.1.1.1 -> 22.22.22.22 => IP adj out of Serial1/0, addr 172.16.0.2

As we can see from the debug output, SPOKE_JAX is still sending updates out of its serial 0/1 interface.  With the update coming in on our Serial 0/2 interface with the networks, it is advertising.  The routing metric is an eight attached to these routes.

Now, if the frame-relay interface does go down, the point-to-point route will come back with a metric of 8

Simply enough, if we want to influence based on Administrative Distance, we would type in the following command. Still, to illustrate the difference, we will only be tagging routes sourced from 172.16.12.2 that match 2.2.2.2/32 to be set with a different AD.

HUB_NYC(config-router)#distance 155 172.16.12.2 0.0.0.0 OFFSET_JAX_SPOKE
HUB_NYC(config-router)#end
HUB_NYC#show ip route 2.2.2.2
Routing entry for 2.2.2.2/32
  Known via "rip", distance 155, metric 1
  Redistributing via rip
  Last update from 172.16.12.2 on Serial1/2, 00:00:04 ago
  Routing Descriptor Blocks:
    * 172.16.12.2, from 172.16.12.2, 00:00:04 ago, via Serial1/2
        Route metric is 1, traffic share count is 1
HUB_NYC#show ip route 22.22.22.22
Routing entry for 22.22.22.22/32
  Known via "rip", distance 155, metric 1
  Redistributing via rip
  Last update from 172.16.12.2 on Serial1/2, 00:00:09 ago
  Routing Descriptor Blocks:
    * 172.16.12.2, from 172.16.12.2, 00:00:09 ago, via Serial1/2
        Route metric is 1, traffic share count is 1

Leave a Comment

Your email address will not be published. Required fields are marked *