Are virtual devices in Linux ever assigned duplicate MACs (actually duplicate IPv6 link-local addresses)?
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
I'm creating a completely virtual network between different network namespaces on the same host. I'm going to be telling programs to use IPv6 link-local addresses for networking.
One problem I currently have is that the virtual network devices are assigned an initial link-local address but are set in the 'tentative' state while DAD (Duplicate Address Discovery) is done. I would like to assume that this address will not be replaced or removed from the interface.
How bad of an assumption is this if the devices only interact with other virtual devices running on the same host? Is there any way for the kernel to assign the same MAC address to two different virtual devices?
I could just wait for DAD to complete. But that takes 1.8 seconds, and for this application, that is FAR too long. Ideally a program would be up and running in the new network namespace within 10s of µsecs, though 100s of µsecs would probably be acceptable.
linux networking ipv6 mac-address
asked Nov 9 '17 at 19:30
Omnifarious
895515
add a comment |Â
up vote
1
down vote
favorite
I'm creating a completely virtual network between different network namespaces on the same host. I'm going to be telling programs to use IPv6 link-local addresses for networking.
One problem I currently have is that the virtual network devices are assigned an initial link-local address but are set in the 'tentative' state while DAD (Duplicate Address Discovery) is done. I would like to assume that this address will not be replaced or removed from the interface.
How bad of an assumption is this if the devices only interact with other virtual devices running on the same host? Is there any way for the kernel to assign the same MAC address to two different virtual devices?
I could just wait for DAD to complete. But that takes 1.8 seconds, and for this application, that is FAR too long. Ideally a program would be up and running in the new network namespace within 10s of µsecs, though 100s of µsecs would probably be acceptable.
linux networking ipv6 mac-address
asked Nov 9 '17 at 19:30
Omnifarious
895515
2
eg for veth.c: eth_hw_addr_random() --> eth_random_addr() --> get_random_bytes() and that's it. There's no collision check (well, DAD is the check). You should assign MACs yourself with your own method if you want to be 101% sure.
– A.B
Nov 10 '17 at 0:01
@A.B - Hmm, that's a possibility. But that's also kind of disappointing to learn. :-/
– Omnifarious
Nov 10 '17 at 0:15
I'm sure most container (or vm) hypervisor would record the randomly created value or create it themselves, and would check for duplicates. Or it can be checked easily (eg for lxc how difficult would it be to compare all /var/lib/lxc/*/config and see if there are duplicatelxc.network.hwaddr?). Now if everything is made from scratch, well if it has to be done it has to be done
– A.B
Nov 10 '17 at 0:28
@A.B - Well, in this case I'm writing my own process isolation system in C++ that isn't any of these. And part of the reason I'm doing it is to very quickly dynamically create isolation contexts. The isolation contexts will hide parts of the filesystem, but largely they all have the same read-only view of the filesystem.
– Omnifarious
Nov 10 '17 at 0:31
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I'm creating a completely virtual network between different network namespaces on the same host. I'm going to be telling programs to use IPv6 link-local addresses for networking.
One problem I currently have is that the virtual network devices are assigned an initial link-local address but are set in the 'tentative' state while DAD (Duplicate Address Discovery) is done. I would like to assume that this address will not be replaced or removed from the interface.
How bad of an assumption is this if the devices only interact with other virtual devices running on the same host? Is there any way for the kernel to assign the same MAC address to two different virtual devices?
I could just wait for DAD to complete. But that takes 1.8 seconds, and for this application, that is FAR too long. Ideally a program would be up and running in the new network namespace within 10s of µsecs, though 100s of µsecs would probably be acceptable.
linux networking ipv6 mac-address
asked Nov 9 '17 at 19:30
Omnifarious
895515
I'm creating a completely virtual network between different network namespaces on the same host. I'm going to be telling programs to use IPv6 link-local addresses for networking.
One problem I currently have is that the virtual network devices are assigned an initial link-local address but are set in the 'tentative' state while DAD (Duplicate Address Discovery) is done. I would like to assume that this address will not be replaced or removed from the interface.
How bad of an assumption is this if the devices only interact with other virtual devices running on the same host? Is there any way for the kernel to assign the same MAC address to two different virtual devices?
I could just wait for DAD to complete. But that takes 1.8 seconds, and for this application, that is FAR too long. Ideally a program would be up and running in the new network namespace within 10s of µsecs, though 100s of µsecs would probably be acceptable.
linux networking ipv6 mac-address
asked Nov 9 '17 at 19:30
Omnifarious
895515
asked Nov 9 '17 at 19:30
Omnifarious
895515
asked Nov 9 '17 at 19:30
Omnifarious
895515
asked Nov 9 '17 at 19:30
Omnifarious
895515
895515
2
eg for veth.c: eth_hw_addr_random() --> eth_random_addr() --> get_random_bytes() and that's it. There's no collision check (well, DAD is the check). You should assign MACs yourself with your own method if you want to be 101% sure.
– A.B
Nov 10 '17 at 0:01
@A.B - Hmm, that's a possibility. But that's also kind of disappointing to learn. :-/
– Omnifarious
Nov 10 '17 at 0:15
I'm sure most container (or vm) hypervisor would record the randomly created value or create it themselves, and would check for duplicates. Or it can be checked easily (eg for lxc how difficult would it be to compare all /var/lib/lxc/*/config and see if there are duplicatelxc.network.hwaddr?). Now if everything is made from scratch, well if it has to be done it has to be done
– A.B
Nov 10 '17 at 0:28
@A.B - Well, in this case I'm writing my own process isolation system in C++ that isn't any of these. And part of the reason I'm doing it is to very quickly dynamically create isolation contexts. The isolation contexts will hide parts of the filesystem, but largely they all have the same read-only view of the filesystem.
– Omnifarious
Nov 10 '17 at 0:31
add a comment |Â
2
eg for veth.c: eth_hw_addr_random() --> eth_random_addr() --> get_random_bytes() and that's it. There's no collision check (well, DAD is the check). You should assign MACs yourself with your own method if you want to be 101% sure.
– A.B
Nov 10 '17 at 0:01
@A.B - Hmm, that's a possibility. But that's also kind of disappointing to learn. :-/
– Omnifarious
Nov 10 '17 at 0:15
I'm sure most container (or vm) hypervisor would record the randomly created value or create it themselves, and would check for duplicates. Or it can be checked easily (eg for lxc how difficult would it be to compare all /var/lib/lxc/*/config and see if there are duplicatelxc.network.hwaddr?). Now if everything is made from scratch, well if it has to be done it has to be done
– A.B
Nov 10 '17 at 0:28
@A.B - Well, in this case I'm writing my own process isolation system in C++ that isn't any of these. And part of the reason I'm doing it is to very quickly dynamically create isolation contexts. The isolation contexts will hide parts of the filesystem, but largely they all have the same read-only view of the filesystem.
– Omnifarious
Nov 10 '17 at 0:31
2
2
eg for veth.c: eth_hw_addr_random() --> eth_random_addr() --> get_random_bytes() and that's it. There's no collision check (well, DAD is the check). You should assign MACs yourself with your own method if you want to be 101% sure.
– A.B
Nov 10 '17 at 0:01
eg for veth.c: eth_hw_addr_random() --> eth_random_addr() --> get_random_bytes() and that's it. There's no collision check (well, DAD is the check). You should assign MACs yourself with your own method if you want to be 101% sure.
– A.B
Nov 10 '17 at 0:01
@A.B - Hmm, that's a possibility. But that's also kind of disappointing to learn. :-/
– Omnifarious
Nov 10 '17 at 0:15
@A.B - Hmm, that's a possibility. But that's also kind of disappointing to learn. :-/
– Omnifarious
Nov 10 '17 at 0:15
I'm sure most container (or vm) hypervisor would record the randomly created value or create it themselves, and would check for duplicates. Or it can be checked easily (eg for lxc how difficult would it be to compare all /var/lib/lxc/*/config and see if there are duplicate
lxc.network.hwaddr ?). Now if everything is made from scratch, well if it has to be done it has to be done– A.B
Nov 10 '17 at 0:28
I'm sure most container (or vm) hypervisor would record the randomly created value or create it themselves, and would check for duplicates. Or it can be checked easily (eg for lxc how difficult would it be to compare all /var/lib/lxc/*/config and see if there are duplicate
lxc.network.hwaddr ?). Now if everything is made from scratch, well if it has to be done it has to be done– A.B
Nov 10 '17 at 0:28
@A.B - Well, in this case I'm writing my own process isolation system in C++ that isn't any of these. And part of the reason I'm doing it is to very quickly dynamically create isolation contexts. The isolation contexts will hide parts of the filesystem, but largely they all have the same read-only view of the filesystem.
– Omnifarious
Nov 10 '17 at 0:31
@A.B - Well, in this case I'm writing my own process isolation system in C++ that isn't any of these. And part of the reason I'm doing it is to very quickly dynamically create isolation contexts. The isolation contexts will hide parts of the filesystem, but largely they all have the same read-only view of the filesystem.
– Omnifarious
Nov 10 '17 at 0:31
add a comment |Â
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f403593%2fare-virtual-devices-in-linux-ever-assigned-duplicate-macs-actually-duplicate-ip%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
2
eg for veth.c: eth_hw_addr_random() --> eth_random_addr() --> get_random_bytes() and that's it. There's no collision check (well, DAD is the check). You should assign MACs yourself with your own method if you want to be 101% sure.
– A.B
Nov 10 '17 at 0:01
@A.B - Hmm, that's a possibility. But that's also kind of disappointing to learn. :-/
– Omnifarious
Nov 10 '17 at 0:15
I'm sure most container (or vm) hypervisor would record the randomly created value or create it themselves, and would check for duplicates. Or it can be checked easily (eg for lxc how difficult would it be to compare all /var/lib/lxc/*/config and see if there are duplicate
lxc.network.hwaddr?). Now if everything is made from scratch, well if it has to be done it has to be done– A.B
Nov 10 '17 at 0:28
@A.B - Well, in this case I'm writing my own process isolation system in C++ that isn't any of these. And part of the reason I'm doing it is to very quickly dynamically create isolation contexts. The isolation contexts will hide parts of the filesystem, but largely they all have the same read-only view of the filesystem.
– Omnifarious
Nov 10 '17 at 0:31