Comcast routes seen from the cheap seats

Fri Dec 17 20:40:56 UTC 2010

This is part of normal cleaning up of more-specifics (lessening our routing
table footprint).

Apologies for any downstream effects.

Please feel free to contact me if there’s a problem you’re seeing and need
help with.

Thanks,
Tony

(speaking on behalf of AS7922)

On Fri, Dec 17, 2010 at 3:07 PM, Tim Howe <tim.h at bendtel.com> wrote:

> 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
> seems).
>
>        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.
>
> --
> TimH
>
>