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