VLAN mismatch when there is no mismatch

[johnhinckley]

I frequently see MX appliances gripe about a VLAN mismatch when there clearly is no mismatch. Not only does the subnet match the VLAN but the logged event is not even applicable because this is 100% routed traffic; the MX does not RX/TX on a VLAN interface.    

Here is an MX log snippet of some mismatches: 

Here's one of the clients as it shows in the switch; as you can see, it's on the correct VLAN:

Here is the MX route for the subnet the client (above) is using:

I see nothing mis-configured, so can someone please explain to me why the MX is logging a mismatch here?  An ASA would have zero problem with this configuration and I don't understand why the MX does.

Thanks,

John

[NolanHerring]

Can you show us how the port on the MX is configured please 😃

[NolanHerring]

And the port on the switch the MX connects to

[johnhinckley]

Kinda replying to everyone here.  Here's a lousy diagram of the connectivity:

The MX connects to a pass-through interface on a barracuda filter and then hands off the traffic to the core switch on a trunked interface using native vlan 1.  The MX only has 2 VLAN interfaces, VLAN 1 for data traffic and VLAN 99 which it uses to hand out mgmt DHCP addresses to the Meraki gear (switches, APs, etc).  

Here is the trunk ifc to the barracuda pass-through:

As far as the MX LAN port, there really isn't much to configure there except speed/duplex, so I'm not sure why you'd want to see that. It's currently set to auto/auto. 

Before everyone throws their hands up over the Barracuda....it's just bridging the traffic and watching it as it passes through and that's it.  Completely L2.  The mechanism for blocking the client is handled from a different interface on the LAN side (VLAN 1). So it's not doing anything to the traffic.  

So the flow is this:  Inet => MX (access vlan 500) => MX LAN ifc => Bcuda L2 => MS350 Trunked on native 1 => Client or access switch => Client

The MX can only talk on VLANs 1 & 99.  All the mismatched VLAN messages are referencing subnets which are being *routed* between the MX and the LAN.  L2 should not be involved except to ID the transport VLAN (1 or 99).

This is not a very sophisticated flow at all.   

Firmware on the MX is up to date:

FIRMWARE

Up to date

Current version: MX 14.40

-John

[johnhinckley]

Is this happening because the trunk link to the switch is passing the broadcast traffic from all VLANs?  I can't see any other potential reason for the mismatch. 

[ww · Accepted solution]

You  can check using  the packet capture on the lan side of the mx. You could also force the specific allowed  vlan instead  of trunk  all.

[johnhinckley]

This was my next step anyway.  I'll lock it down to 1,99 and see if the mismatch goes away. 

IMO, the MX should just be dropping broadcast traffic that doesn't match any of its VLAN interfaces instead of processing it and complaining about a mismatch.  The events don't show L2 broadcasts so why would its L3 interface even care about packets from subnets it doesn't have an interface for?  Its L2 should not even be handing those packets off to L3.  

[PhilipDAth]

That does look wrong.  Are you running a recent release of the MX firmware?

[ww]

Did you config your network  like third picture?

https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/IP_Source_Address_Spoofing_Protecti...