Hi Matt,
When connectivity is lost through the PIX, can your guests still
communicate with each other ? (at least the two on the same VLAN)
I'll assume that you mean they cannot communicate through the PIX.
Your other (HiperSockets) connection should not affect this interface
directly. Any additional network can complicate the configuration of
gateways and routers (at least that's been my experience). It only
takes one node with a 16-bit subnet mask that should have been a
24-bit subnet mask...
Here are some things to look for:
Try pinging between guests on the same LAN segment to
determine if one specific guest has lost connectivity, or
if it is the path to or from the physical network.
CP QUERY VSWITCH with DETAILS or ACTIVE will show you
the active interfaces and which IP addresses those guests have
registered for this LAN segment. Based on your diagram, I would
guess that you see the following unicast addresses:
192.168.2.10
164.165.57.xxx
192.168.2.4
CP QUERY VSWITCH with DETAILS or ACTIVE will also show
you which VLAN is set for each interface. If you see "VLAN ANY"
it means (1) outbound packets will only be tagged with a nonzero
VLAN ID if the guest does it, and (2) inbound packets will not be
filtered by VLAN ID. If you see (for example) "VLAN 5" it means
every outbound packet is tagged for VLAN 5 and we will only
deliver inbound packets that are untagged, or tagged VLAN 5,
to this interface.
Note that the default SET VSWITCH GRANT will assume VLAN ANY
and it is up to the guest to configure (vconfig?) the interface to
actively use a VLAN group. When you grant a single VLAN ID
to a user on the LAN segment, CP will force the use of that
VLAN ID.
If you can intercept a ping before it is delivered to the OSA card,
that is usually helpful. In this case, check the ping reply going from
the PIX to the OSA card:
(1) The ethernet destination should be the MAC address of the real OSA
card.
(2) If a vlan tag follows the ethernet header, it should match the Linux
VLAN.
(3) The ip destination should be one of the addresses registered on the
VSWITCH.
If you can intercept a ping as it moves through the guest interface,
that's good too. For example, you might run tcpdump (to a disk file)
from the guest that is going to send the ping request.
We don't have a "sniffer" in CP for Guest LAN, but you can use the
packet counts sometimes for debugging a network problem:
CP QUERY VSWITCH with the DETAILS or ACTIVE option tell you
the number of packets sent/received over the OSA interface.
CP QUERY NIC with the DETAILS option will tell you the number
of packets sent/received over your adapter (issue this one from
the Linux that owns the NIC).
Based on the debugging you've already done, I would try the ping
again and watch for changes in the counters from QUERY VSWITCH.
If it looks like the packets are being received by the VSWITCH but
not handed to the guest, the IP Destination may not be one that the
guest has registered on the LAN.
If the counters do NOT indicate inbound data, I would guess that
the MAC address on the ping reply is NOT that of the OSA card.
If these ideas don't help, please update with more information.
This list has a good mix of people with Linux, VM, and networking
skills.
Regards,
Dennis
----------------------------------------------------------------
Dennis Musselwhite ([EMAIL PROTECTED]) +1(607)429-3831
z/VM Development -- CP Network Simulation -- IBM Endicott NY
Matt Lashley/SCO
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
te.id.us> cc:
Sent by: Linux on Subject: [LINUX-390] Troubleshooting
VM VSWITCH
390 Port
<[EMAIL PROTECTED]
IST.EDU>
09/16/2003 11:49
AM
Please respond to
Linux on 390 Port
I have three Linux images coupled to a VSWITCH. The VSWITCH is connected
to an OSA Express. The OSA Express is plugged into a VLAN on a Cisco 6509
which is plugged into a PIX with an IP address if 172.16.64.1
The Linux images have IP addresses in the 192.168.2.0/24 subnet. The PIX
does NAT for the images.
Everything works fine for a few hours and then -- POOF! -- the Linux images
seem to lose all communication. I've queried the VSWITCH when things are
good and when things are bad (Q VSWITCH DET). I've also looked at the OSA
OAT table using OSA/SF. Everything looks the same whether things are
working or not. When things are not working one of the LAN guys watched a
PING from the one of teh Linux images to the PIX and it looks like
everything is working fine to him. The PIX gets the PING and replies back
but the response never makes it back to the Linux image.
Besides the VSWITCH there is a Hipersockets Guest LAN with a Linux image
that routes packets to OS/390 via CTC for Tivoli backups. Could this
router image that is not connected to the VSWICTH be causing a problem?
Everything seemed to work together fine for about five hours. (When I say
router image I mean a very basic static routing image with
/proc/sys/net/ipv4/ip_forward set to '1')
Anyway, I'm looking for more ways to troubleshoot this. A picture of the
environment is here: http://164.165.56.143/~XAS9585/CommEx.jpg
The VSWITCH was set to NONROUTER.
Thanks,
Matt Lashley
Idaho State Controller's Office
