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 Hex
  • 0a 0a = The network portion 10.10
  • c0 a8 58 01 = The gateway IP 192.168.88.1
• Default Route (0.0.0.0/0 via 192.168.88.1): 00c0a85801
  • 00 = 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!