Routing - Using the Null0 interface to prevent routing loops

When creating a rout to the Null0 interface to prevent routing loops it seems almost as if we are creating a route to purposefully drop or black-hole traffic. This initially sounds counterintuitive, however, it makes perfect sense. Take this OSPF topology as an example:

Let’s say that R1 has only three subnets. The fourth one has not been configured.

When we create a summary route in R1 which is the ABR, we advertise the single summary route of 172.16.0.0/22 to R2 rather than three individual routes. That makes OSPF advertisements more efficient. R2 now has an entry in its routing table that looks something like this:

O IA 172.16.0.0/22 [110/2] via 192.168.12.1, 00:03:26, FastEthernet0/0

At the same time, R1 creates a summary route pointing to the null interface, that looks something like this:

O 172.16.0.0/22 [110/2], 00:03:26, Null0

Now, when R1 wants to send a packet to 172.16.1.5, for example, it will match the summary route in its routing table, and be sent to R1.

Now this is the key to the whole situation: When R1 receives that packet, it looks up the destination in the routing table and it matches the specific 172.16.1.0/24 route, not the null summary route! So routing can take place correctly! Remember, routing table matches will always match the more specific prefix, and a /24 is more specific than a /22.

So why is the null route there? Well, what if R2 wanted to send traffic to 172.16.3.3? That network doesn’t exist on our R1 router, but it is included in the summary route! So, if such a packet reaches R1, we want it to be explicitly handled. It wouldn’t match any more specific routes, but it would match the null route. Since R1 has no route to that destination, it is safest to simply discard the packet.

Therefore null route will discard only those packets that don’t match a more specific route found within the summary.