Den 23. dec. 2017 01.02 skrev "Nick Hilliard" :
This isn't about sympathy or caring or not caring or anything else, but
the uncomfortable fact that with a pool this large, mistakes are going
to happen from time to time, whether we like it or not.
It is not even a mistake but just some uninform
Ken Chase wrote:
> (And I'd fix it _right now_, but it's at my major customer's
> discretion.
ok, so this is a customer management problem. If this is the only
customer on that router, then ok, if they want to continue putting
themselves at risk of service loss, I guess that would be their concer
On Fri, Dec 22, 2017 at 5:57 PM, Scott Weeks wrote:
> Well, that's a brilliant platitude, but what do you do
> when it breaks over and over until the other guy upgrades?
> ---
>
>
> Filter that network out of your tables until it's fixed? :)
Good
Ive found some other stuff that's totally busted, but screw those who havent
patched their systems. We should not help them at all as knowlegeable stewards
of big chunks of bandwidth, we should just write stuff about how silly they
are instead:
https://www.usenix.org/system/files/conference/woot1
William Herrin wrote:
> On Fri, Dec 22, 2017 at 5:45 PM, Nick Hilliard wrote:
> If you've been hit with a known service-affecting problem that can
> easily recur without warning and which will be service affecting if it
> hits again, common sense suggests that it would be a good idea t
Push harder on upgrading. "Dec 30" is my earliest window I got from my customer
after previously pushing with previous events (didnt help that Cogent said "yeah
we agree these are silly, we'll be filtering more aggressively" -- this time it
snuck in from the less busy side of our network).
It's no
--- b...@herrin.us wrote:
From: William Herrin
Well, that's a brilliant platitude, but what do you do
when it breaks over and over until the other guy upgrades?
---
Filter that network out of your tables until it's fixed? :)
scott
On Fri, Dec 22, 2017 at 5:45 PM, Nick Hilliard wrote:
> William Herrin wrote:
> > The AS path lengths we're talking about are unreasonable.
>
> "unreasonable" is a peculiar word to use here :-)
>
> It's the internet and you can't expect other people not to do silly
> things from time to time. Th
Ken Chase wrote:
> quagga 0.99.22.4, yes i need to upgrade, as my other
> router on 0.99.23.1 seems ok.
All unpatched versions of quagga between 0.99.2 and 1.2.2 are affected.
Nick
William Herrin wrote:
> The AS path lengths we're talking about are unreasonable.
"unreasonable" is a peculiar word to use here :-)
It's the internet and you can't expect other people not to do silly
things from time to time. This is a known problem and it isn't even the
first time it's been dis
On Fri, Dec 22, 2017 at 12:40 PM, Nick Hilliard wrote:
> What router software version are you running that barfs on long as-paths?
>
Hi Nick,
Versions of quagga up until the very most recent release corrupt the
transmission of routes with very long AS paths. They add up the packet
length wrong.
On 12/22/2017 12:46 PM, Ken Chase wrote:
> quagga 0.99.22.4, yes i need to upgrade, as my other
> router on 0.99.23.1 seems ok. now coordinating with
> customers to get it upgraded is a different issue.
Will that version of quagga not support a filter list?
e.g
neighbor 38.xx.yy.zz filter-list ma
quagga 0.99.22.4, yes i need to upgrade, as my other
router on 0.99.23.1 seems ok. now coordinating with
customers to get it upgraded is a different issue.
/kc
On Fri, Dec 22, 2017 at 05:40:28PM +, Nick Hilliard said:
>What router software version are you running that barfs on long as-path
What router software version are you running that barfs on long as-paths?
Nick
Ken Chase wrote:
> And again this morn at 08:35:19 EST (13:35 UTC). I dont have access to the
> router that fed us the long route, so I cant tell what it was (since we never
> consumed it before barfing).
>
> Let's ho
And again this morn at 08:35:19 EST (13:35 UTC). I dont have access to the
router that fed us the long route, so I cant tell what it was (since we never
consumed it before barfing).
Let's hope for no more over holiday season...
/kc
On Fri, Oct 13, 2017 at 05:02:42PM -0400, Ken Chase said:
> I
Has anyone tried calling them?
Kind regards,
Job
On Fri, 13 Oct 2017 at 23:03, Ken Chase wrote:
> It is happening AGAIN.
>
> And of course it started on a friday aft 15 min before quittin' time in
> EDT:
>
> Last time it was 186.177.184.0/23 0 174 262206 262206 262197 262197
>
> *> 186.176.
It is happening AGAIN.
And of course it started on a friday aft 15 min before quittin' time in EDT:
Last time it was 186.177.184.0/23 0 174 262206 262206 262197 262197
*> 186.176.186.0/23 38.x.x.x 45050 0 174 262206 262206
262197 262197 262197 262197 262197 262197 262197
Got this reply from cogent:
"We have isolated a BGP Routing discrepancy on the Backbone. That routing has
been removed
from the Network."
So apparently they agree they shouldn't just accept this bogosity. Good on em.
/kc
--
Ken Chase - m...@sizone.org Guelph Canada
Its also happily announced onwards, e.g. by Telia:
Oct 2 07:25:09:E:BGP: From Peer ... received Long AS_PATH= AS_SEQ(2)
1299 174 262206 262206 262197 262197 262197 262197 262197 262197 262197
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197
262197 262197 262197 262197 262
Den 2. okt. 2017 00.44 skrev "Randy Bush" :
looks to me as if 262206 is trying a silly tactic to down-pref inbound
from cogent. as cogent probably prefers customers to peers, it may not
be working as 262206 expected, so they keep pounding with the same
hammer hoping for a miracle.
cogent accepts
looks to me as if 262206 is trying a silly tactic to down-pref inbound
from cogent. as cogent probably prefers customers to peers, it may not
be working as 262206 expected, so they keep pounding with the same
hammer hoping for a miracle.
cogent accepts it as they are being paid to do so; normal p
On Sun, Oct 1, 2017 at 1:05 AM, Ken Chase wrote:
> I don't quite understand the exact situation that causes the issue - our
> cogent facing router (quagga .99.22 debian) was receiving the route but
> that
> session stayed up - it was it while sending or the other igp router (also
> quagga .99.22)
On Sun, 1 Oct 2017, Hank Nussbacher wrote:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=2009-1572
Quagga 0.99.11 and earlier affected.
Fixed in 2009.
It was fixed in other OSes as well after this, I presume:
http://blog.ipspace.net/2009/02/root-cause-analysis-oversized-as-paths.html
--
Mik
On 01/10/2017 04:28, Christopher Morrow wrote:
> On Sat, Sep 30, 2017 at 12:47 PM, Ken Chase wrote:
>
>> I dont see that as the solution. Someone else will offend again.
>>
>> However, I also don't see trusting major backbones as our filters (for many
>> other reasons). Our software should be hand
I don't quite understand the exact situation that causes the issue - our
cogent facing router (quagga .99.22 debian) was receiving the route but that
session stayed up - it was it while sending or the other igp router (also
quagga .99.22) receiving (I think the latter) that was crashing their sessi
On Sat, Sep 30, 2017 at 12:47 PM, Ken Chase wrote:
> I dont see that as the solution. Someone else will offend again.
>
> However, I also don't see trusting major backbones as our filters (for many
> other reasons). Our software should be handling what's effectively a
> buffer overflow
> or equiv
I dont see that as the solution. Someone else will offend again.
However, I also don't see trusting major backbones as our filters (for many
other reasons). Our software should be handling what's effectively a buffer
overflow
or equivalent (beware long paths that are actually shellcode).
Quagga
Maybe the next best path had, had 562 prepends? :)
On Sat, Sep 30, 2017 at 12:09 PM, wrote:
> > If you're on cogent, since 22:30 UTC yesterday or so this has been
> happening
> > (or happened).
>
> Still happening here. I count 562 prepends (563 * 262197) in the
> advertisement we receive from
> If you're on cogent, since 22:30 UTC yesterday or so this has been happening
> (or happened).
Still happening here. I count 562 prepends (563 * 262197) in the
advertisement we receive from Cogent. I see no good reason why we
should accept that many prepends.
Steinar Haug, Nethelp consulting, st
If you're on cogent, since 22:30 UTC yesterday or so this has been happening
(or happened).
*> 186.177.184.0/23 38.*.*.*45050 0 174 262206 262206
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197
262197 262197 262197 262197 262197 262197 262197 2621
Thank you all very much for the feedback.
As always it is much appreciated.
From: Tom Beecher
Sent: Wednesday, September 20, 2017 8:01 PM
To: craig washington
Cc: nanog@nanog.org
Subject: Re: AS PATH limits
Too many prepends = any more than you really need for
unpatched routers may still
be out there,
then 200 should not drop any normal route. Just keep an eye on what you are
dropping
Thanks,
Jakob
Date: Tue, 19 Sep 2017 13:33:03 +
From: craig washington
To: "nanog@nanog.org"
Subject: AS PATH limits
Message-ID:
Co
Too many prepends = any more than you really need for what you're trying to
accomplish. :)
I've cutoff paths as short as 4 to as long as 8 before in different jobs
for different reasons.
On Tue, Sep 19, 2017 at 9:33 AM, craig washington <
craigwashingto...@hotmail.com> wrote:
> Hello world.
>
>
In my MUCH younger days, I may have helped abuse the global table via
prepends, but never to that level :)
On Wed, Sep 20, 2017 at 4:36 PM, Randy Bush wrote:
> > Below is an example showing an excessive amount of prepending for prefix
> > 185.135.134.0/23 at 2017-09-18 20:20:05 UTC.
>
> and the
> Below is an example showing an excessive amount of prepending for prefix
> 185.135.134.0/23 at 2017-09-18 20:20:05 UTC.
and they are probably still wondering why it does not achieve what they
want.
randy
An AS_PATH is encoded with one or more segments. Each segment has a
maximum size of 255 entries (8 bit segment length). The absolute limit
will depend on the complete BGP message size, which is limited to 4096
and extended via draft-ietf-idr-bgp-extended-messages.
The longest as_path at this ti
On Tue, 19 Sep 2017 13:33:03 -, craig washington said:
> How many AS PATHS are too many?
Well - how many do you see when things are operating nominally?
How many do you regard as "the other end is obviously too crazy to listen to"?
Add them up and divide by two.
Of course, the hard part is
Hello world.
I was wondering and forgive me if this discussions has already taken place.
How many AS PATHS are too many?
Meaning how do we determine how many to filter on transit links or public
peering links?
Thanks in advance
38 matches
Mail list logo