Source IP and/or VLAN mismatch on C9300X

[rhbirkelund]

Hey

For the first time, I have this 9300X stack in Meraki Persona, that I'm working with on a customer case.

I'm seeing "Source IP and/or VLAN mismatch" in the Event Log about every 30 minutes on the clock, and for the life of me, I cannot seem to understand where it is coming from.

The switch is a member of a 2 member stack, where both MX'es in HA go into each member on port 24. The Mac address in the event log matches that of the interface mac of port 24 on the 9300X.

All ports on the 9300X stack are trunk, and are all trunking the exact same vlans. (Weird limitation btw to only support up to 1000 vlans in total, and they all have to be changed at once, in order to use vlans outside of 1-1000....)

The only other device connected to the stack is a MS255 switch on port 1 on Momber 1 only. This port is also trunk, and they match in both ends.

All switches and APs are management in Vlan 1, which is native. The MX is also default with VLan 1 native, and allowed all.

I can simply not grasp why I am getting a mismatch on Vlan 1 and 1023, according to the event log. There are no clients - wired or wireless - connected, and nothing that refers to Vlan 1023.

The only Meraki devices I have online is a pair of MX450, C9300X stacked, a MS225 and a CW9164, daisy chained all the way through.

[KarstenI]

Who is 10.45.0.2? Have you tried a packet capture to see what is happening?

My typical occurences of this error is when I have some suboptimal routing where traffic from the firewall is sent to the switch and directly back to the firewall.

[rhbirkelund]

10.45.0.2 is the management address of the C9300X stack on Vlan 1.

[PhilipDAth]

Is there anything dual connected - like an MX?  If so you could try an experiment, and temporarily shut down those ports to see if anything changes.

You could try and experiment, and remove as many devices as possible to see if you can get the error to go away, and then add them back in again till you see what causes the issue.

[rhbirkelund]

This core is a stack of two Catalyst 9300s. Besides ports 24 on each member which connects to the active and standby MX respectively, there's only on port connected to a MS225 further down - port 1 to 1 on the MS. On that MS switch there is only one Ap connected, and there are no wireless clients at all. So there really isn't many devices to remove and test with.

But great suggestion though!

[GIdenJoe]

Have you accidentally made an SVI on the C9300X with the same IP like the management address? 10.45.0.2?

[rhbirkelund]

No SVIs at all on the Catalyst.

[rhbirkelund]

So, fun stuff. I opened a case on this with Meraki Support.

Apparently, this is expected behaviour from the Catalyst switch, and is tied to a known issue which has been closed by the development team and will not be fixed. To change it will require a Feature Request.

By default and IGMP querier is configured on the Catalyst switches even though routing is not configured on the switch. The switch sends IGMP queries on all known VLANs, and this causes the MX to detact them as IP/VLAN mismatch since queries are sourced from it's Management interface.

So due to the expected behaviour of the catalyst, it is also expected that the MX will log them as IP/VLAN mismatch, as it continues to send these IGMP queries.

So in short, from Meraki: "Nothing to see here, move along".

I will try to keep my opinion to myself....

[GIdenJoe]

Interesting read.

It is to be expected that Catalysts work on a different way there will be issues albeit sometimes cosmetic with the full integration.

In this case however I haven't yet investigated if this is normal behavior on a Catalyst running in native DNA mode.  Normally IGMP snooping is enabled however I never heard that the IGMP querier feature would also be enabled at the same time by default.

If I get to a customer with native Catalysts I will try to capture this.