The IP 1.1.1.1 is claimed by clients with the following MAC addresses:

[khamees]

The IP 1.1.1.1 is claimed by clients with the following MAC addresses ,once the alert come,all the network goes down 

[alemabrahao]

I can see that this could be caused by either a malicious device or an attacker intentionally spoofing the IP. Or maybe some DHCP misconfiguration or rogue DHCP servers handing out 1.1.1.1.

Have you tried to identify the MAC address that is originating this?

You could try creating a firewall rule for the IP 1.1.1.1 denying everything coming from that source.

[ww]

Most times its a side affect of meraki devices when it loses ip config or reboot.

Do your mr devices use dhcp for the management ip?

Is you dhcp server reachable at all times? Does you upstream router maybe reboot or have other issues?

You could try assign a AP with static ip config and see how it behaves.

You can also find some older topics on this community like https://community.meraki.com/t5/Security-SD-WAN/The-security-appliance-at-lt-gt-has-detected-IP-conf...

[JGill]

As long as you are not using the public 1.1.1.x network as an internal network (I've seen non routed security systems do this).  I would just put a block on the device.  Find it in the console client list,  if its wireless just put a block policy on it (you can always remove it).  If its a wired port, just disable the port.   I'd agree sounds like a rogue router device handing out DHCP.  Developers like to plug things in to add devices 🙂

[TBHPTL]

A lot of older system admind and "neck beards" routinely and incorrectly used 1.1.1.1 for virtual IPs, older controllers load balancers server instances for redundancy etc.. Wasn't really an issue aside from being flat out against standards until Cloudflare started actually using the quad 1 for WARP DNS. here is an old Cisco WLC doc for reference

https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/213535-wlc-virtual-ip...

[alemabrahao]

But in the case of WLC this IP was only used for redirecting the Captive portal, in this case it would not influence the functioning of the network nor generate any type of unavailability.

[PhilipDAth]

You need to methodically work through this.

Can you still ping your default gateway?  If not, has the MAC address changed (aka, something has taken over the MAC address of the default gateway).

Is your machine still showing that it is using the expected DHCP server?  Perhaps someone has plugged in another DHCP server.

Can you ping something on the Internet by IP address (e,g. ping 8.8.8.8)?

Can you ping your DNS server?

Can you do a DNS query?

Just keep methodically working through all the steps till you narrow it down.

[PatWruk]

I get this alert quite a bit. In our case, when a location loses power and comes back or if a switch is rebooted (causing the APs to go down) then come back up. The APs come back up with an IP of 1.1.1.1 (temporarily) for some reason. Then they go to the IP assigned to them.

If your issue is the same, it's not the alert causing the outage, it's the outage causing the alert.

Verify the mac addresses shown in the alert with your APs