Re: [Linux/390] Re: DHCP, guest LANs
> If y'all think that's a > Real Problem, and > > not just an academic oddity, let us know and we'll take it under > > advisement. (For extra credit: Devise an algorithm which constructs > > world-unique virtual MAC addresses. Answers will be graded based on > > originality and legibility.) Q&D method is to allow user assigned MAC addresses. This gets a bit sticky in that this operation should probably only be permitted in a directory entry to avoid spoofing something important (ie, J. Random Bozo doing a DEF VNIC with the MAC address of something important, like your default router for the guest LAN). > Also, will these MAC's be consistent? Normally, were I to > use DHCP in this > environment, I'd want to be able to always assign machine > "foo" the same > IP address, the easiest route is 'foo' always has the same MAC. See above. You'd have to invent some method of coordinating them, but we have to do that with IP addresses as well, so it's not significantly harder. -- db
Re: [Linux/390] Re: DHCP, guest LANs
> Further, be a bit careful with DHCP relays in this environment. While the > MAC addresses generated by VM are in the 00-04-AC range allocated to IBM, > they aren't guaranteed to be unique (hey, they're generated out of thin > air!) in the network universe. If y'all think that's a Real Problem, and > not just an academic oddity, let us know and we'll take it under > advisement. (For extra credit: Devise an algorithm which constructs > world-unique virtual MAC addresses. Answers will be graded based on > originality and legibility.) I'm only half-remembering this, but isn't there a manufacturer range reserved for "user-defined" MAC addresses? If I recall VMWare uses this. Also, will these MAC's be consistent? Normally, were I to use DHCP in this environment, I'd want to be able to always assign machine "foo" the same IP address, the easiest route is 'foo' always has the same MAC. Also, is the MAC generation routine smart enough to not make two of the same on one glan? (I assume yes). >From discussion with a friend: "Now, see, if that was MS, they'd change all networks so they can always route to a central MS server from which it'd check a database for a MAC not in use." :) -m -- Michael Kershaw [EMAIL PROTECTED] Linux Systems Programmer, Information Technology "Don't worry, I'm sure they'll listen to Reason." -- Fisheye, Snowcrash
Re: DHCP, guest LANs
On 03.05.2002 at 05:36:46, Rich Smrcina <[EMAIL PROTECTED]> wrote: > Could the virtual MAC have some element or elements of the CPUID in it, then > a CP maintained counter for uniqueness? That's a good start, but unfortunately 6 hex digits for the 'manufacturer ID' and six digits for the serial number already fills up our 12 hex digit MAC address, and we're still not unique since different machine types will reuse serial numbers... Maybe IBM could register a 'block' of manufacturer IDs so that the serial number could be pushed up into the manufacturer field, making more room for a locally-maintained counter. Alternatively, using Locally Administered Address (LAA) instead of Universally Administered Address (UAA) puts the onus of uniqueness back onto the customer, and potentially frees up more of the 48-bit field for local use (in theory, an LAA is supposed to start with X'4000', but generally as long as the first two bits are '01' it's recognised as an LAA -- this for token-ring, however, so rules may be different for ethernet). I *know* that TCP/IP has eliminated the need for LAAs (thanks to ARP), and that the overhead of administering LAAs has been largely forgotten by most shops, but it might offer a more flexible solution in this scenario. Cheers, Vic Cross -- Vic Cross MACS mailto:[EMAIL PROTECTED] Networking, Linux, on zSeries and S/390
Re: DHCP, guest LANs
Duh, well I obviously ciphered something wrongly :) On Thursday 02 May 2002 07:14 pm, you wrote: > > That's a good start, but unfortunately 6 hex digits for the 'manufacturer > ID' and six digits for the serial number already fills up our 12 hex digit > MAC address, and we're still not unique since different machine types will > reuse serial numbers... -- Rich Smrcina Sytek Services, Inc. Milwaukee, WI [EMAIL PROTECTED] [EMAIL PROTECTED] Catch the WAVV! Stay for Requirements and the Free for All! Update your S/390 skills in 4 days for a very reasonable price. WAVV 2003 in Winston-Salem, NC. April 25-29, 2003 For details see http://www.wavv.org
Re: DHCP, guest LANs
On Thursday 02 May 2002 11:06 am, you wrote: > > Further, be a bit careful with DHCP relays in this environment. While the > MAC addresses generated by VM are in the 00-04-AC range allocated to IBM, > they aren't guaranteed to be unique (hey, they're generated out of thin > air!) in the network universe. If y'all think that's a Real Problem, and > not just an academic oddity, let us know and we'll take it under > advisement. (For extra credit: Devise an algorithm which constructs > world-unique virtual MAC addresses. Answers will be graded based on > originality and legibility.) Could the virtual MAC have some element or elements of the CPUID in it, then a CP maintained counter for uniqueness? -- Rich Smrcina Sytek Services, Inc. Milwaukee, WI [EMAIL PROTECTED] [EMAIL PROTECTED] Catch the WAVV! Stay for Requirements and the Free for All! Update your S/390 skills in 4 days for a very reasonable price. WAVV 2003 in Winston-Salem, NC. April 25-29, 2003 For details see http://www.wavv.org
Re: DHCP, guest LANs
On Thursday, 05/02/2002 at 08:58ZE10, Vic Cross <[EMAIL PROTECTED]> wrote: > On 02.05.2002 at 04:56:58, John Summerfield <[EMAIL PROTECTED]> wrote: > > > I was about to suggest that. It's how ARP works - I've looked at tcpdump > > reports and seen it sending a message 'who is 192.168.1.5" and getting the > > reply "I am 192.168.1.5." > > Yep. ARP sends a broadcast, which everyone (on the local net) receives. The > one who's supposed to reply (the one who has the requested IP address) sends a > unicast reply, and everyone else ignores it. The key is that, you've got to get > past the adapter (because the adapter doesn't know subnets from a hole in the > ground, right Alan ;). Unless an adapter is in 'promiscuous' mode, it will only > pick off the wire those packets sent to its own MAC address, or a special MAC > address that signifies broadcast (or different MACs for multicast, but that's a > bit different again). > > So, simply speaking, the Guest LAN knows how to handle the broadcast MAC > address. Easy. That would be the case if VM was simulating an LCS interface, but it isn't - it's a QDIO interface which means that most of the media-specific architecture is hidden from the host (one of the things we like about it). The MAC addresses assigned by VM aren't used (by VM) for anything. There are there to be returned to the host if it asks or if someone wants to see the ARP cache, which is also maintained by the QDIO device (aka NIC), not the host. When a host wants to broadcast something, it sets a "broadcast" bit in the QDIO data structures. The adapter handles the annoying details - ARP, frame construction, checksumming, etc. Further, be a bit careful with DHCP relays in this environment. While the MAC addresses generated by VM are in the 00-04-AC range allocated to IBM, they aren't guaranteed to be unique (hey, they're generated out of thin air!) in the network universe. If y'all think that's a Real Problem, and not just an academic oddity, let us know and we'll take it under advisement. (For extra credit: Devise an algorithm which constructs world-unique virtual MAC addresses. Answers will be graded based on originality and legibility.) Alan Altmark Sr. Software Engineer IBM z/VM Development
Re: DHCP, guest LANs
Hi David, You are correct... the capabilities flags for the QDIO simulation indicate the adapter has broadcast capabilities... and the qdio driver already knows what to do about that. >From David Boyes: >Good. Do we need new versions of the drivers to enable support for the new >device definitions? If I remember correctly from studying the CP source for >QDIO support in 2.4, there was a capabilities mask that had a bunch of >undefined bits for new goodies, and it sounds like this would be one that >would need a bit. Regards, Dennis Musselwhite ([EMAIL PROTECTED]) IBM Corporation -- z/VM Development -- CP Network Simulation
Re: DHCP, guest LANs
> Broadcast packets are marked as such by the guest (the device > drivers). > [...] > Well... not every adapter... The adapter has to be > initialized and enabled > for receipt of inbound broadcast... but I believe the drivers > for the QDIO > adapter will enable broadcast by default. Good. Do we need new versions of the drivers to enable support for the new device definitions? If I remember correctly from studying the CP source for QDIO support in 2.4, there was a capabilities mask that had a bunch of undefined bits for new goodies, and it sounds like this would be one that would need a bit. > >From David Boyes: > >Another thought on the subject of DHCP. Are/do the new VNICs have a > >unique MAC address so as to allow them to use DHCP and still get a > >fixed configuration. This would be a major goodness if it is > possible. > > Each virtual adapter (NIC) is assigned a unique MACADDR value when it > is defined. That value is unique within the z/VM host system > where the NIC > and the LAN are defined. Excellent! I'll have to look at this today...if this works, then cloning just got a whole lot simpler.
Re: DHCP, guest LANs
On 02.05.2002 at 04:56:58, John Summerfield <[EMAIL PROTECTED]> wrote: > I was about to suggest that. It's how ARP works - I've looked at tcpdump > reports and seen it sending a message 'who is 192.168.1.5" and getting the > reply "I am 192.168.1.5." Yep. ARP sends a broadcast, which everyone (on the local net) receives. The one who's supposed to reply (the one who has the requested IP address) sends a unicast reply, and everyone else ignores it. The key is that, you've got to get past the adapter (because the adapter doesn't know subnets from a hole in the ground, right Alan ;). Unless an adapter is in 'promiscuous' mode, it will only pick off the wire those packets sent to its own MAC address, or a special MAC address that signifies broadcast (or different MACs for multicast, but that's a bit different again). So, simply speaking, the Guest LAN knows how to handle the broadcast MAC address. Easy. Thanks, everyone! Cheers, Vic -- Vic Cross MACS mailto:[EMAIL PROTECTED] Networking, Linux, on zSeries and S/390
Re: DHCP, guest LANs
Hi... Perhaps the ethernet adapter looks at the destination ip address and categorizes it as unicast/multicast/broadcast to put the appropriate MACADDR in the link level header... I really don't know. For QDIO devices, the driver builds the outbound link level header and sets a "broadcast" value in one of the flag bytes. I think this is comperable to the ff:ff:ff:ff:ff:ff value that would be set in the MACADDR field of an ethernet link level header. Apparently there is a flag on the socket interface that indicates a broadcast request, so I assume that the stack (or the driver) would use that to set the equivalent link level header field. The destination ip address just rides along in the IP Header. Regards, Dennis Musselwhite ([EMAIL PROTECTED]) IBM Corporation -- z/VM Development -- CP Network Simulation
Re: DHCP, guest LANs
> On 01.05.2002 at 23:55:40, Dennis Musselwhite <[EMAIL PROTECTED]> wrote: > > > > The guest LAN acts as a hub and delivers a copy of the broadcast packet > > to the data connection of every virtual adapter (NIC) coupled to that LAN > > regardless of the destination IP Address or the subnet mask. > > Ok, let's rephrase... > > How does the guest LAN identify which are broadcast packets, if not by the > destination IP address? > > ... ... > > Wait a minute, there's a special MAC address used for broadcast also, isn't > there...? So the Guest LAN knows by the broadcast *MAC* address that the pac > ket > has to be sent to all coupled NICs, right? I was about to suggest that. It's how ARP works - I've looked at tcpdump reports and seen it sending a message 'who is 192.168.1.5" and getting the reply "I am 192.168.1.5." -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Note: mail delivered to me is deemed to be intended for me, for my disposition. == If you don't like being told you're wrong, be right!
Re: DHCP, guest LANs
On Wed, 1 May 2002 08:40:43 -0400 David Boyes said: >On Wed, May 01, 2002 at 08:34:21AM -0400, [EMAIL PROTECTED] wrote: >> I'd expect DHCP to work within a guest LAN, but not to work to any >> other guest LAN or to the outside world without some more development >> to happen in terms of repeater tools and/or hardware. > > >Another thought on the subject of DHCP. Are/do the new VNICs have a >unique MAC address so as to allow them to use DHCP and still get a >fixed configuration. This would be a major goodness if it is possible. I very good question, that I've been wondering about too. I haven't seen anything definitive yet, but without a something like that, you could only support pooled DHCP, and I'm not sure how the DHCP server responds to the client anyhow. Well, 4.3 GAs in what, 30 days? so we should be able to get answers shortly. /ahw
Re: DHCP, guest LANs
On 01.05.2002 at 23:55:40, Dennis Musselwhite <[EMAIL PROTECTED]> wrote: > The guest LAN acts as a hub and delivers a copy of the broadcast packet > to the data connection of every virtual adapter (NIC) coupled to that LAN > regardless of the destination IP Address or the subnet mask. Ok, let's rephrase... How does the guest LAN identify which are broadcast packets, if not by the destination IP address? ... ... Wait a minute, there's a special MAC address used for broadcast also, isn't there...? So the Guest LAN knows by the broadcast *MAC* address that the packet has to be sent to all coupled NICs, right? Cheers, Vic PS: Patience, please, folks... It's late over here and I should be in bed :) -- Vic Cross MACS mailto:[EMAIL PROTECTED] Networking, Linux, on zSeries and S/390
Re: DHCP, guest LANs
Hi, Regarding z/VM LAN broadcast simulation ... Broadcast packets are marked as such by the guest (the device drivers). The guest LAN acts as a hub and delivers a copy of the broadcast packet to the data connection of every virtual adapter (NIC) coupled to that LAN regardless of the destination IP Address or the subnet mask. Well... not every adapter... The adapter has to be initialized and enabled for receipt of inbound broadcast... but I believe the drivers for the QDIO adapter will enable broadcast by default. >From David Boyes: >Another thought on the subject of DHCP. Are/do the new VNICs have a >unique MAC address so as to allow them to use DHCP and still get a >fixed configuration. This would be a major goodness if it is possible. Each virtual adapter (NIC) is assigned a unique MACADDR value when it is defined. That value is unique within the z/VM host system where the NIC and the LAN are defined. Regards, Dennis Musselwhite ([EMAIL PROTECTED]) IBM Corporation -- z/VM Development -- CP Network Simulation
DHCP, guest LANs
On Wed, May 01, 2002 at 08:34:21AM -0400, [EMAIL PROTECTED] wrote: > I'd expect DHCP to work within a guest LAN, but not to work to any > other guest LAN or to the outside world without some more development > to happen in terms of repeater tools and/or hardware. Another thought on the subject of DHCP. Are/do the new VNICs have a unique MAC address so as to allow them to use DHCP and still get a fixed configuration. This would be a major goodness if it is possible.
