Printer with Static constantly getting caught in IP Conflict Reports

[mcholin]

We have a Canon LBP6670 with a Static IP Address set in the configuration, we can access it via the Web interface and printing is working normally for that device. 

The issue we are having is that our Meraki Firewall is monitoring for IP Conflicts on the network and there are days that this particular printer will be involved in 60+ conflicts over an hour period. The IP address that gets reported as conflicting is always different and will be different from 1 second to the next, the only consistency is that the IP Address always falls under the APIPA Scope of 169.254.x.x. We also tried setting the printer to DHCP with a reservation address and the issue continued to happen as if no change had been made. 

As mentioned the printer is working on the static IP that we have assigned to it and even when the conflicts are being reported we can remote into the web interface of the prinmter and print to it. What I am wondering is, has anyone here had similar experiences and is there a way to get the printer to stop reporting the various APIPA addresses when it has a static IP or a DHCP one? So far the only way we have been able to stop this device from being reported as a Conflict IP Address was to remove it from the network and use it via DHCP.

[shadowsports]

Greetings,

Meraki products.  Use them every day.  Simple fix for this.

Limit the DHCP range.

Assign a static IP above or below this range.  You will no longer get an IP conflict.     

[Darius]

Hi mcholin.

In addition to the option provided by Shadowsports, it's possible that these IP conflicts are being caused conflicts related to subnetting (IPs on different subnets reporting in ways the firewall is not designed or set to process). Ensure the static IP is set both on the printer and on the DHCP server (i.e. your router or network switch).  Refer to your network hardware's documentation and support for directions on how to accomplish this.

Did this answer your question? Please click the Accept as Solution button so that others may find the answer as well.

[mcholin]

Thank you for the reply, as noted when responding to shadowsports, the issue is not that the ip address is actually in conflict, we have a static set that is outside of our DHCP range of addresses, and yet the prionter is still being seen by our Meraki firewall as conflicting with various other devices before they receive their valid IP from DHCP.

Here is a sample of the Conflicts in our Meraki Event logs:

1/13/2020 3:35	Workstation	Client IP conflict	MAC: 88:87:17:54:A7:94 also claims IP: 169.254.62.114
1/13/2020 3:35	88:87:17:54:a7:94	Client IP conflict	MAC: 70:8B:CD:81:B7:3A also claims IP: 169.254.62.114
1/12/2020 2:17	Workstation	Client IP conflict	MAC: 88:87:17:54:A7:94 also claims IP: 169.254.62.114
1/12/2020 2:17	88:87:17:54:a7:94	Client IP conflict	MAC: 70:8B:CD:81:B7:3A also claims IP: 169.254.62.114
1/12/2020 2:17	Workstation	Client IP conflict	MAC: 88:87:17:54:A7:94 also claims IP: 169.254.106.110
1/12/2020 2:17	88:87:17:54:a7:94	Client IP conflict	MAC: 1C:87:2C:57:7A:B4 also claims IP: 169.254.106.110
1/12/2020 2:17	Workstation	Client IP conflict	MAC: 88:87:17:54:A7:94 also claims IP: 169.254.80.192
1/12/2020 2:17	88:87:17:54:a7:94	Client IP conflict	MAC: 1C:87:2C:58:C7:FD also claims IP: 169.254.80.192
1/12/2020 2:16	Workstation	Client IP conflict	MAC: 88:87:17:54:A7:94 also claims IP: 169.254.76.130
1/12/2020 2:16	88:87:17:54:a7:94	Client IP conflict	MAC: 1C:87:2C:56:3C:AF also claims IP: 169.254.76.130
1/12/2020 2:16	Workstation	Client IP conflict	MAC: 88:87:17:54:A7:94 also claims IP: 169.254.252.39
1/12/2020 2:16	88:87:17:54:a7:94	Client IP conflict	MAC: 1C:87:2C:57:7E:46 also claims IP: 169.254.252.39
1/10/2020 13:24	Workstation	Client IP conflict	MAC: 88:87:17:54:A7:94 also claims IP: 169.254.163.48
1/10/2020 13:24	88:87:17:54:a7:94	Client IP conflict	MAC: 1C:87:2C:46:54:2C also claims IP: 169.254.163.48

The MAC Address Device in the list is the Canon printer in question and the workstation was a device that had been offline for a couple of days and ways awaiting the response from our DHCP Server. Once it received the address assignment from DHCP the conflict stopped and during that time the Canon was still working normally from its static IP Address in the 192.168.x.x/24 range. Our DHCP Server is only set to hand out Addresses in the 192.168.x.100-192.168.x.200 range and everything else is either a reservation or a static assignment.

[Darius]

Hello again mcholin.

If the static IP is assigned both host-side (on the printer) and server-side (on the network hardware), and an APIPA address still comes into play (caused by the IP conflict), then either another device on the network is trying to claim the same IP address reserved for the printer, or some other fault is occurring server-side (or, alternatively, from an external source).  Refer to resources for both the firewall and your network connection architecture.

Did this answer your question? Please click the Accept as Solution button so that others may find the answer as well.

[mcholin]

Darius, Thank you for the follow up, but I'm not sure I have been clear enough yet.

Our Printer has a static IP Set that is out side of the Server issued addresses for our network. It maintains the address all of the time and nothing else is conflicting with that static IP address. 

The only addresses getting marked as conflicts involving this printer are the APIPA addresses, and this despite the printer having a valid Static IP assigned in the network configuration of the printer. 

That is where my question is coming from; why does this printer show up in our Client IP Conflict list for an address that it does not have programmed into it? Why do APIPA addresses respond on the MAC Address of this printer when it has a valid IP Address for our LAN scope?

[Darius]

Hello mcholin.

I apologize if my previous post was too verbose, causing the inforamation to be easy to miss.

If an APIPA address is coming up in your error report, it's because some other device is trying to use the printer's static IP.  The other device may be on your network, or it may be from outside your network (in which case your firewall is working as intended).  Your network server responds by trying to assign or reroute through the APIPA address. 

Correcting this problem requires you to go over the settings both on the network server, in the firewall, and on any device on your network that could possibly try to use the printer's static IP.

[mcholin]

So I am still not understanding something here: You are saying that some other device is trying to claim the static IP Address that we have assigned to the printer and this is triggering the printer(or my server) to say that the MAC Address of the printer is active on mutliple APIPA addresses at the same time?

As further clarification and to reiterate my previous posts,

1) The printer (whether static IP, DHCP Reservation, non-reservation DHCP, different static IP Address for the same network) reports that there is a conflict on an APIPA Address only.

2) We have no other devices using the IP Address that the printer is using (when the printer is disconnected from the network nothing responds for that IP and we do not get the conflicts). 

3) As this Screenshot from our Meraki Event logs shows, the printer will conflict with 7 different APIPA Addresses in the same minute, sometimes the conflict will report 2 different IP Addresses in the same second.

4) A device outside of our network could not possibly influence my server, firewall, or the printer to think that the assigned IP Address is being used, especially since my firewall does not allow unsolicited traffic from outsite of the network to communicate to devices on the network. 

5) All of the conflicts being reported are for APIPA Addresses when a workstation  is powered on and has not received a valid IP from our DHCP server. The conflict stops when the workstation no longer is using the APIPA range as it received a valid IP from DHCP.

6) DHCP Range is not issuing addresses in the range that the printer is assigned a static IP Address in. our printer is assigned a static LAN IP at .31 within our LAN and the DHCP Scope is only handing addresses from .100-.200.

You mentioned that to correct the problem we would need to go over the settings on the network server (Listed above), in our Firewall (the firewall is the one reporting the conflicts and we have submitted a feature request to let us exclude the APIPA addresses from reporting and the firewall does not play a role in assigning addresses to client devices), and we have verified that there are no other devices trying to use the static IP assigned to the printer (by disconnecting the printer, changing the address and the way it is assigned). All to no effect on the issue at hand.

What seems to be the issue from our perspective is that the Canon printer is continually cycling through the IP range of the APIPA IP Scope (or claiming the entire range), despite having a valid static IP address that it can and does communicate on. When any other device connects to the network without an IP Address already for the LAN it self assigns an APIPA address until it gets the DHCP address it requested (less than a second for the response). 

[Darius]

Hi again mcholin.

• You are saying that some other device is trying to claim the static IP Address that we have assigned to the printer and this is triggering the printer(or my server) to say that the MAC Address of the printer is active on mutliple APIPA addresses at the same time?

Correct, or that something outside of your network is trying to penetrate in, your firewall is catching it as intended, and the worst fallout is the APIPA error message.

The printer does not assign itself an APIPA address, it is assigned by the host.  Hosts assign APIPA addresses as the result either of settings or due to IP conflicts between devices.  If the DHCP server is co-assigning the printer's static IP address to another device on the network, then that is a DHCP setting issue.  If another device on the network was given the same static IP address, or is trying to claim it for some reason.

If you want to be certain, then, the next time the IP conflict occurs, try powering off the printer completely, then pinging the printer's static IP.  If it pings back with the printer completely powered off, then something else is also using that IP address.

Did this answer your question? Please click the Accept as Solution button so that others may find the answer as well.

[mcholin]

As I have noted previously, our DHCP Server is not assigning the IP Address in question to any other devices, it is outside of our DHCP Lease range that the server hands out. We also do not have anything else on the network trying to use that static IP address as we had the printer disconnected from the network for over a month and nothing responded on that IP Address during that time frame. The APIPA conflicts started again once the printer was plegged back into the network. 

We have also tried to change the IP Address used by the server and still recieved the APIPA address conflicts. It does not matter what IP the printer is assigned it will be reported as being in conflict with other APIPA addresses when a new device is turned on an existing one is turned back on after it's lease expires.