Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!decvax!ucbvax!TOPAZ.RUTGERS.EDU!hedrick From: hedrick@TOPAZ.RUTGERS.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: how to make use of redundant routes Message-ID: <8701210752.AA00659@topaz.rutgers.edu> Date: Wed, 21-Jan-87 02:52:33 EST Article-I.D.: topaz.8701210752.AA00659 Posted: Wed Jan 21 02:52:33 1987 Date-Received: Wed, 21-Jan-87 19:36:42 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 77 Approved: tcp-ip@sri-nic.arpa Noel: I appreciate your advice, but really, the people you should be flaming at are not me, but Berkeley and the various vendors. My problem is very different than Berkeley's: I have to deliver reliable service given products that actually exist. RFC816 says basically - somehow you keep track of what gateways are up - when you want to talk to somebody, try a gateway, and depend upon redirects to get the actual address - when a gateway goes down, just get rid of routes that use it. This will result in trying another random gateway, which will again tell you if there is a better one. For keeping track of what gateways are up, RFC816 mentions - depend upon the network to tell you when a packet isn't delivered. - ping them regularly - depend upon the upper layers [for us, TCP and NFS] to tell you when a route no longer works. When a route stops working, assume that its gateway is down. Now, let's look at how much of that advice I can actually use. I have mostly Suns. This means I have 4.2 networking. I know that's horrible, but there isn't a lot of real 4.3 in the marketplace yet. I'm not in a position to implement my own, or even to port 4.3 to the Sun. In a 4.2 world, none of the suggestions in RFC816 look very attractive. Ethernet obstinately refuses to tell me that it is unable to deliver a packet. The one implementation that tried to ping all of the gateways it knew about [TOPS-20] was roundly condemned by all. And 4.2 has no feedback from the upper layers to the lower ones. [Indeed even in 4.3, it's not clear whether the feedback is good enough that you can really depend upon it in practice. I'd like to hear from anybody who has experience in this area. If you just use the route command to set up several default gateways, will 4.3 really manage to keep up communications, using just redirects and hints from TCP? Note that for many of my users, the main application they are using through the gateway is NFS, which is UDP-based.] Since none of these methods seems very attractive, I proposed the next best thing that I could think of: watching the routing traffic between the gateways. I don't propose to look in the packets. I'm just trying to keep track of what gateways are sending them. If you hate routed, imagine that I am watching Cisco's IGRP traffic (which is by no means impossible). Given this, I thought I was proposing something that was very much in the spirit of RFC816. I proposed a daemon that would do the following: - keep track of what gateways are up, by listening to their routing traffic - periodically scan the routes in the kernel - when it finds a route that uses a dead gateway, remove the route. In Unix, this means that traffic will revert to the default gateway, which will then redirect it to a better one if there is any. This is exactly what RFC816 says. - it would manage the default routing entry, to make sure that it always points to a gateway that is up. What I asked was whether anyone has experience with such a thing, and can advise me on whether it is really worth doing this instead of just using routed. I also mentioned some practical problems that would have to be solved before we could really rely on routed. I really have been trying to follow your advice. I have tried to avoid using routed. I find that I am moving that way, because my connections with NSFnet, and use of various random Unix machines as gateways, provide little choice. Cisco, who supplies our core gateways, had tried to avoid routed as well, but has finally caved in to the inevitable. It would help a lot if there were a standard defining something better. When the current efforts in this direction result in something, I'll be happy to push the vendors we deal with to implement it. I'd be happy to join you in a campaign lobbying vendors for implementations that follow the RFC's. But please don't yell at me. I'm just trying to do something reasonable with the tools I have.