Emergency backup for a small net
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.
Hi, Bradley Dunn wrote:
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...)
What I would advocate here - though it is probably less feasible in the North American context - is application level multihoming. For mail, backup MX'es for inbound, and smarthosts for outbound. For Web access, if the ISP operates a proxy cache for its customers, the customers' actual IP address becomes irrelevant. There has been some discussion in the Squid users' mailing list about this, and we (the Squid contributors) are looking into means and ways of making upstream switchover more transparent. Granted, running caches in our part of the world (across the Pacific from MAE-West) is a must for reasonable performance at reasonable cost. Cheers, -- miguel a.l. paraz <map@iphil.net> +63-2-893-0850 iphil communications, makati city, philippines <http://www.iphil.net>
At 10:49 PM 18-05-97 +0800, Miguel A.L. Paraz wrote:
What I would advocate here - though it is probably less feasible in the North American context - is application level multihoming. For mail, backup MX'es for inbound, and smarthosts for outbound. For Web access, if the ISP operates a proxy cache for its customers, the customers' actual IP address becomes irrelevant. There has been some discussion in the Squid users' mailing list about this, and we (the Squid contributors) are looking into means and ways of making upstream switchover more transparent.
And I would have the web servers addressed with overlays, using DNS to switch between ISP addresses. Another point; application level switching allows the routes to be pre-established, leading to less delay, less route flapping, and better maintenance.
Granted, running caches in our part of the world (across the Pacific from MAE-West) is a must for reasonable performance at reasonable cost.
Even with HTTP 1.1, caches and mirrors are good performance enhancements because no one point is close to every other point on the Net. --Kent
Kent W. England wrote at NANOG:
And I would have the web servers addressed with overlays, using DNS to switch between ISP addresses.
However, even if you manage to dynamically switch addresses at your name server, folks would still have the cached values. I believe Paul Vixie has described this technique earlier: run Squid in accelerator mode so that you have an automatic mirror site. If the link to the original one gets cut the client ought to try the next one (however I think the common clients retry only when they get Connection Refused?)
Even with HTTP 1.1, caches and mirrors are good performance enhancements because no one point is close to every other point on the Net.
Yup. That's why I wish the big providers would run caches that their overseas customers can parent against. While the NLANR services are great, they are free, and I for one would be more comfortable if it were paid for and had a service guarantee. -- miguel a.l. paraz <map@iphil.net> +63-2-893-0850 iphil communications, makati city, philippines <http://www.iphil.net>
You would probably run into some big problems with those /24 announcements if they were obtained from different upstream providers. If they are CIDR, you are saved. [If they work now, they'll work then -- Just have both networks BGP announce both sets of routes, the "alternate" in either case will have a longer AS path and therefore not be prefered [you can prepend to insure this]. If they are not CIDR, you are faced with making illegal announcements on someone else's backbone]. If they both use you as their upstream, you can solve the matter for them. Wouldn't your method require manual intervention for the BGP session to be turned up? If you are their upstream, wouldn't it just be simpler for your NOC to handle the fallover? -Deepak. On Sun, 18 May 1997, Bradley Dunn wrote:
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.
Ok, here is a diagram (with apologies to those of you using broken mailers that don't use a constant-width font): ------------ | Internet | Me ------------ / / \ / -------------- -------------- | ISP A w/ | | ISP B w/ | | CIDR block | | CIDR block | | from NIC | | from NIC | -------------- -------------- | | -------------- -------------- | Small ISP C| | Small ISP D| | w/ /24 from|---| w/ /24 from| | A's block | | | B's block | -------------- | -------------- | \ Emergency backup link On Sun, 18 May 1997, Deepak Jain wrote:
You would probably run into some big problems with those /24 announcements if they were obtained from different upstream providers. If they are CIDR, you are saved. [If they work now, they'll work then --
Just have both networks BGP announce both sets of routes, the "alternate" in either case will have a longer AS path and therefore not be prefered [you can prepend to insure this]. If they are not CIDR, you are faced with making illegal announcements on someone else's backbone].
Well there shouldn't be any problem with announcing them...it's just getting the people who filter to listen. :) Now I was thinking more about this...if some provider is not listening to the /24 but is listening to the aggregate that contains it, then traffic for the /24 will flow to the ISP announcing the aggregate (say ISP A). If ISP A has heard about the more specific that is being announced by ISP D for ISP C, AND ISP A has a path to ISP B that doesn't cross a filtering provider, AND ISP A is configured to trust more specifics of its netblocks coming from the outside, then there should be full, though sub-optimal, connectivity. This hinges on there being a path between A and B that isn't filtering the /24. This also doesn't work if A or B blows up and loses net connectivity.
If they both use you as their upstream, you can solve the matter for them.
As shown above this is not the case. Part of the motivation for the backup is to have a path to the net if A or B blows up and falls off the face of the Earth.
Wouldn't your method require manual intervention for the BGP session to be turned up? If you are their upstream, wouldn't it just be simpler for your NOC to handle the fallover?
I was thinking of having the BGP session up constantly, so then D just has to start announcing C's block when C's link to A is down. A's and B's filters would be configured to allow D's and C's blocks through. So it would require manual intervention on the end of C or D, but not on A's or B's. Of course, during the time it takes the announcements to propagate there will be a blackhole. pbd -- You can make it illegal, but you can't make it unpopular.
In message <Pine.BSF.3.96.970518081702.20348B-100000@ns2.harborcom.net>, Bradle y Dunn writes:
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...)
One solution is to Get a /24 in a larger provider's aggregate. The two ISPs can agree to exchange the /24 but send it no further (if they peer with each other) and send the traffic across the preferred customer path. If they share a common upstream, then they can probably get the upstream provider to carry the more specific route.
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?
I don't speak for the InterNIC, but I don't see why this wouldn't be considered legitimate since it is being done to provide better connectivity to the end user without loading the global routing tables. Failover using DNS would be neither fast or smooth. You'd need to failover using the GRE tunnel thing on the provider side of the links. Curtis
participants (5)
-
Bradley Dunn -
Curtis Villamizar -
Deepak Jain -
Kent W. England -
Miguel A.L. Paraz