Why Adding DHCP Option 121 Breaks Your Default Gateway (and How to Fix It)
July 17, 2026
If you’ve ever configured custom static routes on your router via DHCP, you might have run into a baffling issue: some devices pick up the new route perfectly, but suddenly lose their connection to the internet entirely. They simply ignore the standard default gateway.
This isn’t a bug in your router or your devices. It’s actually standard behavior defined by the internet protocol specifications.
Here is why it happens and exactly how to fix it—using MikroTik’s RouterOS as an example.
The Scenario
Imagine you have a standard network setup:
- Local Subnet: 192.168.88.0/24
- Default Gateway (Router): 192.168.88.1
- Target Subnet (VPN or another internal network): 10.10.0.0/16
You want all clients to automatically know that traffic destined for 10.10.0.0/16 should go through a specific internal gateway (let’s say your main router at 192.168.88.1). Instead of configuring this on every single PC, you use DHCP Option 121 (Classless Static Routes).
You convert the route to Hex format and apply it to your DHCP server:
Code snippet
/ip dhcp-server option
add code=121 name=static_route_10.10 value=0x100a0a192a85801
/ip dhcp-server network
add address=192.168.88.0/24 dhcp-option=static_route_10.10 gateway=192.168.88.1 dns-server=192.168.88.1
You reboot your clients. Some devices work perfectly. But suddenly, your Windows machines can access the 10.10.0.0/16 network but cannot open any websites on the internet. Their default gateway has completely vanished.
The "Why": Strict RFC 3442 Compliance
The culprit behind this behavior is RFC 3442, the official standards document that defines DHCP Option 121. The specification explicitly states:
“If the DHCP server returns both a Classless Static Routes option and a Router option, the DHCP client MUST ignore the Router option.”
In plain English: Option 121 completely overrides Option 3 (the standard Gateway field).
Operating systems like Microsoft Windows adhere strictly to this rule. The moment Windows sees Option 121 in the DHCP offer, it deletes the standard gateway you defined in the DHCP network settings and only applies the routes found inside Option 121. Other operating systems (like macOS or certain Linux distros) are more forgiving and keep both, which is why the bug doesn’t happen everywhere.
The Solution: Include the Default Route in Option 121
To fix this, you cannot rely on the standard DHCP gateway field anymore. You must explicitly include the default route (0.0.0.0/0) inside your Option 121 hex string alongside your custom route.
1. Breaking down the Hex string
- Let’s look at how the Hex value for Option 121 is built:
- Custom Route (10.10.0.0/16 via 192.168.88.1):
100a0a192a85801 10= Subnet mask /16 in Hex0a 0a= The network portion 10.10c0 a8 58 01= The gateway IP 192.168.88.1
- Custom Route (10.10.0.0/16 via 192.168.88.1):
- Default Route (0.0.0.0/0 via 192.168.88.1):
00c0a8580100= Subnet mask /0 in Hex (requires 0 bytes for the network destination)c0 a8 58 01= The gateway IP 192.168.88.1
2. Combining them
Simply append the default route Hex string to the end of your custom route Hex string:
0x100a0a192a85801+00c0a85801=0x100a0a192a8580100c0a85801
3. Applying the fix in RouterOS
Update your DHCP option with the combined string:
Code snippet
/ip dhcp-server option
set [find name=static_route_10.10] value=0x100a0a192a8580100c0a85801
(Note: Keep your standard gateway=192.168.88.1 configured in the DHCP network settings anyway, as older devices that don’t support Option 121 at all will still need it.)
Conclusion
Once the DHCP lease renews (or you unplug and replug the network cable), the affected clients will receive the new, combined Option 121. They will successfully implement your specific internal route and regain their default path to the outside world.
If you are deploying advanced routing via DHCP, always remember: If you touch Option 121, you become fully responsible for defining the default gateway!
No Comments yet »
RSS feed for comments on this post. TrackBack URI
Leave a comment
Powered by WordPress
Entries and comments feeds.
Valid XHTML and CSS.
46 queries. 0.056 seconds.