Comment 12 for bug 1244589

I did some testing that confirms what Ian is saying.
If the dhcp agent is running on the compute-node, then the dhcp tap and vm tap will be in the same linux bridge and there is a bad checksum:
    172.16.242.5.67 > 172.16.242.10.68: [bad udp cksum 0x3d93 -> 0xd1a6!] BOOTP/DHCP, Reply, length 328, xid 0x8ff2ab64, Flags [none] (0x0000)

Some dhcp clients don't care e.g. the one in trusty-server-cloudimg-amd64-disk1.img, but some do e.g. cirros-0.3.2-x86_64-uec.

If the dhcp agent is on a different machine than the compute node and the network type is vlan, then the bad udp checksum gets fixed by something (probably the physical nic on the sending side).

dhcp-node# tcpdump -vvv -enli em3 port 68
...
4:18:22.658000 fa:16:3e:20:4f:82 > fa:16:3e:4d:0b:89, ethertype 802.1Q (0x8100), length 374: vlan 242, p 0, ethertype IPv4, (tos 0xc0, ttl 64, id 13739, offset 0, flags [none], proto UDP (17), length 356)
    172.16.242.5.67 > 172.16.242.11.68: [bad udp cksum 0x3d94 -> 0x6780!] BOOTP/DHCP, Reply, length 328, xid 0x1b08771d, Flags [none] (0x0000)

compute-node# tcpdump -vvv -enli em3 port 68
...
14:17:54.834967 fa:16:3e:20:4f:82 > fa:16:3e:4d:0b:89, ethertype 802.1Q (0x8100), length 374: vlan 242, p 0, ethertype IPv4, (tos 0xc0, ttl 64, id 13739, offset 0, flags [none], proto UDP (17), length 356)
    172.16.242.5.67 > 172.16.242.11.68: [udp sum ok] BOOTP/DHCP, Reply, length 328, xid 0x1b08771d, Flags [none] (0x0000)

I don't know if a vxlan tunnel would do this fixing - doubt it.