[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Failover for a multihomed site with unreachable ISP
Am Donnerstag, 27. März 2003 08:44 schrieben Sie:
> On donderdag, maa 27, 2003, at 08:14 Europe/Amsterdam, Christian Schild
> >> 1. An ISP's aggregate route (the /32) disappearing from the global
> >> routing table is an extremely rare event. Last mile problems are
> >> infinitely more common,
> > Well, rare is not zero :). We just want to cover that case.
> Maybe a better solution would be a backup organization that announces
> the /32 if it disappears and tunnels the packets to the customers over
> the secondary ISPs.
I'm not sure if I got your point here. Are you suggesting that another ISP
has to take over all the traffic for the disconnected ISP? I hardly believe
this will ever happen in the real world :) Things like this could only be
done administratively and we want a protocol-based solution.
> >> and after that there is the class of partial ISP failures (for
> >> instance,
> >> a single POP is partitioned from the network) where the aggregate
> >> remains visible.
> > Hm, if just one POP disappears, the ISP (and the customer) is still
> > rachable,
> > we don't have a loss of connectivity and no action has to be taken.
> ??? If the POP the customer connects to goes down, the customer isn't
> reachable over the addresses from that ISP anymore.
Oh, this is our failure case 3 and shouldn't be considered here. A tunneled
solution could handle this. (Please note that we are preparing a draft for a
protocol based solution that could handle cases 1-3. Later :-).
> >> 2. Conditional announcement makes the global routing system less
> >> predictable, which is dangerous. The sudden appearance of thousands
> >> of more
> >> specific /48s could easily break systems that could just about cope
> >> with the
> >> regular aggregated situation.
> > I see. But in our approach 2, the longer prefix is already present in
> > the
> > routing table. Only if the shorter prefix disappears, it will be added
> > to the
> > forwarding table. It is some kind of 'automatic aggregation'. Do you
> > think it
> > will be that extremely costly?
> Not costly, dangerous.
> > Moreover I think, systems 'that could just
> > about cope' should be replaced, and they shouldn't be a concern here.
> If the routers must be able to handle the full set of unaggregated
> prefixes anyway, why bother aggregating?
Well, a large routing table is only a memory/msg-size problem. A large
forwarding table also slows down the forwarding process. With automatic
aggregation at least the latter is solved.
> Maybe this can work in theory
> but not in practice. Many people will just filter the /48s to avoid
Well, if BGP's behaviour would change to aggregation, filtering of
/48 is done automatically, and configured filtering of /48 is no longer