Hello, Alan,
Taking your advice, I've spoken with the network guy about this. (He
didn't laugh at me. He's an ex-mainframer and a good guy.) They
haven't put in any kind of filter or rule that would affect this one
VSE guest, and they've verified that their arp cache on their Cisco
router is being refreshed with information about the VSE guest
(showing the MAC address for the VM TCPIP interface), which suggests
that VM's proxyarp services are working on behalf of this guest.
(As a side issue, when we do trace routes to the VSE guests that do
work, we get a timeout for the point where the packet is going
through VM TCP/IP. Is there something to turn on within VM TCP/IP to
allow it to respond to trace route commands to those machines for
which he provides proxy arp services?)
When I do NETSTAT GATE DEV HOME I see no difference between the
guests that do work and the one that doesn't. All of them have
"Flgs" of UHS. All the CTCAs are connected and the VSE IP stack is
up and running.
You mention the OBEYFILE command, with MORETRACE IPDOWN. Where do I
do this? From MAINT? Is there something I must configure before i
can issue this command? Is it disruptive in any way to the users who
are successfully using TCPIP? (I've got CMS users and connections to
VSE and Linux guests that are working.)
- Tom.
At 10:11 PM 7/11/2006, you wrote:
On Tuesday, 07/11/2006 at 02:33 MST, Tom Cluster <[EMAIL PROTECTED]>
wrote:
> We have three VSE virtual machines which use TCP/IP in VM as their
> gateway, connected via virtual ctca's. The IP stacks are working
> correctly in two of the guests, but not in the third. It previously
> worked and no changes have been made.
LOL! *Something* changed!
> I can see nothing wrong from
> the guest's point-of-view. It comes up as if full IP connectivity is
> there, but it's not reachable from the outside nor can it reach the
> outside. This suggests to me that the connection between VSE and VM
> is working fine but that the gateway function in VM TCP/IP is down
> for this one IP address. I can't easily bounce the VM TCP/IP machine
> because others are using it.
It suggests to me a routing problem, not a problem in VM TCP/IP. If you
didn't change the host or the hardware, then the network has changed. You
will have to ask the network techs to do their thing and find out for you
where the problem is. Double check that NETSTAT GATE DEV HOME (or
ifconfig on newer systems) shows you what you expect to see (i.e. what it
showed when it worked correctly).
It is most likely that the packets for the 3rd guest are being routed
outbound, but the responses aren't coming back.
> There must be some diagnostic commands to help figure out what's
> going on, but when I look at the TCP/IP Planning and Customization
> Manual I'm not finding them. How can I proceed?
The diagnostic commands are tracerte, ping, and netstat/ifconfig. You can
OBEYFILE a MORETRACE IPDOWN to watch the stack in action for packet
transmission, but if NETSTAT GATE DEV HOME is good, call up the network
elves to have them do their magic. Don't forget to tell them how you
didn't change anything. They will laugh, of course, but let it pass and
stay the course. ;-)
Alan Altmark
z/VM Development
IBM Endicott
Tom Cluster
County of Sonoma
Santa Rosa, CA
(707) 565-3384 (Tuesdays and Wednesdays only)
