Not at all, this is good info. It's not an old thread as long as the proposed task hasn't been done yet, and it hasn't.
I still need to finish researching what exactly we should get, and then how. -- bkw On 4/23/2011 3:25 AM, Geordy Korte wrote: > Hello, > > Sorry to revive an old thread but I would like to share some information > with you that might give you an insight into why an OUI is advisable. > > I work for IBM as a Technical Pre-Sales consultant for Blade network > technologies (what a mouth full). BNT creates switches that are very > very good but that is not the point. One of the features that we have is > VMready which basically means that when the switch detects a Virtualized > uplink to a server it will analyse the traffic and create PORTS for > every virtual host running on that server. This tech allows you to > create policy for that port with which you can set QOS, ACL and anything > else you would like. Now Vmready is fully vmotion enabled so that when > you migrate a virtualhost to another server, the policy moves with it. > > The reason for me writing this to the list is that Vmready works for > Hypervisor, vmware, kvm, powervm... and it only works because of the > mac address. Each switch has a database of Macs that belong to a > virtualization product and by matching passing traffic to the list > Vmready works. Should LXC get it's own block then I can make sure it's > added to the Vmready database. > > Sorry if this sounds like a sales pitch... it's not meant too. > > Geordy Korte > > On Fri, Mar 11, 2011 at 11:08 PM, Brian K. White <br...@aljex.com > <mailto:br...@aljex.com>> wrote: > > On 3/11/2011 10:14 AM, Michael H. Warfield wrote: > > On Thu, 2011-03-10 at 19:09 +0000, Walter Stanish wrote: > >>>>> ... I have read up on the OUI documentation and > >>>>> looking at the detail on the site LXC could opt for a 32bit > OUI which would > >>>>> cost $600 for one block. The dev guys might want to setup a > pledge program... > >> > >>>> I will pay for it. > >> > >>> I too am willing to pay the whole thing, so, halvsies? Or see > how many > >>> others want to split even? > > > >> Sounds good. I guess we can nominate you as the finance go-to > on this > >> one then :) > > > >> Let us know details when they emerge. > > > > Can someone explain to me why we can't simply use a block of > addresses > > with the 0200 (local administration) bit or'ed in. Out of 48 bits of > > addressing, we can use 46 bits of them for anything we want as > long as > > that bit is set and the 0100 bit (multicast) is clear. By the > standard, > > those are locally managed and allocated MAC addresses that are not > > guaranteed to be globally unique. They don't even need to be > unique in > > an entire network, only on the local subnet. Use any convention you > > want. Stuff the 32 bit IP address of the host in the lower 32 > bits and > > you've still got 14 bits worth of assignable addressing per host. > > That's what that bit is intended for. > > That is exactly what I do myself. > > I'm not sure there is a specific need for a recognizable lxc address > space, but exactly the same thing could be said about xen and for some > reason they have one. I don't claim it's necessary I just claim three > things: > > 1) It wouldn't hurt. > > 2) It's cheap enough in both cash and time not to matter, more than > enough volunteers have already presented themselves. > > 3) I don't presume that because I don't perceive a reason, that no > reason exists. > > One scenario I envision off-hand would be that automated vmware tools > and xen tools and lxc tools could each provision addresses from their > own spaces and guaranteed never step on each others toes. > > -- > bkw > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Lxc-users mailing list > Lxc-users@lists.sourceforge.net <mailto:Lxc-users@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/lxc-users > > > > > -- > ============== > Geordy Korte > MSN geo...@geordy.nl <mailto:geo...@geordy.nl> > > > > ------------------------------------------------------------------------------ > Fulfilling the Lean Software Promise > Lean software platforms are now widely adopted and the benefits have been > demonstrated beyond question. Learn why your peers are replacing JEE > containers with lightweight application servers - and what you can gain > from the move. http://p.sf.net/sfu/vmware-sfemails > > > > _______________________________________________ > Lxc-users mailing list > Lxc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lxc-users ------------------------------------------------------------------------------ Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails _______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
