RE: BellSouth prefix deaggregation (was: as6198 aggregation event)
IMHO, I think we should create a route-set obj like call it... RS-DEAGGREGATES and list all the major irresponsible providers's specific /24's in it...
CASE: Business has a /24 from X provider in order to multihome. That /24 is de-aggregated from a /19, with this policy that /24 may not be routed. possible exception: When 2002-3 get passed by ARIN, this could even take on new meaning. ARIN says they will use a single /8 for the handing out of /22-/24 for multihoming end users. will you then filter those /24's also? Also: What happens when that /24 for Business Y noted above is dual routed by ISP A and ISP B, and ISP A's upstream filters but ISP B's does not? Will there be asymmetric routing? Finally: Can anyone from BellSouth, explain the end goal of the de-aggregation? I suspect with 40 + ASs they may be rebuilding their network with a recently announced list of new IP services and DSL growth as asked for under the Federal government Rural DSL regulations... (I'm not trying to defend them, just giving some possibilities)
So some ASes who wish to not accept deaggregated specifics using RPSL can update their AS import policy to not import RS-DEAGGREGATES...
Just my humble opinion.. Comments/critics welcome :)
-hc
-- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | haesu@towardex.com Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | POC: HAESU-ARIN
On Sun, Oct 12, 2003 at 11:26:49AM -0400, Jared Mauch wrote:
On Sun, Oct 12, 2003 at 01:02:57PM +0000, Stephen J. Wilcox wrote:
Can anyone from BellSouth comment? What if a few other
to add a thousand or so deaggregated routes in a few weeks time? Would there be a greater impact?
one word - irresponsible
This clearly stands out to me as a reason to keep and use prefix filtering on peers to reduce the amount of junk in
tables. If bellsouth needs to leak more specifics for load balancing purposes, fine, just make sure those routes don't leave your upstreams networks and waste router memory for the rest of us that don't need to see it.
- Jared
(Note: The above numbers are based on data from cidr-report.org. Some other looking glasses were also checked to see if cidr-report.org's view of these AS's is consistent with the Internet as a whole. This appears to be the case, but corrections are welcome.)
-Terry
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Terry Baranski Sent: Sunday, October 05, 2003 3:01 PM To: 'James Cowie'; nanog@merit.edu Subject: RE: as6198 aggregation event
James Cowie wrote:
On Friday, we noted with some interest the appearance of more than six hundred deaggregated /24s into the global routing tables. More unusually, they're still in there
AS6198 (BellSouth Miami) seems to have been
them over the course of several hours, between about 04:00 GMT and 08:00 GMT on Friday morning (3 Oct 2003).
If you look at the 09/19 and 09/26 CIDR Reports, BellSouth Atlanta (AS6197) did something similar during this time
about 350 deaggregated prefixes, most if not all /24's.
Usually when we see deaggregations, they hit quickly and they disappear quickly; nice sharp vertical jumps in the
This event lasted for hours and, more importantly,
major ISPs were the routing this morning. patiently injecting period -- they added table size. the prefixes
haven't come back out again, an unusual pattern for a single-origin change that effectively expanded global tables by half a percent.
That AS6197's additions are still present isn't encouraging.
-Terry
-- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
The idea is to not filter just /24's. The idea is to work with people who run cidr-report.org (may be.. or other people who are willing to coop), and find an ASNs who advertise a lots of irresponsible deaggregates. As you can see, cidr-report only shows deaggregation for the prefixes that an AS _specifically_ _originates_. It does not show /24's out of downstream ASes, so it is safe. Basically there would need to be some sort of monitoring process to review the cidr-report regularly to keep a close watch on irresponsible providers, and generate route-set filter against them until they aggregate themselves. -hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | haesu@towardex.com Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | POC: HAESU-ARIN On Sun, Oct 12, 2003 at 03:07:46PM -0400, McBurnett, Jim wrote:
IMHO, I think we should create a route-set obj like call it... RS-DEAGGREGATES and list all the major irresponsible providers's specific /24's in it...
CASE: Business has a /24 from X provider in order to multihome. That /24 is de-aggregated from a /19, with this policy that /24 may not be routed.
possible exception: When 2002-3 get passed by ARIN, this could even take on new meaning. ARIN says they will use a single /8 for the handing out of /22-/24 for multihoming end users. will you then filter those /24's also?
Also: What happens when that /24 for Business Y noted above is dual routed by ISP A and ISP B, and ISP A's upstream filters but ISP B's does not? Will there be asymmetric routing?
Finally: Can anyone from BellSouth, explain the end goal of the de-aggregation?
I suspect with 40 + ASs they may be rebuilding their network with a recently announced list of new IP services and DSL growth as asked for under the Federal government Rural DSL regulations... (I'm not trying to defend them, just giving some possibilities)
So some ASes who wish to not accept deaggregated specifics using RPSL can update their AS import policy to not import RS-DEAGGREGATES...
Just my humble opinion.. Comments/critics welcome :)
-hc
-- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | haesu@towardex.com Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | POC: HAESU-ARIN
On Sun, Oct 12, 2003 at 11:26:49AM -0400, Jared Mauch wrote:
On Sun, Oct 12, 2003 at 01:02:57PM +0000, Stephen J. Wilcox wrote:
Can anyone from BellSouth comment? What if a few other
to add a thousand or so deaggregated routes in a few weeks time? Would there be a greater impact?
one word - irresponsible
This clearly stands out to me as a reason to keep and use prefix filtering on peers to reduce the amount of junk in
tables. If bellsouth needs to leak more specifics for load balancing purposes, fine, just make sure those routes don't leave your upstreams networks and waste router memory for the rest of us that don't need to see it.
- Jared
(Note: The above numbers are based on data from cidr-report.org. Some other looking glasses were also checked to see if cidr-report.org's view of these AS's is consistent with the Internet as a whole. This appears to be the case, but corrections are welcome.)
-Terry
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Terry Baranski Sent: Sunday, October 05, 2003 3:01 PM To: 'James Cowie'; nanog@merit.edu Subject: RE: as6198 aggregation event
James Cowie wrote:
> On Friday, we noted with some interest the appearance of more > than six hundred deaggregated /24s into the global routing > tables. More unusually, they're still in there
> > AS6198 (BellSouth Miami) seems to have been
> them over the course of several hours, between about 04:00 GMT > and 08:00 GMT on Friday morning (3 Oct 2003).
If you look at the 09/19 and 09/26 CIDR Reports, BellSouth Atlanta (AS6197) did something similar during this time
about 350 deaggregated prefixes, most if not all /24's.
> Usually when we see deaggregations, they hit quickly and they > disappear quickly; nice sharp vertical jumps in the
> This event lasted for hours and, more importantly,
major ISPs were the routing this morning. patiently injecting period -- they added table size. the prefixes
> haven't come back out again, an unusual pattern for a single-origin > change that effectively expanded global tables by half a percent.
That AS6197's additions are still present isn't encouraging.
-Terry
-- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
participants (2)
-
Haesu -
McBurnett, Jim