Martin,
First, after a closer read of your original problem statement, it appears that I may have sent you off on the wrong route.
Can you give us the output of the following?
$ ifconfig -a ! this gives more info than $ tcpip show interface
From your initial post:
------------------------------------------------
There are following interfaces configured:
$ tcpip sh int
Interface IP_Addr Network mask Receive Send MTU
IE0 10.0.1.1 255.255.255.0 0 1 1500
IE1 10.37.150.29 255.255.254.0 387 6 1500
IE5 192.168.80.211 255.255.254.0 9 1 1500
LE1 10.37.153.132 255.255.255.224 6 6 1500
LO0 127.0.0.1 255.0.0.0 42 42 4096
WE0 10.0.0.1 255.255.255.0 0 1 1500
As the route has UGS flags:
$ netstat -rn
Destination Gateway Flags Refs Use Interface
default 10.37.153.129 UGS 1 4 LE1
10.0.0/24 10.0.0.1 U 1 0 WE0
10/8 10.37.150.1 UGS 0 0 IE1
------------------------------------------------
I assume the routing table you were expecting and wanting is this:
$ netstat -rn
Destination Gateway Flags Refs Use Interface
default 10.37.153.129 UGS 1 4 LE1
10.0.0/24 10.0.0.1 U 1 0 WE0
10/23 10.37.150.1 UGS 0 0 IE1
The difference being the length of the network mask on the IE1 interface route.
It appears to me that TCPIP services is creating classfull routes for "connected" networks, when it should be creating CIDR (variable length mask based routes) based on the mask specified by the netmask specified on the interface.
In other words, the interface mask for IE1 is 255.255.254.0, which corresponds to /23, but the route being created by TCPIP services is a class A /8 (which is "correct" only in the pre-CIDR internet, where masks were based on the internet address prefix, into three classes, A /8, B /16, and C /24).
If you don't have GATED enabled (you said you don't have any dynamic routing enabled), it is still possible that it is receiving IRDP (ICMP Router Discovery Protocol, RFC 1256) advertisements and acting on them, although the TCPIP documentation doesn't suggest this. For more information about IRDP, Google for RFC 1256.
Your last post said: "There are a few 10.37.x.x/24 segments connected to the OpenVMS system." If "a few" means more than 10.37.150/24 and 10.37.151/24 (or 10.37.150/23), then you will need a router and the appropriate static route (for example, if all 10.37/17 addresses (10.37.0.0 - 10.37.127.255)should be reached via the IE1 interface, then you could use one static route to forward all 10.37/17 addresses to the next hop router (10.37.150.1?) and it will be responsible to forward to the correct network. Alternatively, you could put multiple specific /24 routes if you have sparse routing.
As to a work around: My first thing to try would be to add an explicit route for 10.37.x.x/m with net hop address of the correct router. And if the shorter (less specific 10/8) route is there, delete it. I am not sure if that will keep it from returning or not. You will need to try it.
Jon
it depends
