route apperas in routing table after system reboot

[Martin Sedlak]

Hi the route 10.0.0.0/8 comes to the routing table when OpenVMS starts up.
$tcpip sh route
DYNAMIC
Type Destination Gateway
AN 10.0.0.0/24 10.0.0.1
AN 10.0.0.0/8 10.37.150.1


This is strange, because before the system was rebooted, we made sure, the route is removed from routing tables:
$ tcpip route delete -net 10.0.0.0 10.37.150.1
$ tcpip set noroute 10.0.0.0 /gateway=10.37.150.1
$ tcpip set noroute 10.0.0.0 /gateway=10.37.150.1 /permanent


Dynamic routing protocols are not configured.


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 that it must be created by an route command. When monitoring each phase of SYSTARTUP_VMS.COM, we found out that the route comes into the dynamic routing table (tcpip sh route) somewhere in the @SYS$STARTUP:TCPIP$STARTUP.COM phase.

Now I'm searching the TCPIP startup phase, however I'm not too much succesfull.

Has anyone faced similar issue? Have you got an idea/clue, where to have a look?

TCPIP> sh ver
HP TCP/IP Services for OpenVMS Alpha Version V5.4 - ECO 7
on a AlphaServer DS25 running OpenVMS V7.3-2

Thank you very much.

[marsh_1]

hi,

it will probably get that routing info back from that switch (10.37.150.1) when TCPIP has established contact with it, if you do a $tcpip show r/p it won't be there.

hth

[Jon Pinkley]

Martin,

Dynamic routes can be the result of receiving an ICMP redirect from a router, in this case, I would assume the redirects are coming from the default router at 10.37.153.129

See this thread

http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1096481

See response dated Feb 9, 2007 18:39:50 GMT

Jon

[Martin Sedlak]

mark: thx. I'm getting the config already
John: thx. I'll follow your idea with ICMP redirect

I will get back here with the results soon :)

[Martin Sedlak]

Hello, it took quite long time, but finally, the ICMP redirects were disabled. However, when the system was rebooted, the route came up again :)

It looks like the problem is not related to icmp redirect but it resides elsewher.

Unfortunately, the environment did not allowed us to dump the interfaces, therefore we do not know if to track the problem outside the VMS or inside.

Should you have any advice or comment, do not heshitate to reply here. Thank you.

[John Gillings]

Martin,

>However, when the system was rebooted, the
>route came up again :)

I haven't seen a description of any actual problem these routes are causing, other than the apparent expectation that they "shouldn't be there".

Is the route really incorrect? Have you checked that it isn't doing you a favour by bypassing one or more routing hops?

Please post any error messages, or error symptoms that you believe are a result of the unexpected routes.

If everything is working correctly, the best advice I can give for the stated problem is "don't look".

That said...

A long time ago, on even older versions of OpenVMS and TCPIP services, and possibly aided and abetted by incompatible router and switch protocols, there were some serious problems that *incorrect* ICMP redirects could cause, the worst of which was a redirect of all addresses back to the node itself, effectively cuting the node off the network. I had a node that suffered this problem, so I wrote a procedure that ran every hour to delete any bad redirects from the routing table. SMOP a dozen or so lines in DCL. If the route offends you, pluck it out!

I doubt OpenVMS engineering would be terribly interested in this unless you could demonstrate the issue (along with a bona fide negative symptom) on more recent versions of OpenVMS and TCPIP.

[Martin Sedlak]

Hi John, thank you for the reply. The 10/8 route is causing wrong routing. There are a few 10.37.x.x/24 segments connected to the OpenVMS system.

Unfortunately, I have not seen any error message pointing to this.

[Jon Pinkley]

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

[Jim_McKinney]

This may not be convenient, but, if you continue to be unable to determine whether this is a learned route or one that results from your chosen config you could try unplugging your node from the network and booting - if it is immediately present in your routing table after the boot you'll know that is a direct result of your software config.

[The Brit]

This is just a question, and probably has no bearing on the problem, I'm just curious).

Is interface LE1 a "logical" device (i.e. failover set), and if so, which physical devices make up the set?

Dave.