anyone else seeing very long AS paths?

[mike at rockynet.com (Mike Lewinski)]

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

router bgp
  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.