[EDIT]
The production system is currently a mix physical and ESXi based system. We obviously would never use virtualbox even for a pre-production environment ! It was used here only to quickly narrow down the problem directly on my desktop.
Thanks for the explanation for the "on hold" on meta !
[/EDIT]
My setup:
- Private network
vboxnet1
10.0.7.0/24 - 1 Host, ubuntu desktop
- 1 VM, ubuntu server (VirtualBox)
Adressing layout:
- HOST: 10.0.7.1
- VM: 10.0.7.101
- VM MAC NAMESPACE: 10.0.7.102
On the VM
, I ran the following commands:
ip netns add mac # create a new nmespace
ip link add link eth0 mac0 type macvlan # create a new macvlan interface
ip link set mac0 netns mac
On the mac
namespace, inside the VM:
ip link set lo up
ip link set mac up
ip addr add 10.0.7.102/24 dev mac0
So that we basically end up with: (Like Inception ?)
+------------------------+
| Host: 10.0.7.1 |
| |
| +--------------------+ |
| | VM: 10.0.7.101 | |
| | | |
| | +----------------+ | |
| | | NS: 10.0.7.102 | | |
| | | | | |
| | +----------------+ | |
| +--------------------+ |
+------------------------+
What works:
- Ping between
Host
andVM
- Ping between
NS
andNS
- dhclient from
NS
What does not work:
- ping between
NS
andVM
- ping between
NS
andHost
Where I started to go nuts:
- tcpdump on
host
(the real machine) actually shows ARP request AND replies - tcpdump on
NS
shows ARP requests sent to the host - tcpdump on
VM
makes the whole mess work (!) –> ping starts to get answers when tcpdump is started on the VM ?!?
So, I bet you were eager for it, my question is: how to I make it work ? I suspect something's wrong with ARP on the macvlan inside the NS but can't figure out what exactly…
Btw, I did the same expérimentations with the mac0
interface directly on the VM (no namespace) and it worked flawlessly.
Best Answer
OK, so, for posterity, the fact that tcpdump makes all suddenly works should have put me on track. What it does internally is switch
eth0
into promiscuous mode. That is to say,eth0
will yield all the network traffic, not only the one with the server's mainMAC
However, this is precisely how
macvlan
works: it adds a new secondary virtual MAC address which the "physical" (that's a VM) network adapter doesn't know.So the easy workaround is to manually:
ifconfig eth0 promisc
I hope it helps !