North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: Static routes in an AS vs BGP advertised routes

  • From: Brandon Ross
  • Date: Thu Aug 09 19:19:22 2001

On Thu, 9 Aug 2001, Murphy, Brennan wrote:

> If the theoretical AS advertised its /19 itself to the ISPs, and then
> one of the /24 networks became inaccessible via the asteroid ISP,
> wouldn't withdrawing the /19 take all traffic off of the asteroid ISP?

It sure would, but in the case of an asteroid strike, I'd assume that
there wouldn't be too much reachable through it.  In that case you could
simply continue to advertise the /19, but of course the stuff in the /24's
that are not reachable any longer will end up in the bit bucket.  The real
question here is, is there internal connectivity between the sites
advertising the more specifics, or are they islands?  If they are islands,
your only real/good solution is to advertise the more specifics
only.  With a bit of planning, hopefully you can aggregate all the
locations that are using a specific upstream into a single block to reduce
the number of routes required in the global table.  For example if you use
2 different upstreams, you might number all the sites on upstream A into
the top /20 and the rest into the bottom /20.

If there is internal connectivity, you might just depend on that to cover
some backup routes.

> What if the outage was not an asteroid but something more common, like
> uncontrolled testing of the network while the stock market is in
> session? More specifically, what if there was reason to believe the
> affected ISP could still deliver service in the unaffected areas?

See above, pretty much all of the possible cases are covered.

> I have examined the responses to my query thus far and
> it seems there are two options: 
>  1) have both ISPs advertise both the /19 and /24s all the time
>  2) change nothing til the asteroid hits. call the unaffected ISP
>     and have them send out the /24 for the affected site
> Option 1 creates larger route tables but automatically handles
> the asteroid situation. Option 2 respects the desire for smaller
> route tables but requires a manual process of phoning in a service
> request.  In the meantime, the customers served by that connection
> may receive sub-optimal routing, ie, if the /19 is still advertised
> by the asteroid ISP, traffic reaches that AS and where does it go?

The bit bucket.

> Am I understanding this correctly? If so, this seems to be a case where
> being internet friendly conflicts with a theoretical entity's desire for
> uptime.

That conflict is pretty typical.

Brandon Ross                                                 404-522-5400
EVP Engineering, NetRail                 
AIM:  BrandonNR                                             ICQ:  2269442
Read RFC 2644!