Disabled Gateway (bad IP assignment)

[antoine.bak.59]

Hello

i have the following message on my Meraki

Disabled gateway - Bad IP assignment

My meraki switches are the folllowing:

C9300-24UX

C9300-48UXM

meraki switches are statically IP assigned

The default gateway is a fortinet playing the L3 routing.

I have a 9500 cisco, meraki monitored, with C9300 switches connected to it.

I tried :

- clear ap on fortinet

- change IP on 9300 switches

- reboot switches

I have also two meraki switches MS120, they are online with no error message

same for the 9500, online no error message

I suspect an issue with the C9300-M switches. Are you aware about possible issues with these devices ?

Thanks mate

Antoine

[MerakiGnome]

More than likely a duplicate IP on the network. Is there a dhcp scope setup for this range? Did you reserve the IPs within the dhcp scope so they would t be assigned elsewhere? Maybe try changing the IP in these switches to see if the issue clears

[antoine.bak.59]

Thanks for your reply

It was my idea as well

I tried already to change the ip but not betterave

I ask to change the dhcp scope to a range different than the static ips of the switches

But before the static ips were included in the dhcp scope

[MerakiGnome]

When you changed the switch IP how long did you leave it there for? Some alerts can take a while to clear in the dashboard

[michalc1]

Hi @antoine.bak.59 ,
Please follow the instructions from the Bad IP Assignment Configuration KB and let us know if any of recommendations helped.

[DWAM]

Hello, we apply all the recommandations but the problem is still present. All ideas are welcome.

[MaghM]

Hi @antoine.bak.59

You can as well take packet capture and check for Duplicate IP with the filter "arp.duplicate-address-frame", if there's duplicate address and if you made some change, the alert can take some time to clear from the dashboard.

[DWAM]

Hello MaghM, we did some captures from L3 - Firewall We didn't see the arp.duplicate-adresse-frame. The problem occurs randomly only on 9300M. Do you think we should have switch logs? we see nothing inside.

[MaghM]

Hi @DWAM ,

Alert means a bad static IP or an incorrect VLAN tag with DHCP is being assigned to the Meraki device. Typically, network hardware will simply not work if you assign a bad IP address to it. Meraki devices, however, will automatically switch back to DHCP (automatic IP assignment) so that it can check in to the cloud and alert you about the problem if at all possible. Referenced Here.

Would advice when you notice the issue occurring take packet capture on the upstream of the device, meanwhile Local status page can be checked while the capture is downloading to check if there's any error highlighting.

As been confirmed the issue is occurring randomly, hence sooner is better to check the above, as the UI sometimes takes time to clear the alert so you might see the alert but in reality the issue is recovered.

[DWAM]

Thanks for the answer.

How can you explain that the problem is present for 9300M and not for 9500 or MS210. Every device has the same configuration (static IP configuration).

Best regards.

[MaghM]

Hi @DWAM ,

The error itself is not related to specific type or model, this error is available for all devices.

If you went through all the troubleshooting steps mentioned here and still the same, you can try to swap one of the known working static IP between the devices so you can check if the issue is following up.

[antoine.bak.59 · Accepted solution]

Hello,

thank you so much for your support

Issue is solved

The 9500 is meraki monitored.

This action has created the tracking of all the interfaces included the interfaces towards the firewall.

The command looks likes this:

interface port-channel

device tracking attach-policy MERAKI_POLICY

With a show device-tracking messages, we can observe packet drop on the port channel between the 9500 and the fortinet

The solution is to apply this on all the interfaces especially on the ports towards the gateway

device-tracking attach-policy NOTRACK

The management of the switches is stable now

I'm not sure these tracking commands are useful for the monitoring of core switches.