North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Emergency backup for a small net
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. > > > > > > - - - - - - - - - - - - - - - - -
|