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.