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
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@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
On Fri, 17 Dec 2010 15:40:56 -0500 Tony Tauber <ttauber@1-4-5.net> wrote:
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)
Thanks for responding, Tony. I will do that. -- Tim Howe tim.h@bendtel.com Data Processing 541-389-8252 BendTel GPG pubkey id: 302D210B
participants (2)
-
Tim Howe -
Tony Tauber