A city public-works campus uses centralized DHCP servers while dual distribution switches run HSRP for access VLANs. How should DHCP relay typically be designed?
Select an answer to reveal the explanation.
Short Explanation
DHCP Discovers are shy—they broadcast on the VLAN and need a relay at the gateway to reach central servers. Put helpers on the SVI/FHRP gateway and mind which HSRP peer is active so offers still land. Standing up DHCP only on the standby is a recipe for silent leases.
Full Explanation
Public-works campuses with centralized DHCP and HSRP on distribution SVIs should place DHCP relay (helpers) on the gateway SVI with HSRP-aware considerations so the active first hop forwards client Discovers correctly. Relay belongs on the L3 gateway for the client subnet, and FHRP design must ensure the active forwarder—and any anycast/helper behaviors—keep lease acquisition working during failover.
Enabling the DHCP server only on the HSRP standby and disabling relay everywhere breaks the active path clients actually use. Configuring ip helper only on access switches toward broadcast domains that already contain the DHCP server is unnecessary or wrong when the server is centralized off-segment. Replacing DHCP with static addressing on every SCADA host avoids relay but does not answer how relay should be designed with HSRP.
Exam caveat: some designs use HSRP address as the relay source or rely on specific helper redundancy features—verify platform behavior rather than assuming any standby answers DHCP. Operational check: place helpers on the SVI, boot a client before and after HSRP failover, and confirm Discover/Offer completes via the active gateway path. Public-works acceptance tests must include DHCP renew across HSRP failover, not only initial boot, because lease refresh often exposes relay gaps.