On Thu, May 31, 2018 at 11:12:38AM +0000, Job Snijders wrote: > On Wed, May 30, 2018 at 03:18:45PM +0200, Claudio Jeker wrote: > > This adds a protection to handle aspaths overly large attributes in > > bgpd. The main idea is to protect other bgp routes downstream for > > hitting the limit with is often not well catched. > > I am not sure this is sound logic. The BGP UPDATE limit has been 4096 > for decades, and protocol developers are even looking into extending it > beyond 4096. If a downstream router cannot handle the legal limit that > is on them, they need to fix their non-compliance.
Adding support for beyond 4096 size should not be hard and I assume the RFC would cover many of the cases where sizes mix and stuff stops to fit. I don't fully remember why I added this but it had to do with a propagation issue because of hitting the limit. I'm not even 100% sure if bgpd is handling this in a reasonable way right now. > > The limit is currently a bit arbitarily set to 4096 - 1024 which is > > afaik the same limit that bird uses. > > Arbitrary limits are arbitrary, not sure I agree with how BIRD handles > this either. I agree with this. In general I would prefer if we just handle the case as clean as possible. One issue I see is that we can grow the attributes internally over 4096 and then the prefix fails to be sent out (to some neighbor but maybe not all). The cheap way of solving this is to allow enough scratch room as done in the diff. Another option is probably to handle the error case correctly and withdraw the update in Adj-RIB-Out. What I'm not sure is if in that case also the Loc-RIB entry should be flagged invalid. I'll check how my Adj-RIB-Out patch is handling this. Will work on a better solution for this corner case. -- :wq Claudio
