UCX - Connectivity Issues

[Andrew Baughan]

Hi,

I'm looking for help for an old VMS box we have on our network. The relevant system and versions are as the below output:

UCX> show version

DIGITAL TCP/IP Services for OpenVMS VAX Version V4.2
on a MicroVAX 3100-80 running OpenVMS V5.5-2

This system has not been responsive to tcp since before I started here, but LAT works fine and is how the box is currently used. I am looking to get TCP working again, but my knowledge of VMS in general and UCX specifically is very limited. No connection can be made to or from this box using any TCP based app.

A loop to the localhost via IP or alias works fine, a loop to the hostname or actual IP fails. As below:

UCX> loop 127.0.0.1
%UCX-I-LOOPACT, 127.0.0.1 is alive
UCX> loop localhost
%UCX-I-LOOPACT, LOCALHOST is alive
UCX> loop 10.0.88.32
%UCX-I-LOOPINACT, 10.0.88.32 does not respond
UCX> loop netops
%UCX-I-LOOPINACT, NETOPS does not respond

The default route is to an IP of 10.0.88.13, which does not respond to a straight forward loop, but does respond when /noroute is passed.

UCX> loop 10.0.88.13
%UCX-I-LOOPINACT, 10.0.88.13 does not respond
UCX> loop /noroute 10.0.88.13
PING 10.0.88.13: 56 data bytes
64 bytes from 10.0.88.13: icmp_seq=0. time=10. ms
64 bytes from 10.0.88.13: icmp_seq=1. time=0. ms
64 bytes from 10.0.88.13: icmp_seq=2. time=20. ms
Cancel
----10.0.88.13 PING Statistics----
3 packets transmitted, 3 packets received, 0% packet loss
round-trip (ms) min/avg/max = 0/10/20


I will also include the output from some basic commands to provide more information, but any assistance would be appreciated.
Cheers

UCX> show int
Packets
Interface IP_Addr Network mask Receive Send MTU

SE0 10.0.88.32 255.0.0.0 39338085 85684 1500
LO0 127.0.0.1 255.0.0.0 49 90 65535
UCX> show route

DYNAMIC database

Type Destination Gateway

AH 127.0.0.1 127.0.0.1
AN 32.0.0.0 10.0.88.249
AN 0.0.0.0 10.0.88.13
AN 17.0.0.0 10.0.88.248
AN 10.19.0.0 10.0.88.248
AN 10.19.0.0 10.0.88.249
AN 10.0.0.0 10.0.88.32
AN 192.168.85.0 10.0.88.14

[Bojan Nemec]

Andrew,

If loop/noroute 10.0.88.13 works, this means that the VMS and 10.0.88.13 are on the same local network.

What is abbout this route:

AN 10.0.0.0 10.0.88.32

The 10.0.88.13 is routed thru 10.0.88.32. Try to loop 10.0.88.32 or try to delete this entry.

Bojan

[Andrew Baughan]

Bojan,

The 10.0.88.32 address is the IP of the host/box in question, from my understanding that entry is correct, specifying all 10.0.0.0 address (anything on that class A network) passes through the IP address of the host?

Am I incorrect in that evaluation?

[Bojan Nemec]

Andrew,

Sorry, you are right this route is auto generated and I have not seen that 10.0.88.32 is the VMS.

Have you try to ping the VMS from 10.0.88.13?

What about UCX> show interface/full

Bojan

[Andrew Baughan]

The output requested is below. I am attempting to gain access to the device at that IP, might take awhile though.

UCX> show interface/full
Interface: SE0
IP_Addr: 10.0.88.32 NETWRK: 255.0.0.0 BRDCST: 10.255.255.255
Ethernet_Addr: AA-00-04-00-CA-04 MTU: 1500
Flags: UP BRDCST NOTRL RUN
RECEIVE SEND
Packets 39373707 85764
IP packets 603 30
Broadcast IP packets 5436659 5
Trailer 1 IP packets 0
Trailer 2 IP packets 0
ARP packets 218 32917
Broadcast ARP packets 33936227 52812
Drops
IP packets 0 0
ARP packets 0 0
Errors
Hardware 0 11
Software 0 0
Restarting attempts 0
Successful restarts 0

Interface: LO0
IP_Addr: 127.0.0.1 NETWRK: 255.0.0.0 BRDCST:
Ethernet_Addr: MTU: 65535
Flags: UP LOOP
RECEIVE SEND
Packets 50 91
IP packets 50 91
Broadcast IP packets 0 0
Trailer 1 IP packets 0
Trailer 2 IP packets 0
ARP packets 0 0
Broadcast ARP packets 0 0
Drops
IP packets 0 0
ARP packets 0 0
Errors
Hardware 0 0
Software 0 0
Restarting attempts 0
Successful restarts 0

[Andrew Baughan]

Ok,

Got access alot quicker than I thought. The device is an ISDN router, and the output showing a failed ping is below.

AMAZON1:NOT SAVED* ping 10.0.88.32
Target Address = 10.0.88.32
Request Count = 1

AMAZON1:NOT SAVED*
*** TRAP from local agent at 19-Jan-07 12:23:12 uptime 34 Days, 19:07:28
*** PING: [10.0.88.32] 1/0 packets sent/rcvd;

[Bojan Nemec]

Andrew,

The show interface/full shows some hardware errors. Do some activity on tcpip (ping...) and look if this value changes.

Probably it will be good to test from another node in the same local network. Maybe there is a misplaced route in the 10.0.88.13 router.

Bojan

[Steven Schweda · Accepted solution]

If the node's address and netmask are given
by:

> IP_Addr: 10.0.88.32 NETWRK: 255.0.0.0

then all those 10.x.x.x routes:

> AN 10.19.0.0 10.0.88.248
> AN 10.19.0.0 10.0.88.249

are confusing to me, as any 10.x.x.x address
is on the local subnet. If they're also
confusing to TCPIP, that might explain
something.

255.0.0.0 is the _default_ netmask for a
10.x.x.x address, but if your network is not
arranged that way, you may need to specify a
non-default netmask for this interface.

For example, on my home network, I use
10.0.0.x addresses, with a netmask of
255.255.255.0:

TCPIP> show interface
Packets
Interface IP_Addr Network mask Receive Send MTU

LO0 127.0.0.1 255.0.0.0 9144383 9144383 4096
WE0 10.0.0.9 255.255.255.0 22966483 11700214 1500

and:

TCPIP> show route

DYNAMIC

Type Destination Gateway

AN 0.0.0.0 10.0.0.1
AN 10.0.0.0/24 10.0.0.9
AH 10.0.0.9 10.0.0.9
AH 127.0.0.1 127.0.0.1


On some other (working) node on your network,
what is the netmask being used?

With a netmask of 255.255.255.0, those
10.19.x.x routes make more sense (to me).

For the record, everything's different here,
but should be close enough:

TCPIP> show version

HP TCP/IP Services for OpenVMS Alpha Version V5.4 - ECO 6
on a COMPAQ Professional Workstation XP1000 running OpenVMS V7.3-2


10.0.0.9 is the Alpha, and 10.0.0.1 is the
DSL router (hence the default route).

[Andrew Baughan]

Steven,

Those routes you highlighted were part of an old legacy setup, which is now in-active.

I removed those routes and the host started responding, so I have also removed from perm table to ensure this doesn't re-occure after a re-boot.

Are you able to suggest a reason why those route would cause this type of issue?

FYI, i removed both 10.19.0.0 routes, 17.0.0.0, and 32.0.0.0 routes.

[Steven Schweda]

I don't know exactly what the code does, but
if the netmask is 255.0.0.0, then 10.19.0.0
probably looks just like 10.0.0.0 after the
mask has been applied. This would mean that
you had specified multiple routes to the
10.0.0.0 subnet (which is practically
everything), and two of them made no sense,
and one of those was probably being used.

I'd still like to know what other systems in
your network are using for a netmask, as
this system should agree with them.

[Andrew Baughan]

This is the output from one of the other older systems

UCX> show ver

Digital TCP/IP Services for OpenVMS VAX Version V4.2 - ECO 4
on a VAX 4000-600A running OpenVMS V6.2



UCX> show int
Packets
Interface IP_Addr Network mask Receive Send MTU

QE0 10.0.88.34 255.0.0.0 45988099 8016 1500
ZE0 10.0.88.20 255.0.0.0 47015422 121482 1500
LO0 127.0.0.1 255.0.0.0 38 38 65535
UCX> show routes /full

DYNAMIC database

Type Destination Gateway

AH * 127.0.0.1 LOCALHOST * 127.0.0.1 LOCALHOST
AN * 10.0.0.0 * 10.0.88.20 CSRDCD_2
AN * 10.30.0.0 * 10.0.254.254
AN * 10.0.0.0 * 10.0.88.34 CSRDCD_1

[Steven Schweda]

Ok. If the consensus is 255.0.0.0, then you
should be ok (so long as all the routes make
sense).

[Andrew Baughan]

Thanks for the help.

[Andrew Baughan]

Solution found, as direct by Steven.