When the “multiple DHCP servers detected” alert appears in a Cisco Meraki network, it’s a sign that more than one device is responding to DHCP requests within the same broadcast domain. This condition leads to inconsistent IP addressing, unpredictable client behavior, and intermittent connectivity issues that are often difficult to reproduce.

This guide is designed as a practical troubleshooting reference. It’ll walk through how Meraki detects the issue and how to identify the source of unexpected DHCP offers. Hummingbird Networks will also show you how to correct configuration or design problems, and prevent the alert from returning.

Why This Alert Appears In Real Networks

This alert is triggered based on observed traffic, not configuration state. Meraki raises it when it sees multiple DHCP offer packets responding to the same client discovery request. From the platform’s perspective, this means more than one device believes it is authoritative for the same broadcast domain.

In real environments, this almost always points to a boundary or design issue rather than a Meraki defect. DHCP relies on broadcast traffic, so when VLANs extend further than intended or devices are left misconfigured, those broadcasts reach places they should not. Meraki is effectively surfacing design drift.

Before troubleshooting, it’s important to understand the most common conditions that cause this alert so you know what you’re actually looking for during isolation.

What Meraki Is Detecting

Meraki identifies this condition by observing DHCP traffic patterns on the wire.

1. A client sends a DHCP discover message.

2. More than one DHCP offer is received in response.

3. The offers originate from different MAC addresses.

At that point, Meraki determines that multiple DHCP servers are active in the same broadcast domain and generates the alert.

Common Real-World Causes To Check

In production networks, you’ll typically find this behavior is caused by one of the following conditions:

• Unmanaged switches bridging VLANs that should be isolated

• Old routers, firewalls, or access points with DHCP still enabled

• Trunk ports allowing VLANs beyond their intended scope

• HA or VRRP devices responding unexpectedly after changes

• Test or lab DHCP servers bleeding into production segments

The alert itself is not the problem. It’s a symptom that something is responding where it shouldn’t be.

Zeroing In On The Source DHCP Server

At this stage, the goal is not to disable DHCP randomly. The goal is to identify which device is sending the unexpected DHCP offers and how that traffic is entering the affected VLAN. Everything that follows depends on correctly answering those two questions.

Meraki provides enough visibility to do this methodically if you follow the evidence in order.

Step 1: Identify The Source MAC Address

Start by determining which device is actually responding to DHCP requests.

1. In the Meraki Dashboard, navigate to Network-wide > Event log.

2. Apply a filter for DHCP.

3. Locate the event indicating multiple DHCP offers.

4. Record the source MAC address associated with the unexpected offer.

This MAC address represents the device sending DHCP offers, regardless of whether it is local or upstream.

Step 2: Map The MAC Address To The Switch Layer

Once you have the MAC address, determine where it appears in the switching infrastructure.

1. Navigate to Switch > DHCP servers & ARP.

2. Search for the MAC address identified in Step 1.

Interpret what you see carefully:

• If the MAC appears on an access port, the DHCP server is downstream. This typically indicates a rogue device, an unmanaged switch, or hardware with DHCP unintentionally enabled.

• If the MAC does not appear on any access port, the DHCP traffic is entering through a trunk, routed interface, or upstream network.

This step determines whether you troubleshoot locally or upstream.

Step 3: Confirm The Entry Point With Packet Capture

Packet captures are used to validate where the DHCP offer first appears.

1. Run a packet capture on the suspected interface:

   • Access port if you suspect a local device

   • Trunk port if you suspect VLAN bleed

   • Uplink if you suspect an upstream source

2. Filter the capture for DHCP traffic

3. Observe where the DHCP Offer is first seen

Use the capture to interpret the condition:

• Offer seen on a single access port indicates a local rogue device

• Offer seen across multiple access ports simultaneously indicates a VLAN or trunking issue

• Offer arriving from an uplink indicates an upstream DHCP source

Step 4: Use Neighbor Data To Identify The Physical Device

Once the entry point is identified, use neighbor visibility to pinpoint the actual device.

1. Review LLDP or CDP neighbor information on the identified port

2. Check port descriptions and connected device details

3. Physically trace the connection if needed
   
   

You should not move forward until you can clearly identify which device is responding to DHCP and how it is connected.

Cleaning Up Meraki DHCP Configuration Across VLANs

After identifying the source of the extra DHCP offers, the next step is to ensure DHCP configuration aligns with the intended network design. Many alerts persist because multiple devices are configured in ways that technically work in isolation but conflict when combined.

This step focuses on validating ownership, scope boundaries, and alignment between DHCP and routing.

Step 1: Review DHCP Mode Per VLAN

For each affected VLAN, verify how DHCP is currently configured.

1. Navigate to Security & SD-WAN > Addressing & VLANs or Switch > Routing & DHCP.

2. Confirm the DHCP mode is set to one of the following:

   • Meraki DHCP

   • DHCP relay

   • Do not respond

Only one device should be authoritative for DHCP per VLAN.

Step 2: Check For Scope And Subnet Issues

Once the DHCP mode is confirmed, validate the scopes themselves.

1. Ensure subnets do not overlap across VLANs.

2. Remove any old lab or test scopes.

3. Confirm VLAN IDs still match their intended purpose.

Overlapping or forgotten scopes are a common source of duplicate offers.

Step 3: Validate SVI and Ownership Alignment

Finally, ensure DHCP ownership matches Layer 3 ownership.

1. Identify which device owns the VLAN gateway (SVI).

2. Confirm that the same device is responsible for DHCP.

If DHCP and routing ownership are split incorrectly, Meraki will continue to detect competing offers.

Using The MX As The Authoritative DHCP Server

Using the MX as the DHCP gear is most appropriate in smaller environments where routing is simple and centralized. In these designs, the MX often owns both DHCP and the default gateway.

Before making changes, confirm that the MX is intended to be authoritative for the VLANs in question.

Validation Steps For The MX

Follow these steps to ensure your MX configuration is accurate.

1. On the MX, review each VLAN configuration:

   • Subnet and gateway

   • DNS servers

   • Lease times

   • Reservations and exclusions

2. Validate VLAN tagging on access ports and trunks

A common failure here is VLANs being allowed where they shouldn’t be, causing MX DHCP scopes to appear in unintended segments.

Using Switch-Based DHCP On The MS Layer

Switch-based DHCP is commonly used in campus or multi-VLAN environments to keep DHCP traffic local to clients.

This design only works correctly when you’ve clearly defined ownership for each segment.

Validation steps:

1. Confirm only one MS switch per VLAN is running DHCP

2. Verify that the same switch owns the SVI

3. Check for duplicated scopes across stacks or redundant pairs

If more than one switch believes it is authoritative, duplicate DHCP offers will occur consistently.

When Windows Server DHCP Should Stay Central

Windows Server DHCP is appropriate when Active Directory integration, DHCP failover, or centralized lease management is required.

Problems usually appear when environments evolve without revisiting boundaries.

Validation steps for Windows Servers:

1. Review DHCP interface bindings on the Windows server.

2. Verify NIC VLAN assignments.

3. Inspect hypervisor vSwitch configuration for unintended bridging.

Lab VLANs and multi-NIC servers are frequent sources of unexpected DHCP offers.

Deploying DHCP Relay Without Introducing New Problems

DHCP relay changes the packet flow from broadcast to unicast, which makes routing accuracy critical. A misconfigured relay can easily introduce duplicate offers or failed renewals for your gear.

Before adjusting relay settings, understand the expected traffic flow and verify that only one relay exists per path.

Expected Packet Flow

You’ll see the following sequence when your relay is working correctly.

1. Client sends DHCP Discover.

2. Relay forwards the request to the DHCP server.

3. Server replies to the relay interface.

4. Relay forwards the response to the client.

Any break or duplication in this path can trigger repeated alerts.

Common Relay Misconfigurations To Check

Review these common errors if you’re seeing repeated alerts.

• Relay configured on multiple devices in the same path.

• Helper addresses pointing to the wrong interface.

• Firewalls allowing requests but silently dropping replies.

Relay On The MX

MX-based relay is typically used in branch-to-central DHCP designs where a remote server services multiple sites.

Validation steps:

1. Verify helper address configuration.

2. Confirm VPN or SD-WAN paths allow return traffic.

3. Run a packet capture on the MX to confirm:

   • Requests are forwarded

   • Replies return as unicast

If replies do not return, investigate routing symmetry and firewall behavior.

Relay On MS Switches

In campus environments, MS switches often act as relay points at the SVI level.

This design requires careful handling in HA scenarios.

Validation steps:

1. Confirm only the VRRP master forwards DHCP relay traffic

2. Review switch event logs for relay activity

3. Disable relay on standby devices if necessary

Dual relay points will consistently generate duplicate offers.

Field Diagnostics When The Alert Persists

If the alert remains after configuration cleanup, isolation is required. At this stage, assume something is still responding unexpectedly.

Work methodically to reduce the broadcast domain until the alert clears.

Isolation steps for persistent alerts:

1. Temporarily disable suspect access ports.

2. Monitor whether DHCP offers stop.

3. Capture uplink traffic during isolation.

4. Re-enable ports one at a time.

Devices commonly missed:

• Third-party access points

• Printers and IP cameras

• IoT devices with embedded DHCP

• Temporary WAN, mesh, or failover links

Also verify that no duplicate Meraki networks are unintentionally bridged.

Locking Down DHCP To Prevent Recurrence

Once the issue is resolved, focus on preventing future alerts. Most repeat incidents are caused by design drift rather than new hardware failures.

Locking down DHCP ownership and boundaries is the most effective long-term fix.

Hardening steps:

1. Enforce strict VLAN isolation

2. Disable DHCP on all non-authoritative devices

3. Restrict UDP ports 67 and 68 using Meraki switch ACLs

4. Standardize DHCP ownership:

   • MX or

   • MS or

   • Windows

Document where DHCP lives and who owns it. Clear ownership prevents future ambiguity.

Recurring DHCP conflicts are usually an architecture problem. Cisco Meraki switches simplify DHCP control and eliminate hidden broadcast issues across sites.