Customer AS

Fri Aug 16 21:38:12 UTC 1996

Tim Crowell (GTE.NET) wrote-

> Howdy folks,
> 
> I would like to pose a question to the group about the best way 
> to implement the following;
> 
> GTE has a customer who is a content provider that we have 
> allocated a class C out of our CIDR block.
> 
> They have subsequently also ordered a second transit service 
> from ISP XYZ.
>
I would make them renumber with a new class c that was not in your CIDR
block.
Maybe they could get a class C from the swamp?

> Our assumptions are:
> 1. Customer will obtain an AS number to do BGP with both GTE and 
> XYZ.  
> 2. BGP will be established with both ISPs
> 3. GTE will announce the class 'C' as both a part of our 
>   aggregate CIDR block and as a specific /24

No you would just advertise the aggregate CIDR block, they
should advertise the more specific route so when you
peer with them their route is propagated with their AS number.

> 4. XYZ will announce the class 'C' as a /24 only.

XYZ should peer with them just as you have done.

> 5. Both GTE and XYZ will supply a default route.  

If the client is carrying the full routing table should be default free,
if they chose not to then they will have to decide on which provider
should be the default route.

Anyway my thoughts on an entity having multiple ISP's would want
to have an autonomous system number routing his class C.  I guess
you could strip his AS and route is as your own but I dont think
his would fall in line with current RFC's.  I may be wrong though.
Someone from this mailing list I am sure can enlighten us.

 > Explanation/Questions;
> 1. Does this AS number have to be an officially registered AS or 
> can it be a reserved number?

If they are advertising the route the rest of the world it would have to
be registered. 

>  The thought is that the Class 'C' 
> will be announced by both ISPs and strip the customers AS.  The 
> AS would only be used to connect between ISPs.
> It seems extremely wasteful for every little company that wishes 
> a dual homed network would have to get a registered AS.  
>
They have registered domain names and a 24 bit network?
Just kidding.  This is beyond my political domain.

> 2. We first had major heartburn with carving the 'C' out because 
> we just couldn't see having to add 2 additional announcements to 
> the internet routing tables but we have come to the conclusion 
> that there is no other way to do it.

Would not there be just one additional route that is propagated by you?

> We assume that we have to 
> announce the /24 in addition to our aggregate otherwise XYZ's 
> more specific announcement of our network would route all 
> traffic through them from the internet.

That is correct

>  It just seems that if 
> there were a large number of these multi-homed Class 'C's that 
> the internet routing table would be flooded.  (Maybe thats a 
> part of the problem.
> 
>
Now you understand why everyone is using Cisco 7500 series routers
with 64 to 128 megs of RAM.

> 3. As a followup,  what would you do if a subnetted class 'C' 
> customer  who only requires a dozen or so addresses but orders 
> connections to two ISP's.  Do you burn a whole Class 'C' ????

Yeah.  I dont think anyone will accept nor propagate a route larger than 24
bits.

> 4. Is there anyway to accomplish what the customer wants that we 
> haven't considered.

If it was me I would first of all register for a class C network address
from the NIC in order to not break up you CIDR block.  As I said
before stripping their AS and adverstising the route with your
origin and another ISP would not be thing to do.  If I am wrong somebody
please correct me.

> 
> 5. I understand that we will have to submit the Class C to RADB 
> and create a "hole" in our aggregate to effectively represent 
> the network topology.
>

It would actually just be a more specific route that would seem seemless to
you.

> 
> PS.  If i'm just being stupid about this feel free to say so.  I 
> don't pout too long.

Don't worry, everyone has BGP nightmares.  Unfortunately
it is one of the nightmares that reoccur every once a while..

Chris MacFarland
President
CompuNet	214.994.0190
chris at computek.net