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