Skip to main content
Cisco Meraki Documentation

IP Conflict Events Triggered by iOS Devices

Before an Apple iOS device uses DHCP to obtain an IP address on a new network connection, it will first attempt to re-use the IP address configuration received from a previous networks DHCP server. The iOS device does not take into account whether the new network and previous network are different. If the new network and previous network happen to have the same IP address range, there is a chance an IP address conflict will occur. Specifically, if the iOS devices attempts to use its previous DHCP assigned IP address on network where the same IP address is already in use by a different host. In the case of an MX network, which performs IP conflict detection, this will trigger an IP conflict event and alert as shown below.

 

Time (PDT) DHCP Re-trigger after IP Conflict on iOS Device
Client Event type Details
Mar 29 13:14:04 iOS Client IP conflict MAC: F0:DE:F1:39:1C:7B also claims IP: 192.168.64.2
Mar 29 13:14:04 Windows Client IP conflict MAC: 64:20:0C:4D:DC:B9 also claims IP: 192.168.64.2

 

Following the example above, a user connects to a home network and corporate network that use the same 192.168.64.0/24 subnet scheme. The iOS device received a DHCP assigned IP address of 192.168.64.2 from the home network. When the user takes the iOS device into work and connects to the corporate network, it attempts to re-use IP address 192.168.64.2 before obtaining an IP address via DHCP from the corporate server. Because a machine named Windows on the corporate network is already assigned the IP address 192.168.64.2, the iOS device is now in conflict. The MX detects this and logs an IP conflict event for IP address 192.168.64.2.

Screenshot of packet capture depicting ARP traffic observing a duplicate IPv4 address in use by two or more clients.

 

A packet capture above shows in detail how iOS (64:20:0c:4d:dc:b9) attempts to re-use IP address 192.168.64.2 at link up. The device sends ARP requests to locate 192.168.64.1, the default gateway used on the home network, when connecting to the corporate network. In this instance, DHCP clients on the users home network and corporate network even share the same default gateway IP address configuration. The MX, 192.168.64.1, which is the default gateway on the corporate network detects an IP conflict and sends an ARP response back to iOS. On the corporate network a machine named Windows (f0:de:f1:39:1c:7b) is already using 192.168.64.2 and actually received this IP address via DHCP from the MX so the iOS device is now in conflict.

After a short period of time, in milliseconds, iOS realizes it is in conflict and stops using 192.168.64.2. Now the device attempts to obtain an IP address using DHCP. When the DHCP process completes successfully, iOS gets a different IP address from the DHCP server, 192.168.64.252, which is not in conflict on the corporate network.

Screenshot of packet capture of DHCP DORA process.

 

In conclusion, this issue can be prevalent on any IP network where iOS devices are connected. The problem is not specific to the MX, Dashboard, or any other networking device. In most cases, this IP conflict occurs so briefly that it does not affect network performance and is merely a nuisance. 

 

Please refer to the following link with similar scenarios reported by other users at the Apple's discussion site and contact Apple support for more assistance.

 

https://discussions.apple.com/thread/3681645?start=0&tstart=0

 

See also:

Troubleshooting DHCP conflicts

Using Packet capture to troubleshoot client-side DHCP issues

Detecting Network Attachment in IPv4 - Apple RFC for this behavior

  • Was this article helpful?