Comcast route server not reflecting their reality

Tue Sep 10 16:42:10 UTC 2019

Hi Will,

Unlike AS2914 which purely interconnects with AS7922, it seems that AS3356 also has direct interconnections to the various Comcast subsidiary networks which are hidden from the DFZ through no-export communities.. I figured this out due to a routing leak which happened a few years ago: https://dyn.com/blog/widespread-impact-caused-by-level-3-bgp-route-leak/

Give it a shot with the following list of communities - that should swing your traffic away from the AS3356 links: 65000:7922 65000:7015 65000:7016 65000:7725 65000:13367 65000:20214 65000:22909 65000:33287 65000:33490 65000:33491 65000:33650 65000:33651 65000:33652 65000:33657 65000:33659 65000:33660 65000:33662 65000:33667 65000:33668

Best regards,
Martijn Schmidt
________________________________
From: NANOG <nanog-bounces at nanog.org> on behalf of Will Orton <will at loopfree.net>
Sent: 10 September 2019 01:06
To: nanog at nanog.org <nanog at nanog.org>
Subject: Comcast route server not reflecting their reality

I'm seeing odditiies when trying to traffic-engineering my way around an AS 3356-to-7922 performance issue.

I buy transit from 3356 and announce my /19 to 3356. I set traffic engineering community 65000:7922 to supress announcement of it from 3356 to 7922.
When I do that, at route-server.newyork.ny.ibone.comcast.net I see the AS-path for my /19 change from:
3356 <me>
to:
2914 <me>

which makes sense as I also have transit from 2914.

So that's great, 7922 should be routing to me via 2914 or, any path not via 3356.
But then if I go to a customer location on 7922's network, and traceroute to my /19, it still goes via 7922 3356 <me> !

Is 7922's looking glass no longer reflecting actual route selection in their network? Does Comcast do traffic engineering that is not otherwise reflected at their looking glass?

If I deaggregate my /19 and announce a /24 from it to 2914, I can draw the inbound traffic to me away from the 7922 3356 path. Which is not a real nice long-term solution...

-Will

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190910/e510d3d6/attachment.html>