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 this morning.
AS6198 (BellSouth Miami) seems to have been patiently injecting
them over the course of several hours, between about 04:00 GMT
and 08:00 GMT on Friday morning (3 Oct 2003).
Usually when we see deaggregations, they hit quickly and they
disappear quickly; nice sharp vertical jumps in the table size.
This event lasted for hours and, more importantly, 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.
Can anyone share any operational insight into the likely causes of
this event? Has it caused any operational problems for anyone?
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 this morning.
AS6198 (BellSouth Miami) seems to have been patiently injecting
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 period -- they added
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 table size.
This event lasted for hours and, more importantly, 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.
Two of BellSouth's AS's (6197 & 6198) have combined to inject around
1,000 deaggregated prefixes into the global routing tables over the last
few weeks (in addition to their usual load of ~600+ for a total of
~1,600).
This does indeed appear to be having an operational impact on some
folks, an example of which is here:
The vast majority (if not all) of these prefixes are covered within
aggregates announced by BellSouth AS6389, which acts as an upstream to
these and around 20 other BellSouth AS's. (These other AS's combine for
another ~700 deaggregated announcements, meaning that BellSouth may
currently be advertising more deaggregated prefixes into the global
routing tables than any other entity.) Some of these AS's appear to use
Qwest as backup transit, so presumably the motive behind the vast
deaggregation is failover. Is there a better way of achieving this than
forcing the Internet to store ~2,300 extra routes?
Can anyone from BellSouth comment? What if a few other major ISPs were
to add a thousand or so deaggregated routes in a few weeks time? Would
there be a greater impact?
(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.)
Can anyone from BellSouth comment? What if a few other major ISPs were
to add a thousand or so deaggregated routes in a few weeks time? Would
there be a greater impact?
> Can anyone from BellSouth comment? What if a few other major ISPs were
> 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 the routing
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.
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...
So some ASes who wish to not accept deaggregated specifics using RPSL can update their AS import policy to not import RS-DEAGGREGATES...
Kudos to BellSouth for taking first steps to clean this up
overnight -- about 1100 of the prefixes left the table between
about 01:45 and 03:45 GMT. Very nice deflation.
] Thanks Rob. Noticed one of our routes there that an upstream was also
] originating, for no reason. That's cleared up, so one less inconsistent
] AS...
Looks like they've started getting things a bit organized since sunday night/
monday early dawn. From my network's pt of view, you can see the sudden slight
"sink" in announcements transited thru UUNET which is where bellsouth's prefixes
come from on my end: http://www.twdx.net/bgp/graph-1w.png
For a simple view:
