[170570] in North American Network Operators' Group
RE: 3356 leaking routes out 3549 lately?
daemon@ATHENA.MIT.EDU (Siegel, David)
Mon Mar 31 18:35:36 2014
From: "Siegel, David" <David.Siegel@Level3.com>
To: Jared Mauch <jared@puck.nether.net>, "chip@2bithacker.net"
<chip@2bithacker.net>
Date: Mon, 31 Mar 2014 22:34:08 +0000
In-Reply-To: <F9BFBD4E-558B-4457-9783-567EEF34FED5@puck.nether.net>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
There shouldn't be any reason for this happening. Our network integration =
work generally involves moving a customer ASN from behind 3549 to be behind=
3356, and once moved is generally permanent. In some cases, 3356 provides=
transit for 3549 to get to some peers that have been consolidated onto 335=
6, which would create a 3356 3549 <yourasn> path, but not the one you outli=
ne in your note, which implies 3549 providing transit for 3356. To my know=
ledge, and the guy I check with in engineering, we are not intentionally do=
ing that anywhere.
So, if you see this problem continue, please open a ticket and escalate it =
if you don't get a good response.
Dave
-----Original Message-----
From: Jared Mauch [mailto:jared@puck.nether.net]=20
Sent: Friday, March 28, 2014 2:32 PM
To: chip@2bithacker.net
Cc: nanog@nanog.org
Subject: Re: 3356 leaking routes out 3549 lately?
On Mar 28, 2014, at 3:42 PM, Chip Marshall <chip@2bithacker.net> wrote:
> On 2014-03-28, David Hubbard <dhubbard@dino.hostasaurus.com> sent:
>> Has anyone had issues with Level 3 leaking advertisements out their=20
>> Global Crossing AS3356 for customers of 3549, but not accepting the=20
>> traffic back? We've been encountering this more and more recently,=20
>> bgpmon always detects it, and all we ever get from them is there's=20
>> nothing wrong. Today it affected CloudFlare's ability to talk to us.
>> It seems to happen mostly with Europe and Asian peering points.
>> Typically lasts five to ten minutes which makes me think someone=20
>> working on merging the two networks is doing some 'no one will notice th=
is'
>> changes in the middle of the night.
>=20
> I'm not sure if it's the same thing, but I've had a few alerts from=20
> Renesys lately seeing a path to my AS via GLBX 3549 that shouldn't=20
> exist, as we only have connections with Level 3 3356.
>=20
> For example, Renesys reports "x 3549 33517" where it should only be=20
> able to see "x 3356 33517" or maybe "x 3549 3356 33517".
>=20
> (Due to Renesys policy, I can't know what x is)
It's been a few years i think now since the "level-crossing" merger so I'm =
certainly not surprised to see them doing work on this front.
This often happens during integration work, and networks of that scale I wo=
uld imagine tools that detect routing leaks need to account for this merger=
activity.
I can see I need to update my tools :)
http://puck.nether.net/bgp/leakinfo.cgi?search=3Ddo&search_prefix=3D&search=
_aspath=3D3549_3356&search_asn=3D&recent=3D1000
http://puck.nether.net/bgp/leakinfo.cgi?search=3Ddo&search_prefix=3D&search=
_aspath=3D3356_3549&search_asn=3D&recent=3D1000
