anyone else seeing very long AS paths?
mike at rockynet.com
Tue Feb 17 13:44:04 CST 2009
Jack Bates wrote:
> Just to reconfirm. The issue arrives with sending an update, not
> receiving? So if an ISP does not have a limit and their IOS cannot
> handle this, they will send an invalid BGP UPDATE to the downstream
> peers causing them to reset regardless of their max as-path settings?
> Just trying to reconfirm, so I can inform my customers if there was
> anything they could do to prevent it, or if it is actually their
> provider that instigated the peer reset by sending invalid updates.
We were dropping ALL prefixes and the eBGP session was still resetting.
I used this filter:
ip prefix-list drop seq 1 deny 0.0.0.0/0 ge 32
neighbor x.x.x.x prefix-list drop in
I confirmed via "show ip bgp sum" that there were 0 prefixes received.
Of course "show ip bgp nei x.x.x.x received-routes" still showed the
routes coming in, they just weren't being installed into the tables (or
redistributed to any iBGP neighbors).
So, to reiterate:
1) "bgp maxas-limit 75" had no effect mitigating this problem on the IOS
we were using. That is: it was previously verified to be working just
fine to drop paths longer than 75, but once we started receiving paths >
255 then BGP started resetting.
2) "prefix-list drop in" ensured that ALL eBGP learned routes were
dropped before being installed or re-advertised. eBGP still reset itself
every three minutes or so, which was about the length of time it took
for the session to restore itself and get to the offending route.
I believe that upgraded IOS is the ONLY possibly fix in some cases.
More information about the NANOG