"Phantom" routes being created in TCP/IP Services (VAX)

All types of networks, network stacks, and protocols supported by OpenVMS.
Post Reply

Topic author
jeremybegg
Contributor
Posts: 18
Joined: Mon Jun 08, 2020 3:39 am
Reputation: 0
Status: Offline

"Phantom" routes being created in TCP/IP Services (VAX)

Post by jeremybegg » Sun Oct 22, 2023 4:13 am

Hi,

I have been asked to investigate a problem with a Charon-VAX setup running Compaq TCP/IP Services for OpenVMS VAX Version V5.3 - ECO 4, OpenVMS V7.3.

This system runs an manufacturing order processing application with users connected from around the country, and printer queues pointing to various printers around the country. Yes, it's rather old and there is "a plan" to migrate the business processing to SAP - but that's still a couple of years away.

Every now and again a printer queue will stall for no apparent reason; the printer is fine, it can be accessed from anywhere else on the network - anywhere other than the VMS server! Looking into the issue I eventually worked out that TCP/IP Services had created a route to the printer via the "wrong" gateway. For example:

Code: Select all

$ TCPIP SHOW ROUTE

                             DYNAMIC

Type           Destination                           Gateway

AN    0.0.0.0                               192.168.50.253
...
DH    192.168.134.20                        192.168.50.254
The default gateway 192.168.50.253 is the correct gateway to reach all sites.
There is a router at 192.168.50.254 but it can't be used to reach this site (192.168.134.x).

So the question arises, what would be creating this route, and why? Note, neither ROUTED nor GATED routing is configured.

Thanks,

Jeremy Begg


babydr
Valued Contributor
Posts: 52
Joined: Thu Dec 23, 2021 8:02 pm
Reputation: 0
Location: Fairbanks , AK.
Status: Offline

Re: "Phantom" routes being created in TCP/IP Services (VAX)

Post by babydr » Sun Oct 22, 2023 5:12 pm

@Jerremy , Is it possible that the default router may be seeing moments of processing difficuty ?
And/Or It possible that the VMS server is allowing ICMP Redirect prompts from the other router ?
Just a couple of thoughts .
Last edited by babydr on Sun Oct 22, 2023 5:13 pm, edited 1 time in total.


mberryman
Active Contributor
Posts: 27
Joined: Sat Sep 02, 2023 1:31 pm
Reputation: 0
Location: Colorado Springs, CO, USA
Status: Offline

Re: "Phantom" routes being created in TCP/IP Services (VAX)

Post by mberryman » Mon Oct 23, 2023 1:14 pm

The route type is DH. D means dynamic and H means a host route. Something is dynamically inserting this route into your routing table and, without any dynamic protocols running, that almost certainly means an ICMP redirect. However, ICMP redirects are supposed to time out (according to the docs, in 3 minutes). The implication here is that something keeps sending the redirect. You can try the following:

1. Add a static route for this host with a precedence of 0. This should override any other route for this host entered into the routing table. However, if there are any other DH routes in your table, then further investigation is warranted.

2. Enable GATED. In the configuration file, set all interfaces to passive, all protocols to off and also set redirect to off. This should cause the system to ignore ICMP redirect messages without actually running any routing protocols.

3. I can't find any documentation on the various kernel variables but perhaps the command
tcpip sysconfig -r inet icmp_redirecttimeout=1
will cause the route to timeout more quickly. If it does, then make the change permanent by editing tcpip$etc:sysconfigtab.dat

Note that all of this is based on TCPIP Services v5.7. It is possible that not everything applies to v5.3.

Finally, the use of ICMP redirects is out of favor these days. If possible, have whoever manages your routers to turn it off. I would also note that, if your default router is sending a redirect to a router that cannot actually reach the destination, then your default router is misconfigured. If it is not the default router sending the message, then you have a rogue device on your network (many hosts these days ignore ICMP redirects, apparently TCPIP services does not unless specifically instructed to).

Post Reply