Wednesday, October 26, 2011

Null routes: Float or sink?

I've seen a configuration on customer networks that I just don't understand.

Let's say that some routing tier has been allocated the 10.10.0.0/16 network block. Because only some of that space is actually in use, a null route has been added so that traffic for unused portions of the space doesn't wander the network aimlessly:
Dist-A#show ip route 10.10.0.0 255.255.0.0
Routing entry for 10.10.0.0/16
Known via "static", distance 1, metric 0 (connected)
Redistributing via ospf 1
Advertised by ospf 1 subnets
Routing Descriptor Blocks:
* directly connected, via Null0
Route metric is 0, traffic share count is 1

Dist-A#
So far so good, but look what's on Dist-B:

Dist-B#show ip route 10.10.0.0 255.255.0.0
Routing entry for 10.10.0.0/16
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 1
Last update from 10.10.0.0 on FastEthernet0/0, 00:24:56 ago
Routing Descriptor Blocks:
* 10.10.0.0, from 10.10.0.0, 00:24:56 ago, via FastEthernet0/0
Route metric is 20, traffic share count is 1

Dist-B#
Uh-oh. Dist-B isn't trashing traffic for these unused destinations. It's learned the route from Dist-A via an IGP. Maybe they forgot to null route that block on Dist-B?

Dist-B#show run | include ip route
ip route 10.10.0.0 255.255.0.0 Null0 254
Dist-B#
Okay, I get it. Dist-A null-routes the unused portions of 10.10.0.0/16. If Dist-A fails, then Dist-B's floating (AD of 254) route gets installed so that Dist-B can null-route the unused space.

I'm sure it works fine, but I don't understand why the floatiness is useful. Someone had to design this and type it in. I would like to understand the motivation behind it. Why not just add a normal (AD of 1) null route to both distribution routers?

Is there an advantage to doing things this way? What is it?

3 comments:

  1. By having all the invalid traffic (during normal operations) head to the same place it gives you a single point to monitor if you want to look at what is heading towards that IP space?

    ReplyDelete
  2. BGP routing involved? That would require an active IIGP-route for a prefix to be considered to be anounced over BGP...

    ReplyDelete
  3. Anon's suggestion is a reasonable one. I don't think that's what was going on, but it's a reason somebody might choose to configure things this way.

    Roman, no BGP involved. Even if it were, BGP doesn't care whether the route comes from an IGP or from OSPF, it only cares that the route exist in the IP routing table.

    ReplyDelete