4

I have

  • an interface, name eth0, in my main network namespace
  • another interface, name jail0, in an alternate network namespace (name name0). This namespace is used by a jailed environment.
  • jail0 is a macvlan alias of eth0.

I see the network without any problem, from the my main system and also from my jail.

However, I can't ping eachother.

Why is it so? I would like to make them reachable.

None of the network interfaces exists in the namespace of the others.

Improve this question

2 Answers 2

Reset to default
8

To complete the accepted answer, the bridge mode is the easiest way to go, but it's not enough to get the communication.

When the jail instance tries to ping the host, it sends an ARP request to get its IP. Because the host has no macvlan instance, the packet will be transmitted directly on the physical link (the corollary of the bridge mode definition). The host will never see this packet so can't answer: no ping answer. The other way is the same: the host emits all its packets to the real physical LAN, no host's packet will ever be going to the macvlan interface of the container (jail...).

The trick is to create an 2nd macvlan interface, also in bridge mode, intended for the host: this will integrate the host with the container/jail's traffic.

host# ip link add link eth0 name hostmvl0 type macvlan mode bridge

Then there are two methods:

  • same IP on both interfaces

    pro: no change to eth0 or its settings, so for example no issue with host's DHCP.
    con: some complexity, can't have broadcasts going everywhere.

    Assign the host's IP (same as on eth0) on it, without default lan route (noprefixroute) or this could confuse the whole hosts's routing:

    host# ip addr add hostip/netmask dev hostmvl0 noprefixroute
host# ip link set hostmvl0 up

    For each container (jail...) add its route through the host's macvlan interface instead of the real one:

    host# ip route add jailip/32 dev hostmvl0

    Now everything will work (except that a broadcast (ping,udp...) from the host won't be seen by the container/jail because it will be routed on eth0).

    Note: the new interface gets a random MAC address.It can be set with an additionnal address xx:xx:xx:xx:xx:xx at creation but it can't be the real (eth0's) one. Only the jail will see this MAC address.

  • IP on host's macvlan interface, physical interface without IP

    pro: network configuration more usual, no special case (eg: host's broadcast works everywhere), no additional route setting per container.
    con: requires removing eth0's network settings and migrate them to hostmvl0. MAC address will change (unless some other hack is made to prevent it) thus might affect a DHCP client.

    As suggested by sebasth, one can simply remove the IP from eth0 and consider the new "main" network card to be hostmvl0. Of course if there's some service managing this, change it there instead. Better always set the same MAC address, else it would change on the net at every restart, this is frowned upon in business environment.

    host# ip addr del hostip/netmask dev eth0 #careful, connectivity is lost
host# ip link set hostmvl0 address xx:xx:xx:xx:xx:xx
host# ip addr add hostip/netmask dev hostmvl0
host# ip link set hostmvl0 up
host# ip route add default via usualrouterip

    If using DHCP instead, the MAC having changed, the IP will as well. One could change eth0's MAC to be able to reuse its original for hostmvl0. Some tools are sometimes too smart when this is done. This Archlinux discussion might have informations on how to prevent NetworkManager from reverting settings.

Improve this answer
2
  • This answer probably should be marked as the accepted one, since it answers the OP's question (somehow I neglected to notice the interface on main namespace was not a macvlan one). Another alternative worth mentioning in your answer (imho): creating a macvlan interface in the main namespace and not assigning any IP address to the physical interface itself. This would avoid any additional route configuration.
    – sebasth
    Oct 25, 2017 at 12:28
  • Yes indeed this works, avoids the broadcast from the host not being seen by the container and it's easier to set. But that means for a container/jail just running on a desktop computer, having to change usual host's settings (card's name, mac address meaning the IP from DHCP might not be the same anymore... hum unless the eth0's mac is changed first, but NetworkManager doesn't like this). So it depends on usage. I'll add it
    – A.B
    Oct 25, 2017 at 18:00
4

macvlan interface can be used in different modes which alter how data transmitted between two macvlan instances is treated. The default mode is vepa (Virtual Ethernet Port Aggregation), which possibly is why your setup doesn't work.

Short description of common modes you might want to configure:

  • vepa data is transmitted over physical interface, for communication between macvlan instances the switch needs to support hairpin mode or there must be a IP router forwarding the packets.

  • private no communication between macvlan instances allowed, even if the external switch supports hairpin mode.

  • bridge allow direct communication between instances, traffic between macvlan instances is not transmitted on physical link.

You probably want to use macvlan in bridge mode. For communication between the macvlan instance and the namespace containing the network interface itself, you need to create a macvlan instance in the same (main/host) network namespace. For details and explanation, see A.B's answer.

For full documentation (and the other modes), see man 8 ip-link.

Improve this answer
0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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