Back to the basics today. I have seen this pop up a few times and wanted to offer some clarification on what seems to be a cloudy issue for CCNP (and some CCIE) candidates. I’ve seen quite a few times now where engineers see a route to Null0 in a Cisco router and assume instantly that the router is “black holing” traffic.


Sometimes, a route to Null0 is inserted into the routing table when performing summarization with nearly every routing protocol in common use today. Take this example topology, for instance:


After initial configuration, the routing table on R1 looks like this:

R1#show ip route

[output omitted] is subnetted, 1 subnets
C is directly connected, FastEthernet0/0
D [90/156160] via, 00:00:20, FastEthernet0/0
D [90/156160] via, 00:00:15, FastEthernet0/0
D [90/156160] via, 00:00:10, FastEthernet0/0
D [90/156160] via, 00:00:07, FastEthernet0/0
D [90/156160] via, 00:00:07, FastEthernet0/0

Let’s tidy this routing table up with a nice summary route from R2 that encapsulates these five routes. After all, they all have the same next hop, there’s really no need for the specificity.

R2(config)#int Fa0/0
R2(config-if)#ip summary-address eigrp 10

Of course, the world (even the theoretical one) isn’t perfect, so the best summary route we can do for this is a /21, which would encapsulate up through We don’t have those networks assigned, and if this were a real world scenario, I’d go ahead and use a /22 and leave that extra network out of the summary, to avoid the problem we’re about to explore. However, for the sake of being exhaustive and learning more about this feature, let’s continue with this method.

Using this summary address, we see that our five networks have been nicely summarized down to

R1#show ip route eigrp
D [90/156160] via, 00:02:49, FastEthernet0/0

And now for the moment when everyone (at least once) freaks out a little bit. Back on R2, we seem to have created a route to Null0.

R2#show ip route eigrp
D*EX [170/28416] via, 00:06:11, FastEthernet0/0
D is a summary, 00:04:37, Null0

But Null0 is the “bit bucket”!! That’s bad!

Well….Null0 is indeed the virtual interface on every Cisco router that is used to “black hole” traffic, for various reasons. Don’t worry though….this is no reason to fret. Take a look at R2’s full routing table:

R2#show ip route

[output omitted] is subnetted, 1 subnets
C is directly connected, FastEthernet0/0
C is directly connected, Loopback1
C is directly connected, Loopback2
C is directly connected, Loopback3
C is directly connected, Loopback4
C is directly connected, Loopback5
D*EX [170/28416] via, 02:41:29, FastEthernet0/0
D is a summary, 02:39:55, Null0

You’ll notice that our summary route would also encapsulate the networks - Since these networks are not specifically present in the routing table, normal behavior would dictate that the default route (which is incidentally being advertised from R1) be used to get traffic out. So, for any of the networks that are part of the summary route but not locally represented, traffic would bounce back and forth between R1 and R2, causing a routing loop.

However, most routing protocols are aware that it’s quite common to have a summary route that doesn’t perfectly encapsulate the networks you intend to summarize. As a result, they inject a routing table entry with a length equivalent to the mask specified in the “ip summary-address” command, with a next-hop interface of Null0. Since legitimate traffic will choose the specific routes anyways (remember, the **number one rule of routing** is “the most specific route always wins”) the only traffic that this route will be used for is the potentially looping traffic destined for non-existent networks like - networks that are part of the summary, but do not actually exist anywhere in the topology.

If you really want to remove this route - maybe to lessen confusion - you can advertise this summary address AND specify the Administrative Distance while doing so. An AD of 255 is a quick way to mark a route “dead”, so this action will remove the route from the table.

R2(config)#int Fa0/0
R2(config-if)#no ip summary-address eigrp 10 5
R2(config-if)#ip summary-address eigrp 10 255

Keep in mind, AD is not an attribute that can be transmitted through routing updates, so this merely affects the local interpretation of the summarization we’re performing, so the summary route will still be advertised to the EIGRP neighbors, who are by default programmed to accept this standard EIGRP route and install it with an AD of 90. So in effect, this will “remove” the route (more like make it ineligible) on R2, but R1 will still receive and use it. So…while it is removed on R2:

R2#show ip route eigrp
D*EX [170/28416] via, 03:03:19, FastEthernet0/0

it is still present with the correct AD on R1, as it was before the change:

R1#show ip route eigrp
D [90/156160] via, 00:02:09, FastEthernet0/0

However, we have essentially disabled the preventative routing measure that this feature had provided us. A ping to an address in the network (which is inside the summary route but if you recall, does not exist on R2) will result in a routing loop.


Type escape sequence to abort.
Tracing the route to

  1 36 msec 40 msec 16 msec
  2 24 msec 16 msec 24 msec
*Mar  1 04:30:38.222: ICMP: time exceeded rcvd from
*Mar  1 04:30:38.266: ICMP: time exceeded rcvd from
*Mar  1 04:30:38.282: ICMP: time exceeded rcvd from
*Mar  1 04:30:38.302: ICMP: time exceeded (time to live) sent to (dest was
*Mar  1 04:30:38.306: ICMP: time exceeded rcvd from
*Mar  1 04:30:38.322: ICMP: time exceeded (time to live) sent to (dest was
*Mar  1 04:30:38.322: ICMP: time exceeded rcvd from
*Mar  1 04:30:38.342: ICMP: time exceeded (time to live) sent to (dest was
*Mar  1 04:30:38.342: ICMP: time exceeded rcvd from *  *  *

Addendum: ICMP Redirects

In labbing this topology up, I was not immediately able to cause a routing loop, due to the fact that ICMP Redirects were enabled (they are by default in IOS - not sure if this has changed in later versions).

ICMP is able to send messages to neighboring devices when a packet arrives on the same interface that it would be leaving on. Obviously this would indicate some kind of inefficient routing, so R2 basically said to R1 - “You could do this more efficiently if you wanted, here, try the next-hop address that I’m using for that traffic.”

Since this next-hop was R1 itself, R1 viewed this as a bogus redirect:


Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:

*Mar  1 04:28:37.110: ICMP: bogus redirect from - for use gw
*Mar  1 04:28:37.110:       gateway address is one of our addresses.

Easy enough to disable for the purposes of demonstrating the routing loop mentioned earlier:

R2(config)#int Fa0/0
R2(config-if)#no ip redirects

Read here for more on ICMP redirects on Cisco IOS:

Matt Oswalt

Matt Oswalt is an all-around technology nerd, currently focusing on networking, software development, and everything in between. He is at his happiest in front of a keyboard, next to a brewing kettle, or wielding his silo-smashing sledgehammer. He spends his days diving deep into the intersection of networking and software, and likes to blog about his experiences when he comes up for air. You can follow him on Twitter or LinkedIN.