cancel
Showing results for 
Search instead for 
Did you mean: 

different BGP session behavior 12.6->15.3?

different BGP session behavior 12.6->15.3?

EtherNation_Use
Contributor II
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)
16 REPLIES 16

EtherNation_Use
Contributor II
Create Date: Apr 16 2013 8:33AM

I repported the same problem around August last year. Back then I recorded the BGP updates and found the exact update causing the problem. You can filter on BGP UPDATE specific parameters in wireshark, pretty useful in this case. Back then it started happening occasionally that Telecom Italia would announce a route with Aggregator AS0.

RFC4271 (BGP-4 http://www.ietf.org/rfc/rfc4271.txt) states that the only way to notify about an update error is to reset the BGP session.
It seems every other vendor has implement the mentioned draft long ago. I'm also curious why it would take Extreme so long? (from Kenneth_Oestrup)

EtherNation_Use
Contributor II
Create Date: Mar 13 2013 8:02PM

So it appears the issue was indeed the AS 0 with aggregate. I did do some searching and found the proposed draft change to the RFC:
http://tools.ietf.org/html/draft-ietf...

I'm curious as to why Extreme made this the default behavior before it made it into the RFC. There may have been a good reason, I'm just curious, since it obviously caused problems (hence the release of the patches allowing the behavior to be turned off.) (from Ansley_Barnes)

EtherNation_Use
Contributor II
Create Date: Mar 12 2013 1:11PM

Looks like that was the fix. Thanks again, everyone, for your help. (from Ansley_Barnes)

EtherNation_Use
Contributor II
Create Date: Mar 11 2013 4:08PM

Looks like 15.1.4 might have have done the trick - the session is back up, and hasn't reset throughout the entire process of downloading and installing the IPv4 route table. Once 15.2.3 is fully up with the SSH module, or 15.3.2 is out, I'll move to one of those so that we have both the fix and the features.

I'm asking our ISP to remove their inbound route filters they installed to allow us to test fixes, and I'm removing my own, and will bring the session fully up after hours to see if it's truly fixed.

You guys have been a lifesaver - our Extreme support contract didn't get renewed for some reason (we're working with our vendor to get it renewed now) so I was flying blind. I really appreciate the information and advice. (from Ansley_Barnes)
GTM-P2G8KFN