Cisco IP Helper-Address: DHCP Relay Configuration

When every VLAN has its own DHCP scope you end up managing dozens of pools, one on each router and switch, and every address change has to be made in a dozen places. The cleaner design is one central DHCP server - Windows, Linux, or a pair of appliances - with the switches and routers relaying client broadcasts to it. On Cisco IOS and IOS XE the relay is configured with a single command per VLAN interface: ip helper-address. It is a one-liner that hides a surprising amount of behaviour, because the same keyword controls a whole list of UDP services beyond DHCP. This article explains what helper-address actually forwards, how to configure it for one or many servers, how to scope it to just DHCP, and how to verify that clients are getting addresses through the relay.

What ip helper-address Does

DHCP clients start with no IP address, so their first message - the DISCOVER - is a broadcast to 255.255.255.255 that a router will not forward by default. ip helper-address turns the interface into a UDP broadcast relay agent: it receives the broadcast, converts it into a unicast packet addressed to the configured server, and forwards it. Because it is a relay, the router inserts its own interface address into the packet's giaddr field, which is how the server knows which scope to answer from.

By default ip helper-address also relays several other UDP services (TFTP, DNS, TACACS, time, NetBIOS and a few more). The default forward list is what surprises people: enabling a DHCP helper on a user VLAN can suddenly start forwarding NetBIOS name broadcasts to a server across the WAN, which is rarely wanted. In most deployments you only want DHCP; disable the extra services with no ip forward-protocol udp <port> for each one you want to suppress. The relevant default ports are 69 (TFTP), 53 (DNS), 37 (time), 49 (TACACS), and 137/138 (NetBIOS).

Router(config)# no ip forward-protocol udp tftp
Router(config)# no ip forward-protocol udp domain
Router(config)# no ip forward-protocol udp netbios-ns
Router(config)# no ip forward-protocol udp netbios-dgm
Router(config)# ip forward-protocol udp bootps

Leaving the forward list minimal is good hygiene: it reduces cross-subnet chatter and removes a class of accidental traffic forwarding that security teams dislike.

Configuration

Clients live in VLAN 20 (192.168.20.0/24) and the DHCP server is 10.55.11.3 in VLAN 10. On the Layer 3 interface of VLAN 20, point the helper at the server:

Router# configure terminal
Router(config)# interface vlan 20
Router(config-if)# ip address 192.168.20.1 255.255.255.0
Router(config-if)# ip helper-address 10.55.11.3
Router(config-if)# exit
Router(config)# no ip forward-protocol udp tftp
Router(config)# no ip forward-protocol udp domain
Router(config)# end

Add the same command on every VLAN interface whose clients should use the central server. The helper must be configured on the interface that receives the client broadcast - the client-facing SVI - not on the interface that faces the server. Pointing it the wrong way is one of the most common mistakes: the command is accepted, no error is shown, and clients simply never get an address. To relay to multiple servers (for redundancy or split scopes), configure several helper addresses on one interface; the router forwards the client's request to each of them and the client takes the first OFFER it receives.

Router(config-if)# ip helper-address 10.55.11.3
Router(config-if)# ip helper-address 10.55.11.4

If the DHCP server is reachable only over a specific path, you can combine the helper with a route or with policy routing, but the helper itself always uses the normal routing table to reach the server address.

Relay Agent Information (Option 82)

When the server needs to know which VLAN, switch or port a client came from, enable option-82 insertion on the relay interface so the giaddr and option 82 identify the source circuit. This is what allows a single flat scope to serve many sites with per-port address assignment, and it is essential in carrier and campus networks where the server must distinguish hundreds of access ports:

Router(config)# interface vlan 20
Router(config-if)# ip dhcp relay information option
Router(config-if)# end

On Nexus NX-OS the equivalent is ip dhcp relay information option plus ip dhcp relay information option vpn for VRFs; IOS XE Catalyst switches use the same ip helper-address on SVIs. Option 82 also lets the server trust or reject a request based on the receiving circuit, which is why it is central to DHCP snooping designs. Note that some servers strip or reject option 82 by default - check your server's "remote-id" handling before blaming the network.

Verification and Troubleshooting

show ip interface vlan 20 | include Helper
show ip dhcp relay
debug ip dhcp server packet
debug ip udp

Confirm the helper address is listed on the SVI, then watch debug ip dhcp while a client requests an address: the relay should show the DISCOVER arriving on VLAN 20, being forwarded to 10.55.11.3, and the OFFER coming back. If you see the DISCOVER but no OFFER, the problem is on the server side or in the return path; if you see nothing at all, the client broadcast is not reaching the SVI. Common failures: helper-address on the wrong interface (it must be the client-facing SVI), an ACL blocking UDP 67/68 between relay and server, the server's scope not matching the giaddr subnet, or the relay interface having no IP. Also check that the VLAN is actually up and that the client is in the right broadcast domain.

DHCP relay is the routing-side companion to the access-layer protections in our DHCP snooping guide; the SVI design it depends on is in Cisco inter-VLAN routing. If you also run a DHCP server on the router itself, the pool side is covered in our Cisco IOS DHCP server guide.

Design Notes and Best Practices

• One helper per client subnet minimum, two for redundancy. A single server address is a single point of failure for every VLAN that points at it.
• Keep the DHCP server close to the relay. Every broadcast becomes a unicast to the server, so a WAN round trip adds latency to every client boot.
• Do not enable the helper on uplinks. It belongs on the client-facing SVI only; on an uplink it can relay irrelevant broadcasts.
• Document which VLAN uses which scope. The server decides based on giaddr, so the mapping must be intentional.
• Pair with snooping. A rogue DHCP server on a user port can hand out bogus gateways; snooping stops it.

Running the Relay in VRFs and on Nexus

In a multi-tenant or segmented design the DHCP server often lives in a management VRF while clients are in user VRFs, so the helper has to be configured per VRF rather than globally. On IOS XE you attach the helper inside the VRF-aware SVI and make sure the server address is reachable through the correct routing table; if the server has an address in a different VRF, as is common in a firewall-in-the-middle design, you need route leaking or a dedicated transit VLAN. On Nexus NX-OS the syntax is similar but the relay is configured per interface with ip dhcp relay address, and VRFs each carry their own relay configuration. The conceptual rule is the same on every platform: the relay must be able to route to the server, and the server must be able to route back to the giaddr.

Security and Scale Considerations

Relaying DHCP across a routed network is convenient but it concentrates risk: one server becomes the single source of addressing for every VLAN, so losing it stops client onboarding everywhere. Configure two helper addresses on each SVI so that a second server can answer if the first is down, and keep the two servers' scopes synchronised either by splitting the range or by a native failover feature. On the security side, remember that a relayed DHCP request is a unicast packet that carries no authentication by default; DHCP snooping on the access layer, option 82 trust rules, and a strict ACL between the relay and the server are what keep a rogue client from claiming addresses it should not. Rate-limit DHCP on access ports so that a single misbehaving device cannot flood the server.

Alternatives: When Not to Centralise DHCP

A central server is the right answer for most campus and enterprise networks, but it is not universal. Very small branches with a single VLAN are often simpler to serve with the router's own DHCP pool, which removes a dependency on the WAN link for client onboarding. Networks with strict segmentation may prefer a per-site server so that address data never crosses a trust boundary. And in highly dynamic environments - container platforms, virtualisation clusters - IPAM tooling and DHCP may both be replaced by orchestration that assigns addresses programmatically. The decision is really about where you want the single point of failure to sit, and how much WAN dependency you can tolerate during a branch link outage. Whichever model you pick, document it, because the next engineer to add a VLAN needs to know whether to create a scope or add a helper line.

A Minimal End-to-End Checklist

When a new VLAN goes live and clients should get addresses from the central server, work through the same five items every time. First, confirm the SVI exists and has the correct gateway address. Second, add ip helper-address pointing at the server (or both servers). Third, verify the server has a scope whose subnet matches the SVI's address. Fourth, confirm routing exists in both directions between the relay and the server. Fifth, test with a client and watch the relay's debug output for the DISCOVER/OFFER exchange. Doing this in a fixed order turns a vague "DHCP is broken" complaint into a short, deterministic checklist that anyone on the team can run.

原文链接：https://www.cisco.com/en/US/docs/ios/12_4t/ip_addr/configuration/guide/htdhcpre.html