[ovs-dev] [PATCH] vswitch: Consistently set Nicira OUI.

[Jesse Gross]

On Mon, Feb 1, 2010 at 8:50 PM, Justin Pettit <jpettit at nicira.com> wrote:

> On Feb 1, 2010, at 4:43 PM, Jesse Gross wrote:
>
> > The bottom line is that we should be consistent everywhere because
> otherwise we end up with the worst of both worlds.  Personally I prefer have
> the OUI set since it is nicer when looking at packet traces.  It's also
> friendlier to the rest of the world.  VMware sets their OUI on addresses
> they generate.
>
> Is there a standard for randomly-generated "official" addresses?  We set
> that top bit of the third byte to indicate that the address is randomly
> generated, so that we could also assign real, static addresses if we need to
> down the line.  The IEEE doesn't like handing out additional OUIs unless you
> can prove that you've actually run out of the first block you were given.
>  I'm just curious if there's a better approach than my
> off-the-top-of-the-head suggestion of setting a single bit to indicate this.
>  I'd think VMware or someone has given this a little more thought.


 I don't believe that there is any standardized way of doing this.  VMware
has been allocated four OUIs, which they use in different products.
 However, even within ESX they use two different OUIs: one for generated
addresses and one for manually configured addresses.  The generated
addresses are not random though: they are based on the IP address of the
machine, a hash of the config file, etc.

I think we could make a pretty good case getting another OUI if necessary in
the future, so I don't think that is a big concern.  Setting the top bit is
fine with me too (we are currently setting the top two bits in one place but
none in another).  Also, these addresses are only used for traffic actually
generated by an OVS interface, not every VM (this is different from VMware),
so the chance of a collision isn't too high.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20100202/ad9bdf01/attachment-0003.html>