Hi,
say I have container A and B, both have macvlan over an Interface:
sudo lxc network attach enp2s0 container_A eth1
sudo lxc network attach enp2s0 container_B eth1
enp2s0 has a static ip of 10.0.0.120
then the two containers have 10.0.0.121 and 10.0.0.122
seems to me, I can’t ping from container A to B and vice versa, is this the limitation of macvlan?
Thanks
Hmm, not that I know of. macvlan should let you ping between 10.0.0.121 and 10.0.0.122 but not from/to 10.0.0.120.
here are the static ip settings in two containers, maybe something lacking here?
container_A:
auto eth1
iface eth1 inet static
address 10.0.0.122
netmask 255.255.255.0
network 10.0.0.0
broadcast 10.0.0.255
container_B
auto eth1
iface eth1 inet static
address 10.0.0.123
netmask 255.255.255.0
network 10.0.0.0
broadcast 10.0.0.255
routing table in 10.0.0.123:
ernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 10.52.176.1 0.0.0.0 UG 0 0 0 eth0
10.0.0.0 * 255.255.255.0 U 0 0 0 eth1
10.52.176.0 * 255.255.255.0 U 0 0 0 eth0
traceroute 10.0.0.122
traceroute to 10.0.0.122 (10.0.0.122), 30 hops max, 60 byte packets
1 10.0.0.123 (10.0.0.123) 3000.084 ms !H 3000.024 ms !H 3000.011 ms !H
That’s certainly unusual behavior from macvlan, this usually does work perfectly fine.
That being said, macvlan is very dependent on your kernel version, NIC driver and NIC hardware…
I’d recommend switching to a good old bridge, that may be slightly slower but shouldn’t have such weird issues (or if it does, it should be easier to figure out what’s going on at least).
you are right about NIC hardware, turned out, the hub the host connected to was off, when it is on, everything works, thanks.
Haha, yeah, that does actually make sense, unlike a software bridge, macvlan uses hardware hairpin, so it actually sends the traffic out the NIC (or at least to its buffer) and then back in. Having that link down would explain things not working so well 
right, was ssh into a remote host, thus not noticing that and ip is static, can be seen.