Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

[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:

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

Adressing layout:

  1. HOST: 10.0.7.1
  2. VM: 10.0.7.101
  3. 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 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.

share|improve this question
3  
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 '13 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 '13 at 18:48

1 Answer 1

up vote 6 down vote accepted

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 !

share|improve this answer
    
So you had to uncheck "no promisc mode" on that VM as well, I suppose? –  Nils Nov 23 '13 at 22:25
    
Indeed, it is unchecked. –  jtlebi Nov 24 '13 at 16:48

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.