Re: how is the MAC for tap(4) computed?

2013-11-05 Thread John-Mark Gurney
ill...@gmail.com wrote this message on Mon, Nov 04, 2013 at 16:08 -0500:
 On 4 November 2013 12:09, Dan Nelson dnel...@allantgroup.com wrote:
  In the last episode (Nov 04), Aryeh Friedman said:
  There seems to be a very high rate of MAC address collisions when tap is
  running on different machines  is there anyway to make the selection
  of MAC more random
 
  It looks like it's generated based on the number of ticks since boot, plus
  the unit number of the tap device:
 
  http://fxr.watson.org/fxr/source/net/if_tap.c#L434
 
  So if you have devices created on boot on a bunch of machines, chances are
  high that you'll get conflicts.  Maybe instead of using the 'ticks' value,
  kern.hostid could be used instead?  That has much better randomness than
  'ticks'.
 
 With physical interfaces you can use something like
 ifconfig ath0 ether 00:2d:44:88:ff:00
 (assuming the device  the driver support changing MAC
 addresses)
 
 I've never tried it with a virtual interface, but it should work if the
 device supports it.

But remeber when choosing an address like that, that you set the second
low bit of the first octect to one to designate that it's a locally
administered address...

See wikipedia for more info:
https://en.wikipedia.org/wiki/MAC_address#Address_details

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
freebsd-virtualization-unsubscr...@freebsd.org


Re: how is the MAC for tap(4) computed?

2013-11-04 Thread Peter Grehan

Hi Aryeh,


There seems to be a very high rate of MAC address collisions when tap is
running on different machines is there anyway to make the selection of
MAC more random


 Do you mean, tap(4) when used with bhyve ? If so, bhyve calculates the 
MAC address for adapters based on an md5 hash of the PCI slot/function 
and VM name. If you use the same bhyve configuration on a different 
machine, the MAC address will be the same.


 If that's the problem, you may want to supply your own MAC address 
with the mac= parameter on the command line e.g.


later,

Peter.

___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
freebsd-virtualization-unsubscr...@freebsd.org


Re: how is the MAC for tap(4) computed?

2013-11-04 Thread Dan Nelson
In the last episode (Nov 04), Aryeh Friedman said:
 There seems to be a very high rate of MAC address collisions when tap is
 running on different machines  is there anyway to make the selection
 of MAC more random

It looks like it's generated based on the number of ticks since boot, plus
the unit number of the tap device:

http://fxr.watson.org/fxr/source/net/if_tap.c#L434

So if you have devices created on boot on a bunch of machines, chances are
high that you'll get conflicts.  Maybe instead of using the 'ticks' value,
kern.hostid could be used instead?  That has much better randomness than
'ticks'.

-- 
Dan Nelson
dnel...@allantgroup.com
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
freebsd-virtualization-unsubscr...@freebsd.org


Re: how is the MAC for tap(4) computed?

2013-11-04 Thread ill...@gmail.com
On 4 November 2013 12:09, Dan Nelson dnel...@allantgroup.com wrote:
 In the last episode (Nov 04), Aryeh Friedman said:
 There seems to be a very high rate of MAC address collisions when tap is
 running on different machines  is there anyway to make the selection
 of MAC more random

 It looks like it's generated based on the number of ticks since boot, plus
 the unit number of the tap device:

 http://fxr.watson.org/fxr/source/net/if_tap.c#L434

 So if you have devices created on boot on a bunch of machines, chances are
 high that you'll get conflicts.  Maybe instead of using the 'ticks' value,
 kern.hostid could be used instead?  That has much better randomness than
 'ticks'.

With physical interfaces you can use something like
ifconfig ath0 ether 00:2d:44:88:ff:00
(assuming the device  the driver support changing MAC
addresses)

I've never tried it with a virtual interface, but it should work if the
device supports it.

-- 
--
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
freebsd-virtualization-unsubscr...@freebsd.org