Emergency backup for a small net

Bradley Dunn bradley at dunn.org
Sun May 18 19:11:45 UTC 1997


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.







More information about the NANOG mailing list