Operator here.

We have limitations around 128 to avoid some vendor bugs. I suspect we could 
remove them but people with mental histories of pain always worry about that 
change. 

Sent from my iStarship

> On Sep 16, 2019, at 12:42 PM, Jeffrey Haas <[email protected]> wrote:
> 
> Speaking as a vendor:
> 
> 
>> On Sep 16, 2019, at 11:18 AM, David Farmer <[email protected]> wrote:
>>> On Mon, Sep 16, 2019 at 8:25 AM Job Snijders <[email protected]> wrote:
>>> Can we articulate what problem is solved by limiting the AS_PATH length?
>> 
>> I'm aware of a Netflow tool that crashes when it receives BGP paths that are 
>> excessively long.  Furthermore, excessively long paths will use more memory 
>> which could cause stability issues in some situations.
> 
> There are a number of bugs in implementations over the life of BGP related to 
> path length.  In particular, overflows either in the number of ASes in the 
> segment (max 255), where a second segment needs to be created; overflows in 
> the length of the path attribute and needing to switch the size of the length 
> field (the extended bit).
> 
> This is the primary reason we've tended to see strong pushes for filter 
> length - attempts to avoid exercising such bugs.  Ideally, implementations 
> should have been upgraded to avoid them by this point.
> 
> I am not optimistic. :-)
> 
> With regard to memory use, it's not a real problem for implementations and is 
> generally noise in the real world vs. the total number of paths in your 
> router.
> 
>> 
>> Having a sanity limit on path length isn't a bad idea. Personally, I think 
>> 20 a little on the short side, but 40 or 50 seems like a reasonable limit. 
>> Anything beyond that is most definitely excessive, and I'm not sure you 
>> would even want to use such a path if it were real.
> 
> Quoting a coworker: constants are almost always wrong. :-)
> 
> -- Jeff
> 
> _______________________________________________
> GROW mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/grow

_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow

Reply via email to