On Mon, Sep 16, 2019 at 11:47 AM Jeffrey Haas wrote:
> Speaking as a vendor:
>
> 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.
>
Yes, for a good implementation with sufficien
On Mon, Sep 16, 2019 at 1:25 PM Jakob Heitz (jheitz)
wrote:
> 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 Netfl
On Mon, Sep 16, 2019 at 11:43:06PM +0300, Nick Hilliard wrote:
[snip]
> If people want to shoot themselves in the foot, then they should be
> given plenty of leeway to do so. There's no reason to draw a line at
> the ietf for this sort of thing.
> https://www.ietf.org/mailman/listinfo/grow
+100
Iljitsch van Beijnum wrote on 16/09/2019 22:54:
In theory, yes. In practice, how does that work? Suppose I prepend
250 times, and a few hops away, routers start to explode because they
hit 255 or 256 ASes in the path? How do these people debug the issue?
Once they know the problem, how do they in
On Mon, Sep 16, 2019 at 09:54:36PM +0200, Iljitsch van Beijnum wrote:
> On 16 Sep 2019, at 20:37, Job Snijders wrote:
>
> > Limiting the AS_PATH length - from an IETF RFC publication process in
> > context of providing operational guidance, probably shouldn’t be “limit the
> > path length to av
On 16 Sep 2019, at 20:37, Job Snijders wrote:
> Limiting the AS_PATH length - from an IETF RFC publication process in context
> of providing operational guidance, probably shouldn’t be “limit the path
> length to avoid vendor bugs”.
> Instead, the guidance perhaps should be “please report and
Limiting the AS_PATH length - from an IETF RFC publication process in
context of providing operational guidance, probably shouldn’t be “limit the
path length to avoid vendor bugs”.
Instead, the guidance perhaps should be “please report and fix bugs”,
right? :-)
Kind regards,
Job
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 wrote:
>
> Speaking as a vendor:
>
>
>> On
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 do
Speaking as a vendor:
> On Sep 16, 2019, at 11:18 AM, David Farmer wrote:
> On Mon, Sep 16, 2019 at 8:25 AM Job Snijders 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
> excess
On 16 Sep 2019, at 18:03, john heasley wrote:
>> Furthermore, excessively long paths will use more memory
> Not significantly. It is not length that represents large consumption
> by AS-PATHs, its variance of paths in the RIB. ie: no sane
> implementation copies the path to every RIB entry, it
Mon, Sep 16, 2019 at 10:18:09AM -0500, David Farmer:
> Furthermore, excessively long paths will use more memory
Not significantly. It is not length that represents large consumption
by AS-PATHs, its variance of paths in the RIB. ie: no sane
implementation copies the path to every RIB entry, its
On Mon, Sep 16, 2019 at 8:25 AM Job Snijders wrote:
> On Mon, Sep 16, 2019 at 16:19 John Kristoff wrote:
>
>> On Mon, 16 Sep 2019 08:21:08 +
>> Iljitsch van Beijnum wrote:
>>
>> > Dear Global Routing Operators,
>>
>> And medium-size academic netop.
>>
>> > My question: is rejecting excessiv
On Mon, Sep 16, 2019 at 16:19 John Kristoff wrote:
> On Mon, 16 Sep 2019 08:21:08 +
> Iljitsch van Beijnum wrote:
>
> > Dear Global Routing Operators,
>
> And medium-size academic netop.
>
> > My question: is rejecting excessively long AS paths something we want
> > to do?
>
> It is somethin
On Mon, 16 Sep 2019 08:21:08 +
Iljitsch van Beijnum wrote:
> Dear Global Routing Operators,
And medium-size academic netop.
> My question: is rejecting excessively long AS paths something we want
> to do?
It is something I've decided to do. When I looked at the paths we were
getting a few
Hi Iljitsch,
This is somewhat alluded to in RFC 7454, section 9:
Network administrators SHOULD accept from customers only 2-byte or
4-byte AS paths containing ASNs belonging to (or authorized to
transit through) the customer. If network administrators cannot
build and generate
Dear Global Routing Operators,
I attended a presentation by someone from a tier-1 network who talked about BGP
filtering. One thing he mentioned is filtering out prefixes with excessively
long AS paths, in their case paths longer than 40 AS hops.
There are a few best practices style documents t
17 matches
Mail list logo
