different BGP session behavior 12.6->15.3?

[EtherNation_Use]

Create Date: Feb 28 2013 8:38PM

Hi all,

I recently tried upgrading one of our core X480 routers from 12.6.3-patch1-8 to 15.3.1 as we're hoping to turn up IPv6 BGP soon. The switch is peered with another X480 inside our AS, running 12.6, and an ISP router, which is a Juniper. The IBGP session came up just fine, but the EBGP session with the Juniper came up, exchanged routes, and was shut down from the Juniper side, with an "optional attributes error." The session gets reset, and eventually the cycle repeats. Traffic flows, but the resets cause our routes to flap through that ISP, causing connectivity issues. The ISP has opened a ticket with Juniper to see what might be causing this, but has anyone seen behavior like this in moving from 12.6 to 15.3? Is there a different set of standard behavior with BGP sessions in 15.3?

Anonymized config follows. Route policy "ISPOut" referenced below restricts our exported routes to our NLRI, matching exactly.

enable bgp address-family ipv4-unicast advertise-inactive-route
configure bgp AS-number 65000
configure bgp routerid 192.168.1.2
configure bgp maximum-paths 4
enable bgp community format AS-number:number
configure bgp restart aware-only
configure bgp add network 192.168.1.0/22
create bgp neighbor 10.10.10.5 remote-AS-number 65001
configure bgp neighbor 10.10.10.5 source-interface ipaddress 10.10.10.6
configure bgp neighbor 10.10.10.5 password encrypted "blahblahblah"
configure bgp neighbor 10.10.10.5 description "ISP BGP Peer"
create bgp neighbor 192.168.1.1 remote-AS-number 65000
configure bgp neighbor 192.168.1.1 source-interface ipaddress 192.168.1.2
configure bgp neighbor 192.168.1.1 password encrypted "blahblahblah"
enable bgp neighbor 192.168.1.1
configure bgp neighbor 10.10.10.5 next-hop-self
configure bgp neighbor 10.10.10.5 route-policy out ISPOut
disable bgp neighbor 10.10.10.5 capability ipv4-multicast
configure bgp neighbor 192.168.1.1 send-community standard
disable bgp neighbor 192.168.1.1 capability ipv4-multicast
(from Ansley_Barnes)

[EtherNation_Use]

Create Date: Mar 7 2013 4:26PM

Good to know. I'm still waiting on TAC, oddly, but does 15.2.2.7-patch1-6 have the same fix? It appears to in the release notes. I'm hoping TAC will have some insight too, I'm just trying to line up all my options here. I appreciate the info. (from Ansley_Barnes)

[EtherNation_Use]

Create Date: Mar 7 2013 2:20PM

Those 2 software releases are not out yet. 15.2.3 is going to be out soon though from what I heard.

The ACL option for AS in Aggregator attribute does not exist in EXOS. But it would address this issue for sure.

I think 15.1.4 is out and contains the fix, however. (from ethernet)

[EtherNation_Use]

Create Date: Mar 6 2013 7:29PM

I'm still waiting on TAC (I don't have download access to images for 15.2.3 or 15.3.2) but I was wondering - is it possible to emulate this behavior with a policy applied to the routes received from the peer? something like if {as-number 0;} then {deny;}? Would this (assuming it's possible) even prevent the reset from occurring? I'd be more experimental in my testing of solutions, but every time this issue recurs it disrupts connectivity to our AS from the outside, and I'd naturally like to avoid that. (from Ansley_Barnes)

[EtherNation_Use]

Create Date: Mar 6 2013 4:10PM

It's been a difficult issue to troubleshoot because neither side of the session can see exactly what message(s) are causing the reset. (from Ansley_Barnes)

[EtherNation_Use]

Create Date: Mar 6 2013 4:09PM

Many thanks! I've opened a ticket with TAC to investigate this, I'll look into ethernet's suggestion as well. We were hoping to keep the features in 15.3 - is there a timeframe on the release of 15.3.2, or a way to get this config into 15.3.1? Otherwise we can attempt a rollback to 15.2.3 until 15.3.x is patched. I appreciate the info. (from Ansley_Barnes)