10.120..x.x: Address not used, duplicate address no detected!

[hammerniski]

Hi - we have a SonicWall Firewall with two interfaces running, no VLAN's configured with 25 Meraki switches.  MS220 units serve as our Core switches in our MDF, a MS220 is acting as root.

We have 2-3 non Meraki switches (Netgear/TPlink consumer 5-8 ports) still in use and have plans to swap out for MS130P units.

We also have 24 Meraki AP's, models MR36, MS44 and MR72 in use.

We plan to move to three VLANS in the future and move to the MX95.  Still documenting all of the ports and ensuring we have located all of the network devices. 

So far things are very stable and users are happy.

We recently in the last couple weeks have started seeing the message of: 10.120..x.x: Address not used, duplicate address no detected! on some of our printers.  

We keep very close track of all static IP address assignments and rarely are adding or making changes.  In all cases if we take the printer offline and scan/ping the IP we get no response, if we restart the printer or the interface on the printer everything is fine.  Sometimes it comes back the next day or a different printer is affected.  Seems very random.

I think it's an ARP issue, just not really sure where to start first in trying to figure out the root cause of this.

DAI is turned off by default in the switches and all ports are all still configured as Trunk ports.

Any suggestions would be very much appreciated as I am a novice...

[alemabrahao]

Hi,

I've seen a similar case where a device had a static IP, but I don't think that's your case.

At the moment, have you checked the ARP table to get the device's MAC and try to identify who might be causing the problem?

In my case, I was able to identify the problem this way.

[PhilipDAth]

What is doing DHCP in the network?  Does it have exclusions for statically configured devices?

[hammerniski]

I currently have the SonicWall providing DHCP, there are several DHCP scopes in place.  

[IvanJukic]

Hi @hammerniski ,

It sounds like a rouge DHCP server. DAI would be recommended as you have other vendor switches in place. I suggest to set the Port to the printer to Access and not Trunk and ensure only the Printer VLAN is set.

[AlexL1]

Hi hammerniski,

Welcome to Meraki Community 🙂

Most IP conflicts are related to two issues:

• A rogue DHCP server on the network
• A static IP address is assigned to a device even though the IP address is a part of an active DHCP scope:
  • A Duplicate IP Address error message occurs when another device, such as a Laptop, Desktop, Cell Phone or Tablet has connected to the Network, and obtained the same IP Address from the DHCP Server that is in use by the Printer. This can occur if the IP Address used by the Printer is not programmed as reserved on the Router, Modem or Server running the DHCP service.

1) Ensure that all static IP addresses assigned to the printers are unique and not overlapping with any DHCP scope or other static assignments in the network.

• Use the Meraki Dashboard to check for duplicate IP addresses:
  • Navigate to Network-wide > Monitor > Clients to identify devices with conflicting IP addresses

2) The issue might be related to ARP (Address Resolution Protocol) conflicts. Perform the following:

• Use packet capture tools available in the Meraki Dashboard to analyze ARP traffic and identify any anomalies
• Cisco Meraki switches track DHCP servers and provide a network-wide view of this information. This page is available on Dashboard by navigating to Switch > Monitor > DHCP servers & ARP.
  • https://documentation.meraki.com/MS/Monitoring_and_Reporting/MS_DHCP_Servers#Detected_DHCP_Servers

3) Verify that there are no rogue DHCP servers in the network - "bootp" filter can be used to sort out DHCP packets:

• https://documentation.meraki.com/MX/DHCP/Tracking_Down_Rogue_DHCP_Servers#Cisco_Meraki_Switches
• https://documentation.meraki.com/MX/DHCP/Tracking_Down_Rogue_DHCP_Servers#Using_a_Packet_Capture_to_...

4) Plan for VLAN Implementation:

• As you plan to move to VLANs in the future, ensure proper segmentation of devices to reduce broadcast domains and minimize the likelihood of IP conflicts.
• As IvanJukic suggested make sure all switchports where printers are configured are Access Mode.

5) Enable Dynamic ARP Inspection (DAI) - Since DAI is currently disabled, consider enabling it to prevent ARP spoofing and ensure ARP packets are validated against the DHCP snooping table. This can help mitigate ARP-related issues:

• Configure trusted ports for uplinks and untrusted ports for end devices

If you have any questions, please don't hesitate to contact us.

[hammerniski]

Thank you Alex,

Couple questions..

I have checked the dashboard and the only DHCP servers seen are coming from our SonicWall which at present is correct.  

Item 4:  Are you suggesting that I create separate subnets for certain device types to segment the network?  I did create a new subnet just for the Meraki devices.  

Item 5:  Before I enable DAI do I need to first identify each printer port and mark them as trusted?  I'm assuming I should also trust all of the uplink ports as well between the switches?  What would happen if I enable DAI before I mark any ports as trusted?