[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Failover for a multihomed site with unreachable ISP
On Thu, 2003-03-27 at 07:57, Christian Schild wrote:
> Hi Marcelo,
>
> Am Mittwoch, 26. März 2003 16:20 schrieben Sie:
> > Hi Cristian
> >
> > Wouldn't this be somehow similar to RFC 2260?
>
> Hm, I don't think so. RFC 2260 seems to be similar but isn't the same. In
> fact, it could be used to help in one of the first three cases of failures I
> talked about.
>
Agree, specially the tunnel part of the solution.
> But RFC2260 talks about connecting a site to an ISP (e.g. by extending BGP to
> the customer). In my mail I talk about how an ISP A could inject a customers
> prefix (that is part of another ISP B's /32) to the DFZ,
I understand that the difference would be that RFC 2260 proposes that
the end-site injects the alternative route information and in the other
case is the ISP that injects the address space assigned by the other ISP
to the end-site.
However, i am not sure that this is a feature of the alternative
proposal. I mean RFC 2260 does not requires coordination between ISPs
while the other proposal does.
> without endangering
> the size of the routing table. This is not solved by RFC2260.
>
I do not see any difference between the two proposals in this point
(probably i am failing to understand something)
I both cases a more specific prefix in injected when an outage occurs,
so both proposal contribute with an additional entry in the DFZ routing
table during the outage (and no longer than that)
Am i missing something?
Regards, marcelo
> Christian
>
> >
> > On Wed, 2003-03-26 at 13:39, Christian Schild wrote:
> > > Hi ho,
> > >
> > > inspired by the 'dual homing experiment' document of Christian Huitema,
> > > we (JOINers) thought about a solution to offer robustness for a site that
> > > is multihomed and multiaddressed and that we like to discuss here.
> > > Exteral connectivity of such a site is affected by failures of
> > >
> > > - the sites border router
> > > - the sites uplink
> > > - the ISPs infrastructure (spec. the router with the link to the customer)
> > > - the ISPs global border router
> > > - the ISPs global uplink
> > >
> > > To recover from such a failure in the fist three cases, the site could
> > > communicate with the ISP a set of possible prefixes and connectivity could
> > > get reestablished via a tunnel technology. We already thought about this,
> > > but the solution is quite complex to explain it in short. It is not
> > > discussed here.
> > >
> > > The approach I try to explain here is a solution for the last two cases,
> > > where there the ISP is no longer reachable and a tunneled solution is not
> > > possible.
> > >
> > >
> > > First, we consider a failure a seldom and abnormal event. Only if a direct
> > > connect fails, the network (or the ISP) has to take some failover action.
> > > This means that - if you think of the size of the global routing table -
> > > in default behaviour the table is small (only /32 prefixes) and only in
> > > case of a failure a more specific prefix (/48 or shorter) is neccessary.
> > >
> > > +----------------------------+
> > > | 'Global Internet'/'DFZ' |
> > > +--+-----------------------+-+
> > > | |
> > > | |
> > > +-----------+--+ +--+-----------+
> > > | ISP A | | ISP B |
> > > | Prefix PA/32 | | Prefix PB/32 |
> > > +-----------+--+ +--+-----------+
> > > | |
> > > | |
> > > ++-----------------------++
> > > | Customer C |
> > > | Prefix PAC/48 |
> > > | Prefix PBC/48 |
> > > +-------------------------+
> > >
> > > In this scenario customer C gets a /48 from every ISP (PAC/48 from ISP A
> > > and PBC/48 from ISP B) and communicates the existance of these prefixes to
> > > every provider (as mentioned earlier, how this is done is not explained
> > > here). Thus, e.g. ISP A knows that it has a multihomed route to
> > > customer C with prefix PBC/48.
> > >
> > > Usually, all traffic from the outside to PBC/48 will go through ISP B.
> > > If ISP B detaches from the DFZ now, ISP A has to announce to the DFZ
> > > somehow, that it has a valid route to PBC/48. This can be done in two
> > > different ways within (e)BGP:
> > >
> > >
> > > Approach 1:
> > > When ISP B detaches, it's BGP announcement of PB/32 will vanish from the
> > > global routing table. ISP A's border router could use this as a trigger to
> > > announce PBC/48 to the DFZ. It will remove this announcement when PA/32
> > > reappears.
> > >
> > > The advantage here is that the /48 will only be present in the DFZ, when
> > > the usual routes fail. The disadvantages are bad convergence and possible
> > > multiple routes. If ISP A and ISP B are very distant, it may take some
> > > time until the /48 is known everywhere. If ISP B detaches from the DFZ
> > > only for a split second - or even flaps - both prefixes will be visible
> > > in the DFZ for some time.
> > >
> > >
> > > Approach 2:
> > > The second approach is more severe and requires a change in BGPs default
> > > routing behaviour.
> > >
> > > Usually BGP choses the route for a packet based on the longest prefix
> > > match calculation. The suggestion here is, that (e)BGP - despite this
> > > rule - chooses the _shortest_ prefix in the DFZ. This behaviour has to
> > > be restricted to prefixed between /32 and /48. This restriction is
> > > neccessary, because we only want this to happen in the routing area.
> > > Within a site, longest prefix match should still be possible. And,
> > > shortest match needs to be prevented for prefixes shorter than /32, else
> > > anyone could create a _real_ black hole by announcing an /<32 to the
> > > DFZ.
> > >
> > > Assuming this behaviour of (e)BGP, in the above scenario ISP A could
> simply
> > > announce PBC/48 to the DFZ. It will get announced to everyone, but it
> > > should not get used in the forwarding table, cause the (now) better prefix
> > > PB/32 exists. If now ISP B detaches and the prefix PB/32 is retrieved from
> > > the routing table, every node in the DFZ will add the PBC/48 to the
> > > forwarding table and the new route to the customer establishes.
> > >
> > > Advantages here are the faster convergence. A disadvantage is the major
> > > change in BGPs behaviour. This 'shortest path' criteria may be critical,
> > > because calculation of the best route might get complex and expensive.
> > > Also, again the routing table may grow large, but in return the
> > > forwarding table will stay small. It is not know what other impact a
> > > 'shortest prefix' selection will have.
--
marcelo bagnulo <marcelo@it.uc3m.es>
uc3m