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