eigrp summary from a summary.

[stevetyler123]

I recently introduced a rather unhelpful black hole for all traffic into a campus being unaware that manual eigrp summarisation could generate a summary prefix despite receiving no more specific prefixes in the summary prefix range. Unfortunately the admin cost of the summary was at the default of 5. I have seen examples of where this is demonstrated using a default route, but the cisco documentation does state that a more specific prefix in the eigrp topology table is required. the behaviour was seen on an Asr 1004 running 3.4.2 . Our cisco se was as surprised as I was. I'm aware of the workaround a (an admin cost of 95 fixed it), but didn't expect to have to use it. anyone else been surprised by this?

[paul driver]

hello

Int x/x
Ip summary-address eigrp xxx 0,0,0,0; 0,0,0,0,255

That should remove the implicit default null route

Res
paul

Sent from Cisco Technical Support iPad App

[stevetyler123]

The default route isn't applicable to my case and I'm aware of using the AD to get rid of the discard route. I wanted to know whether this is a bug or intentional. I.e If a router receives a 10.1.0.0/16 in eigrp and has a summary 10.1.0.0/16 configured as a summary then I would not expect that router to be able to originate the summary itself.

cheers

[paul driver]

steve- if i have understood your query

the receiving router takes on the summary route which will take this over all others routes valid for in summary range- are you then saying from the receiving router you are then performing summerisation?

res

Sent from Cisco Technical Support Android App

[stevetyler123]

yes. it sounds a bit strange but it occurred during migration from one pair of campus edge routers to a new pair, which I was trying to do with no disruption. the campus edge devices originate a default into ISPs and then redistribute all routes from osprey into eigrp, using manual summarisation to the wan edge router below them. at the final stage I removed the took the old pairs liks to the campus out of osprey hoping that the new pair would become the path for traffic into the campus. so at this point I am o longer populating the old pair of routers with specific prefixes from ospf but the new pair are fully informed. unfortunately the path from the wan to the campus has to traverse the old pair to get to the new pair. the new pair of sending summary routes to the old pair, and they then generated the same set of summaries to null0 because I hadn't yet removed the summarisation statements from that router. so all traffic trying to get to campus was discarded the old pair. had I realised this behaviour beforehand I would have ensured the summaries had an AD of greater than 90.

I've actually been trying to find a better way of creating summary routes because you have to configure them on loads of interfaces. the new pair of campus edge routers are n7k running 6.1(1) and don't support eigrp manual summary configuration under address families and also don't advertise static routes by including the static prefix under the eigrp process - it's important that they go into the wan as eigrp internal prefixes. so I'm stuck with manual summarisation of about 10 campus summaries on about 10 interfaces which makes for a clunky config.



Sent from Cisco Technical Support iPad App

[stevetyler123]

sorry ISP should read Ospf as should osprey.

[paul driver]

Steve
are you aware of candidate defaults whch can be manipualted by the default information command in the eigrp process

http://www.cisco.com/en/US/docs/ios/12_2/iproute/command/reference/1rfeigrp.html#wp1017477

res
Paul

Sent from Cisco Technical Support Android App