ACI DHCP Deployment and Design Guide

1. The Foundation: Understanding DHCP and ACI Fundamentals

1.1 The DHCP DORA Process Explained

The Dynamic Host Configuration Protocol (DHCP) automates IP address assignment through a four-step dialogue known as DORA: Discover, Offer, Request, and Acknowledge. This process ensures that clients can join a network without manual IP configuration.

1. Discover: A client without an IP address broadcasts a DHCPDISCOVER message onto the local network segment. This packet has a source IP of 0.0.0.0 and a destination of 255.255.255.255.
2. Offer: Any DHCP server that receives the discovery and has an available address can respond with a unicast DHCPOFFER message. This offer contains a proposed IP address, lease duration, and other network options.
3. Request: The client receives one or more offers and chooses one. It then broadcasts a DHCPREQUEST message that identifies the chosen server and requests the offered IP address. This is broadcast so that any other servers that made an offer know their offer was declined.
4. Acknowledge (ACK): The selected server finalizes the lease by sending a unicast DHCPACK message to the client. The client can now use the assigned IP address.

1.2 ACI’s Policy-Based Networking

ACI abstracts traditional network configuration into a scalable object model. Instead of configuring VLANs and SVIs with helper addresses on individual switches, you define logical policies that ACI automatically renders into concrete configurations on the physical leaf switches. This ensures consistency and dramatically simplifies management at scale.

1.3 The Critical Role of DHCP Relay and Option 82

Because DHCP discovery messages are broadcasts, they cannot cross Layer 3 boundaries. A DHCP relay policy may be used when the DHCP client and server are in different subnets. ACI’s built-in DHCP relay function solves this by intercepting the broadcast and forwarding it as a unicast packet to a configured DHCP server. To do this, it populates the Gateway IP Address (giaddr) field in the DHCP packet with the IP address of its own Bridge Domain SVI. This tells the server which subnet the request came from. Critically, ACI also injects DHCP Option 82 into the packet. This is not optional; if a DHCP server does not understand or is not configured to handle Option 82, the exchange will fail. When a Cisco Application Centric Infrastructure (ACI) fabric acts as a DHCP relay, it inserts the DHCP Option 82 (the DHCP Relay Agent Information Option) in DHCP requests that it proxies on behalf of clients. If a response (DHCP offer) comes back from a DHCP server without Option 82, it is silently dropped by the fabric. Therefore, when the Cisco ACI fabric acts as a DHCP relay, DHCP servers providing IP addresses to compute nodes attached to the Cisco ACI fabric must support Option 82.

1.4 DHCP Relay Policy Scopes: User, Common, and Global DHCP Policy

ACI provides three distinct scopes for defining DHCP Relay Policies. Understanding their purpose is critical for correct implementation.

User Tenant Policy

This policy is created within a specific user tenant (e.g., Tenant-A). It is locally significant and can only be used by Bridge Domains within that same tenant. This model is ideal for environments where a tenant manages its own dedicated DHCP services for its endpoints.

Common Tenant Policy

This policy is created in the common tenant and is not available to other tenants when configuring DHCP relay in a bridge domain. For inter-tenant DHCP relay communications, create a global DHCP relay policy.

Global DHCP Relay Policy

This policy is fundamentally different. It is configured under Fabric > Access Policies > Global > DHCP Relay. The global DHCP relay policy identifies a DHCP relay server that can be referenced by bridge domains in different tenants across the fabric. With tenant DHCP relay you must configure the DHCP relay policy in each tenant even if the provider EPG is in the common tenant. The global DHCP relay policy differs from a tenant DHCP relay policy in that it can be referenced from any tenant and does not require the configuration of a DHCP relay policy in each tenant.

*** Configuration steps use the user tenant DHCP relay policy configuraion but Global DHCP relay policy configured under Fabric > Access Policies > Global > DHCP Relay can be used especially for multi-tenant environment sharing the same DHCP servers.

Table 1.1: Policy Scope Comparison

2. Scenario 1: Client and DHCP Server in the Same VRF

2.1 Conceptual Overview

This is the simplest scenario. If the client and server are in the same Bridge Domain (BD), no DHCP Relay is needed. However, if they are in different BDs within the same VRF, ACI’s DHCP relay function is required to forward the request across the L3 boundary.

2.2 APIC Configuration Steps

1. Create DHCP Relay Policy: Navigate to Tenant > Policies > Protocol > DHCP > Relay Policies. Create a new policy. This object acts as a container for your DHCP server information.
2. Add DHCP Relay Provider: Inside the policy, add a provider. Set the EPG Type to Application EPG, select the EPG where the server resides, and enter the server’s IP address. This tells ACI where to forward the DHCP requests.
3. Associate Policy with Client’s BD: Navigate to the client’s Bridge Domain. Under the BD, find DHCP Relay Labels and create a new label that references the policy you just created. This final step activates the DHCP relay service on the SVI for this Bridge Domain.

3. Scenario 2: Client in ACI and Server External via L3Out

3.1 Conceptual Overview

When the DHCP server is outside the ACI fabric, requests must be routed through an L3Out. This requires a contract to permit traffic between the client’s EPG and the External EPG representing the outside network. The L3Out must have learned the route to the external DHCP server for the relay to succeed.

3.2 APIC Configuration Steps

1. Create DHCP Relay Policy: Same as the intra-VRF scenario.
2. Add DHCP Relay Provider: In the provider configuration, change the EPG Type to L3 External Network. This is the key difference.
3. Specify L3Out: Select the L3Out and the specific External EPG that provides reachability to the DHCP server. Enter the server’s IP address.
4. Create DHCP Relay Label: Associate the policy with the client’s BD as before.
5. Configure Contract: ACI operates on a whitelist security model. You must create and apply a contract between the client’s EPG and the External EPG to permit DHCP traffic (UDP ports 67 and 68). Without this contract, the fabric will drop the relayed packets.

4. Scenario 3: Inter-VRF DHCP

4.1 Conceptual Overview

By design, VRFs are isolated routing domains. To allow a client in one VRF to use a DHCP server in another, you must explicitly configure a path between them. There are two primary methods to achieve this.

4.2 Method A: Routing through an External L3Out (Hairpinning)

This traditional approach uses an external device (like a firewall or router) to bridge the two VRFs. Traffic from the client VRF leaves the fabric via one L3Out, is routed by the external device, and re-enters the fabric via a second L3Out connected to the server VRF. This is called “hairpinning” and adds complexity and latency.

4.3 Method B: The “Use Server VRF” Feature (APIC 5.2(4)+)

This modern, preferred approach simplifies inter-VRF shared services immensely. Instead of complex external routing, you simply check a box in the DHCP policy. ACI then handles the route leaking between the client and server VRFs internally and transparently, eliminating the need for hairpinning, external devices, and complex contract setups.

APIC Configuration Steps (Use Server VRF)

1. Create DHCP Relay Policy: In the client’s tenant, create a new DHCP Relay Policy.
2. Add DHCP Relay Provider: Inside the policy, add a provider. Set the EPG Type to Application EPG, select the EPG where the server resides, and enter the IP address of the DHCP server, which resides in a different VRF and/or tenant. This tells ACI where to forward the DHCP requests.
3. Enable Server VRF Feature: Check the box labeled Use Server VRF. This is the crucial step.
4. Apply Policy: Associate this policy with the client’s BD using a DHCP Label. ACI now handles all necessary route leaking automatically.

5. Advanced Concepts and Best Practices

5.1 ACI’s Distributed Anycast Gateway and DHCP

ACI uses a distributed anycast gateway, where the same gateway IP is active on every leaf switch in a BD. This creates a challenge for DHCP relay: when a leaf inserts the anycast gateway IP into the giaddr field, the server’s unicast reply is sent to that IP. Since the IP is active everywhere, the fabric’s routing protocol (IS-IS) may deliver the reply to the “closest” leaf, which may not be the leaf that originated the request.

Solution: When the DHCP Relay Proxy adds OPTION 82 to DHCP Request, the gateway includes sub-options as part of the OPTION 82 body. Agent Circuit ID and Agent Remote ID are sub-options added by the ACI switches for DHCP Relay to resolve the issue outlined above. Agent Circuit ID: is the Physical Interface and VLAN ID of where the Client resides on the DHCP Relay Proxy Gateway. Agent Remote ID: is the TEP Address of the DHCP Relay Proxy Gateway.

5.2 Summary of Best Practices

• Use the Correct Tenant: As detailed in Section 1.4, use the Global DHCP relay policy for shared endpoint services and the user tenant exclusively for single tenant fabric deployment.
• Ensure Option 82 Compliance: Verify that your DHCP server fully supports and is configured to handle DHCP Option 82. This is the most common cause of failure.
• Verify Server Scopes: The DHCP server must have a correctly configured IP address scope that matches the subnet of the client’s Bridge Domain.
• Use Unique Loopback for giaddr: In large-scale deployments, use unique leaf loopbacks as the relay source to avoid issues with the anycast gateway.
• Prefer “Use Server VRF”: For inter-VRF DHCP, use the “Use Server VRF” feature over hairpinning whenever possible to reduce complexity and improve performance.

6. Troubleshooting Common DHCP Issues

When DHCP fails, a systematic approach is key. Here are common failure points and tools to diagnose them.

1. Verify Policy Deployment: Log into the APIC CLI and use moquery to confirm the DHCP policy has been pushed to the leaf switch. For a tenant policy, the query would be: moquery -c dhcpRelayP -f 'dhcp.RelayP.dn*=="topology/pod-1/node-101.*tn-MyTenant"'.
2. Verify configuration on Leaf Nodes: You only have to check the Leaf Nodes that have endpoints which will be using the DHCP Relay services.
• 1. SSH into the leaf switch.
• 2. On each Leaf with DHCP-Relay configured, run “show ip dhcp relay”. The output will verify that the “DHCP relay service is enabled”. The output will also show the “IP Helper Address” information for the Leaf.
3. Reachability test: If experiencing DHCP Relay issues after DHCP Relay configuration has been verified, you can run “iping” CLI commands from each Leaf experiencing issues to test the connectivity to the DHCP SERVER.
4. Check Leaf Relay Statistics: SSH into the leaf switch where the client is connected. Use the command vsh -c 'show dhcp internal relay statistics detail' to see if DISCOVER packets are being received and if OFFER packets are being dropped.
5. Packet Captures (tcpdump): This is the most powerful tool. From the leaf switch CLI, use tcpdump to capture traffic on the client-facing interface and the fabric-facing uplink.
   • Look for the inbound DHCPDISCOVER from the client.
   • Look for the outbound relayed request on the uplink. Check that the giaddr is correct and that Option 82 is present.
   • Look for the inbound DHCPOFFER from the server. If it’s missing, the problem is with the server or the path to it. If it arrives but doesn’t get forwarded to the client, the issue is likely an Option 82 mismatch.
6. Check Contracts: If using an L3Out, double-check that a contract permitting UDP ports 67/68 exists and is correctly applied between the EPGs.

7. Conclusion

DHCP deployment in ACI masterfully replaces complex, per-device CLI configurations with a streamlined, policy-based model. By understanding the core objects and their interactions, operators can automate this critical network service across a large-scale fabric with consistency and control.

The analysis of various scenarios—from simple intra-VRF setups to advanced inter-VRF shared services—demonstrates the flexibility of the policy model. The evolution from complex hairpinning designs to the simple "Use Server VRF" feature highlights a commitment to operational simplicity. For a successful deployment, a deep understanding of the underlying principles is paramount. The mandatory use of Option 82, the architectural implications of the anycast gateway, and the distinct policy scopes for user tenants, common, and global DHCP relay policy are not just details; they are the foundation of a robust and maintainable ACI network.