Cannot get macvlan working, no DHCP reply, network not working


(Anders Sandblad) #1

I’m running Ubuntu 16.04 and LXD 2.0.10-0ubuntu1~16.04.1.
All my containers are currently NAted behind lxdbr0 but I’ve set a newly created container to use macvlan with this command:
lxc config device add new-container eth0 nic nictype=macvlan parent=ens3 name=eth0
However, the container does not get any dhcp reply.
Even if I set the IP static it still cannot communicate with anything else on the network.

The LXD host is a virtual machine running on a KVM host and is itself running macvlan, can that cause an issue?

I’m kind of lost here, any advise is appreciated.

Here’s the IP-tables for the container host:

arune@server5:~$ sudo iptables -L -n -v
Chain INPUT (policy ACCEPT 1172K packets, 113M bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp – lxdbr0 * tcp dpt:53 /* managed by lxd-bridge /
420K 23M ACCEPT udp – lxdbr0 * udp dpt:53 /
managed by lxd-bridge /
12449 4083K ACCEPT udp – lxdbr0 * udp dpt:67 /
managed by lxd-bridge */

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
13M 6900M ACCEPT all – * lxdbr0 /* managed by lxd-bridge /
16M 18G ACCEPT all – lxdbr0 * /
managed by lxd-bridge */

Chain OUTPUT (policy ACCEPT 1721K packets, 2624M bytes)
pkts bytes target prot opt in out source destination

(Stéphane Graber) #2

macvlan doesn't hit the firewall so iptables isn't going to matter here.

I suspect that it's either macvlan somehow failing when chained the way you have it done, or your VM host is somehow doing MAC filtering and dropping any packet that doesn't come from the VM's main mac address (that's a very common issue with VMWare but the same can be done with kvm, especially if run on OpenStack).

(Anders Sandblad) #3

Hm, the KVM setup is rather "default" and I'm a bit unsure where to dig for info, this is what I found:

arune@pc10:~$ sudo virsh nwfilter-list

fd9df1da-fa9a-48d7-b847-5a638f185cbe allow-arp
3afff8a9-298b-4123-a108-d66eb12f15e3 allow-dhcp
4730cf44-e20f-4bae-86e1-ff5ed4789f77 allow-dhcp-server
1c8383a0-db2d-4cb8-9f97-2dc7db417ea7 allow-incoming-ipv4
4702c44e-f213-4c67-abb5-25eb62d71233 allow-ipv4
e2af2bc8-9665-4b1a-abbf-86a0fdc32cc4 clean-traffic
62cb5483-d157-4ad3-9ba1-9078c741a720 no-arp-ip-spoofing
fab44c0a-fe27-412d-b901-cbb666266833 no-arp-mac-spoofing
ea16202f-df86-4fee-b9b8-c4b91b798ab3 no-arp-spoofing
4b599c0b-c0c7-4212-877f-12f80bff5373 no-ip-multicast
5a4f6a00-356b-4a13-a860-a517a2ca4fe9 no-ip-spoofing
24644a2c-0003-46e7-8af3-21c53d15a42d no-mac-broadcast
f49852b0-39fb-4ca8-a068-2cc68f127fe1 no-mac-spoofing
e12f83e3-6e97-4614-ae12-e94e0f52e96e no-other-l2-traffic
0c92ee17-c1d0-4651-bc3e-41761339800c no-other-rarp-traffic
c039aa1f-62da-426a-8d05-0e6aa8a209f0 qemu-announce-self
626dac09-4aa6-4e19-9903-67ad19c35ead qemu-announce-self-rarp

The no-mac-spoofing looks like this:
<filter name='no-mac-spoofing' chain='mac' priority='-800'>
<rule action='return' direction='out' priority='500'>
<mac srcmacaddr='$MAC'/>
<rule action='drop' direction='out' priority='500'>

But I have no idea if that rule is applied.

Thanks for reply!

(Anders Sandblad) #4

Solved by using a bridge on the KVM host for the VM. Then I could use macvlan for the containers.