RE: Multihoming - Resilience or Independence
- Date: Thu, 11 Oct 2001 11:02:07 -0400
> -----Original Message-----
> From: BLOCKI,JACEK (HP-Poland,ex1) [
]
> Sent: Wednesday, October 10, 2001 1:10 PM
>; routing-wg@localhost
> Subject: RE: Multihoming - Resilience or Independence
>
>
> Hi,
> It seems multihoming discussion is an example of vicious
> circle (sp): More
> specific routes result in larger routing table but we want
> those routes and
> small table... Let me suggest a blasphemy: CIDR being
> advertised from two
> ASes. They say it should be only one, but why? In my opinion there is
> nothing wrong in advertising CIDR from two ASes as long as
> you can guarantee
> each border router advertises CIDR only if it can reach it.
> Imagine the
> following construction:
> AS-A--\
> +(OSPF) --(CIDR)
> AS-B--/
>
That's the problem. When customer want to be muitl-homed you can't tell them
to use which ISP ? If the original prefix are not in the CIDR with the other
ISP
then the customer have to change all their IP address. If they don't then
the second
ISP have to leak the original prefix into global routing table.
The question is how do you convince your customer to change all their IP
addresses to
have a second link without the risk of losing its business ?
> Each BGP speaker advertises CIDR if and only if it learned
> about it from
> OSPF. It can be done, if you don't know how I'll forward you a working
> example. Each border router generates a default router and
> injects it into
> OSPF. From technical point of view I see no reasons why it
> should not work.
> What you need is:
> * An agreement between ISPs
> * Change in procedure making such a union of ASes an
> officially blessed
> solution so nobody would dare to hinder cooperation with filters.
> * Optionally you may need a separate CIDR, since both ASes
> have to advertise
> same prefix. You need it if each ISP wants to have private
> customers in
> addition to shared ones.
>
> The customer has "an independent connection to two ISPs"
> which is the quest
> item. I see more commercial than technical problems with such
> a solution.
> However my expertise is limited and somebody can point
> drawbacks I cannot
> see. Feel free to burn me on a stake, that's the right way of
> treating a
> blasphemy ;-)
> Regards,
> Jacek
>
It is a good idea but not easy to implement under the pressure of making
revenue.
Ping Lu
Cable & Wireless USA
Network Tools and Analysis Group
W: +1-703-292-2359
E: plu@localhost
