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.
David
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
I have seen prefix leaking via AS3356 as well in the past year.
-Hank
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