DHCP and VLANs from the server side

Why this matters

Servers are usually on the receiving end of DHCP and VLANs, but in Server+ they are often the provider. A Windows or Linux server is commonly the DHCP server for the whole organisation, and a virtualisation host or a busy server often sits on several VLANs at once. When either is misconfigured, the effects reach every client on the network: machines that cannot get an address, or a server that is plugged in, powered on and unreachable.

This lesson covers running DHCP well, serving subnets beyond the server's own, how VLANs divide a network, connecting a server to more than one of them, and making DHCP redundant without creating the duplicate addresses it exists to prevent.

The lesson

Scopes, reservations, options and lease times

A client that needs an address broadcasts a request, and a DHCP server answers in a four-step exchange usually remembered as DORA: Discover, Offer, Request, Acknowledge. DHCP servers listen on UDP port 67 and clients on port 68.

The DHCP server's configuration is organised by scope, one per subnet it serves:

• The address range it may hand out, with exclusions carved out for devices that have static addresses, so DHCP never offers an address already in use.
• Reservations, which always give a particular device, identified by its MAC address, the same address, as the previous lesson described for servers.
• Options, the extra settings delivered with each address. The ones to know are option 3 (router, the default gateway), 6 (DNS servers) and 15 (the DNS domain name), plus options 66 and 67, which point PXE clients at a boot server and boot file.
• The lease time, how long a client may keep its address. Clients try to renew halfway through the lease. Short leases suit networks where devices come and go, such as guest wireless, so addresses are recycled quickly; longer leases suit stable networks and reduce DHCP traffic.

When every address in a scope is leased, the scope is exhausted, and new clients get no address at all. They typically fall back to a self-assigned 169.254 address, which is one of the most common clues in DHCP troubleshooting.

DHCP relay, and serving subnets the server is not on

DHCP starts with a broadcast, and routers do not forward broadcasts. So a DHCP server can only hear clients on its own subnet unless something carries their requests across.

That something is a DHCP relay agent, usually configured on the router or layer 3 switch that serves as each subnet's gateway, often under the name IP helper. The relay picks up the client's broadcast and forwards it as an ordinary unicast message to the DHCP server's address, recording which subnet it came from. The DHCP server uses that information to choose the right scope and hands the offer back through the relay.

With relays in place, one pair of DHCP servers can serve every subnet in an organisation. Without them, a scope configured for a remote subnet simply never receives a request, and its clients never get an address.

VLANs, tagged and untagged ports, and trunks

A VLAN (virtual local area network) divides one physical switched network into separate logical networks. Devices in different VLANs cannot talk to each other directly, even on the same switch; traffic between VLANs has to pass through a router or layer 3 switch, where it can be controlled. VLANs are used to separate servers from users, voice from data, or management networks from everything else, and they keep broadcast traffic confined to each segment.

Switch ports work in two modes:

• An access port belongs to a single VLAN. Traffic on it is untagged, and the connected device does not know VLANs exist.
• A trunk port carries several VLANs at once. Each frame carries an 802.1Q tag, which includes the VLAN ID, so both ends know which VLAN it belongs to. One VLAN on a trunk can be left untagged, the native VLAN.

Trunks normally connect switches to each other and to routers. They also connect servers that need to be on more than one VLAN.

Putting a server on a VLAN through a tagged NIC

A server that needs presence on several VLANs, such as a virtualisation host whose guests live on different networks, connects through a trunk port and handles the tags itself.

• On Linux, the server creates a VLAN interface on top of the physical adapter for each VLAN, each with its own address.
• On Windows, a VLAN ID can be set on an adapter or on a NIC team interface.
• On a hypervisor, the virtual switch assigns a VLAN ID to each virtual machine's network adapter, so each guest lands on the right network without knowing anything about tags.

Both ends must agree, and the mismatches are a classic cause of a server that is up and unreachable:

• the server sends tagged frames into an access port, which is not expecting them;
• the server and the switch port use different VLAN IDs, or the VLAN is not in the trunk's allowed list;
• the two ends disagree about the native VLAN.

When a server's link lights are on, its address looks right and it still cannot reach anything, check the switch port's mode and VLAN configuration before anything else.

Redundant DHCP without two servers handing out the same address

DHCP is essential, so a single DHCP server is a single point of failure. But two DHCP servers must never hand out addresses from the same pool without coordinating, or both will offer the same address to different clients and create conflicts.

There are two standard approaches:

• A split scope divides each subnet's range between two servers so they never overlap. The traditional split is 80/20: the main server holds 80 per cent of the addresses and the second holds 20 per cent, enough to keep the network running while the main server is repaired.
• DHCP failover, supported by Windows Server and by other modern DHCP servers, lets two servers share one scope and synchronise their leases, so each knows what the other has handed out. It runs either in load-balance mode, with both answering, or hot-standby mode, with the second taking over only when the first fails.

The opposite problem is a rogue DHCP server: an unauthorised device, or a misconfigured lab machine, answering requests with wrong addresses. This is the danger the lab lesson warned about when it said to keep the lab network isolated. Switches defend against it with DHCP snooping, which only allows DHCP offers from ports that are trusted.