RE: 3356 leaking routes out 3549 lately?
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:ja...@puck.nether.net] Sent: Friday, March 28, 2014 2:32 PM To: c...@2bithacker.net Cc: nanog@nanog.org Subject: Re: 3356 leaking routes out 3549 lately? On Mar 28, 2014, at 3:42 PM, Chip Marshall c...@2bithacker.net wrote: On 2014-03-28, David Hubbard dhubb...@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=dosearch_prefix=search_aspath=3549_3356search_asn=recent=1000 http://puck.nether.net/bgp/leakinfo.cgi?search=dosearch_prefix=search_aspath=3356_3549search_asn=recent=1000
Re: 3356 leaking routes out 3549 lately?
At 15:42 28/03/2014 -0400, Chip Marshall wrote: I have seen prefix leaking via AS3356 as well in the past year. -Hank On 2014-03-28, David Hubbard dhubb...@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) -- Chip Marshall c...@2bithacker.net http://2bithacker.net/
Re: 3356 leaking routes out 3549 lately?
On 2014-03-28, David Hubbard dhubb...@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) -- Chip Marshall c...@2bithacker.net http://2bithacker.net/ pgpUcrBhQwmHj.pgp Description: PGP signature
Re: 3356 leaking routes out 3549 lately?
On Mar 28, 2014, at 3:42 PM, Chip Marshall c...@2bithacker.net wrote: On 2014-03-28, David Hubbard dhubb...@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=dosearch_prefix=search_aspath=3549_3356search_asn=recent=1000 http://puck.nether.net/bgp/leakinfo.cgi?search=dosearch_prefix=search_aspath=3356_3549search_asn=recent=1000
