Hi Romney,

That's just it, I don't see anything in the VM TCPIP trace that suggests a
timeout (at least no verbage that clearly says "timed out" or anything like
that).  Is there a keyword I can use to scan for that would indicate a
timeout?  Maybe it's there and I'm just not seeing it (the trace is very
chatty, just running it for a few seconds generates thousands of lines of
trace data).

Michael Coffin, VM Systems Programmer
Internal Revenue Service - Room 6527
1111 Constitution Avenue, N.W.
Washington, D.C.  20224

Voice: (202) 927-4188   FAX:  (202) 622-3123
[EMAIL PROTECTED]



-----Original Message-----
From: Romney White [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 18, 2002 12:30 PM
To: [EMAIL PROTECTED]
Subject: Re: Odd TraceRoute To Linux/390 Guests via VM TCPIP


Michael:

This looks fine. What we're interested in finding in the trace output is the
reception and handling of the packet that TRACERTE sends to the VM system
(the one that times out).

Romney

On Wed, 18 Dec 2002 12:19:34 -0500 Coffin Michael C said:
>Hi Romney,
>
>I ran a trace which is too big to include here, but I'm seeing "Passed
>Route F" and "DontRoute F" in the trace, here's a snip:
>
>DTCPDO065I DispatchDatagram: Dest 152.225.118.49, protocol 17 dispatch
>mode 0, P assed Route F, DontRoute F
>
>DTCPDO066I DispatchDatagram releases LastRouteEntry
>
>DTCPDO080I FindRoute looking for route for: 152.225.118.49
>
>DTCPDO077I FindRoute found HostRTE for 152.225.118.49 on interface
>CTC504
>
>DTCPDO067I DispatchDatagram allocates LastRouteEntry
>
>DTCPDO044I Ipdown: Link: Link Name: CTC504, Link Type: CTC, Dev Name:
>CTC504, De v Type: CTC, Queuesize: 0
>
>DTCPDO046I Ipdown: FirstHop 152.225.118.49
>
>DTCPDO027I IP-down: ShouldFragment: Datagram: 78 Packet size:1492
>DTCPRC001I      version: 4
>DTCPRC002I      Internet Header Length: 5 = 20 bytes
>DTCPRC009I      Type of Service:Precedence = Routine
>DTCPRC010I      Total Length: 78 bytes
>DTCPRC011I      Identification: 37557
>DTCPRC009I      Flags: May Fragment, Last Fragment
>DTCPRC009I      Fragment Offset: 0
>DTCPRC019I      Time To Live: 124
>DTCPRC020I      Protocol: UDP
>DTCPRC021I      Header CheckSum: 56509
>DTCPRC022I      Source Address: 98E12738
>DTCPRC023I      Destination Address: 98E17631
>DTCIPU031I    IP-up examining:
>DTCPRC001I       version: 4
>DTCPRC002I       Internet Header Length: 5 = 20 bytes
>DTCPRC009I       Type of Service:Precedence = Internetwork control
>DTCPRC010I       Total Length: 106 bytes
>DTCPRC011I       Identification: 1057
>DTCPRC009I       Flags: May Fragment, Last Fragment
>DTCPRC009I       Fragment Offset: 0
>
>DTCPRC019I       Time To Live: 255
>
>DTCPRC020I       Protocol: ICMP
>
>DTCPRC021I       Header CheckSum: 59269
>
>DTCPRC022I       Source Address: 98E17631
>
>DTCPRC023I       Destination Address: 98E12738
>
>DTCIPU037I    IP-up: datagram ID 1057, len 106, Protocol ICMP from
>152.225.118.4
>9
>
>DTCIPU040I    IP-up: forward datagram
>
>DTCPDO065I DispatchDatagram: Dest 152.225.39.56, protocol 1 dispatch
>mode 0, Pas sed Route F, DontRoute F
>
>DTCPDO066I DispatchDatagram releases LastRouteEntry
>
>DTCPDO080I FindRoute looking for route for: 152.225.39.56
>
>DTCPDO077I FindRoute found DefaultRTE for * on interface SHUTTLE3
>
>DTCPDO067I DispatchDatagram allocates LastRouteEntry
>
>DTCPDO044I Ipdown: Link: Link Name: SHUTTLE3, Link Type: ETHERNET, Dev
>Name: SHU TTLE3, Dev Type: LCS, Queuesize: 0
>
>DTCPDO046I Ipdown: FirstHop 152.225.118.1
>
>
>In the trace "SHUTTLE3" is our gigabit connection, 152.225.39.56 is the
>IP address of the Win2K workstation I ran the tracert from,
>152.225.118.49 is the address I was tracing (a Linux/390 guest VCTC'd
>to the TCPIP at 152.225.118.46).
>
>Is this perhaphs because I have not provided explicit routing, but
>rather use the "DefaultRoute" in VM's TCPIP configuration?
>
>
>Michael Coffin, VM Systems Programmer
>Internal Revenue Service - Room 6527
>1111 Constitution Avenue, N.W.
>Washington, D.C.  20224
>
>Voice: (202) 927-4188   FAX:  (202) 622-3123
>[EMAIL PROTECTED]
>
>
>
>-----Original Message-----
>From: Romney White [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, December 18, 2002 10:59 AM
>To: [EMAIL PROTECTED]
>Subject: Re: Odd TraceRoute To Linux/390 Guests via VM TCPIP
>
>
>Michael:
>
>Run the test with TRACE IPUP IPDOWN ICMP enabled. It looks as though
>the packet is being dropped by VM TCP/IP. The trace will show what is
>going on.
>
>Romney
>
>On Wed, 18 Dec 2002 10:45:19 -0500 Coffin Michael C said:
>>Hi Rob,
>>
>>Yes, pinging works fine to/from the guests.  In fact all IP traffic
>>to/from the guests works fine - but traceroute shows this timeout at
>>.46 (the VM TCPIP server).  I'd just like to understand why it times
>>out and clear it up if possible.
>>
>>I'm not sure what you mean by "the status of the VCTC device".  It's
>>pairs are coupled and working fine or we wouldn't be able to talk
>>between the Linux/390 and VM TCPIP machines.
>>
>>-TIA
>>
>>Michael Coffin, VM Systems Programmer
>>Internal Revenue Service - Room 6527
>>1111 Constitution Avenue, N.W.
>>Washington, D.C.  20224
>>
>>Voice: (202) 927-4188   FAX:  (202) 622-3123
>>[EMAIL PROTECTED]
>>
>>
>>
>>-----Original Message-----
>>From: Rob Schwartz [mailto:[EMAIL PROTECTED]]
>>Sent: Wednesday, December 18, 2002 10:43 AM
>>To: [EMAIL PROTECTED]
>>Subject: Re: Odd TraceRoute To Linux/390 Guests via VM TCPIP
>>
>>
>>Can you ping from VM  to .49?
>>
>>What's the status of the VCTC device?
>>
>>Can you ping from the .49 Linux machine to .46?
>>
>>
>>Robert C Schwartz
>>Technical Services
>>Boscovs Department Stores LLC
>>610-929-7387
>>[EMAIL PROTECTED]
>>
>>----- Original Message -----
>>From: "Coffin Michael C" <[EMAIL PROTECTED]>
>>To: <[EMAIL PROTECTED]>
>>Sent: Wednesday, December 18, 2002 10:20 AM
>>Subject: Re: Odd TraceRoute To Linux/390 Guests via VM TCPIP
>>
>>
>>> Arrggh - I have guests at both .49 and .50, I evidently included the
>>> trace to .49 (same results).  Strike .50 in my note and replace it
>>> with .49
>>(sorry
>>> for the confusion).
>>>
>>> Michael Coffin, VM Systems Programmer
>>> Internal Revenue Service - Room 6527
>>> 1111 Constitution Avenue, N.W.
>>> Washington, D.C.  20224
>>>
>>> Voice: (202) 927-4188   FAX:  (202) 622-3123
>>> [EMAIL PROTECTED]
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Rob Schwartz [mailto:[EMAIL PROTECTED]]
>>> Sent: Wednesday, December 18, 2002 10:21 AM
>>> To: [EMAIL PROTECTED]
>>> Subject: Re: Odd TraceRoute To Linux/390 Guests via VM TCPIP
>>>
>>>
>>> Hey Michael,
>>>
>>> Am I missing something here... What is 152.225.118.49????
>>>
>>> Rob
>>>
>>> Robert C Schwartz
>>> Technical Services
>>> Boscovs Department Stores LLC
>>> 610-929-7387
>>> [EMAIL PROTECTED]
>>>
>>> ----- Original Message -----
>>> From: "Michael Coffin" <[EMAIL PROTECTED]>
>>> To: <[EMAIL PROTECTED]>
>>> Sent: Wednesday, December 18, 2002 10:02 AM
>>> Subject: Odd TraceRoute To Linux/390 Guests via VM TCPIP
>>>
>>>
>>> > (Crossposted on VMESA-L and Linux-VM)
>>> >
>>> > Hi Folks,
>>> >
>>> > I'm in the process of implementing gigabit ethernet for a client
>>> > and am very curious about something.  I have a TCPIP stack on VM
>>> > (VM/ESA
>>> > 2.4.0) with a dedicated gigabit card at IP address 152.225.118.46.
>>> > I have a Linux/390 guest virtual machine VCTC coupled to this
>>> > TCPIP virtual machine at IP address 152.225.118.50.  Take a look
>>> > at the traceroute below, when I trace to .46 it's nice and clean.
>>> > However when I trace to .50 .46 times out.  Any idea what causes
>>> > this?  VM's TCPIP is proxyarping for these guests, by the way.
>>> >
>>> > I:\>tracert 152.225.118.46
>>> >
>>> > Tracing route to 152.225.118.46 over a maximum of 30 hops
>>> >
>>> >   1   <10 ms   <10 ms   <10 ms  152.225.39.2
>>> >   2   <10 ms   <10 ms   <10 ms  152.225.119.194
>>> >   3   <10 ms   <10 ms   <10 ms  152.225.46.36
>>> >   4   <10 ms   <10 ms   <10 ms  152.225.118.46
>>> >
>>> > Trace complete.
>>> >
>>> > I:\>tracert 152.225.118.49
>>> >
>>> > Tracing route to 152.225.118.49 over a maximum of 30 hops
>>> >
>>> >   1   <10 ms   <10 ms   <10 ms  152.225.39.2
>>> >   2   <10 ms   <10 ms   <10 ms  152.225.119.194
>>> >   3   <10 ms   <10 ms   <10 ms  152.225.46.36
>>> >   4     *        *        *     Request timed out.
>>> >   5   <10 ms   <10 ms   <10 ms  152.225.118.49
>>> >
>>> > Trace complete.
>>> >
>>> > Thanks in advance.  :)
>>> >
>>> > -Michael Coffin

Reply via email to