3356 leaking routes out 3549 lately?

Jared Mauch jared at puck.nether.net
Fri Mar 28 20:31:46 UTC 2014


On Mar 28, 2014, at 3:42 PM, Chip Marshall <chip at 2bithacker.net> wrote:

> On 2014-03-28, David Hubbard <dhubbard at 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



More information about the NANOG mailing list