Re: how is the MAC for tap(4) computed?
On Tue, 2013-11-05 at 10:24 -0800, John-Mark Gurney wrote: > ill...@gmail.com wrote this message on Mon, Nov 04, 2013 at 16:08 -0500: > > On 4 November 2013 12:09, Dan Nelson 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 > Several ethernet drivers for embedded systems have logic to cook up a random address (probably it should be commonized somewhere) in which they set the first 3 bytes to 'b','s','d' and the low bytes to a random number. The nifty thing about the value 62:73:64 (beside that it's bsd) is that it sets the locally-administered bit in the address. -- Ian ___ 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?
ill...@gmail.com wrote this message on Mon, Nov 04, 2013 at 16:08 -0500: > On 4 November 2013 12:09, Dan Nelson 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?
On 4 November 2013 12:09, Dan Nelson 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"
Re: how is the MAC for tap(4) computed?
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?
Hi Michael, Peter, lost the last part of your message ... Doh: meant to say e.g. -s 5,virtio-net,tap0,mac=00:0c:29:3f:71:e2 An alternative would be hashing the vm name with the host name and host MAC address. Yes, though in that case a VM will end up with a different MAC address if it's moved to a different host :( What we'll probably end up doing is to generate a UUID when a VM is created and hash off that. 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?
Peter, lost the last part of your message ... An alternative would be hashing the vm name with the host name and host MAC address. Sent from my iPhone > On Nov 4, 2013, at 6:26 AM, "Peter Grehan" wrote: > > 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" ___ 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?
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"
