DHCP over VSWITCH?
> I am trying to set up DHCP for linux users on our VSWITCH. > > Right now I have two linux users, both on VSWITCH. One is the DHCP > server (SLES9 SP2 with ISC dhcpd), and one is the DHCP client (SLES10 > with dhcpcd). > > The client sends its VM user name as its DHCP client identifier; the > server assigns a fixed address using that instead of the ethernet MAC > address, as our VSWITCH is running in layer 3. > > It's partly working right now. The client sends its DHCPDISCOVER. This > is received by the server, which sends its DHCPOFFER. The DHCPOFFER is > never received by the client. > > Here is a tcpdump on the client. You can see it sending DHCPDISCOVER: > > 27 769.364929 0b.00.0a -> 00.7f.f9 FC Unknown frame > 28 833.397832 0.0.0.0 -> 255.255.255.255 DHCP DHCP Discover - > Transaction I > D 0x7ff9580b > 29 833.409721 0b.00.0a -> 00.7f.f9 FC Unknown frame > 30 897.567832 0.0.0.0 -> 255.255.255.255 DHCP DHCP Discover - > Transaction I > D 0x7ff9580b > 31 897.572165 0b.00.0a -> 00.7f.f9 FC Unknown frame > > Here is what's going on at the same time, from the server's point of > view, receiving DHCPDISCOVER and sending the DHCPOFFER: > > 0.00 0.0.0.0 -> 255.255.255.255 DHCP DHCP Discover - > Transaction ID 0 > x7ff9580b > 0.000164 0.0.0.0 -> 255.255.255.255 DHCP DHCP Discover - > Transaction ID 0 > x7ff9580b > 0.005826 192.54.6.17 -> 255.255.255.255 DHCP DHCP Offer- > Transaction ID 0 > x7ff9580b > 0.008912 192.54.6.17 -> 255.255.255.255 DHCP DHCP Offer- > Transaction ID 0 > x7ff9580b > 0.009443 192.54.6.17 -> 255.255.255.255 DHCP DHCP Offer- > Transaction ID 0 > x7ff9580b > 0.011666 192.54.6.17 -> 255.255.255.255 DHCP DHCP Offer- > Transaction ID 0 > x7ff9580b > > This is as far as we get. What is preventing the DHCPOFFER from being > received by the client? I don't understand how this could be only > half-broken (the IP broadcast works in one direction, but not the > other). Is there some patch or APAR we're missing? I really, really > hope we don't have to reconfigure our VSWITCH to layer 2 to make this > work. > > Thanks; > > ok > r. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: DHCP over VSWITCH?
On Thursday, 08/24/2006 at 01:33 MST, "Stricklin, Raymond J" <[EMAIL PROTECTED]> wrote: > > I am trying to set up DHCP for linux users on our VSWITCH. > > > > Right now I have two linux users, both on VSWITCH. One is the DHCP > > server (SLES9 SP2 with ISC dhcpd), and one is the DHCP client (SLES10 > > with dhcpcd). > > > > The client sends its VM user name as its DHCP client identifier; the > > server assigns a fixed address using that instead of the ethernet MAC > > address, as our VSWITCH is running in layer 3. Easiest is to change to use a Layer 2 VSWITCH (TYPE ETHERNET). To use DHCP with Layer 3, you have to get the device driver to generate fake ethernet frame headers. E.g. For NIC A000 on SLES9: /etc/sysconfig/hardware/hwcfg-qeth-bus-ccw-0.0.a000: CCW_CHAN_IDS='0.0.a000 0.0.a001 0.0.a002' CCW_CHAN_MODE='OSAPORT' CCW_CHAN_NUM='3' MODULE='qeth' MODULE_OPTIONS='' SCRIPTDOWN='hwdown-ccw' SCRIPTUP='hwup-ccw' SCRIPTUP_ccw='hwup-ccw' SCRIPTUP_ccwgroup='hwup-qeth' STARTMODE='auto' QETH_OPTIONS='fake_ll=1'< look here! Alan Altmark z/VM Development IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: DHCP over VSWITCH?
For the benefit of the rest of the list; Alan's suggestion to enable faked frame headers solved the problem I was having. Unfortunately, a second problem surfaced immediately. The VSWITCH would give me an error when the DHCP client received its lease: HCPSWU2833E Error 'E00A'X adding IP address 192.54.6.16 for VSWITCH SYSTEM VLINUX1. HCPSWU2833E IP address is already in use on the LAN. There is no other machine (real or virtual) on the network with this address. I could have ignored the message except that the DHCP client will then only respond to other machines on the VSWITCH. It will not communicate with the router on the subnet (nor consequently with any machine outside of the subnet). I left the user logged off overnight; when I logged it on this morning it started up, received its DHCP lease without triggering the VSWITCH error, and was communicating normally on the network, with both other VSWITCH users and with the rest of the world. As soon as I rebooted it, I began to receive the VSWITCH errors again. After asking Dr Google, I found that I needed to add the line "ARP='no'" to /etc/sysconfig/network/ifcfg-qeth-bus-ccw-0.0.a001 (our NIC dev) for an IP VSWITCH. We've been using IP VSWITCH without DHCP for about a year, and why we never ran into this problem before, I couldn't exactly say. http://www.vm.ibm.com/virtualnetwork/hintarp.html IBM: z/VM Virtual Networking Hints and Tips - Error x0002, xE00A We've been using IP VSWITCH without DHCP for about a year, and why we never ran into this problem before, I couldn't exactly say. As of right now it looks a lot like we have what we need for a successful DHCP implementation. Thanks, everybody. ok r. -Original Message- From: Alan Altmark [mailto:[EMAIL PROTECTED] Sent: Thursday, August 24, 2006 3:18 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: DHCP over VSWITCH? On Thursday, 08/24/2006 at 01:33 MST, "Stricklin, Raymond J" <[EMAIL PROTECTED]> wrote: > > I am trying to set up DHCP for linux users on our VSWITCH. > > > > Right now I have two linux users, both on VSWITCH. One is the DHCP > > server (SLES9 SP2 with ISC dhcpd), and one is the DHCP client > > (SLES10 with dhcpcd). > > > > The client sends its VM user name as its DHCP client identifier; the > > server assigns a fixed address using that instead of the ethernet > > MAC address, as our VSWITCH is running in layer 3. Easiest is to change to use a Layer 2 VSWITCH (TYPE ETHERNET). To use DHCP with Layer 3, you have to get the device driver to generate fake ethernet frame headers. E.g. For NIC A000 on SLES9: /etc/sysconfig/hardware/hwcfg-qeth-bus-ccw-0.0.a000: CCW_CHAN_IDS='0.0.a000 0.0.a001 0.0.a002' CCW_CHAN_MODE='OSAPORT' CCW_CHAN_NUM='3' MODULE='qeth' MODULE_OPTIONS='' SCRIPTDOWN='hwdown-ccw' SCRIPTUP='hwup-ccw' SCRIPTUP_ccw='hwup-ccw' SCRIPTUP_ccwgroup='hwup-qeth' STARTMODE='auto' QETH_OPTIONS='fake_ll=1'< look here! Alan Altmark z/VM Development IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: DHCP over VSWITCH?
You don't mention what release of VM your on (at least I don't see it). I believe there may have been some VM service at one point that dealt with Linux DHCP servers running under VM. You may want to query IBMLink (or the support center). Stricklin, Raymond J wrote: For the benefit of the rest of the list; Alan's suggestion to enable faked frame headers solved the problem I was having. Unfortunately, a second problem surfaced immediately. The VSWITCH would give me an error when the DHCP client received its lease: HCPSWU2833E Error 'E00A'X adding IP address 192.54.6.16 for VSWITCH SYSTEM VLINUX1. HCPSWU2833E IP address is already in use on the LAN. There is no other machine (real or virtual) on the network with this address. I could have ignored the message except that the DHCP client will then only respond to other machines on the VSWITCH. It will not communicate with the router on the subnet (nor consequently with any machine outside of the subnet). I left the user logged off overnight; when I logged it on this morning it started up, received its DHCP lease without triggering the VSWITCH error, and was communicating normally on the network, with both other VSWITCH users and with the rest of the world. As soon as I rebooted it, I began to receive the VSWITCH errors again. After asking Dr Google, I found that I needed to add the line "ARP='no'" to /etc/sysconfig/network/ifcfg-qeth-bus-ccw-0.0.a001 (our NIC dev) for an IP VSWITCH. We've been using IP VSWITCH without DHCP for about a year, and why we never ran into this problem before, I couldn't exactly say. http://www.vm.ibm.com/virtualnetwork/hintarp.html IBM: z/VM Virtual Networking Hints and Tips - Error x0002, xE00A We've been using IP VSWITCH without DHCP for about a year, and why we never ran into this problem before, I couldn't exactly say. As of right now it looks a lot like we have what we need for a successful DHCP implementation. Thanks, everybody. ok r. -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com Catch the WAVV! http://www.wavv.org WAVV 2007 - Green Bay, WI - May 18-22, 2007 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: DHCP over VSWITCH?
Please, see the Apar VM63608 from IBM. Good luck. _ Clóvis Pereira IBM Brasil Global Technology Services/SW Services HCPSWU2833E Error 'E00A'X adding IP address 192.54.6.16 for VSWITCH SYSTEM VLINUX1. HCPSWU2833E IP address is already in use on the LAN. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: DHCP over VSWITCH?
On Friday, 08/25/2006 at 12:48 MST, "Stricklin, Raymond J" <[EMAIL PROTECTED]> wrote: > For the benefit of the rest of the list; > > Alan's suggestion to enable faked frame headers solved the problem I was > having. > > Unfortunately, a second problem surfaced immediately. The VSWITCH would > give me an error when the DHCP client received its lease: > > HCPSWU2833E Error 'E00A'X adding IP address 192.54.6.16 for VSWITCH > SYSTEM VLINUX1. > HCPSWU2833E IP address is already in use on the LAN. ...snip... > We've been using IP VSWITCH without DHCP for about a year, > and why we never ran into this problem before, I couldn't exactly say. Did you perhaps change the client from SLES9 to SLES10 in the process? Somewhere along the way, Linux (dhclient?) changed to issue a gratuitous ARP *before* it registers the IP address in the OSA. Of course, the registration of an IP address in a Layer 3 OSA causes it to see if the IP address is already used. WHAM! You hit the ARP cache entry created by the "manual" grat ARP. Or Linux has always done that but timings have changed sufficiently to finally surface the problem. (A gratuitous ARP is what we call an unsolicited response to an ARP query.) It doesn't make sense for Linux to send a grat ARP before it has finished configuring the interface. In fact, I would think that would be a function of interface configuration itself, left to the device driver itself. Or maybe something's broken. It works with Layer 2 because the OSA doesn't do any automatic grat ARPs. I think the problem *could* be mitigated by the OSA itself. OSA could allow an IP address to be registered if the grat ARP was received on a data channel associated with the control channel over which the IP address is being registered. Of course, the h/w guys would say that just disabling the grat ARP (ARP=no) makes the problem go away and that's sufficient. I'm also of the opinion that the *applications* should not have to change to accomodate this odd behavior of the Layer 3 OSA. But, then, my nickname is "Mr. Quixotehead". AND, the fix really does be in Lniux itself. Alan Altmark z/VM Development IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: DHCP over VSWITCH?
Gratuitous ARP's are usually used to allow the registration of a MAC address into a Layer-2 switch's forwarding data base. In essence, the gratuitous ARP lets the device tell the switch what physical port to use to send a frame when the MAC address is encountered as the destination MAC address in a frame. They are also frequently encountered when a Layer-2 based virtual address changes host residency, for example Virtual Router Redundancy Protocol, as opposed to Layer-3 based virtual IP addresses which utilize a routing protocol such as OSPF to report it's new location. Harold Grovesteen Alan Altmark wrote: On Friday, 08/25/2006 at 12:48 MST, "Stricklin, Raymond J" <[EMAIL PROTECTED]> wrote: For the benefit of the rest of the list; Alan's suggestion to enable faked frame headers solved the problem I was having. Unfortunately, a second problem surfaced immediately. The VSWITCH would give me an error when the DHCP client received its lease: HCPSWU2833E Error 'E00A'X adding IP address 192.54.6.16 for VSWITCH SYSTEM VLINUX1. HCPSWU2833E IP address is already in use on the LAN. ...snip... We've been using IP VSWITCH without DHCP for about a year, and why we never ran into this problem before, I couldn't exactly say. Did you perhaps change the client from SLES9 to SLES10 in the process? Somewhere along the way, Linux (dhclient?) changed to issue a gratuitous ARP *before* it registers the IP address in the OSA. Of course, the registration of an IP address in a Layer 3 OSA causes it to see if the IP address is already used. WHAM! You hit the ARP cache entry created by the "manual" grat ARP. Or Linux has always done that but timings have changed sufficiently to finally surface the problem. (A gratuitous ARP is what we call an unsolicited response to an ARP query.) It doesn't make sense for Linux to send a grat ARP before it has finished configuring the interface. In fact, I would think that would be a function of interface configuration itself, left to the device driver itself. Or maybe something's broken. It works with Layer 2 because the OSA doesn't do any automatic grat ARPs. I think the problem *could* be mitigated by the OSA itself. OSA could allow an IP address to be registered if the grat ARP was received on a data channel associated with the control channel over which the IP address is being registered. Of course, the h/w guys would say that just disabling the grat ARP (ARP=no) makes the problem go away and that's sufficient. I'm also of the opinion that the *applications* should not have to change to accomodate this odd behavior of the Layer 3 OSA. But, then, my nickname is "Mr. Quixotehead". AND, the fix really does be in Lniux itself. Alan Altmark z/VM Development IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: DHCP over VSWITCH?
On Saturday, 08/26/2006 at 07:41 EST, Harold Grovesteen <[EMAIL PROTECTED]> wrote: > Gratuitous ARP's are usually used to allow the registration of a MAC > address into a Layer-2 switch's forwarding data base. In essence, the > gratuitous ARP lets the device tell the switch what physical port to use > to send a frame when the MAC address is encountered as the destination > MAC address in a frame. They are also frequently encountered when a > Layer-2 based virtual address changes host residency, for example > Virtual Router Redundancy Protocol, as opposed to Layer-3 based virtual > IP addresses which utilize a routing protocol such as OSPF to report > it's new location. Grat ARPs are absolutely required. Trying to stop them would be a Bad Thing. The problem (IMO) is with the OAT IP address registration process, not with grat ARPs, per se. Alan Altmark z/VM Development IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
