With the ubiquity of wireless routers follow a surprising network instability issue. It turns out that wireless routers at many of the 330 apartments connected to network where I live bring with them rogue DHCP servers that make the network unstable.
Non-authoritative DHCP servers on the network have posed a challenge for years. At first, I attributed the DHCP servers to badly configured Windows machines. However, the number of DHCP servers suggested that another explanation might be closer to the truth. Users accidentally installing DHCP servers are just not that common, and inspecting a couple of machines in question they were acquitted. What else could be the source of the DHCP traffic, then? Common to the machines were that wireless routers sat between them and the LAN.
After much investigation, it turns out that a lot, if not all, wireless routers expose their DHCP server on all ports of the router, when it’s only necessary to expose it on inward-facing ports. I guess vendors don’t bother limiting the exposure because generally it’s of no concern to consumers. ISPs provide the wireless router with the necessary configuration parameters (IP address, subnet mask, default gateway, DNS servers, and so on) in addition to blocking DHCP traffic originating from the wireless router.
On our network — equipped with eight aging 48-port Cisco Catalyst 3500 XL switches — DHCP traffic cannot be prevented from escaping the wireless router and making its way into the switches and onto LAN. The configuration parameters of rogue DHCP servers, intended for internal use only, are transmitted to external DHCP clients. Clients for which the supplied gateway, DNS server, and so on are only internally available. The DHCP client, unable to discern the rogue servers from the authoritative one, passes the parameters on to the network stack, setting itself up for network disconnectivity.
The essence of the issue is that whenever a client requests configuration parameters, it, by definition of the DHCP protocol, broadcasts a message to be picked up by any DHCP server on the network. The client then awaits an offering of configuration parameters from one or more DHCP servers. Then, still according to specification, the DHCP client may use any strategy to accept one of several offerings. I can only guess as to how Windows makes its decision, but randomness and first responder probably play a key role. In any event, Windows may keep accepting offerings from rogue DHCP servers regardless of the number of times I command the IP configuration to “ipconfig /release” and “ipconfig /renew”.
How to counteract rogue DHCP servers? There’re only a limited set of options: hard-coding the configuration parameters of individual machines, establishing VLANs so computers become invisible to each other, or replacing the Cisco Catalyst 3500 switches with contemporary switches that are able to suppress DHCP traffic travelling the wrong way.