I have 3 subnets
192.168.10.0/24
192.168.103.0/24
192.168.2.0/24
Most of them can route to each other via static routes defined in their respective default gateways. However due to some interesting... hardware it is not possible to configure routes on the default gateway of 192.168.2.0/24
As a solution I decided t configure the isc-dhcpd on a debian machine to provide DHCP option 121 for its clients and tell them to add routes for the other two subnets to their routing table.
The configuration is basically as follows:
option classless-routes 24, 192, 168, 103, 192, 168, 2, 202, 24, 192, 168, 10, 192, 168, 2, 202, 0, 192, 168, 2, 1;
So far I could only test this with windows clients but since they are in use it has to work with them as well :D
This configuration works just fine.
However, thanks to the wonders of technology we have portable devices and it is possible for me to change from the subnet 192.168.2.0/24 to 192.168.103.0/24 without ever rebooting by just switching Wifi networks and a bit of walking ;)
I would have expected these routes to be deleted with the disuse of the DHCP lease by disconnecting the wifi connection. They remain however and of course now screw with my client once it is actually part of the 192.168.103.0/24 subnet.
As an idea I tried to also send option 121 in the 192.168.103.0/24 subnet hoping it would replace the ones already existing. However they just get added to the table and I end up with two different next hops for every subnet including my native subnet which clearly is very wrong.
Is there a way to tell the client to clear routes set by option 121? Did nobody just think about the possibility of clients changing subnets on the fly back in 2002 when this RFC was designed.
Any other solutions to get routing to work without a configurable default gateway?
