Thanks Dennis...
>> Your PING results indicate that this is NOT happening, so I have to
believe
>> one of the following:
>> (1) linux0 ping to 10.105.1.254 does not go to the hsi0 interface.
>> The hsi0 interface address is 10.105.1.250 / 255.255.255.0.
>> Is /etc/sysconfig/network script configured with:
>> GATEWAYDEV=hsi0
>> GATEWAY=10.105.1.254
>> ??
(1) I can't think of a way to get a sniffer onto this segment to verify
this. And I cannot find an /etc/sysconfig/network script. But correct me
if I am wrong, even if my default gw is not configured correctly, I in
theory from 10.105.1.250/24 should be able to ping 10.105.1.1/24 they are
on the same segment and don't need a router. And that doesn't work either.
OR:
>> (2) tcpip ping response to 10.105.1.250 does not go to the VLAN1
interface.
>> If the ping reaches TCPIP but the stack sends the response back out
>> the wrong interface (maybe out the 10.100.1.2 interface?) this would
>> also result in a ping failure. Are you sure the TCPIP configuration
>> is set to direct all 10.105.1.* traffic through 10.105.1.254 ?
>> ??
(2) I am reasonably certain that routing at the VM level is correct. We
tried to eliminate the VM side of the configuration by bringing up a second
VM IP stack. This second stack happily communicated with the 10.105.1.254
address and vice versa. So the primary stack can route to the 10.105.1
network. Also a netstat gate from the primary stack shows:
netstat gate
VM TCP/IP Netstat Level 420
Known gateways:
NetAddress FirstHop Flgs PktSz Subnet Mask Subnet Value Link
---------- -------- ---- ----- ----------- ------------
------
Default 10.100.0.254 UGS Def <none> OSA2
10.0.0.0 <direct> US 1500 0.255.0.0 0.100.0.0 OSA2
10.100.7.1 <direct> HS 1500 HOST C701
10.100.7.2 <direct> HS 1500 HOST D702
10.100.7.3 <direct> HS 1500 HOST C703
10.100.7.4 <direct> HS 1500 HOST D704
10.100.7.5 <direct> HS 1500 HOST C705
10.100.7.6 <direct> HS 1500 HOST D706
10.100.7.7 <direct> HS 1500 HOST C707
10.100.7.8 <direct> HS 1500 HOST D708
10.100.7.9 <direct> HS 1500 HOST C709
10.100.7.10 <direct> HS 1500 HOST D70A
10.100.7.250 <direct> HS 1500 HOST C000
10.0.0.0 <direct> US 1500 0.255.255.0 0.105.1.0
QDIO1
Dennis Musselwhite <[EMAIL PROTECTED]>@VM.MARIST.EDU> on 01/31/2002
00:19:51
Please respond to Linux on 390 Port <[EMAIL PROTECTED]>
Sent by: Linux on 390 Port <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:
Subject: Re: QETH/HiperSockets/Guest Lan.Save me from jumping off a bridge
Hi,
Jeremy Warren wrote:
> I'm at my wits end.......
> The water below looks cool and refreshing.....
I wish I could solve this for you (that water is a lot harder than it
looks).
Perhaps I can fill in some of the blanks based on your observations of
the Guest LAN operation... then maybe the networking experts can
figure out the rest.
>From either Linux instance it can ping its own interface but no-one else
on
>the 10.105.1.0 network.
I'm reasonably sure these pings to the interface IP Address do not
actually go through the adapter, so they don't really count.
>So from linux0
>ping 10.105.1.250 - works
(but does not really exercise the adapter)
>ping 10.105.1.254 - fails
>ping 10.105.1.1 - fails
>From linux1
>ping 10.105.1.1 - works
(but does not really exercise the adapter)
>ping 10.105.1.254 - fails
>ping 10.105.1.250 - fails
>ifconfig for hsi0 shows:
>hsi0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
> inet addr:10.105.1.250 Mask:255.255.255.0
> inet6 addr: fe80::200:ff:fe00:0/10 Scope:Link
> UP RUNNING NOARP MTU:8192 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:100
> RX bytes:0 (0.0 b) TX bytes:728 (728.0 b)
> Interrupt:10
>Note that the HW Address is all 00. This seems wrong to me but since I
>can't get it to work who knows....
This should not affect the operation. I agree that it looks odd, but
the MACADDR is not very meaningful to real HiperSockets. All of the
LPARs communicating on a HiperSockets CHPID are (sort of) on the same
adapter. The HiperSockets adapter uses the Destination IP Address to
deliver packets.
>We are manually configuring the device in chandev.
>Our chandev.conf:
>noauto
>ctc0,0xc000,0xc001,0,0
>qeth0,0x0500,0x0501,0x0502,4096
>add_parms,0x10,0x0500,0x0502,portname:VLAN1
>(We tried hsi0 instead of qeth0 and get unknown verb or something
similar).
This configuration looks OK. I have not tried overriding the memory
allocation
myself, so you might want to try the default (put "0" instead of "4096" on
the
qeth0 line. If the channel layer finds HiperSockets devices at these
addresses,
it will use the "hsi" interface name.
>A Q NIC DETAILS from linux0 shows:
>CP Q NIC DETAILS
>Adapter 0500 Type: HIPER Name: VLAN1 Devices: 3
> Port 0 MAC: 00-04-AC-00-00-11 LAN: SYSTEM VLAN1 MFS: 16384
> Connection Name: HALLOLE State: Session Established
> Device: 0500 Unit: 000 Role: CTL-READ
> Device: 0501 Unit: 001 Role: CTL-WRITE
> Device: 0502 Unit: 002 Role: DATA
> Unicast IP Addresses:
> 10.105.1.250
>Note that I DO have a mac address and the 0500-0502 devices are indeed
>connected.
>(For folks who have been helping offline the NIC Address changed from 0510
>to 0500 on a SWAG)
This looks right... and confirms that /etc/chandev.conf is OK. The fact
that you have an IP Address here, and on the QUERY LAN DETAILS is evidence
that (1) your /etc/chandev.conf is ok, and (2) the qdio and qeth drivers
are working with the simulated NIC devices.
>A Q LAN DETAILS from linux0 shows: (At the time this was taken linux1 was
>down).
>CP Q LAN DETAILS
>LAN SYSTEM VLAN1 Type: HIPERS Active: 2 MAXCONN: INFINITE
> PERSISTENT UNRESTRICTED MFS: 16384
> Adapter Owner: LINUX0 NIC: 0500 Name: VLAN1
> 10.105.1.250
> Adapter Owner: TCPIP NIC: 0510 Name: VLAN1
> 10.105.1.254
>It appears to me anyway that both linux0 and tcpip are properly into the
>guest lan they just wont talk to each other. Which to me points to a
linux
>config error but I can't figure it out.
I agree that the drivers are talking to the Guest LAN. I'm not convinced
that the linux configuration is the problem.
Given the Q LAN DETAILS above, I can just about guarantee that IF the
linux0 stack sent a packet on the LINUX0 500 NIC with a next-hop
10.105.1.254
it would certainly be delivered to the TCPIP 510 NIC. Furthermore...
IF the tcpip stack sent a response on this NIC with a next-hop 10.105.1.250
it would be delivered to the LINUX0 500 NIC.
Your PING results indicate that this is NOT happening, so I have to believe
one of the following:
(1) linux0 ping to 10.105.1.254 does not go to the hsi0 interface.
The hsi0 interface address is 10.105.1.250 / 255.255.255.0.
Is /etc/sysconfig/network script configured with:
GATEWAYDEV=hsi0
GATEWAY=10.105.1.254
??
OR:
(2) tcpip ping response to 10.105.1.250 does not go to the VLAN1 interface.
If the ping reaches TCPIP but the stack sends the response back out
the wrong interface (maybe out the 10.100.1.2 interface?) this would
also result in a ping failure. Are you sure the TCPIP configuration
is set to direct all 10.105.1.* traffic through 10.105.1.254 ?
??
I notice there has been some discussion about using subnet mask
255.255.255.255.
I have access to a test system with a very small set of linux guests and
they
use a 28-bit subnet mask, so I know you can do this without
255.255.255.255,
but we have a gateway defined in each Linux machine.
Hopefully somebody with more experience with configuration files can
come up with better ideas tomorrow.
Regards,
Dennis Musselwhite ([EMAIL PROTECTED])
z/VM CP Development
