Route Summarization and the Route to Null0

Route Summarization and the Route to Null0

Quick Links: Video Explanation Topology Configuration Snippet


Implementing a route to NULL0 is a well-known method for dropping traffic headed somewhere you don’t want it to go, or… a location that doesn’t exist!



When we summarize networks by creating an aggregate route, we’ll normally end up with some “overflow”; it’s just the way it works when you’re working with binary. Remember, powers of 2! This is one reason we could potentially end up with traffic headed somehere that doesn’t exist.

I will create an aggregate route for the following networks to use as an example:

10.0.1.0/24
10.0.2.0/24
10.0.3.0/24
10.0.4.0/24

Aggregate Route: 10.0.0.0/21

Not only does this aggregate route cover all of the networks listed above, it also includes – 10.0.0.0/24, 10.0.5.0/24, 10.0.6.0/24, and 10.0.7.0/24. But why? Well, it is all because of how the binary works out and where the increment lies.

If we used a /20, our increment would be 16 and the aggregate route would include WAY more networks than we need. If we used a /22, then the summary would only cover 10.0.0.0 – 10.0.3.0/24, since the increment would only be 4. We would then be a network short, because 10.0.4.0/24 wouldn’t be included.

The method used to figure out this increment starts with figuring out which octet we need to work within. We don’t need to do anything with the first and second octet (the 10 and 0), since those stay the same throughout. Since each octet contains 8 bits and all of the bits for the 10 and 0 portion of the address will remain on, we now have 16 bits total for the first and second octet. Now we can look at this chart below to figure out how many additional bits we need in the third octet to adequately cover the range of networks shown above.

Chart:  128   64   32   16   8   4   2   1

Remember, if we use increments of 16 (10.0.0.0/20), that would be too large; increments of 4 (10.0.0.0/22) would be too small. 10.0.0.0/21 (255.255.248.0 subnet mask) would indicate an increment of 8 in the third octet, which is the closest we can get to a proper summary route for these networks. When we count from left to right until we get to 8, we end up with 5. So now we have 5 more bits in addition to the 16 we have already, hence the /21 in CIDR notation. All we are doing is adding up all of the bits needed to define the network portion of the summary address: 8 + 8 + 5 = 21.


The subnet mask is calculated by adding all of the numbers from the chart that are indicated by “on” bits. So if we have 8 bits for octet 1, and 8 bits for octet 2, we will add 128, 64, 32, 16, 8, 4, 2, and 1 together for the first octet, and repeat this for the second octet. 128 + 64 + 32 + 16 + 8 + 4 + 2 + 1 = 255; we now have 255.255.0.0. Now for the 5 bits in the third octet, we would add 128 + 64 + 32 + 16 + 8 = 248. That gives us the subnet mask of 255.255.248.0, and once again, the increment would be 8.

All in all, most times you won’t end up with the “perfect” summary address, there will normally be a bit of “overflow”, as I mentioned earlier. Now, a potential problem exists when we have a router that contains a summary route pointing to the next-hop address of another router that contains a default route. If that default route is pointing back to the router that contains the summary route, we may have the perfect configuration for a routing loop.

A routing loop can occur for many different reasons, but one of them is when a packet is forwarded based on a summary route that aggregates “extra” networks that do not exist. If the destination network does exist, the next-hop will have a more specific route, and everything will be fine. If the destination network does not exist, the next-hop router will not have a more specific route and it will use the default. If this default route points back to the router with the summary address, then these two devices are going to be playing packet ping pong for a while until the TTL expires.

This is where the route to NULL0 comes into play. If we take the summary address and point it to NULL0 on the next-hop router, we can prevent this from happening. The reason this works and why legitimate traffic is not discarded is because of route specificity – the longest prefix-length wins. If a more specific route exists (i.e /24 vs /21), then that packet will be forwarded accordingly. Since the summary address (which is a /21) points to NULL0 on the downstream next-hop router, any traffic it receives as a result of the summary route on the upstream router will be discarded if a more specific route doesn’t exist. It will not take the default route because a /21 is more specific than a /0.

Watch the video below for more!


Video Explanation


Topology


Configuration Snippet

Router

Router#sh ip int brief

Interface IP-Address
GigabitEthernet0/0 10.255.255.1
GigabitEthernet0/1 10.1.1.1

Router#sh ip route

S 10.0.0.0/21 [1/0] via 10.255.255.2
C 10.1.1.0/24 is directly connected, GigabitEthernet0/1
L 10.1.1.1/32 is directly connected, GigabitEthernet0/1
C 10.255.255.0/30 is directly connected, GigabitEthernet0/0
L 10.255.255.1/32 is directly connected, GigabitEthernet0/0

L3 Switch

Switch#sh ip int brief

Interface IP-Address
GigabitEthernet0/0 10.255.255.2 YES NVRAM up up
Vlan1 10.0.1.1
Vlan2 10.0.2.1
Vlan3 10.0.3.1
Vlan4 10.0.4.1

Switch#sh vlan brief

1 default active Gi0/1
2 VLAN0002 active Gi0/2
3 VLAN0003 active Gi0/3
4 VLAN0004 active Gi2/0

Switch#sh ip route

Gateway of last resort is 10.255.255.1 to network 0.0.0.0

S* 0.0.0.0/0 [1/0] via 10.255.255.1
10.0.0.0/8 is variably subnetted, 11 subnets, 4 masks
S 10.0.0.0/21 is directly connected, Null0
C 10.0.1.0/24 is directly connected, Vlan1
L 10.0.1.1/32 is directly connected, Vlan1
C 10.0.2.0/24 is directly connected, Vlan2
L 10.0.2.1/32 is directly connected, Vlan2
C 10.0.3.0/24 is directly connected, Vlan3
L 10.0.3.1/32 is directly connected, Vlan3
C 10.0.4.0/24 is directly connected, Vlan4
L 10.0.4.1/32 is directly connected, Vlan4
C 10.255.255.0/30 is directly connected, GigabitEthernet0/0
L 10.255.255.2/32 is directly connected, GigabitEthernet0/0




Did you find this page helpful?

PID: 20230225-00001