Cisco BGP confederation treatment changes in IOS 12.3 (LONG post)

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'`

AFAIK, the problem lies actually with AS65112 non-confed router: it should not accept UPDATE with leftmost (65111) in AS_PATH. Reference:

formatting link

, section 5 "Error handling"

It is an error for a BGP speaker to receive an update message with an AS_PATH attribute which contains AS_CONFED_SEQUENCE or AS_CONFED_SET segments from a neighbor which is not located in the same confederation. If a BGP speaker receives such an update message, it SHALL treat the message as having a malformed AS_PATH according to the procedures of [BGP-4] Section 6.3 ("UPDATE message error handling").

I think in this case it should send BGP Notification error code 3 subcode 11 (malformed AS_PATH), at least what Juniper routers used to do (not sure about latest JUNOS releases). I would add AS65112 non-confed router into confederation and get rid of this issue at source. HTH Cheers Alex CCIE#13405, JNCIE#0107