Hi all.
I've just (painfully) discovered that Cisco changed, on the IOS 12.3, the way the eBGP speakers processes updates with a confederated AS inserted in the path. I will describe shortly the scenario that worked with all of the IOS I have checked, except when I switched to 12.3:
(In the real life steup I'm using public ASNs, but I put here 65xxx ASNs)
- Two confederated routers, one with AS 65111 and another with 65112, confederated with id = 65111.
- Both router had, before confederation, eBGP peerings (with their respective ASNs) with the same ASNs, but only the AS65111 ones have to survive after confederation.
- The AS65112 confed router has a iBGP peer with another AS65112 router, but NOT in confederation (as he keeps eBGP peerings with customers, and cannot change the eBGP peerings overnight, so I connot include it in the confederation, at least as a preferred option).
- This AS65112 not-confed router gets the route announcements from the other two with a "(65111)" inserted into the AS_PATH. When announces this routes to a eBGP (non-confed) speaker, this last one sees "65112 (65111)" in the ASP_PATH (as expected)
- The eBGP speaker don't have direct peering with AS65111 at any other point. And now comes the funny part...
- If the eBGP speaker is running IOS < 12.3, it silently erases the (65111) in the AS_PATH and accepts the route to be processed.
- If the eBGP speaker is running IOS > 12.3, it shows the next messages on each update:
00:11:10: %BGP-6-ASPATH: Invalid AS path 65112 (65111) 1 received from
212.49.128.138: Confederation AS-path found in the middle
00:11:10: BGP(0): 212.49.128.138 rcv UPDATE w/ attr: nexthop 212.49.128.138, origin i, originator 0.0.0.0, path 65112 (65111) 1, community , extended community
00:11:10: BGP(0): 212.49.128.138 rcv UPDATE about 192.168.199.0/24 -- DENIED due to: as-path contains inappropriate confed info;
I've tried to parse the RFCs 1771, 1965, 3065 and 3065bis (2002 IETF draft), etc. to see if there was a review on some "official" document some months/years ago about how eBGP speakers treates the AS_CONFED_SEQUENCE/SET for a similar configuration. I've also searched the Cisco TAC & Bug library and 12.3 release notes, and found nothing relevant (AFICS).
As the point I have managed to search for, I cannot imagine WHY Cisco has changed the way it processes the UPDATES with this kind of "anomalous" AS_PATH, or at least due to WHAT cause: some bug/case reported, IETF/whatever reconsideration of how BGP should process AS confederation setups, etc.
Anybody knows if Juniper/other boxes do the same ??
Any comment/suggest/idea/help is really, really appreciated.
Regards,
Juan P. Cerezo
mailto: `echo snipped-for-privacy@fPfAn.eMs | sed 's/[NOSPAM]//g'`