Because the docs do not give any explanation about the concept behind "shared-networks", a user might be tempted to create the following config:
(let's say untagged = normal network, vlan 100 = guest, vyos has separate interfaces in both, say one interface 10.1.1.1 and the one in vlan 100 is 10.100.1.1)
```
service {
dhcp-server {
shared-network-name my-dhcp-shared-network {
authoritative
subnet 10.1.0.0/16 {
description "normal"
option {
default-router 10.1.1.1
}
range 1 {
start 10.1.2.1
stop 10.1.255.254
}
subnet-id 1
}
subnet 10.100.0.0/16 {
description "guest"
option {
default-router 10.100.1.1
}
range 1 {
start 10.100.2.1
stop 10.100.255.254
}
subnet-id 100
}
}
}
```
Which will work fine for most situations.
Things get tricky when someone switches between the "normal" and "guest" network - kea will happily hand out a lease from the other subnet, leading to no connectivity.
This is also nasty to debug, because there is no obvious reason why the wrong ip is handed out.
If a user starts in the guest network, gets the IP 10.100.2.2, then switches to the internal network, VyOS / kea will give out the same IP 10.100.2.2 again, even though the user is in a different VLAN now. Because the default gateway is not reachable in the other VLAN, the user will not have connectivity.
VyOS seem to translate the 1:1 to kea-dhcp's "shared-networks", so the config above will look like this
```
"shared-networks": [
{
"name": "my-dhcp-shared-network",
"authoritative": true,
"subnet4": [
{
"id": 1,
"subnet": "10.1.0.0/16",
"pools": [ { "pool": "10.1.2.1 - 10.1.255.254" } ]
},
{
"id": 2,
"subnet": "10.100.0.0/16",
"pools": [ { "pool": "10.200.2.1 - 10.200.255.254" } ]
}
]
}
],
```
**in my experience, shared-networks are a rather uncommon config in kea, reserved for special cases. Is it really the best approach for VyOS?**
In any case, this behaviour should be clearly documented.
kea itself has a nice doc page:
https://kb.isc.org/docs/do-i-need-to-use-shared-networks-or-not-with-kea-dhcp
The most important bit that should be added to the docs, bold and red, in case the behaviour is not changes:
**unless classification is added, it's OK for a client to get an address from any subnet within the shared-network.**