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.
