Re: [Qemu-discuss] DHCP reply packet got dropped in bridged network

[Xingbo Wu]

Finally I found the solution to this issue.

Although it said that the RR bonding (the default) method does NOT require hardware support from the switch or router, a bridge over the bonding interface DOES require the hardware support to make the DHCP work.

The solution is simple:

Set LAG in the switch (mine is a netgear GS752TXS), put each two port in a lag group, that's simple. I didn't change the binding mode in the linux machine, but it works with the default "RR". The 802.3ad might be another choice, but I haven't tried it.

As I don't have any iptable rules, these iptable settings and even the sysctl settings are not required. Also, the "net.ipv4.ip_forward" is also NOT required.

In summary, to let you VMs running on a bridged network over binding interface with DHCP enabled --- vm-dhcp(br0(bond0(eth0,eth1))):

 (1) you need a switch with LAG configured.

 (2) simple bonding/bridge configuration (managed by netctl in my case).

 (3) no extra system settings if you don't use iptables, or proper filtering rules on your host's networking system.

On Thu, Nov 6, 2014 at 6:38 PM, Xingbo Wu <address@hidden> wrote:

It's been bothering me for days. Currently the setup is like this:

two physical machines: (1) VM host (2) dhcp server running dnsmasq. Both are running archlinux with linux-3.17.2

The host machine has two ethernet ports. a bonding interface is first set up and a bridge is built on the bonding interface. br0 ( bond0 (eth0 eth1)).

The bridge is configured to use dhcp and the host networking works well.

But when I attach VMs to this bridge, weird things began to happen. The guest uses kvm and virtio nic driver.

part of the parameters:

 -net bridge,br=br0 -net nic,model=virtio,macaddr=52:54:00:00:01:01

if I configure the guest to use static address, it works WELL. If it uses dhcp, it fails.

After some investigation, I tried to set net.ipv4.ip_forward=1, net.*bridge*tables=0, etc.. via sysctl -w, nothing changed, accepting some iptable rules.. But it still made no difference.

I tried to track the network packets with tcpdump. It shed some light on this:

the bridge got the dhcp reply packet from the dhcp server:

tcpdump -i br0 -vvv -ne '(port 67 or port 68)' on br0:

17:18:51.824369 00:1b:21:09:de:ab > 52:54:00:00:01:01, ethertype IPv4 (0x0800), length 375: (tos 0xc0, ttl 64, id 40531, offset 0, flags [none], proto UDP (17), length 361)

    10.0.0.1.67 > 10.1.1.1.68: [udp sum ok] BOOTP/DHCP, Reply, length 333, xid 0x2c6b7e75, secs 4, Flags [none] (0x0000)

 Your-IP 10.1.1.1

 Server-IP 10.0.0.1

 Client-Ethernet-Address 52:54:00:00:01:01

but on tap0, this packet never appeared, neigher in the VM.

the bridge is set up by netctl. the stp is off on the bridge, it shows a forwarding delay of 15. I can't set it to 0, the minimal valid value is about 2.0.

> brctl showstp br0

br0

 bridge id 8000.001517ac834c

 designated root 8000.001517ac834c

 root port   0 path cost   0

 max age  19.99 bridge max age  19.99

 hello time   1.99 bridge hello time   1.99

 forward delay  14.99 bridge forward delay  14.99

 ageing time 299.99

 hello timer   1.59 tcn timer   0.00

 topology change timer   0.00 gc timer  20.78

 flags

bond0 (1)

 port id 8001 state     forwarding

 designated root 8000.001517ac834c path cost 100

 designated bridge 8000.001517ac834c message age timer   0.00

 designated port 8001 forward delay timer   0.00

 designated cost   0 hold timer   0.59

 flags

tap0 (2)

 port id 8002 state     forwarding

 designated root 8000.001517ac834c path cost 100

 designated bridge 8000.001517ac834c message age timer   0.00

 designated port 8002 forward delay timer   0.00

 designated cost   0 hold timer   0.59

 flags

--

Cheers!
       吴兴博  Wu, Xingbo <address@hidden>

--

Cheers!
       吴兴博  Wu, Xingbo <address@hidden>