Emergency backup for a small net

Sun May 18 18:06:38 UTC 1997

Couldn't/wouldn't you just be able to BGP announcement the /16 to both 
providers and if one gets a little too well announced [i.e. not even 
split] unsweeten it with a higher metric?

The idea of splitting a /16 into two /17s for the sole purpose of getting 
two providers is a little shaky in my world it strikes me as twice as 
vulnerable to outage. 

You *could* announce the same /16 to both upstreams and then 1 of the two 
/17s to [each] to the two providers [as a more specific route] -- if they 
take it, great, if they don't you are still covered with the /16.

-Deepak.

On Sun, 18 May 1997, Hank Nussbacher wrote:

> At 09:04 AM 5/18/97 -0400, Bradley Dunn wrote:
> 
> This brings up a problem I have been trying to solve for a while that I have
> not found an answer to.  A company with an old style Class B (/16) wants to
> be multihomed and split their incoming load between 2 ISPs (outgoing they
> can live with going via 1 and if the primary fails they fallback to the
> secondary conenction).  In order to split the load on incoming, one ISP has
> to announce a /17 and the other ISP has to announce a /17 (or even the
> entire /16).  But since this net is from the 147.x.x.x range, various ISPs
> around the globe will filter out the /17.  This means that having a /16 from
> the 192.x.x.x range is better (these days), unless someone can show me a
> solution.
> 
> Thanks,
> Hank 
> 
> >Hi,
> >
> >We have a small ISP customer that wants to run a circuit to another local
> >ISP and the ISPs would use that pipe only in the case of primary link
> >failure. The two ISPs would split the cost, etc.
> >
> >The obvious solution would be for both ISPs to set up BGP peering with
> >their upstreams and not announce anything in normal operation. The
> >upstreams would continue to statically route the smaller ISPs' blocks and
> >the smaller ISPs would default to their upstreams. The smaller ISPs would
> >also put in a default pointing at each other with a higher cost. Then in
> >the case of primary link failure the ISP who still has a path to the net
> >would begin announcing the other ISP's block(s) to their upstream. The
> >upstream would in turn see this as a valid announcement and propagate it
> >to the world. Therefore specificity should draw all the traffic to the
> >correct place.
> >
> >The problem is both ISPs are small and have /24s from their providers. The
> >/24s would be filtered by many, leading to only partial connectivity in
> >the case of failure. (Partial connectivity is better than no connectivity,
> >I guess...)
> >
> >Another possible solution I thought of is to use NAT. The small ISPs would
> >use RFC1918 internally and use a block from their provider to translate
> >into. When the primary link fails they switch over to using a block from
> >the other ISP's provider. They would also have to use very low TTLs for
> >their DNS zones and be prepared to switch the DNS zones to point to the
> >other block. Does the NIC consider this efficient utilization
> >to have a block lying around that only gets used when a link fails?
> >
> >An important thing to remember here is that the backup link will not be
> >used in normal operation. This is not multihoming. They do not want load
> >balancing.
> >
> >I would be interested to hear others' thoughts on this. If you reply
> >privately I will summarize any interesting replies to the list.
> >
> >Thanks!
> >
> >pbd
> >--
> >You can make it illegal, but you can't make it unpopular.
> >
> >
> 
> 