EIGRP Poisoned Floating Summarization

Am I right in thinking that in IOS 15.X, a poisoned summary route will NOT make it to the routing table and will NOT be advertise? Where in IOS 12.X, the summary route does not get placed in the routing table but still gets advertised? If my understanding is correct, I'm not sure I understand the purpose for creating a poisoned summary route in this lab. If the summary route is not in the routing table nor advertise, why bring them into EIGRP using the network command in the first place?


  • Yup, Summary AD metric of 255. I'm using VIRL with vIOS 15.4. If I create a summary route with an AD of 255, the route doesn't go into the routing table NOR does it get advertised.

  • Here are my findings

    the summary-metric command behaves likes a macro, and also has order or operation issues.

    1) Classic mode injects a Null0 route when summarization is done.

    e.g int g0/1.58

         ip summary eigrp 100


     2) Multi-AF mode injects a null0 route when summarization is done at the af-interface


    router eigrp DMVPN


     address-family ipv4 unicast autonomous-system 20


      af-interface Ethernet0/1.67



    2) This classic mode null zero can be removed with the "summary-metric distance 255" command, however it behaves like a macro, clear the eigrp adj and you'ld lose the routes

    also the command uses the following order or the routes won't remain.

    a) ip summary eigrp 20

    b) summary-metric distance 255

    3)With Multi-AF mode the null0 will be removed along with the summary, once the command "summary-metric distance 255" is entered


    Happy lab time



  • In my case, regardless of the order I configured, the summary route is also removed.

    Im using CSR1000v :
    Cisco IOS XE Software, Version 03.11.03.S - Standard Support Release
    Cisco IOS Software, CSR1000V Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version 15.4(1)S3, RELEASE SOFTWARE (fc6)

    Anyways R5 and R8 can reach R4's loopback because of the default route.


  • Hi dtrujillo63

    Been a while since your post but labs still in the workbook so I guess still worth a reply.

    I've just been working through this lab and came accross your question, i.e. regards to 15.x removing the summary and NOT advertising a poisoned summary then why bring them into EIGRP via the network command?  The way I read it poisoning stops it advertising the summary (and its suppressed routes) out of the interface on which the summary is configured - routes entered via the network command are still being advertised out other interfaces.

    Hope it helps 

  • So I pulled this note from the INE lab itself:

    " From a design perspective, this configuration is for cases in which you want the router to forward traffic for destinations inside the summary that it does not have a longer match for. In previous IOS codes (before 15.x), the router performing the summarization would still advertise the summary in its EIGRP updates, even though AD of 255 was configured which prohibited the router to install it in the routing table. In newer IOS codes, the summary is no longer advertised if poisoned with AD of 255, but it is active because all routes comprised within the summary are no longer advertised out on the interface the summary is configured on."

    My guess is that this used to be useful in the older versions of code but I am struggling to see why we would even enable summery on the interface if we were just going to increase the metric and not advertise it anymore. 


    Can anyone confirm my reasoning that this type of behavior only applies to the older code and would not be any benefit in the newer code? 



  • Some more of my thoughts... and I could have this all wrong so take with a pinch of salt

    1.  I think we have to think of this as if it where a scalability issue with hundreds/thousands of routes.

    2.  Benefits of summary:  Limits query scope & saves on space in the routing table

    3. In the eigrp config guide it mentions that a summarised route is constantly checked for changes to the routes in the summary and each time a change is found the summary is readvertised.  It points out that where the number of routes and corresponding changes are large it starts to get out of hand. 


    Say its an existing router, R1, advertising networks X,Y,Z  and has interfaces eth1,eth2,eth3.  R2 is an eigrp neighbor hanging off R1's interface eth3.

    However network Z has 1000's of routes and they bounce about all over the place.  To protect neighbour router R2 and the networks behind it summarisation is being used.

    Network Z summarised on interface eth3 and this limits query scope but a summarised route is constantly checked for changes to the routes in the summary and each time a change is found the summary is readvertised.  Over time an issue arises:  the summarised route has become too chatty with adverts being continually sent.

    So we're given the task to keep chatter about Z to a minimum out interface eth3.

    What are the options?

    1. Can't use passive-interface eth3 as that kills the adjacency and stops advertising X and Y aswell as Z.

    2. We can remove the summary and filter out the routes with a distribute-list/prefix-list? I think that should work.  We might also add a static route to Z on R2, the neighbor facing eth3, and redistribute that back into eigrp.

    3. Or we could just poison the summary and again add the static to the neighbour R2. Note that in newer code poisoning the route stops the advertisements - but this wouldn't work if we still used older code.

    Thanks again

  • @ Rubbertoes


    Could you post a link to the EIGRP config guide you are referring to?



  • Hi @Dopplercisco - slight apology - it's from the command reference not the config guide



    The bit I'm referring to is in the section for summary-metric under the usage guidelines.



  • Quote from CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1, Fifth Edition Chapter 8 EIGRP, Foundation Topics > Route Summarization.

    "By default, when an EIGRP router originates a summary route, it looks up the lowest metric from among all known component routes that are covered by this summary, and uses this metric as the metric of the summary route itself. This means, however, that whenever the lowest metric from among all known component routes changes, EIGRP has to select the new lowest metric and advertise the summary route again with an updated metric. In scenarios when multiple hundreds or thousands of component routes are summarized into a single summary route, walking through this number of routes and identifying the new lowest metric each time a component route is updated (added, removed, its metric changed) can be CPU intensive, and at the same time, not worth the effort: The summary route itself does not change; only its metric is updated. Therefore, the summary-metric command in the topology basesection can also be used to define a static metric for a particular summary route. The summary route will then always be advertised with the configured metric, relieving the router of the need to walk the topology table to identify the least metric of covered components."

    Which the way I read it means that summary-metric command would stop the the summary from being continually readvertised regardless of the metric used.  Shoots holes in my previous scenario I think.

  • I just went through this section of the workbook, and it was bothering me that I couldn't figure out a use case for this. Then it dawned on me: remember that the lab is NOT a real-world exam. It seems true to me that you would not create an EIGRP summary out of an interface if you will be unable to use it, but then I realized that the purpose of this example is to allow you to get around a possible lab constraint. 

    The configuration task in the workbook says to create the summary on the interface, but to modify it so that the automatic route to Null0 is not installed. The summary-metric command with AD 255 allows you to do exactly that - create the summary, but not have the automatic route to Null0 installed because the AD is 255. Once again, I can't imagine why you would do such a thing in the real world, but it makes perfect sense to remain within the constraints of the configuration task (the purpose being, of course, to see how well you know the protocol and behavior).

    If you issue "show ip eigrp topology" on the router performing the summarization (R5 in this case), you will see that the EIGRP summary is indeed in the EIGRP topology table, but with 0 successors and an infinite FD. However, the route does not appear in the local routing table via "show ip route". 

    UPDATE: Brian took some time to explain this to me (for which I am most appreciative!) The real-world use case for this is for when you are advertising a summary through EIGRP, but the router advertising the summary does not have a longer match to all the component routes in the summary. This lets you fall back to a shorter match, such as a default route.

Sign In or Register to comment.