skip to content

After a DHCPv4 scope adds option 121 with a single route to 10.20.0.0/16, newer clients lose their default route while older ones keep it; why?

level: seniorimportance: should knowfreq 15%

answer

  1. two ways to send routes
  2. one option overrides the other
  3. RFC 3442 client rule
  4. default route as a zero-width descriptor

basics

~20 s

RFC 3442 says a DHCPv4 client that supports option 121 must ignore option 3 when both arrive. Newer clients install only the one listed route and no default; older clients ignore 121 and keep option 3. Put 0.0.0.0/0 inside option 121 too.

solid answer

~40 s

Option 121, Classless Static Route (RFC 3442), and option 3, Router, can both supply routes, and RFC 3442 settles the conflict: a client that supports option 121 **MUST ignore the Router option** when the server sends both. So the newer clients install only `10.20.0.0/16` and end up with no default route, while older clients, which RFC 3442 requires to ignore an option they do not support, keep using option 3 and work. The fix is to carry the default route inside option 121 as well, encoded as a destination of width 0 followed by the gateway, and keep option 3 for clients that do not understand 121. RFC 3442 tells administrators to configure exactly that, and a server SHOULD then leave option 3 out of replies to clients that requested option 121.

go deeper

for a junior

Recall that option 3 gives the default gateway and option 121 gives a list of routes, and that the two can conflict.

for a middle

Explain the RFC 3442 rule that a client supporting 121 ignores option 3, and encode a destination as a width octet plus its significant octets.

for a senior

Diagnose the split fleet: clients that support 121 lose the default route, older ones do not. Fix it by putting 0.0.0.0/0 in 121 and keeping option 3 for old clients.

for a principal

Weigh pushing routes by DHCP against routing them on the gateway: per-host routes spread routing policy across every lease, while a single gateway keeps it in one place.

## Two options that both install routes A DHCPv4 server has three ways to hand a client routes: | Option | Defined in | Carries | Default route? | |---|---|---|---| | 3, Router | RFC 2132 §3.5 | A list of gateway addresses for the client's subnet | Yes, that is its job | | 33, Static Route | RFC 2132 §5.8 | Destination and router pairs, **classful** only | No: RFC 2132 calls 0.0.0.0 an illegal destination | | 121, Classless Static Route | RFC 3442 | Destination prefixes of any length, each with a router | Yes, as a zero-width destination | RFC 3442 says option 121 **obsoletes option 33**: option 33 can only install classful routes, whose mask is implied by the address class, so it cannot describe a `/22` or a `/25`. ## The rule that caused the outage RFC 3442's client section is short and strict: - A client that does **not** support option 121 MUST ignore it. - A client that **does** support it MUST install its routes. - If the server returns **both option 121 and option 3, the client MUST ignore option 3**. Likewise, option 33 is ignored when 121 is present. - A client that sends a parameter request list MUST request both 121 and 3, with 121 listed first. So in the scenario the scope still sends option 3 = `192.168.10.1` and now adds option 121 with one entry, `10.20.0.0/16` via `192.168.10.254`. A client that understands 121 throws option 3 away and installs a single route; with no default route, everything outside `10.20.0.0/16` and its own subnet becomes unreachable. A client that does not understand 121 ignores it, uses option 3 and carries on, which is why the problem looks random across a fleet. ## Encoding a route in option 121 Each route is a **destination descriptor** followed by a four-octet router address. The descriptor is one octet giving the prefix length (the mask width), then only the **significant octets** of the subnet number, that is the width divided by 8, rounded up: | Mask width | Significant octets | |---|---| | 0 | 0 | | 1-8 | 1 | | 9-16 | 2 | | 17-24 | 3 | | 25-32 | 4 | The corrected option carries two routes: | Route | Descriptor | Router | Octets | |---|---|---|---| | `10.20.0.0/16` | `16.10.20` | `192.168.10.254` | 3 + 4 = 7 | | `0.0.0.0/0` (default) | `0` | `192.168.10.1` | 1 + 4 = 5 | That is 12 octets of value, so on the wire the option reads `79 0C 10 0A 14 C0 A8 0A FE 00 C0 A8 0A 01` (code `0x79` = 121, length `0x0C` = 12). Three further rules apply when reading it: 1. **Host bits are zeroed.** The client must AND the subnet number with the mask, so a descriptor with stray host bits still installs the network route. 2. **Router `0.0.0.0` means on-link.** RFC 3442 lets a server describe another subnet on the same link with router `0.0.0.0`; the client reaches it directly, and a stack that cannot do that must ignore those entries. 3. **Size.** A long route list may exceed 255 octets, so option 121 is a concatenation-requiring option in RFC 3396's terms, and RFC 3442 says clients SHOULD send option 57 to accept messages larger than 576 octets. ## The operator's fix RFC 3442's section on server administrator responsibilities gives the configuration: - Send **both** option 3 and option 121, and list the default router(s) in **both**, because many clients do not implement 121. - When a client requested option 121 and the server is sending it, the server **SHOULD NOT** also include option 3 or 33. With that in place, every client gets a default route whichever option it honours. Before adding any 121 entry, check that the default route is in it; the incident pattern is always a list built for one extra network that forgot the gateway everyone else depends on. ## What making option 121 authoritative costs Because a client that supports option 121 ignores option 3, option 121 becomes the **only** source of routes for those clients, so the default route has to be stated in it explicitly. The administrator gets one place to describe a modern client's whole routing table, and pays for it with this trap whenever option 121 is treated as an add-on to option 3 instead of a replacement for it.

  • How is the route 10.0.0.0/8 via 192.168.10.254 encoded in DHCPv4 option 121?
    The descriptor is the width octet 8 followed by one significant octet, 10, because a width of 1 to 8 needs one octet. Then the router follows as four octets, giving `08 0A C0 A8 0A FE`, six octets for that route.
  • Why can option 33 not fix the scenario instead of option 121?
    DHCPv4 option 33 carries classful destinations only, so it cannot express an arbitrary prefix length, and RFC 2132 makes 0.0.0.0 an illegal destination in it. RFC 3442 also has a client that supports option 121 ignore option 33 when both arrive, and it describes 121 as obsoleting 33.

saying these in an interview costs you the question

  • Option 121 routes are added on top of the default route from option 3.
  • Option 121 cannot carry a default route, so option 3 must always supply it.
  • Option 33 already handles classless prefixes, so option 121 is redundant.
  • A router address of 0.0.0.0 in option 121 tells the client to drop that traffic.
  • The client installs a descriptor's subnet bits exactly as sent, host bits included.