bush@evax.arl.utexas.edu (Joe Bush) (07/31/90)
Lately the routing tables on an MicroVAX 3900 running Ultrix 3.1 have started to include "host" information in the "destination" and "gateway" fields produced by the "netstat -r" command. For example, previously, the output from the "netstat -r" command returned only that information statically added by the "route" command (we are NOT running the notorious "routed"). That is, it returned the standard, "localhost" and "ethernet" destinations, as well as, a few REAL gateways (and the network destinations that could be reached from gateways). For example, here is the output from a VAXStation 3100 (running Ultrix 3.1) on the very same network that still behaves in the old familiar manner: ----------------------------------------------------------------------- Routing tables Destination Gateway Flags Refcnt Use Interface localhost localhost UH 0 3 lo0 eesun1-net eesun1 UG 0 0 se0 default uta1 UG 0 27 se0 csun5-net csun5 UG 0 0 se0 meap-net meap UG 0 0 se0 ethernet escro U 3 68619 se0 ----------------------------------------------------------------------- But for reasons I can't explain, the MicroVAX 3900 is suddenly loading up its routing tables with "host" info. None of the "hosts" (ie., those records where the destination and gateway field are the same and UGHD in the "Flags" field) are gateways. Here is a typical execution of "netstat -r" on the MicroVAX 3900: ----------------------------------------------------------------------- Routing tables Destination Gateway Flags Refcnt Use Interface localhost localhost UH 0 3 lo0 eesun1-net eesun1 UG 0 0 qe0 meap-net meap UG 0 0 qe0 default uta1 UG 1 115678 qe0 csun5-net csun5 UG 6 685680 qe0 ethernet evax U 0 4964 qe0 ksun ksun UGHD 0 5 qe0 mac-ii-rm314 mac-ii-rm314 UGHD 0 258 qe0 mac-ii-kamangar mac-ii-kamangar UGHD 0 860 qe0 escro escro UGHD 0 15566 qe0 mac-se-grabow mac-se-grabow UGHD 0 938 qe0 tandy-4k-rm118 tandy-4k-rm118 UGHD 0 2346 qe0 129.107.2.91 129.107.2.91 UGHD 0 24 qe0 129.107.2.27 129.107.2.27 UGHD 0 1970 qe0 utacfd utacfd UGHD 0 30 qe0 129.107.2.171 129.107.2.171 UGHD 1 2297 qe0 csun1 csun1 UGHD 0 1411 qe0 129.107.2.59 129.107.2.59 UGHD 0 2515 qe0 mac-se-kavi mac-se-kavi UGHD 0 4459 qe0 meap meap UGHD 0 7201 qe0 csejos csejos UGHD 0 1808 qe0 csun2 csun2 UGHD 0 11557 qe0 129.107.2.93 129.107.2.93 UGHD 0 444 qe0 mac-se-weems mac-se-weems UGHD 0 1623 qe0 csun4 csun4 UGHD 0 6432 qe0 eene eene UGHD 0 64 qe0 cracs1 cracs1 UGHD 0 1653 qe0 129.107.2.94 129.107.2.94 UGHD 0 993 qe0 agnos agnos UGHD 0 100 qe0 utat4 utat4 UGHD 0 1402 qe0 cracs2 cracs2 UGHD 0 2174 qe0 tandy-3k-muths tandy-3k-muths UGHD 0 1089 qe0 thingol thingol UGHD 0 170 qe0 mac-se-umbaugh mac-se-umbaugh UGHD 0 3989 qe0 ------------------------------------------------------------------------ I can find no reason to explain why the MicroVAX is suddenly including all this host information in its routing tables (ie., the records with the UGHD value flags field). Both machines have their "routed" turned off, use /etc/rc.local "static" routing, and the same broadcast and netmask values. In addition, each machine has only one ethernet interface (ie., does not serve as a gateway). Also curious is the response time to the "netstat -r" command on the MicroVAX. It used to take just a second to return (as the VAXstation still does) but now takes over two minutes to return, essentially independent system load. Can any one hassard a guess as to what might be causing this strange phemonena? In addition, why would routing tables *ever* want to include "host" info in this manner? Note that when the route tables are flushed with a "route -f" the "host" data returns in after 5-10 minutes under normal work loads. - Joe -- bush@evax.arl.utexas.edu Vax Systems Manager (817) 273 - 3333 CSE Dept. UT-Arlington Office Rm 221 EB2 403 South Cooper P.O. Box 19015 Arlington, Texas 76019
iglesias@orion.oac.uci.edu (Mike Iglesias) (07/31/90)
In article <1990Jul31.005036.17883@evax.arl.utexas.edu> bush@evax.arl.utexas.edu (Joe Bush) writes: > > Lately the routing tables on an MicroVAX 3900 running Ultrix >3.1 have started to include "host" information in the "destination" >and "gateway" fields produced by the "netstat -r" command. You're probably getting ICMP redirects from some system or router. The 'D' in the flags means that the route should be deleted sometime, but I think you have to have routed running for the routes to go away. The ICMP redirects are usually sent by a router when it knows a better route to a subnet than you wanted to use. For example, you have a router, two systems, and one of them has two interfaces with a different subnet behind it: router ------------------------------ <- net 1 | | system a system b | | <- net 2 If system a just knows the router as it's default route, and the router knows that net 2 is behind system b, the router would tell system a via an ICMP redirect that it should route stuff for net 2 via system b. The reason that netstat -r is taking a long time to run is due to the lines that look like this: >129.107.2.91 129.107.2.91 UGHD 0 24 qe0 If you're using nameservers, you're waiting for the nameserver to try to resolve that address to a name and it can't. This takes a while until it times out, gives up, and prints the IP address in dotted form. You might look around for a newly installed system, or a recently booted or (mis)reconfigured router that could be causing the ICMP redirects. You also didn't say whether all the host entries in the routing table are for hosts on the same subnet/ethernet as your system. It's possible that something has gotten confused on your system and it no longer knows what it's local network is. Some useful information to see is the output of 'ifconfig qe0', and what it should be. Have you tried rebooting your system? Mike Iglesias University of California, Irvine Internet: iglesias@orion.oac.uci.edu BITNET: iglesias@uci uucp: ...!ucbvax!ucivax!iglesias
mogul@wrl.dec.com (Jeffrey Mogul) (08/01/90)
In article <26B5005F.14260@orion.oac.uci.edu> iglesias@orion.oac.uci.edu (Mike Iglesias) writes: >You might look around for a newly installed system, or a recently >booted or (mis)reconfigured router that could be causing the >ICMP redirects. I didn't examine the routing tables in the original message that carefully, so they could have reflected a problem of some sort ... but please note that there is nothing intrinsically wrong with having your host's routing tables built up out of redirects. In fact, this is precisely the RIGHT way for things to work, under current thinking. Hosts should not know about routing protocols or routes to non-local networks; rather, a host should know the address of one or more "default routers", and for non-local destinations should pick one of its default routers more or less at random (there is a concept of "preference level" to confuse the issue here, but one can ignore that in most cases). The routers know the right routes, and if a host makes the wrong choice, the router in question provides an ICMP Redirect referring to the specific destination host. I believe that recent versions of Ultrix properly handle incoming Redirect messages. The other piece of the puzzle is how an Ultrix host finds the neighboring default routers; right now, you can either run /etc/routed (which is "wrong" but works) or configure it by hand (which is wrong but usually works). The problem is that the IETF working group on Router Discovery (of which I am a member) hasn't quite finished specifying a standard for Router Discovery, so you really cannot blame anyone for not having implemented it. But within a year or two, Redirects in your routing tables will be the moral equivalent of fiber in your breakfast: good for what ails you and practically the only alternative. -Jeff
hans@umd5.umd.edu (Hans Breitenlohner) (08/01/90)
I noticed that a number of your redirects point to hosts with addresses 129.107.2.x (perhaps they all do). The machine in question seems to be address 129.107.2.51. Therefore it seems that it is confused about what addresses are on its local network. Perhaps the netmask is set incorrectly on the ifconfig statement?
hans@umd5.umd.edu (Hans Breitenlohner) (08/01/90)
In article <1990Jul31.184659.6260@wrl.dec.com> mogul@wrl.dec.com (Jeffrey Mogul) writes: = =I didn't examine the routing tables in the original message that =carefully, so they could have reflected a problem of some sort ... =but please note that there is nothing intrinsically wrong with =having your host's routing tables built up out of redirects. = =In fact, this is precisely the RIGHT way for things to work, under =current thinking. Hosts should not know about routing protocols =or routes to non-local networks; rather, a host should know the =address of one or more "default routers", and for non-local destinations =should pick one of its default routers more or less at random (there =is a concept of "preference level" to confuse the issue here, but =one can ignore that in most cases). The routers know the right routes, =and if a host makes the wrong choice, the router in question provides =an ICMP Redirect referring to the specific destination host. = ... = =-Jeff There is a problem with this approach in connection with the way Ultrix currently works: Once you have a redirect, it will be there forever (unless you manually flush the routing tables, or you run gated). If the entry should be bad, either because it was generated by a transient routing disturbance, or because the network configuration has changed, then that host may be permanently unreachable. Since other hosts on the same network will work fine, such problems are great fun to debug. Hans