Original message:
> Howdy!
>
> Under SunOS 4.1.4 we have a need to route to a subnet described as:
>
> net 172.22.16.0 netmask 255.255.240.0
>
> The command we used to do this is:
>
> route add net 172.22.16.0 192.168.184.102 1
>
> which seems to work just fine. An address such as 172.22.24.71
> becomes pingable. However, it also sucks in destinations like
> 172.22.139.140, which seems completely wrong -- it should be
> unaffected by the previous routing statement, and get sent to the
> default router. Unfortunately, the routers do not share each others'
> routing tables, so we need to get this source-level routing to work
> correctly.
>
> On the theory that /etc/netmasks needs updating, we have:
>
> 172.22.16 255.255.240.0
>
> in that file, but it helps not at all. A reboot did not help either,
> so this seems to be a configuration problem of some sort.
>
> Any help greatly appreciated.
>
> -Steve Kives
Thanks to everyone who responded. I got lots of great help, good explanations,
and some hopeful but apparently doomed suggestions.
First off, the /etc/netmasks entry should be:
172.22 255.255.240.0
With this correction, the routing should work as planned in this table:
127.0.0.1 127.0.0.1 UH lo0
default 204.148.184.150 UG le0
204.148.184.64 204.148.184.85 U le0
172.22.16.0 204.148.184.102 UG le0
172.22.128.0 204.148.184.125 UG le0
As you can see, a packet for 172.22.24.11 should use the 102 router, while a
packet for 172.22.139.10 should use the 125 router. In reality, the
/etc/netmasks entry is completely ignored and the 172.22 address are treated as
class B, and the first 172.22.xx.yy route in the table gets used.
Bummer!
Some folks pointed out that SunOS has been known to do subnet routing, but
others folks noted that this only occurs when one of your interfaces is part of
the subnet in question. As you can see, the subnets are remote. The local
interface has a ffffffc0 netmask.
One very helpful note:
---- john heasley <heas@shrubbery.net> at Internet: .... 4.1.4 is definitely classful. it is based on bsd 4.3 kernel. there is no way to install subnet masks in the routing table and hence everything is interpreted classful. .... i know it's disgusting ... but unless you use a funky netmask on the intf itself (which really won't work for your situation), you're not going to get it. .... this will is avail. in sol 2.5.1 via an expensive patch from sun (~$1000) or wait for sol 2.6. upgrade! for christ sakes, you get support, out of a dying/dead o/s, better memory management, free raid via ODS, ... do it now...in fact, most of your hand-rolled 4.1.4 stuff should just work via BCP. ----Armed with this knowledge, I managed to get the same admission out of 1(800)SUN-NONHELP. The non-help lady claimed there was no such routing patch, but that 2.6 would have classless routing when it comes out mid-summer or so. (Re: "non-help" -- I emphatically stated that we were not running routed, gated, or any other routing daemon but she still insisted that RIP packets were flying around all over the place and therefore you had no control over the routing on your machine. She also insisted on knowing whether or not the destination subnets were more than 15 hops away before we proceded further with the problem analysis.)
Faced with using host-routes for all 172.22 destinations (we could not get Class-C routing to work either) we browbeat the network group into letting the two routers know about each others' networks, so we are back to using a single default route for the time being. Once we go to 2.6 (soon, I hope) we should be able to solve this problem elegantly.
Thanks to all who took the time to respond.
-Steve Kives
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:48 CDT