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 <[email protected]> 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 > >
