ip helper-address solves a boring but necessary problem: DHCP clients use broadcasts, and broadcasts do not cross routed boundaries. Put a helper address on the client VLAN’s Layer 3 interface and the router forwards the DHCP request to a central server. That lets one DHCP service support many subnets without putting a server in every VLAN.

The catch is that Cisco’s helper mechanism is broader than “relay DHCP.” On IOS and IOS XE platforms, configuring a helper address enables forwarding for a set of UDP broadcast services by default. That can include BOOTP/DHCP, DNS, TFTP, Time, NetBIOS, TACACS, and IEN-116 Name Service, depending on the platform and release. A router upgrade can also change how defaults appear in the running configuration.

The practical lesson is not “turn everything off except DHCP.” It is: inspect the actual forwarding policy, understand why each protocol is present, and make the smallest change that matches the network you operate.

What ip helper-address does

On an interface receiving client broadcasts, a helper address tells the router where to forward qualifying UDP broadcast packets. For DHCP, that means a client on VLAN 20 can broadcast a DHCPDISCOVER while the DHCP server lives on another subnet. The router relays the request to the configured server address and the reply returns through the relay path.

For a simple DHCP relay, the interface configuration looks familiar:

interface Vlan20
 description Client VLAN
 ip helper-address 10.20.30.40

The address should be the approved DHCP server or relay destination, not a casual directed broadcast address. If you configure multiple helpers for redundancy, confirm the server pair is designed for that lease model. Duplicate offers are normal protocol behavior; duplicate or inconsistent lease state is not.

Read Demystifying DHCP: A Network Engineer’s Guide for the DHCP exchange and relay model before using helper-address as a general network fix.

Why the default UDP forwarding list matters

The historical configuration advice to disable a long list of services was trying to avoid accidental broadcast relaying. The concern is real, but that copy-and-paste list is not a durable control. Cisco documents the current default-port set and platform behavior in its IOS XE IPv4 broadcast packet handling guide.

On one platform, a no ip forward-protocol udp entry may be visible in show running-config; on another, only non-default changes are visible. Some services may not exist on a given image. Applying a 2007-era list of negated protocol names can therefore produce noisy errors, hide useful defaults, and make later troubleshooting harder.

Start with evidence instead:

show ip interface Vlan20
show running-config | include ^ip forward-protocol
show running-config interface Vlan20

The interface output should show the helper address and the broadcast-forwarding state. The configuration output tells you which global exceptions were made. Consult the exact IOS XE command reference for the release on the device rather than assuming every default appears in every command output.

A safe way to narrow forwarding

First, write down the services that legitimately rely on broadcasts on that VLAN. DHCP is the common one. PXE can depend on DHCP options and sometimes other boot services; legacy monitoring or discovery software may use a UDP broadcast you did not expect. Test clients and owners before removing a forwarding path.

Then change one protocol at a time. Cisco exposes the global ip forward-protocol controls for this purpose. For example, a site that has confirmed it does not need broadcast TFTP forwarding can remove that protocol:

configure terminal
no ip forward-protocol udp tftp
end

Verify DHCP immediately after any change:

1. Release and renew a test client lease on the affected VLAN.
2. Confirm its address, gateway, DNS servers, and lease server are correct.
3. Check the DHCP server or relay logs for the request.
4. Confirm the removed protocol has no expected consumers.

If the goal truly is DHCP-only forwarding, do not assume the one command above has achieved it. Compare the platform’s documented default list with the running configuration and explicitly document the allowed set. On current systems, a short change record is far more useful than a wall of stale no commands.

DHCP has a special relationship to BOOTP

DHCPv4 uses the BOOTP transport model, which is why a helper address commonly handles DHCP without an additional per-port command. Do not remove BOOTP client or server forwarding just because the word “BOOTP” looks obsolete; test DHCP first. The router’s forwarding decision and the server’s DHCP policy are separate concerns.

If clients use DHCP Option 82, the helper-address configuration is only one link in the path. The upstream relay must also trust the controlled switch that inserted the relay information. See Allow DHCP Option 82 Through Cisco DHCP Relay Agents Safely.

Do not confuse helper forwarding with a security boundary

Restricting forwarded UDP broadcasts reduces unintended services crossing the relay boundary. It does not stop a rogue DHCP server on the local VLAN from answering clients before the router sees the packet. That is an access-switch problem: DHCP snooping, correct trusted ports, and related controls belong there.

Likewise, a helper address does not authenticate a DHCP server or verify that a server returned safe DNS or gateway options. It only forwards eligible broadcast traffic. Treat the DHCP server, relay routing, firewall policy, and switch enforcement as separate controls with separate failure modes.

A practical change and rollback plan

Before changing broadcast forwarding, capture the interface configuration, the current global forward-protocol configuration, DHCP server logs, and a successful test lease. Make one change in a maintenance window, test it, and keep the rollback equally narrow:

configure terminal
ip forward-protocol udp tftp
end

That restores the example TFTP forwarding setting. If DHCP itself fails, stop and restore the specific control you changed; do not compensate by adding helper addresses to random interfaces or disabling every access-layer protection.

The boring answer is the good one

Use ip helper-address to relay DHCP deliberately, then verify which other UDP broadcasts the platform forwards by default. Keep the services your network needs, remove only those you can prove are unnecessary, and test the lease flow after every change. That is safer than both extremes: blindly accepting every default or pasting a long obsolete deny list into a production router.

For more networking and systems notes, visit Slaptijack.