Distributing a Static Route via DHCP with MikroTik RouterOS
Announce an IPv4 route to clients using DHCP option 121, encode the prefix and next hop correctly, preserve the default route, and test on Windows, Linux and macOS.
A local network workstation sometimes needs to reach a second subnet through a router that is not its Internet gateway. Adding the route manually on each computer works, but the configuration quickly becomes inconsistent: a new workstation forgotten, a laptop reinstalled, an old route kept, or a gateway modified without all clients being corrected.
DHCPv4 can distribute this information at the same time as the IP address, DNS, and gateway. Option 121, named Classless Static Route, carries one or more CIDR destinations with their next hop. RouterOS 7 allows building the binary value, associating it with a DHCP network, and, if necessary, also providing the Microsoft 249 option.
Scenario used in this guide
The main network is 192.168.88.0/24. The MikroTik 192.168.88.1 provides Internet access and DHCP. A second router, directly reachable at address 192.168.88.254, serves the remote site 10.20.30.0/24.
10.20.30.0/24 via 192.168.88.254, while the default route remains directed towards 192.168.88.1.The goal is to avoid the detour through the main gateway for intersite traffic. However, DHCP does not turn a device into a router: the next hop must be in a subnet directly accessible to the client, IP routing must be active on this next hop, and the return path must know 192.168.88.0/24.
1. Verify routing before touching DHCP
Work from the LAN, enable Safe Mode with Ctrl+X and export the configuration. The following commands allow you to identify the DHCP network and check the reachability of the second router.
/export file=avant-route-dhcp
/system backup save name=avant-route-dhcp
/ip address print
/ip dhcp-server print detail
/ip dhcp-server network print detail
/ping 192.168.88.254 count=4Temporarily add the route to the MikroTik only to test the path and the return. If the route already exists, do not create a duplicate.
/ip route add dst-address=10.20.30.0/24 \
gateway=192.168.88.254 \
comment="Remote site test"
/ping 10.20.30.1 count=4
/tool traceroute 10.20.30.1A response from the next hop, but no response from the remote site, generally indicates a forwarding, firewall, or return route problem. Fix it before distributing the route to the workstations. Otherwise, you will only be automating an incomplete configuration.
2. Understand the encoding of option 121
Each route contains three successive elements:
- the prefix length on one byte;
- only the significant bytes of the destination;
- the four bytes of the IPv4 address of the next hop.
For 10.20.30.0/24 via 192.168.88.254:
| Field | Value | Hexadecimal |
|---|---|---|
| Prefix length | /24 | 18 |
| Significant destination | 10.20.30 | 0A 14 1E |
| Next hop | 192.168.88.254 | C0 A8 58 FE |
The last byte of 10.20.30.0 is not transmitted for a prefix /24. The first route therefore becomes:
18 0A 14 1E C0 A8 58 FEThe default route 0.0.0.0/0 via 192.168.88.1 contains no destination bytes: it starts with 00, immediately followed by the four bytes of the gateway.
00 C0 A8 58 01By concatenating the two routes without spaces or colons, the complete value is:
0x180A141EC0A858FE00C0A858013. Create the standard option 121
RouterOS directly accepts a raw string preceded by 0x. The force=yes parameter, available in RouterOS 7 since branch 7.1, sends the option even if the client did not place it in its list of requested parameters.
/ip dhcp-server option
add name=route-site-distant-121 code=121 force=yes \
value=0x180A141EC0A858FE00C0A85801For a homogeneous and recent fleet, start with only option 121. It is standardized and replaces the old classful option 33, which cannot properly represent all CIDR prefixes.
4. Add the Microsoft 249 option if the fleet requires it
Microsoft documents option 249 with exactly the same format as option 121. It remains for compatibility with Windows clients and legacy environments. It is not a second encoding: the same binary sequence is used.
/ip dhcp-server option
add name=route-site-distant-249 code=249 force=yes \
value=0x180A141EC0A858FE00C0A85801Do not deploy it mechanically on all networks. Microsoft specifies that a server receiving a request for options 121 and 249 should respond with 121 only. RouterOS can be configured to force both; this strategy must therefore be validated on the Windows versions actually present. If all workstations correctly install the route with 121, 249 brings nothing.
5. Associate the options with the DHCP network
With only the standard option, associate it directly with the relevant network.
/ip dhcp-server network
set [find where address="192.168.88.0/24"] \
dhcp-option=route-site-distant-121
/ip dhcp-server network print detail \
where address="192.168.88.0/24"If the test fleet actually needs both codes, group them in an option set. First verify that another set is not already associated with the network: replacing it without an inventory could make PXE, VoIP, or Wi-Fi controller parameters disappear.
/ip dhcp-server option sets
add name=routes-lan \
options=route-site-distant-121,route-site-distant-249
/ip dhcp-server network
set [find where address="192.168.88.0/24"] \
dhcp-option="" dhcp-option-set=routes-lanThe options can also be assigned at the server level or to a specific lease. RouterOS applies a priority ranging from RADIUS to the lease, then to the server and finally to the network. For a route common to an entire subnet, the network level is the most readable.
6. Renew the lease without losing administrative access
An option added to the server is not instantly pushed to all devices. The client receives it at the next DHCP exchange. On a local workstation, disable and then re-enable the interface, or renew its lease.
# Windows — in a local administrator terminal
ipconfig /release
ipconfig /renew
# Linux with NetworkManager
nmcli connection down "LAN"
nmcli connection up "LAN"
# macOS — replace en0 if needed
sudo ipconfig set en0 DHCPDo not run a DHCP release across the remote connection you are using to administer the workstation: the session will be interrupted. On a critical server, wait for the normal renewal or plan for an independent console.
7. Verify the route on each client family
The presence of a lease does not prove that the system accepted the option. Check the routing table and the next hop actually chosen.
# Windows
route print 10.20.30.0
tracert -d 10.20.30.10
# Linux
ip route show
ip route get 10.20.30.10
traceroute -n 10.20.30.10
# macOS
netstat -rn -f inet
route -n get 10.20.30.10
traceroute -n 10.20.30.10The expected result is 192.168.88.254 for a destination 10.20.30.x and 192.168.88.1 for the Internet. Test both paths. A correct remote route accompanied by an Internet outage almost always indicates that the default route was forgotten in option 121.
On RouterOS, inspect the leases and capture the exchange if a workstation ignores the configuration.
/ip dhcp-server lease print detail
/tool sniffer quick interface=bridge \
ip-protocol=udp port=67,68
/log print where topics~"dhcp"In Wireshark, open the DHCP ACK and expand options 121 or 249. The capture allows you to distinguish a poorly encoded value, an option not sent, and a client that receives it but refuses to install it.
8. NAT, firewall, and return path
For routed communication between the two networks, the second router should normally not masquerade traffic coming from 192.168.88.0/24. It must know this network as directly connected or have a return route to it. The firewalls of both routers must then allow only the necessary flows.
Check in particular:
- IPv4 forwarding on router
192.168.88.254; - a return route from
10.20.30.0/24to192.168.88.0/24; - the absence of a too general
srcnat masqueraderule between the two LANs; - the
forwardrules in both directions and the local policies of the hosts; - a consistent MTU if the remote site crosses a tunnel.
Keep NAT at the Internet border, but avoid it between internal networks when real routing is possible. Routing preserves source addresses, simplifies logs, and allows precise security rules.
9. Security and limits
A route obtained via DHCP is a network control instruction. A rogue DHCP server can divert traffic to a hostile next hop. Isolate untrusted ports, enable DHCP snooping on manageable switches, limit authorized servers, and monitor unexpected DHCP offers.
Option 121 concerns IPv4 only. IPv6 uses other mechanisms, mainly Router Advertisements and, depending on the architecture, a routing protocol or managed configuration. Do not transpose the hexadecimal string to DHCPv6.
Finally, not all clients apply the received routes in the same way. A VPN, a security agent, an MDM profile, or an embedded network stack can add a more specific route, a different priority, or ignore the option. Deploy first on a representative test VLAN.
Troubleshooting
| Symptom | Likely cause | Verification |
|---|---|---|
| No new route | Old lease, option not sent, or incompatible client | Renew, capture the DHCP ACK, and test force=yes |
| Internet disappears | Route 0.0.0.0/0 missing from option 121 | Add 00 C0 A8 58 01 to the value |
| Windows ignores the route | Version or policy using code 249 | Test the same payload in 249 on a pilot VLAN |
| First hop responds, not the site | Forwarding, firewall, or return route missing | Trace in both directions and inspect counters |
Traffic still goes through .1 | Route missing, incorrect metric or prefix | Compare prefix lengths and the effective table |
| Only some devices fail | Incomplete DHCP support or priority VPN | Compare the capture and table of two clients |
| Remote network sees a single IP | NAT still active on the second router | Audit srcnat and create an inter-LAN exclusion |
Rollback
Remove the network association before deleting the objects. Clients will keep the route until renewal or expiration of their lease; then renew a pilot workstation and confirm the return to the previous table.
/ip dhcp-server network
set [find where address="192.168.88.0/24"] \
dhcp-option="" dhcp-option-set=""
/ip dhcp-server option sets
remove [find where name="routes-lan"]
/ip dhcp-server option
remove [find where name="route-site-distant-121"]
remove [find where name="route-site-distant-249"]Restore the options that existed before the guide if the network already used a custom set. Delete the test route from the MikroTik only if it was created for this procedure.
/ip route remove [find where comment="Remote site test"]Conclusion
DHCP option 121 avoids manually maintaining the same route on each workstation. Reliable configuration relies on four points: a directly reachable next hop, a valid return path, exact CIDR encoding, and the default route included in the payload.
Option 249 remains a compatibility tool, not a systematic replacement for 121. Test the actual behavior of clients, observe the DHCP ACK and the routing table, then extend the deployment gradually. A distributed route is only useful if it is both received, installed, and reversible.
Technical references
Read next
About the author
Jeremy Kraft runs the infrastructure and the self-hosted services of the IBCSC. These guides describe configurations that were actually deployed and re-checked before publication.
Discussion
Comments
No comment yet. Feel free to open the discussion with a question or your own experience.