External DHCP not getting to guests

[cscracker]

I've configured my system with a bridge. I have a DHCP server on the local network, and I want guests to pick up DHCP from it. However, the DHCP is not being forwarded on to the guest.

It gets through to the bridge interface.

root@pve1:~# tcpdump -ni vmbr0 port 67 or port 68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vmbr0, link-type EN10MB (Ethernet), capture size 65535 bytes
21:45:05.368257 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from e6:ab:50:ad:8a:d6, length 387
21:45:05.368303 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from e6:ab:50:ad:8a:d6, length 387
21:45:05.368740 IP 192.168.1.1.67 > 192.168.1.167.68: BOOTP/DHCP, Reply, length 300
21:45:06.358140 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from e6:ab:50:ad:8a:d6, length 387
21:45:06.358183 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from e6:ab:50:ad:8a:d6, length 387
21:45:06.358599 IP 192.168.1.1.67 > 192.168.1.167.68: BOOTP/DHCP, Reply, length 300
21:45:08.332625 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from e6:ab:50:ad:8a:d6, length 387
21:45:08.332671 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from e6:ab:50:ad:8a:d6, length 387
21:45:08.333096 IP 192.168.1.1.67 > 192.168.1.167.68: BOOTP/DHCP, Reply, length 300
21:45:12.290124 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from e6:ab:50:ad:8a:d6, length 387
21:45:12.290167 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from e6:ab:50:ad:8a:d6, length 387
21:45:12.290586 IP 192.168.1.1.67 > 192.168.1.167.68: BOOTP/DHCP, Reply, length 300

It doesn't get to the tap interface.

root@pve1:~# tcpdump -ni tap100i0 port 67 or port 68
tcpdump: WARNING: tap100i0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap100i0, link-type EN10MB (Ethernet), capture size 65535 bytes
22:18:01.574322 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from e6:ab:50:ad:8a:d6, length 387
22:18:01.574379 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from e6:ab:50:ad:8a:d6, length 387
22:18:02.562958 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from e6:ab:50:ad:8a:d6, length 387
22:18:02.563013 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from e6:ab:50:ad:8a:d6, length 387
22:18:04.540882 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from e6:ab:50:ad:8a:d6, length 387
22:18:04.540935 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from e6:ab:50:ad:8a:d6, length 387
22:18:08.494840 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from e6:ab:50:ad:8a:d6, length 387
22:18:08.494902 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from e6:ab:50:ad:8a:d6, length 387

I have tried turning the firewall on and off, adding accept rules, and changing the enable DHCP, enable firewall, and MAC filter settings, and it makes no difference. I have another KVM host (not proxmox) where this same setup works perfectly, so I know the technology is capable and the rest of the network is configured correctly, it must be something on the proxmox hosts. What else can I check?

 

[dietmar]

works here.

 

[cscracker]

I've done more testing, I was able to boot from a CD and test with a static configuration, and my networking works, I can ping and curl google.com no problem, it's only DHCP which won't go through, and it has me stumped.

 

[cscracker]

Finally figured it out after beating my head against the wall. Turns out one of my switches is throwing a fit over the balance-alb bonding mode, so even though the traffic was getting through it wasn't addressed properly. Good news is it's not a Proxmox problem, and after shutting down one of the bonded interfaces on each node, everything works properly. I'll have to implement a different bonding mode, going to try 802.3ad.

Issue resolved!

 

[albert_a]

Thank you cscracker for posting this, you saved me a lot of time!
I had the similar issue. My pve servers are connected to LAN via active-backup bonds. But the switch they're connected to does not support bonding. Everything worked except DHCP. The DHCP communication was:
dhcp_client_vm_on_pve1 -> pve1 -> switch -> pve2 -> dhcp_server_vm_on_pve2 -> pve2 -> switch -> pve1 -XXX-> dhcp_client_vm_on_pve1
XXX - is where the communication is broken, according to dhcpdump.

The solution was to write simple script that turns down secondary slave in a bond when primary slave is active and turns it up when primary goes down via commands:

ip link set down dev lan0p2​

ip link set up dev lan0p2​

So only one active slave in the bond is up at a time. But redundancy is preserved.