Xen devel - Aug 2008 - using a different MAC in netfront than the one given by netback

Is there any problem if netfront (or Windows in my case) uses a
different MAC address than the one given to it by netback? NLB (Network
Load Balancing) appears to need to assign a Locally Administered Address
to the network interface.

The only issue I can think of is if iptables added rules on a MAC
address basis, which it doesn''t at least in 3.2.x...

Thanks

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Mon, Aug 18, 2008 at 01:42:28PM +1000, James Harper
wrote:
> Is there any problem if netfront (or Windows in my case) uses a
> different MAC address than the one given to it by netback? NLB (Network
> Load Balancing) appears to need to assign a Locally Administered Address
> to the network interface.
> 
> The only issue I can think of is if iptables added rules on a MAC
> address basis, which it doesn''t at least in 3.2.x...
This will break on Solaris dom0, where there''s an implicit filter for
the MAC address assigned by the dom0 tools.

It might be useful to allow the guest to extend the set of unicast
addresses it receives in a manner similar to the multicast stuff (that
no-one else implements :-/).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> 
> On Mon, Aug 18, 2008 at 01:42:28PM +1000, James Harper wrote:
> > Is there any problem if netfront (or Windows in my case) uses a
> > different MAC address than the one given to it by netback? NLB
(Network
> > Load Balancing) appears to need to assign a Locally Administered
Address
> > to the network interface.
> >
> > The only issue I can think of is if iptables added rules on a MAC
> > address basis, which it doesn''t at least in 3.2.x...
> 
> This will break on Solaris dom0, where there''s an implicit filter
for
> the MAC address assigned by the dom0 tools.
> 
> It might be useful to allow the guest to extend the set of unicast
> addresses it receives in a manner similar to the multicast stuff (that
> no-one else implements :-/).
> 
Windows NLB isn''t going to work with the GPLPV drivers on a Solaris
Dom0
then, unless the filter can be lifted on a case by case basis?

Or maybe the multicast mode of NLB will work around that problem...

Thanks for the reply!

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Mon, Aug 18, 2008 at 06:02:03PM +1000, James Harper
wrote:
> > On Mon, Aug 18, 2008 at 01:42:28PM +1000, James Harper wrote:
> > > Is there any problem if netfront (or Windows in my case) uses a
> > > different MAC address than the one given to it by netback? NLB
> (Network
> > > Load Balancing) appears to need to assign a Locally Administered
> Address
> > > to the network interface.
> > >
> > > The only issue I can think of is if iptables added rules on a MAC
> > > address basis, which it doesn''t at least in 3.2.x...
> > 
> > This will break on Solaris dom0, where there''s an implicit
filter for
> > the MAC address assigned by the dom0 tools.
> > 
> > It might be useful to allow the guest to extend the set of unicast
> > addresses it receives in a manner similar to the multicast stuff (that
> > no-one else implements :-/).
> > 
> 
> Windows NLB isn''t going to work with the GPLPV drivers on a
Solaris Dom0
> then,
With any software that uses a MAC address other than that assigned,
irrespective of the drivers, in fact.

I recall that the RTL8139 code in qemu-dm also filters, but perhaps
that gets disabled if the guest sets promiscuous mode.

Does the driver in question (your GPLPV driver in this case) get
notified when Windows wants to use an extra unicast address? Perhaps
it just pushes the device into promiscuous mode?
> unless the filter can be lifted on a case by case basis?
There are some knobs in the driver stack that should make this
possible. I''ll look into it.
> Or maybe the multicast mode of NLB will work around that problem...
Multicast should "just work".

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> >
> > Windows NLB isn''t going to work with the GPLPV drivers on a
Solaris
Dom0
> > then,
> 
> With any software that uses a MAC address other than that assigned,
> irrespective of the drivers, in fact.
> 
> I recall that the RTL8139 code in qemu-dm also filters, but perhaps
> that gets disabled if the guest sets promiscuous mode.
> 
> Does the driver in question (your GPLPV driver in this case) get
> notified when Windows wants to use an extra unicast address? Perhaps
> it just pushes the device into promiscuous mode?
What actually happens is that Windows sets a registry entry when NLB is
enabled and my driver uses that to set the MAC address to something
other than what Dom0 says it should be. Windows then reads the MAC
address to see if I noticed the registry entry, and if I didn''t it
complains and refuses to enable NLB on that interface saying that it
doesn''t support a change of MAC address.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Mon, Aug 18, 2008 at 10:46:39PM +1000, James Harper
wrote:
> > Does the driver in question (your GPLPV driver in this case) get
> > notified when Windows wants to use an extra unicast address? Perhaps
> > it just pushes the device into promiscuous mode?
> 
> What actually happens is that Windows sets a registry entry when NLB is
> enabled and my driver uses that to set the MAC address to something
> other than what Dom0 says it should be. Windows then reads the MAC
> address to see if I noticed the registry entry, and if I didn''t it
> complains and refuses to enable NLB on that interface saying that it
> doesn''t support a change of MAC address.
Then there is only one MAC address used, rather than it being an
additional address?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> On Mon, Aug 18, 2008 at 10:46:39PM +1000, James Harper wrote:
> > > Does the driver in question (your GPLPV driver in this case) get
> > > notified when Windows wants to use an extra unicast address?
Perhaps
> > > it just pushes the device into promiscuous mode?
> >
> > What actually happens is that Windows sets a registry entry when NLB
is
> > enabled and my driver uses that to set the MAC address to something
> > other than what Dom0 says it should be. Windows then reads the MAC
> > address to see if I noticed the registry entry, and if I
didn''t it
> > complains and refuses to enable NLB on that interface saying that it
> > doesn''t support a change of MAC address.
> 
> Then there is only one MAC address used, rather than it being an
> additional address?
Correct.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel