On 5/11/2020 8:25 PM, Joshua Schaeffer wrote:
On 5/11/20 4:10 PM, Brian Hechinger wrote:
It never gets to the switch in the first place. Watching tcpdump on
the dhcp server I only see the requests coming in but never sending
anything out.
That's what I figured but wanted to be sure.
Traceroute doesn't work oddly enough. It just times out.
That can be typical in some networks as a lot of firewalls drop ICMP
packets by default.
There is no firewall in place though. packet path for this traceroute
should be: vm -> switch -> other interface on same switch.
Something doesn't seem quite right here.
- How is Kea's interfaces-config map configured in kea-dhcp4.conf?
"interfaces-config": {
"interfaces": [ "*" ],
"dhcp-socket-type": "udp"
},
AFAIK everything looks fine. Can't give you an definitive answer as to
why when Kea sends a packet the OS thinks the host has no route:
- Could be a firewall or security context issue. Check IPTables,
AppArmor, SELinux, etc.
None of those are running, no.
- As a test you could try changing to raw sockets (remove
"dhcp-socket-type": "udp"). If that does work I'm not sure why it
would as it's a relayed request.
Didn't make a different.
- Force Kea to use the kernel routing table by adding
"outbound-interface": "use-routing" to the configuration (after
re-adding "dhcp-socket-type": "udp" back to the config).
Now it silently fails. Kea *thinks* it sent the packet but it never goes
anywhere.
I'm going to dig into this weird networking that's going on here because
I'm starting to think it's definitely not Kea who is to blame here.
-brian
_______________________________________________
Kea-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-users
