I'm currently testing a 10 gig ethernet capable network setup with a DIY router running Kea for DHCP. I've not been able to replicate the circumstances where I'd caused this but during testing a raspberry pi (which does up to 100mbps) on my switch, I ended up having some unusual DHCP issues.
My network topology, for the moment looks a little like this
Aurora is my desktop - and I'm using the onboard gigabit to connect to my 'legacy' network (upstream internet) and the 10 gigabit router. Due to 10 gig interfaces having a lower metric it will always connect first The router has one 10 gig port connected to the upstream, and one to a switch to which client devices are connected. The PC has a reserved IP on the DHCP server and will always get the same IP based on the MAC address of the interface.
While I've not been able to replicate the issue - after plugging in a freshly set up raspberry pi, the entire 10gig network setup went down. At some point through working through the various components of the router it fixed itself. While I forgot to document the checks I did, the router was able to connect to the upstream through these troubles. My PC wasn't able to connect out to the internet or to the router, despite getting an IP from it.
While its a similar issue to this older post - I'm able to connect if I set my IP and default gateway manually. I didn't take screenshots but the router was able to connect out, there were no changes in the settings of the DHCP server (kea) or firewall
The Kea subnet block looks like this
"subnet4": [
{
// This defines the whole subnet. Kea will use this information to
// determine where the clients are connected. This is the whole
// subnet in your network.
// Subnet identifier should be unique for each subnet.
"id": 1,
// This is mandatory parameter for each subnet.
"subnet": "10.0.0.1/24",
// Pools define the actual part of your subnet that is governed
// by Kea. Technically this is optional parameter, but it's
// almost always needed for DHCP to do its job. If you omit it,
// clients won't be able to get addresses, unless there are
// host reservations defined for them.
"pools": [ { "pool": "10.0.0.51 - 10.0.0.200" } ],
// These are options that are subnet specific. In most cases,
// you need to define at least routers option, as without this
// option your clients will not be able to reach their default
// gateway and will not have Internet connectivity.
"option-data": [
{
// For each IPv4 subnet you most likely need to specify at
// least one router.
"name": "routers",
"data": "10.0.0.1"
}
],
The PC is on roughly as simple a reservation block as possible
{
"hw-address": "AA:BB:CC:DD:EE:FF",
"ip-address": "10.0.0.50"
},
The one odd thing out was this
Which resulted in any attempt to connect out failing as it was trying to connect to a non existent default gateway, and one that hadn't been configured anywhere. This doesn't have anything to do with routes at all. During previous experimentation I found out that you can't even set up 2 default gateways on a subnet intentionally - so this is unusual, I couldn't actually ssh into the router either via 10.0.0.1 and ended up using its upstream IP to test.
I was able to get the system running by setting a static IP with the correct default gateway - and subsequently the problem seemed to self resolved. During the period, I re-set the firewall settings and restarted DHCP, so I'm unsure what is the exact fix.
Why would a system get a non existent default gateway from DHCP, and how would one 'properly' fix that?
