Re: Failover for a multihomed site with unreachable ISP

[Christian Schild <ipng@uni-muenster.de>]

Am Donnerstag, 27. März 2003 08:44 schrieben Sie:
> On donderdag, maa 27, 2003, at 08:14 Europe/Amsterdam, Christian Schild 
> wrote:
> 
> >> 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 
> problems.

Well, if BGP's behaviour would change to aggregation, filtering of 
/48 is done automatically, and configured filtering of /48 is no longer 
neccessary. 

Christian