EIGRP Summary - Shooting Yourself in the Foot

During my lab session the other night I was bitten by EIGRP summary routes and it took a little bit for me to wrap my head around what happened. So I figured it was a good idea to blog about the unexpected behavior.

The topology is as follows:

  • R1, R2 and R3 run EIGRP AS 100 on all interfaces. Auto-summary is disabled
  • R1 is the Internet facing router and generates a default route via EIGRP 
  • R1 connects two internal networks, and
  • R2 connects two internal networks, and

Im not going to post the base config of each router but its as simple an EIGRP config as you can get. I will point out, the default route on R1 is configured using the summary-address interface command.

Looking at the routing table on R3 you see all routes as expected. This is a good time to remind everyone that all routes that fall within the summary prefix are filtered from advertisements to EIGRP neighbors.

Wanting to condense R3s routing table further we decide to summarize all 192.168.x.x subnets at R2.

Alright lets check our routing table on R3 to make sure we summarized correctly. We should see a default route from R1 and a summary route from R2.

Hell yeah Im freaking awesome!! Now lets ping from R3 to make sure we have full reachability and I can get back to playing GTA V.

Alright networks attached to R2 are good.

Crap! Can't communicate with networks attached to R1.

The routes are in the routing table and everything looks good on R3, so what is going on? Take a look at the routing table on R2 and you will start to see what is going on here.

R2 has a EIGRP route pointing to Null0 for the summary route. So all traffic hitting R2 destined for the space will be directed out the Null0 unless there is a better route in the routing table. This is normal operation of summary-routes.

R2 has directly connected routes to both and which is expected and everyone else has the default-route pointing to R1. So why is R2 dropping traffic destined to and

Even though it took me a couple minutes to beat it into my head, the answer here is simple. The route to Null0 wins because it's a more specific match than the default summary learned via EIGRP. I should slap myself for not seeing this the first time...

With that in mind if we place a static route on R2 for the summary address we should restore reachability from R3. Since the prefix length of both the summary and static route match, AD will now come into play.

Also keep in mind that EIGRP gives all summary routes an AD of 5. So as long as the static route is configured with an AD of 5 or less, the static route will be installed in the routing table.

Lets test with both an AD of 6 and 5 just to see if Im correct.

As expected with an AD of 6 the summary to Null0 is still showing up. Now change the static route to an AD of 5

R2 now inserts the static route as the best route and R3 can ping everyone just fine.

Yay! Now that we have the routing working what is the best way to approach this situation?

Honestly, Im not sure of the best approach. For the CCIE lab maybe a single static route is fine and we can move on but from what I understand static routes are not acceptable. Also I'm not a fan of static routes as it then introduces a manual process to route propagation.

I see two three options to this scenario. Good catch +Kenneth George
  1. Use a static default route on R1 and redistribute into EIGRP. EIGRP will then advertise both the default route and the and networks. R2 can then use the summary-address command to summarize the prefix to R3.
  2. Use leak-maps on R1 with the summary-address command to allow the and routes to still be advertised to R2. R2 can then use the summary-address command with the same results as the first option. But once again we are having to specify leaked routes manually on R1 this time either in an ACL or prefix-list.
  3. As mentioned in the comments below setting the AD of the summary-address command on R2 will effectivly remove the summary route to Null0 and allow R2 to pass traffic to and via the default summary route.

Option 3 is a great solution and requires no static routes. I also like the static default route option on R1. Its clean and you only have to create a single static route and the rest is learned automatically via EIGRP.


  1. Nice explanation! I'm sure I would have had the same issue in a lab sooner or later.

  2. Wouldn't setting the metric to 255 for the summary (removing the null0 route) also fix it? That's my direction for a solution regarding the CCIE.

    1. Absolutely! I completely overlooked the AD option on the summary-address command. Great catch.

      Setting the AD to 255 on the summary-address command effectively removes the Null0 route and allows R2 to use the default summary route to pass traffic to R1 for those two subnets.



Note: Only a member of this blog may post a comment.