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 !


My setup:

  1. Private network vboxnet1
  2. 1 Host, ubuntu desktop
  3. 1 VM, ubuntu server (VirtualBox)

Adressing layout:

  1. HOST:
  2. VM:

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 dev mac0

So that we basically end up with: (Like Inception ?)

| Host:         |
|                        |
| +--------------------+ |
| | VM:     | |
| |                    | |
| | +----------------+ | |
| | | NS: | | |
| | |                | | |
| | +----------------+ | |
| +--------------------+ |

What works:

  • Ping between Host and VM
  • Ping between NS and NS
  • dhclient from NS

What does not work:

  • ping between NS and VM
  • ping between NS and Host

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.

  • 4
    I don't understand why this question has been flagged as off-topic. It's definitely a sysadmin/netadmin question, relevant to multiple virtualization environments, and it's not a trivial one (or, if it is, 90% of the questions on StackOverflow are off-topic as well). I would love if the people who flagged it as "off-topic" bothered to explain why, rather than copy-pasting a rule that obviously doesn't apply here. Thank you!
    – jpetazzo
    Oct 24, 2013 at 22:38
  • @jpetazzo This isn't off-topic, and I can only assume the people closing did so based on the poor organization/presentation of the question (likely due to the OP not being a sys/net admin). Also, Server Fault's scope (not just topic) is different from Stack Overflow - your argument makes me think you haven't visited our help center as it makes no sense.
    – Chris S
    Oct 26, 2013 at 18:48

1 Answer 1


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 main MAC

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 !

  • So you had to uncheck "no promisc mode" on that VM as well, I suppose?
    – Nils
    Nov 23, 2013 at 22:25
  • Indeed, it is unchecked.
    – yadutaf
    Nov 24, 2013 at 16:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .