karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (09/08/89)
I am having a problem convincing a couple of my systems to do the right things in advertising and using a route to/through a SLIP connection. There is one host (Giza, 128.146.8.61, netmask 0xffffff00) on which exists a SLIP line out to another host. The SLIP connection is configured as 128.146.60.6 at Giza's end and 128.146.60.14 at the remote end. The connection between these two hosts runs just fine. I would like to be able to reach Giza's and the remote host's SLIP interfaces using Giza's ...8.61 interface as the gateway. Routed seems unable to advertise the route automatically. This is a problem, but not fatal in and of itself. It was suggested to me that routed cannot find interface sl0 when it first starts up on Giza because sl0 is not configured at that time - the slattach to the SLIP port is done much later. Lacking routed support, it seemed reasonable to try adding a route from another host manually. There are at least two peculiar things happening here. First, I attempted "route add 128.146.60.0 128.146.8.61 1" from another host (Cheops, 128.146.8.62), upon which I was informed that a route to "host" ...60.0 was added. Attempts to reach ...60.6 did not work. It seems odd that route considered this to be a host and not a network. I would think that route should be able to infer the subnet mask based on configuration of other network interfaces, thus determining that the indicated destination is a (sub)network and add the route appropriately. So I deleted that route, and added it back in with an explicit "net" keyword. This works. Ping, telnet, rlogin, and other stuff to both ...60.6 and ...60.14 now work. However, most peculiarly, my routing table (from netstat -r) now shows two default routes, one through our backbone ethernet's Proteon connection to the campus ring (which is correct) and one through Giza's ...8.61. It's a bona fide default route: I can delete it again via "route delete 0 128.146.8.61" and I am informed blandly that the route to network 0 is removed. The final kicker is that this extra default route is not a problem, no matter how strange it looks: while that extra default route is in place, I can reach any other host I want with no trouble, e.g., telnet to nic.ddn.mil worked just fine. I'd be most interested in any clues anyone can give me about any of the 3 problems (lack of routed advertisement, probably now understood due to non-existence of sl0 at routed startup; lack of route's comprehension of ...60.0 as a network; extra default route). --Karl