Comcast routes seen from the cheap seats
tim.h at bendtel.com
Fri Dec 17 14:07:00 CST 2010
I apologize in advance if this information is uninteresting. Since
there was talk about Comcast I thought I might share what I have been
looking at for the last couple weeks with how I see Comcast route
announcements from my network.
On November 22nd (early morning US/Pacific time) we noticed a
significant increase in traffic over our backup transit connection.
Looking at the traffic, I found it was mostly to Comcast. The announced
prefixes from Comcast on our backup were more specific (smaller prefix
length) than those from our main link. So x.x/16 from our main link
might be x.x/16 but also x.x.m/17 and x.x.z/17 from our backup.
This probably isn't too strange. It's a pretty effective way to
control inbound traffic. What I don't recall ever seeing is using
different source AS numbers for the more specific prefixes.
The routes kind of all end up looking like this for a given network:
x.x/16 from source-as foo on main AS path ends with foo
x.x/16 from source-as foo on backup AS path ends with foo
x.x.m/17 from source-as bar on backup AS path ends with foo bar
x.x.z/17 from source-as bar on backup AS path ends with foo bar
foo is AS7922 in every case. bar is any one of at least 24 AS
numbers assigned to Comcast, many of which are in sequential blocks
(they don't look like customer reassignments to me, in other words) and
combine to advertise all of Comcast in smaller prefixes (or so it
I didn't see any advertisements from the "bar" AS numbers on
our main link (well VERY few, and they were redundant). That single
point of data would be pretty easy to filter (by design?) which would
leave you with the more equitable distribution comprised of something
like the first two routes above.
Maybe this isn't that weird; I don't usually look this closely
at it. The built-in, single data point is handy... Well, single point
per network; I tested a single filter rule with all 24 AS #'s I found.
More information about the NANOG