Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!clyde!cuae2!ihnp4!inuxc!pur-ee!j.cc.purdue.edu!i.cc.purdue.edu!arthur.cs.purdue.edu!narten From: narten@arthur.cs.purdue.edu (Thomas Narten) Newsgroups: comp.dcom.lans Subject: Re: Milking machine performance/function (routing table management) Message-ID: <675@arthur.cs.purdue.edu> Date: Thu, 4-Dec-86 09:50:29 EST Article-I.D.: arthur.675 Posted: Thu Dec 4 09:50:29 1986 Date-Received: Fri, 5-Dec-86 06:47:25 EST Distribution: na Organization: Department of Computer Science, Purdue University Lines: 87 >In <7432@topaz.RUTGERS.EDU>, hedrick@topaz.RUTGERS.EDU (Charles Hedrick) writes: >There are several problems with routed that make it unlikely that it >will take over as a routing protocol. One is that in large networks, >the algorithms behind RIP can lead to instability. It's unclear to me >how many real networks have configurations that would lead to >problems, but Cisco and similar companies would like their boxes to be >usable to build networks on the scale of the Arpanet. (NSFnet and a >number of regional networks are creating a market for routers that can >handle big networks.) A more practical problem is that routed is >largely a Unix-only protocol. If all your machines and gateways are >BSD, fine. But we find it more practical to use other techniques to >distribute routing. Could you please elaborate on what "algorithms...lead to instability"? Is this a flaw in the protocol, or would other algorithms also run into similar problems? The fact that routed is found mostly in BSD systems is no reason not to use it. I can turn the argument around and say that any other routing algorithm available from other vendors is impractical cause Unix machines don't run them. >The most common ways to distribute routing information are routing >redirects and proxy ARP. To use routing redirects, you set up a >default gateway for each host. (It is common to have a convention >that host number 1 on each subnet is a gateway.) If that gateway >turns out not to be on the best route, it will issue an ICMP redirect >pointing you to the better route. To use proxy ARP, you set things up >so that your host issues an ARP request for every destination. The >appropriate gateway responds to the ARP with its own Ethernet address. >Routing redirects are probably the most common. Their use is >described in the standards. Every TCP/IP implementation that I know >of can use them. Proxy ARP is used primarily to handle hosts that do >not understand subnetting on a subnetted network. However if you >prefer not to wire in knowledge of a gateway to each host, you can >also use this as your primary method for distributing routing. This >method will always work for handling the subnet problem, but many >host can't be told to ARP destinations on other networks. I would have to dispute what you call as "most common". Routing redirects and proxy ARPs are one way to manage routes, but all is not rosey. With redirects, one starts with one gateway finds new and better routes cause the gateway you are currently using tells you of a more direct path. If that new route should go away, however, you have no way of finding out cause you would need a redirect from the gateway that just went away. You may in fact have another gateway that could still be used. RIP would detect gateways that go away and either remove the route or find another gateway. In summary, Redirects can be used to fix up incorrect entries, not to manage routing tables. It certainly has as many and probably more problems than RIP. Using "proxy ARP" may work some of the time, but it is not robust. ARP entries are cached for about 20 minutes of non reference, hence there is no guarantee that a route that no longer works will ever time out. If you have only one gateway, that isn't a problem. Lots of sites have many. Besides, using ARP/redirects for routing just pushes the problem of needing a routing algorithm to the gateways. They cannot use this trick themselves. The gateways will have to use some sort of algorithm (such as RIP) to get routes straight between them. Again, having just one gateway simplyfies things. The convention of host 1 being a gateway is a local assumption. We don't follow that convention, and I would be surprised if many others do. Besides, lots of sites have more than 1 gateway per net anyway. What do you do then? >As far as I know, Berkeley Unix will not issue redirects when used as >a gateway, but it will obey them when used as a host. It will also >not respond to ARP requests for other networks when used as a gateway, >but can be made to issue them when used as a host. In my opinion, >this make Unix perfectly well-behaved as a host, but rules it out for >use as a gateway, except in a network where you know you will never >have any hosts other than Unix machines. (These comments are >certainly true for 4.2. It is always possible that 4.3 has added code >to issue redirects, though I haven't seen any sign of it in the >announcements and other discussions on the net. I know that it hasn't >added code to do proxy ARP, even though a number of sites have had to >add it in order to bring up subnets.) 4.3 BSD will issue and accept redirects if properly configured. Properly configured means that it must have 2 or more "real" interfaces (loopback doesn't count), otherwise it thinks it is a host. This is a wise decision, as hosts aren't gateways, and shouldn't act as such. 4.3 will change routing entries that are updated via redirects. It will, however, only do so if the redirect came from the same gateway it is currently routing packets addressed to the destination given in the redirect to. This prevents it from installing redirects that come from a random host. -- Thomas Narten narten@purdue.EDU or {ucbvax, ihnp4, allegra}!purdue!narten