RE: 3356 leaking routes out 3549 lately?

["Siegel, David" <David.Siegel () Level3 com>]

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 3356, which would create a 3356 3549 <yourasn> path, but 
not the one you outline in your note, which implies 3549 providing transit for 3356.  To my knowledge, and the guy I 
check with in engineering, we are not intentionally doing 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] 
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 
> > Global Crossing AS3356 for customers of 3549, but not accepting the 
> > traffic back?  We've been encountering this more and more recently, 
> > bgpmon always detects it, and all we ever get from them is there's 
> > 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 
> > working on merging the two networks is doing some 'no one will notice this'
> > changes in the middle of the night.
>
> I'm not sure if it's the same thing, but I've had a few alerts from 
> Renesys lately seeing a path to my AS via GLBX 3549 that shouldn't 
> exist, as we only have connections with Level 3 3356.
>
> For example, Renesys reports "x 3549 33517" where it should only be 
> able to see "x 3356 33517" or maybe "x 3549 3356 33517".
>
> (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 would 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=do&search_prefix=&search_aspath=3549_3356&search_asn=&recent=1000

http://puck.nether.net/bgp/leakinfo.cgi?search=do&search_prefix=&search_aspath=3356_3549&search_asn=&recent=1000