If you are advertising a /24 through both ISPs in each city then you won't need them to do anything special as routers always put the most specific route in their routing table. If you are advertising specific /24s to the ISPs and one of the peering links drop then that /24 will be withdrawn from that ISP's table and henceforth to the internet making the only available route your other ISP. The problem is if they aggregate and advertise only a /19 instead of individual /24s In this case you could: - Ask the pulverized ISP to withdraw the aggregate in favor of the specific /24s - Ask your second ISP to advertise your specific /24 in that city I'd choose the second option because if your first ISP was truly hit by an asteroid they'll be spending too much time a. Attempting to make people actually believe they were hit by a piece of ancient space debris b. Trying to recover their network c. Working on an appropriate press release showing lack of fault and sorrow for the loss of several competent engineers and d. All the surviving employees will be trying to sign a bunch of book and movie deals about their experience :> All in all your second ISP will be better equipped to get your traffic up and running. Greg Pendergrass Manager of Operations ____________________________________________ BAND-X, Inc. www.band-x.com -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Murphy, Brennan Sent: Wednesday, August 08, 2001 10:16 AM To: 'nanog@merit.edu' Subject: Static routes in an AS vs BGP advertised routes Suppose you had a scenario where your AS is multi-homed to two ISPs in, for example, 8 cities around North America. Every site is connected to both ISPs and all of your address space occupies a /19. To your ISPs, you advertise specific /24s in each city. In turn, each ISP advertises your /19 to the rest of the Internet. Everything is going along smoothly until an asteroid crashes into the data center of one of your ISPs in one of the cities. It causes extensive damage and a certain amount of hysteria but to you, it means that only one of your ISPs can truly reach your full /19. That is, the /24 you were advertising in that city is now only reachable via one of the ISPs. But the ISP taken out by the asteroid is still advertising the full /19. Under the circumstances (loss of life, hysteria, sub-optimal routing), would it be appropriate to ask the unfortunate ISP to create a static route on their network to push traffic destined for that particular /24 over to the other ISP's network? This way, the /19 advertisements can be maintained and when traffic destined for that one /24 reaches the asteroid ISP, it can get passed over to the non-asteroid ISP. The route wouldnt be advertised to other carriers.....just used to make sure traffic reached the correct final destination. Will ISPs make these types of accommodations? Suppose the reason was less unexpected than an asteroid. For example, suppose you open a site in a 9th city, but only one carrier is available there. In other words, are ISPs reluctant to slap in static routes for every customer who comes along with some sob story about poor planning and/or unexpected growth? Your comments on this theoretical scenario are much appreciated. -BM
On Wed, 8 Aug 2001, Greg Pendergrass wrote:
The problem is if they aggregate and advertise only a /19 instead of individual /24s In this case you could:
- Ask the pulverized ISP to withdraw the aggregate in favor of the specific /24s - Ask your second ISP to advertise your specific /24 in that city
Better yet, advertise your own /19 aggregate, mark your /24's with communities that mean to your provider that they shouldn't be propagated outside of their network and their customers (if they can't do this, fire them) to be a good neighbor by not polluting the global routing table with unnecessary routes. Then when the asteroid hits, just pull down the /19 advertisement (or if you're lucky, they are so destroyed they won't get the announcement out to the world anymore anyway). -- Brandon Ross 404-522-5400 EVP Engineering, NetRail http://www.netrail.net AIM: BrandonNR ICQ: 2269442 Read RFC 2644!
participants (2)
-
Brandon Ross
-
Greg Pendergrass