10-17-2011 12:37 AM
This is a variation on my posting of 18-Aug-2011 where I asked about disabling Path MTU Discovery.
Having done that, the problem still occurs. So let me try again.
The system is running OpenVMS VAX V7.3 with TCP/IP Services V5.3 ECO 4.
There are many printer queues sending to various HP laserjet printers around the country and most of them work fine. However one queue in particular is prone to stalling each evening at about 1:30am when the first job of the day is queued to it.
After some investigation I determined that the stall was due to an incorrect TCP/IP route being present on the system.
TCP/IP Services is configured with static routes (only), no dynamic routing and no Path MTU Discovery.
The static routing table looks like this:
Sys_T1> tcpip show route/perm
Type Destination Gateway
PN 0.0.0.0 192.168.50.253
PN 18.104.22.168/16 192.168.50.252
PN 192.168.0.0/16 192.168.50.252
For some reason the following route is popping up when the TCPIP$TELNETSYM symbiont attempts to contact the printer at IP address 22.214.171.124
Type Destination Gateway
DH 126.96.36.199 192.168.50.254
If I manually delete the route it usually goes away and the print job runs to completion. However that's provided I delete the route after 9am (more or less); it seems that someone insists on having this route on the system between 1am and 9am! (The gateway in question is the Internet firewall, but the printer is not reachable through it.)
Can someone tell me, what TCP/IP component or config setting would cause a route to be dynamically added? As I said, I've not enabled dynamic routing and I've disabled Path MTU Discovery. Those are the only two mechanisms I know of which could automatically add routes to the system, but maybe there's one I don't know about.
10-17-2011 02:23 PM
I've had trouble with dynamic routes before. Not sure I understand exactly how they work, but the blame is possibly outside the OpenVMS system. A router will occasionally give feedback saying "this is a better route", which somehow gets into the dynamic route table. Unfortunately, it can be wrong! In one case, my own workstation would get a subnet route pointing back to itself, breaking all inward and outward network connections.
I gave up trying to figure out where it was coming from, and treated the symptom with a job which checked for and deleted any dynamic routes every 30 minutes or so (I may have been more selective, don't remember the exact details). If you want to be more selective, maybe have a job which pings your target address, if that every fails, delete the dynamic route.
Deleting a dynamic route should always be "safe", as they're an optimisation. Worst case is you will take a longer path than necessary.
In a well designed network, dynamic routes shouldn't be necessary, and as you've discovered, can break things if they're incorrect.
10-17-2011 03:10 PM
This is probably coming from an icmp redirect message. A gateway can provide an updated "better" route to a target host back to the originating node. This a legitmate behavior, but if something on your network is generating these messages in error, that will cause problems.
Kick this back to your networking team. Run a packet capture. There may be a misconifgured router or a duplicate address somewhere on the network.
10-17-2011 09:50 PM
Hoff, yes, this is an emulated environment but I'm not sure how that's relevant.
Andy, your suggestion that it's ICMP redirects seems like a good one. I've thought it rather odd that the erroneous route is added at roughly the same time every day and maybe this remote site is on a link which goes down regularly (I don't know, but I'll try to find out).
I'll have another go at pushing this back to the networking team.
10-18-2011 05:17 AM
You're potentially tussling with a network emulation layer that can classically be problematic in various hardware emulators, and you're also involving another operating system platform as a network gateway. These components can and do introduce IP routes, can mess up network connections, can encounter address collisions, and can implement the evil that is NAT.
Would you rule out networking hardware and a switch and a gateway router that's the primary connection for a physical VAX out to a larger network? That's what the emulator is providing you with here, after all.
The ability to view what the emulator and the host and the network emulation layer is doing is dicy here, too; you can't tap into that nearly as easily as you can mirror a switch port to see what's going on.
If you can mirror the switch port, you can see if the routing update is external. If not, then it's probably the morass that can be the emulator, host and network layer that's "getting helpful".