I agree with Jeff.
Not that Cisco has these bugs :)
Just kidding Jeff, I take your point.
Cisco once had a bug at 255. It's long been fixed.

I'll add that Netflow can use the AS-PATH. When that option is used,
the AS-PATH is downloaded to FIB, which is more constrained of memory than BGP 
is.
I don't know what kinds of bugs could result from long AS-PATHs in Netflow 
collectors.

Regards,
Jakob.

-----Original Message-----
From: GROW <[email protected]> On Behalf Of Jeffrey Haas
Sent: Monday, September 16, 2019 9:43 AM
To: David Farmer <[email protected]>
Cc: Iljitsch van Beijnum <[email protected]>; [email protected]
Subject: Re: [GROW] Limiting AS path length?

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