> -----Original Message----- > From: David Boyes [mailto:[EMAIL PROTECTED] > > That trick works because you're depending on the layer 3 > fixup code in the OSA to sort things out, since in that > situation all the guest frames have the physical MAC of the > OSA. The second one of those interfaces has to talk to > something outside the box on a layer 2 VSWITCH, then the MACs > have to be unique.
Eh? I run layer 3. I have to rely on the OSA code to sort things out whether DHCP is in the picture, or not. I couldn't easily in this situation, however, rely on a DHCP server not on my VSWITCH, no. I'm perfectly aware of that. My DHCP server is a tiny SLES9 user under VM, on the same layer 3 VSWITCH as all my clients, so it's not an issue. If I had the luxury of running a layer 2 VSWITCH, I could still key on the DHCP Client ID field like I am now, but with the added "benefit" of potentially being able to be served by a DHCP server on a different network (which in my case would be run by somebody else anyway, so it's not a win). Sending a DHCPDISCOVER with a Client ID for the server to key on is not a function of layer 2 or layer 3; think about PPPoA and how all those cablemodem or DSL DHCP clients out there work. 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
