> Right, but the problem we're trying to avoid is the one (which you noted in > a previous e-mail) where the interface stays up but the link breaks > somewhere upstream. In this case, the next hop would not change based on > default routes. The way around this is to have the whole route table, right? > So again, it seems that we must have at least one router capable of handling > the whole table, right?
For full protection in this scenario, you're right. However, you can protect against almost all possible ways for this to fail by using keepalives on the interface (detecting loss of connectivity to the neighboring router even though the interface is still up), and by making sure the upstream ISP carries full routes from multiple transit providers. It's your typical cost/benefit tradeoff :-) Another way is to talk BGP with the upstream ISP, but only accept a default route. This still isn't 100% safe, but it's a little better than just using keepalives. Also, the DNS method will suffer from the same problem. Have you figured out a way to detect an upstream failure and switch the DNS table? Another idea, that can also help the DNS problem, is to do sort of a roll-your-own keepalive. Have a host ping a particular site out on the Internet, using policy routing to force the pings out the appropriate interface. If the pings start failing, you can do a failover. The only real downside to this, aside from the complexity of setting it up, is that the site you're pinging may go down, producing a false failure. A good site to ping to help avoid this is one hop beyond your ISP's border router. If the ISP is multihomed, you can ping just beyond all of their border routers, and fail the connection if you lose pings to all of them. -- Bruce Robertson, President/CEO +1-775-348-7299 Great Basin Internet Services, Inc. fax: +1-775-348-9412 http://www.greatbasin.net _______________________________________________ RLUG mailing list [EMAIL PROTECTED] http://www.rlug.org/mailman/listinfo/rlug
