2.4 Host IP Addressing and DHCP Relay Operations

For endpoints to communicate beyond their local Layer 2 broadcast domain, they require valid Layer 3 Internet Protocol (IP) configurations. Every host operating on an enterprise campus network requires a valid IP address, a subnet mask, a default gateway address, and one or more Domain Name System (DNS) server addresses.

While critical servers and network management interfaces use statically configured addresses, configuring thousands of user laptops, smartphones, IP phones, and IoT endpoints manually is completely unscalable. Enterprise networks rely on the Dynamic Host Configuration Protocol (DHCP) to automate IP assignment. In segmented campus networks where clients reside in separate VLANs isolated from centralized enterprise DHCP servers, the DHCP Relay Agent (ip helper-address) plays an indispensable bridging role.

---

IPv4 Host Addressing Principles and Network Boundaries

An IPv4 address is a 32-bit binary number traditionally written in dotted-decimal format as four 8-bit octets separated by periods (e.g., 192.168.10.50).

The Anatomy of an IPv4 Address

Every IPv4 address is divided into two distinct components:

1. Network Portion (Prefix): Identifies the specific Layer 3 logical network or subnet. All hosts residing on the same physical or virtual broadcast domain share the identical network portion.
2. Host Portion: Uniquely distinguishes an individual interface within that specific subnet.

The boundary between the network portion and host portion is determined by the Subnet Mask, expressed in standard dotted-decimal notation (e.g., 255.255.255.0) or Classless Inter-Domain Routing (CIDR) prefix notation (e.g., /24).

Common Subnet Masks in Enterprise Campus Networks

Important Addressing Rule: In every subnet from /0 through /30, two addresses are reserved and cannot be assigned to hosts (only /31 point-to-point links and /32 host routes are exceptions):

• Network Address: All host bits set to binary 0 (e.g., 10.1.10.0 in a /24). Represents the subnet itself.
• Directed Broadcast Address: All host bits set to binary 1 (e.g., 10.1.10.255 in a /24). Targets all hosts within that specific subnet simultaneously.

The Host Configuration Quartet

To communicate fully across an enterprise intranet and the global Internet, a client operating system requires four configuration values:

1. IP Address: A unique unicast address within the local subnet.
2. Subnet Mask: Defines which destination IPs are local (reached directly via Layer 2 ARP) versus remote.
3. Default Gateway: The IP address of the local Layer 3 router interface or Switched Virtual Interface (SVI). When a host needs to communicate with an IP address outside its local subnet, it encapsulates the IP packet into a Layer 2 frame addressed to the default gateway's MAC address.
4. DNS Servers: The IP addresses of recursive name servers that resolve human-readable domain names (e.g., portal.company.com) into routable IP addresses.

Automatic Private IP Addressing (APIPA)

When a client device configured for dynamic addressing boots up, it issues DHCP Discover requests. If no DHCP server responds within a timeout window (typically 30 to 60 seconds), the client operating system falls back to Automatic Private IP Addressing (APIPA), formalized in RFC 3927:

• Address Block: 169.254.0.0/16 (specifically 169.254.1.0 through 169.254.254.255, reserving the first and last 256 addresses for future use).
• Link-Local Scope: APIPA addresses are strictly link-local. Routers and Layer 3 switches must never forward packets containing 169.254.x.x addresses across network boundaries.
• Collision Detection: The host generates a pseudo-random host address within 169.254.0.0/16 and transmits gratuitous Address Resolution Protocol (ARP) probes onto the local wire. If another device replies, the host generates a different address until uniqueness is verified.
• Troubleshooting Significance: Seeing a 169.254.x.x address on an endpoint is an unmistakable diagnostic indicator: it proves that the physical Ethernet link and local network adapter driver are working properly, but Layer 2 or Layer 3 communication to a reachable DHCP server has completely failed.

---

DHCP Protocol Architecture and the DORA Flow

DHCP operates on a client-server architecture utilizing the User Datagram Protocol (UDP):

• DHCP Servers listen on: UDP Port 67
• DHCP Clients listen on: UDP Port 68

The Four-Step DORA Handshake

When a client requests an IP configuration, it executes the four-step DORA exchange:

+-------------+                                         +-------------+
| DHCP Client |                                         | DHCP Server |
+------+------+                                         +------+------+
       |                                                       |
       |  1. DHCP Discover (Broadcast)                         |
       |  Source: 0.0.0.0:68  Dest: 255.255.255.255:67         |
       |------------------------------------------------------>|
       |                                                       |
       |  2. DHCP Offer (Unicast or Broadcast)                 |
       |  Source: Server IP:67  Dest: Client IP/Broadcast:68   |
       |<------------------------------------------------------|
       |                                                       |
       |  3. DHCP Request (Broadcast)                          |
       |  Source: 0.0.0.0:68  Dest: 255.255.255.255:67         |
       |------------------------------------------------------>|
       |                                                       |
       |  4. DHCP Acknowledge / ACK (Unicast or Broadcast)     |
       |  Source: Server IP:67  Dest: Client IP/Broadcast:68   |
       |<------------------------------------------------------|
       v                                                       v

1. DHCP Discover:

   • Because the client has no assigned IP address and does not know where the DHCP server resides, it emits a broadcast packet.
   • Source IP: 0.0.0.0
   • Destination IP: 255.255.255.255 (Limited Broadcast)
   • Source Port: UDP 68 | Destination Port: UDP 67
   • Payload: The client places its physical Layer 2 MAC address inside the CHADDR (Client Hardware Address) field so the server knows who originated the request.

2. DHCP Offer:

   • Any reachable DHCP server that receives the Discover inspects its address pools. It reserves an unassigned IP address and replies with an Offer.
   • Payload: Proposes an available IP address (the YIADDR / Your IP Address field), subnet mask, lease duration, default gateway (Option 3), and DNS servers (Option 6).

3. DHCP Request:

   • In multi-server environments, a client may receive multiple Offers. The client selects one (typically the first received) and broadcasts a DHCP Request.
   • Why Broadcast? Broadcasting the Request serves two critical purposes: it confirms acceptance to the chosen server (identifying it via Option 54, Server Identifier), and it notifies all other servers that their Offers were rejected, allowing them to release their reserved IP addresses back into their pools.

4. DHCP Acknowledge (ACK):

   • The chosen server commits the IP lease to its local binding database and transmits a final DHCP ACK.
   • Once the client receives the ACK, it initiates an ARP probe for the assigned IP to ensure no duplicate IP address exists on the local link, and then binds the IP address to its interface.

Lease Lifecycles and Timers

DHCP assignments are not permanent; they are leases:

• Lease Time: Total duration for which the client is permitted to use the IP address.
• T1 Renewal Timer (50% of lease): When half the lease expires, the client sends a unicast DHCP Request directly to the original leasing server. If the server is online, it replies with a unicast ACK extending the lease.
• T2 Rebinding Timer (87.5% of lease): If the original server fails to respond at T1, the client continues using the IP until 87.5% of the lease expires. At T2, the client broadcasts a DHCP Request across the local network, seeking a lease extension from any authorized DHCP server.
• Expiration (100% of lease): If no server replies before the lease reaches 100%, the client must immediately stop using the IP address and restart the Discover cycle from scratch.

Essential Enterprise DHCP Options

DHCP options carry supplemental configuration parameters inside the DHCP packet payload:

• Option 3 (Router): Specifies the IPv4 address of the default gateway for the client subnet.
• Option 6 (Domain Name Server): Lists primary and secondary DNS server IP addresses.
• Option 15 (Domain Name): Supplies the default DNS search domain suffix (e.g., corp.example.com).
• Option 43 (Vendor-Specific Information): Used extensively in enterprise campus networks to pass operational parameters to specialized hardware. For example, controller-based (AOS 8) Aruba campus APs can use Option 43 to learn the IP address of their Mobility Controller, and AOS-CX switches read Option 43 sub-options during ZTP.
• Option 60 (Vendor Class Identifier / VCI): Transmitted by the client to identify its device category (e.g., ArubaAP or ArubaInstantAP), allowing the DHCP server to return tailored Option 43 payloads.
• AOS-CX ZTP options (AOS-CX 10.14 Fundamentals Guide): Option 43 sub-option 144 names the configuration file, 145 names the firmware image, 146 gives the FQDN or IPv4 address of an on-premises Central server, and 148 gives an HTTP proxy; Option 66 supplies the TFTP server IPv4 address and Option 67 the configuration file name.

---

DHCP Relay Operations (ip helper-address)

In modern enterprise networks, campus access switches create separate Layer 2 broadcast domains for every department or floor (e.g., VLAN 10 for Engineering, VLAN 20 for Sales, VLAN 30 for VoIP). Dedicated enterprise DHCP servers reside centrally in a secure data center or server farm VLAN (e.g., VLAN 100).

The Layer 2 Broadcast Problem

By fundamental design, routers and Layer 3 switches drop Layer 2 broadcast frames (255.255.255.255). Therefore, when a client in VLAN 10 broadcasts a DHCP Discover, the broadcast is bounded by VLAN 10 and cannot cross the Layer 3 boundary to reach the centralized DHCP server in VLAN 100.

Deploying a dedicated physical DHCP server inside every individual access VLAN would be unmanageable and cost-prohibitive. The standard architectural solution is configuring a DHCP Relay Agent.

How the DHCP Relay Agent Works

The DHCP Relay Agent is configured on the Layer 3 interface that serves as the default gateway for the client subnet (typically a Switched Virtual Interface, or SVI, on an AOS-CX aggregation or core switch):

[ Client Workstation ]
      | (VLAN 10)
      | 1. Broadcast Discover (255.255.255.255:67)
      v
[ AOS-CX Aggregation Switch ]
  SVI Interface vlan 10 (IP: 10.1.10.1)
  ip helper-address 10.1.100.50
      |
      | 2. Relay Agent Actions:
      |    - Intercepts broadcast Discover on UDP 67
      |    - Populates giaddr = 10.1.10.1
      |    - Converts broadcast into unicast packet
      |    - Source IP: 10.1.10.1, Destination IP: 10.1.100.50:67
      v (Routed Campus Backbone)
[ Central Enterprise DHCP Server ] (IP: 10.1.100.50)
      |
      | 3. Inspects giaddr (10.1.10.1)
      |    - Matches giaddr to local pool: 10.1.10.0/24
      |    - Selects available IP: 10.1.10.55
      |    - Sends unicast DHCP Offer back to giaddr (10.1.10.1:67)
      v
[ AOS-CX Aggregation Switch ]
  SVI Interface vlan 10
      |
      | 4. Relays the reply onto VLAN 10
      |    - Delivers the Offer to the client MAC
      v
[ Client Workstation ] (Binds 10.1.10.55)

The Role of the giaddr Field

The most critical mechanism in DHCP relay operations is the Gateway IP Address (giaddr) field inside the DHCP header:

1. When the client broadcasts its Discover, giaddr is set to 0.0.0.0.
2. When the AOS-CX SVI intercepts the frame, it writes its own IP address (10.1.10.1) into the giaddr field.
3. The switch converts the broadcast into a routable unicast IP packet (Source IP: 10.1.10.1, Destination IP: 10.1.100.50) and forwards it across the routed campus core.
4. When the central DHCP server receives the packet, it does not look at the source IP in the IP header; it examines the giaddr field inside the DHCP payload.
5. The giaddr value (10.1.10.1) tells the DHCP server exactly which subnet pool to draw from (10.1.10.0/24). Without giaddr, the central server would have no way of knowing which subnet the client belongs to.
6. The server generates a DHCP Offer and unicasts it directly back to the IP address specified in giaddr (10.1.10.1).
7. The AOS-CX switch receives the unicast Offer on UDP port 67, recognizes that it is a relayed response, and relays it onto the local VLAN 10 segment to the client's hardware address (as a broadcast or unicast, depending on the client's broadcast flag).

---

AOS-CX DHCP Relay Configuration and Diagnostics

Configuring DHCP Relay on an SVI

In AOS-CX, the DHCP Relay Agent is enabled by applying the ip helper-address command directly to the routed SVI (interface vlan) or routed physical interface. Multiple helper addresses can be specified to support redundant DHCP servers:

switch# configure terminal

! Configure the Layer 3 SVI for VLAN 10
switch(config)# interface vlan 10
switch(config-if-vlan)# description "Engineering Department Gateway"
switch(config-if-vlan)# ip address 10.1.10.1/24

! Configure primary and secondary centralized DHCP servers
switch(config-if-vlan)# ip helper-address 10.1.100.50
switch(config-if-vlan)# ip helper-address 10.1.100.51
switch(config-if-vlan)# exit

Verifying DHCP Relay Status and Counters

To list the helper addresses configured on each interface, execute show ip helper-address (AOS-CX 10.14 CLI Guide). The output below is abbreviated:

switch# show ip helper-address

 IP Helper Addresses

 Interface: vlan10
  IP Helper Address         VRF
  -----------------         -----------------
  10.1.100.50               default
  10.1.100.51               default

To confirm that the relay agent is enabled and to read its request and response counters, execute show dhcp-relay:

switch# show dhcp-relay

 DHCP Relay Agent                 : enabled
 DHCP Request Hop Count Increment : enabled
 Option 82                        : disabled

 DHCP Relay Statistics:

    Valid Requests Dropped Requests Valid Responses Dropped Responses
    -------------- ---------------- --------------- -----------------
    1420           0                1418            0

Common DHCP Relay Troubleshooting Checkpoints

When clients in a VLAN fail to receive IP addresses and self-assign APIPA addresses, verify the following root causes:

1. Missing ip helper-address: The helper address must be configured on the specific SVI acting as the client's Layer 3 gateway. If configured on the wrong VLAN interface, broadcasts will be dropped.
2. Routing Reachability: The switch SVI must have a valid routing path to reach the DHCP server, and the DHCP server must have a return route back to the SVI's giaddr subnet.
3. Access Control Lists (ACLs) / Firewalls: Security policies traversing intermediate firewalls or applied to switch interfaces must permit UDP port 67 and 68 traffic between the SVI IP and the DHCP server.
4. DHCP Scope Exhaustion: If show dhcp-relay shows valid requests climbing but almost no valid responses, the central DHCP server scope matching giaddr may be deactivated or 100% exhausted.