[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::digital_unix

Title:	DIGITAL UNIX(FORMERLY KNOWN AS DEC OSF/1)
Notice:	Welcome to the Digital UNIX Conference
Moderator:	SMURF::DENHAM

Created:	Thu Mar 16 1995
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	10068
Total number of notes:	35879

9394.0. "Route add -net gives "network is unreachable"" by CSC32::N_HENDERSON (Nancy (Henderson) Flavell, CSC) Fri Apr 04 1997 15:31

Some advice on the following customer's configuration would be greatly
appreciated.  They are running Digital UNIX 4.0b on the Alpha.

   Ethernet
  198.119.19.42
     Alpha              both use 255.255.255.224 subnet mask
  198.119.19.76
     ATM
      |
       ------ATM SW-----ATM SW-----ATM SW-----------
                                                    |
                                                198.119.1.2
                  netmask 255.255.255.0           Cisco RTR
                                                198.118.56.1

He tried to configure two network routes on the Alpha:

        route add -net 198.119.1.0 198.119.19.76       ; can now ping RTR
        route add -net 198.119.56.0 198.119.1.2   ; "network is unreachable"

The customer claims the same routes work on Sun systems on the same
topology, thus the Digital UNIX implementation must have a bug.  If 
I believed this, I would be composing an IPMT instead of seeking
support here.

The manpages for route describe "network is unreachable" as:

   An attempt to add a route failed because the gateway listed was
   not on a directly connected network.  The next hop gateway must
   be given.

If I take the latter statement to mean, "Give a gateway which is the
next hop in relation to one of the directly-connected networks,"
then the route to network 198.119.56 shouldn't be expected to work.

Questions:  Am I assuming correctly that he should not be able to
set that second network route?  If so, is there some piece of an
rfc or something definitive which I can go armed with back to the
customer to convince him not to escalate this problem (we're 
dealing with a clout-conscious organization).  Additionally, would
there be a recommended work-around in their configuration to achieve
the same results, namely to get to the 198.119.56 network via the
ATM interface?

Ramblings and observations, for what they're worth:  I don't think
the fact that the interface is ATM has anything to do with getting
the "network unreachable" error, but feel free to correct me otherwise.
Also, it seems kind of scarey that there is at least one implementation
out there which would allow you to set specific routes "down the
line" like this.  Thoughts?

Nancy

T.R	Title	User	Personal Name	Date	Lines
9394.1	-netmask needed?	SMURF::DUSTIN		`Fri Apr 04 1997 19:39`	10
	My quick guess is you need to add -netmask 255.255.... whatever your mask is for the network when you do the route add commands. The route command adds the route using the default netmask appropriate for the class of the network, so for 198, Class C address, the netmask will be 255.255.255.0 unless you specify otherwise. John
9394.2	Class-C netmask is okay	CSC32::N_HENDERSON	Nancy (Henderson) Flavell, CSC	`Mon Apr 07 1997 15:10`	80
	John, Thank you for your considerations. The netmask they're wanting to point to IS the default Class C netmask, so shouldn't that be okay already? Here is some more information on what this looks like to them. It almost seems like a difference of interpretation between Sun (Solaris) and Digital UNIX. original routing table: # netstat -rn Routing tables Destination Gateway Flags Refs Use Interface Netmasks: Inet 255.255.0.0 Inet 255.255.255.0 Inet 255.255.255.224 Route Tree for Protocol Family 2: default 198.119.19.33 UG 1 8 tu0 127.0.0.1 127.0.0.1 UH 1 0 lo0 128.183 198.119.19.33 UG 1 56 tu0 192.43.240 198.119.19.33 UG 0 0 tu0 192.107.196 198.119.19.33 UG 0 0 tu0 198.119.19.32 198.119.19.42 U 2 24 tu0 198.119.19.64 198.119.19.76 U 0 1 lis0 198.119.19.67 198.119.19.76 UH 0 1 lis0 # add the interface route: # route add -net 198.119.1.0 198.119.19.76 -interface add net 198.119.1.0: gateway 198.119.19.76 # This works fine, and produces the following routing table: # netstat -rn Routing tables Destination Gateway Flags Refs Use Interface Netmasks: Inet 255.255.0.0 Inet 255.255.255.0 Inet 255.255.255.224 Route Tree for Protocol Family 2: default 198.119.19.33 UG 1 8 tu0 127.0.0.1 127.0.0.1 UH 1 0 lo0 128.183 198.119.19.33 UG 1 164 tu0 192.43.240 198.119.19.33 UG 0 0 tu0 192.107.196 198.119.19.33 UG 0 0 tu0 198.119.1 198.119.19.76 U 0 7 lis0 198.119.19.32 198.119.19.42 U 2 25 tu0 198.119.19.64 198.119.19.76 U 0 1 lis0 198.119.19.67 198.119.19.76 UH 0 2 lis0 # He can ping the gateway that he wants to use on the interface route: # ping 198.119.1.2 PING 198.119.1.2 (198.119.1.2): 56 data bytes 64 bytes from 198.119.1.2: icmp_seq=3 ttl=255 time=1 ms 64 bytes from 198.119.1.2: icmp_seq=4 ttl=255 time=1 ms 64 bytes from 198.119.1.2: icmp_seq=5 ttl=255 time=0 ms 64 bytes from 198.119.1.2: icmp_seq=6 ttl=255 time=1 ms When he tries to add a route using the address that he has an interface route to: # route add -net 198.119.56.0 198.119.1.2 writing to routing socket: Network is unreachable add net 198.119.56.0: gateway 198.119.1.2: ioctl returns 51 Network is unreachable The identical setup works fine on solaris 2.5 and 2.4. - Nancy
9394.3	try this	NETRIX::"[email protected]"	Brian Haley	`Tue Apr 08 1997 16:51`	26
	Hi, I believe you were correct in .0 with "An attempt to add a route failed because the gateway listed was not on a directly connected network. The next hop gateway must be given." The gateway the customer is trying isn't on any local network, so I wouldn't expect the command they're trying to work. They should maybe try the address of the ATM switch (198.119.19.XX) because it looks like it's doing some routing of it's own to 198.119.1 (there has to be some way to get from 198.119.19 to 198.119.1). Or maybe even easier just: # route add -net 198.119.56.0 198.119.19.76 -interface This worked for me, but I guess it all depends on how smart your routers are. The first-hop here is a Cisco and might have still had it in it's cache. You should also be using the -netmask as John suggested, otherwise I think you'll get the implied network interface netmask of 255.255.255.224. -Brian [Posted by WWW Notes gateway]
9394.4	Elevated	CSC32::N_HENDERSON	Nancy (Henderson) Flavell, CSC	`Fri Apr 11 1997 16:45`	11
	Brian and John, I appreciate your efforts to find a workaround for this configuration! However, the suggestions we have given to the customer have all either not worked, or were rejected. The customer continues to insist that this is a bug and that it be reported as such, so it has been escalated as case HPAQ40M7A (CFS.50420). Nancy