Can't communicate with new V-lan

[Daniel McCracken]

I have two alpha stations connected to our network. An employee who needed to access the system moved to another part of the city which is on a different switch. The Alpha cannot ping anyone from that swith. Anyone from that switch can ping the switch that the Alpha stations are on, but not the Alpha stations themselves. I already checked with our IT department and they say that everything is OK on there in. We have narrowed it down to the Open VMS environment. The V-lan in question is a new one installed a year ago. Is there anything in the Alpha station that I needed to do to allow them to "see" the switch?

Thank you.

[Volker Halle]

Daniel,

welcome to the OpenVMS ITRC forum.

Network questions are generally hard to answer without information about things like the network infrastrucutre, IP adresses etc.

First, do the AlphaStation LAN interfaces have a valid link to the switch-port.

$ MC LANCP SHOW DEV/CHAR or /INT

should give you that information. /INT will also show the LAN driver messages issued on the console. You should see link up and link down messages.

$ TCPIP SHOW INT will show up the IP interfaces, addresses and receive/send packet counters - if you're using HP TCP/IP Services.

Do the IP addresses match the subnet those AlphaStations are supposed to be on ?

Volker.

[Richard Brodie_1]

As Volker said, it's not easy to debug a network remotely at the best of times.

However, the obvious questions would be: is the remote location on a different subnet, and if so is the gateway/netmask set up correctly on the Alpha.

[Robert Gezelter]

Daniel,

As Volker observed, it can be a challenge to troubleshoot a network problem like this remotely.

That said:
- Are the stations configured with Static IP or are they using DHCP?
- What addresses are they using?
- What is your VLAN configuration?

There are many things that can go wrong, and having diagnosed many remotely (although with management access to the systems and the switches), it is even harder to diagnose with even less information.

Being able to use PING to reach the switch MAY only mean that the management port for the switch is different than the VLAN for the stations.

More details are needed.

- Bob Gezelter, http://www.rlgsc.com

[Daniel McCracken]

Hope I can shed a little more light on the problem. The Alphas are on V-Lan 17, (xxx.xxx.17.1). The new V-Lan is set as 22,(xxx.xxx.22.1). The system can communicate with other V-lans such as 13 14 15 18 19 and 21. Anything coming from 22 can not communicate with the Alpha (xxx.xxx.17.10), but can communicate with the switch itself (xxx.xxx.17.1). The Alpha however cannot communicate to anything on the 22 switch, even to the switch itself (ie: ping xxx.xxx.22.1). Our IT department says that the switch is set up exactly like the others.
All of the switches are on the same sub-net. Both the Alphas and the workstations are on static IPs. The main switch is V-lan 10 (xxx.xxx.10.1) which routes all of the communication to the other switches. Also the Alphas are running VMS 6.2.10a so newer command do not work. I also didn't do anything with the Alphas when the new V-lan was installed.
Hope this gives you alittle more information on my problem.

Thank you

[Robert Gezelter]

Daniel,

Thank you for the additional information. I would TRULY like to see the details of the switch configurations. VLANs are almost always a switch level technology, and I strongly suspect that something is mis-set at that level.

I would consider using WireShark (http://www.wireshark.org ) and an inexpensive HUB (hub, not switch!) hooked up between the LAN switch and the workstation(s) to see what is actually going over the wire. I might also consider using a notebook directly on the wire to create a simpler case to show the network group.

- Bob Gezelter, http://www.rlgsc.com

[Volker Halle]

Daniel,

to prove to your IT department, that this may have nothing to do with OpenVMS, how about connecting a PC/laptop with the same address/netmask as the AlphaStation to the same switch-port as the Alpha and try to repeat the ping tests ?

Does UCX SHOW ROUTE show anything unusual ?

Volker.

[Daniel McCracken]

Thanks alot Volker, you indirectly lead me to the answer. It was a problem with OpenVMS. I checked the ucx show route and it listed all of the V-lans that I could access. I noticed that V-lan 22 was not on it. Doing a little research, I figured out how to add that V-lan to the list.

set route xxx.xxx.22.0/gateway= xxx.xxx.17.1

It appeared in the list and now I can ping it. It also appears that everyone from 22 can ping the Alphas.

Once again, thank you for your help.

[Robert Gezelter]

Daniel,

For future reference (and for readers of this thread), this is better characterized as a "routing" problem. It is not VLAN specific.

VLANs appear as totally separate networks. Thus, it is necessary that some intermediate node, with visibility to both LANs, act as a router. It is also necessary for this intermediate node to be identified to the individual systems (or the router identified as the default router) as the router responsible for traffic to the specific LAN.

It is also a good idea at that point to verify that the opposite direction is similarly configured.

- Bob Gezelter, http://www.rlgsc.com

[Joseph Huber_1]

Just a suggestion:
it appears that x.x.17.1 routes to all other subnets, so I would set it up as the default gateway:
set route /gateway=x.x.17.1/default
and the network mask of the interface
to 255.255.255.0 .
Then there is no need to set (the same) gateway for each individual subnet added.