> 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