>OK. No one else has nibbled. And as everyone knows, I'm not afraid to make a
>fool of myself publicly.
>
>So here goes......
>
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
>Howard C. Berkowitz
>Sent: Friday, December 15, 2000 9:18 PM
>To: [EMAIL PROTECTED]
>Subject: Re: Weekend Challenge - Route Aggregation
>
>>>SNIP for brevity<<
>
>And a counterchallenge -- anyone want to take a stab and suggest why
>certain of these might be being advertised as less-than-optimal
>aggregations, for quite good reasons?
>
>CL: as tempted as I am to crack wise about sloth and clue, it is more likely
>that the lack of aggregation has to do with downstream requirements and
>agreements in place. Far too many people are "load balancing on the
>internet". Whether they need to or not is a different issue.
I did have the opportunity to visit the National Zoo yesterday, and
did refresh my knowledge on sloth(s).
Load balancing is often only marginally achievable, at best. Fault
tolerance is another matter.
Consider the following scenario, which is basic but very real world.
AS1 is an B2C service provider with critical application
requirements. It obtains an AS number, but not its own address space
(which is a perfectly legal scenario).
AS1 has two upstreams, AS2 and AS3. AS1 receives a delegation of
provider-assigned address space from AS2.
AS2's block, hypothetically, is 96.0.0.0/14. It delegates 96.0.0.0/22 to AS1.
AS1, AS2, and AS3 reach administrative agreement that AS3 will
advertise that part of AS2's space that is delegated to AS1, so the
Internet can see paths to AS1's 96.0.0.0/22 via AS2 and AS3.
One of the things that breaks aggregation, however, is that if AS2
only advertises its best aggregate, 96.0.0.0/14, _no_ traffic outside
AS2 destined for 96.0.0.0/22 will enter AS2. Instead, since AS3 is
offering the more specific route to 96.0.0.0/22, all incoming traffic
to AS1 will come through AS3, even though it is going to AS2 address
space.
In order to send a plausible route to the rest of the Internet, AS2
must advertise both the aggregate 96.0.0.0/14 and the more-specific
96.0.0.0/22. AS3 must also advertise 96.0.0.0/22. So, AS2, for
legitimate reasons, is sending less-than-optimally-aggregated
announcements.
>
>Note -- I have not researched whether these are or are not good
>aggregations. But where might I look? What is the single most
>important additional piece of information about each of these groups?
Even more basic, although you'll use it to use the resources you
listed. I was thinking of the originating AS number.
>
>CL: RADB database? www.radb.net ? ARIN WHOIS? www.arin.net ?
>
>CL: In terms of the internet backbone providers and Tier 1 ISP's, I suppose
>it becomes a matter of the amount of work involved, particularly after the
>spate of mergers in the last year or so. UUNet / MCI seems to be one of the
>major "offenders" in the lack of CIDR conformance. Having dealt with both in
>a limited fashion, I was highly impressed with their engineering prowess.
>Which leads me to believe that massive aggregation on their part would be no
>simple matter.
For the legitimate technical reasons listed below, as well as less
legitimate ones (commercial or just plain cluelessness). In
addition, very large providers such as you name may or may not have
different AS numbers on a continental or other large regional basis,
and may send what seem to be less than optimal aggregates simply to
reach another part of their own service.
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
