Question about mismatch vlan

[alsavi1984]

Hi, good afternoon,

I am completely newby Meraki technology.

I am checking a problem related with a misscheck configuration on a port that it has assigned a wrong vlan, or I dont know if it has a bad configuration on the customer server. I have tried to change the vlan in the port configuration but I can´t.

This message appears in the log event and notices that as I have explained before that there is a mismatch because vlans aren´t equaled. 

I´m completely sure that the problem is at customer side, but there´s an option to solve at meraki side, or on the contrary a report or log that show the problem is at customer side?

Thank you very much for your aid. 

Have a good day.

Cheers

[ww]

you cant change the vlan why?

The message is related  to that Port?

Is this  a server that uses  vlan tags/trunk? Or could you just change the Port to  a access port and set 1 access vlan.

[alsavi1984]

Thanks for answering soon. I message of the event log:

Source IP and/or VLAN mismatch source_client_ip: xxxxxxx, source_client_mac: xxxxxxxx, source_client_assigned_vlan: 200 «
last_illegal_ip_mapped_vlan_id 201
client_total_illegal_packets 966
all_total_illegal_packets 615974
last_reported_total 615479

If I click on the client link it shows the following info:

Port 39:

Network
IPv4 address: xxxxxxxxx
IPv6 address (link-local): 
MAC address: 
VLAN: 200 
Port forwarding: none
1:1 NAT IPs: none

And also the MS appliance has two port with the following info: one as example por 39 has configured vlan 200 and port 40 has the vlan 201. 

In this port I have found mac customers that have correctly ip adrress, but too have wrong ip adress. A few days ago, customer noticed myself that there could be a wrong configuration on esx, but to be honest I don´t know what happenned at the end.

[PhilipDAth]

That event log message is produced by an MX when a client is using an IP address from the wrong VLAN.

This is not an uncommon issue with notebooks that plug into one network (such as at home) and then resume or are plugged into a different network (such as at work) and commence using their existing IP address while waiting for a DHCP renew response.  They then figure out they are on a new network and get an IP address from the new network they are plugged into.

On the whole, ignore these messages unless you have something or someone actually not working.

[NolanHerring]

VLAN mismatch is simply letting you know that the VLANs being allowed on both sides of the TRUNK ports do not match. So the only fix is to make sure they do, so you'll want to have the customer confirm how they have their port configured (have them show you via screenshot or something) so that you can ensure your side matches.

[alsavi1984]

Thanks Nolan for your aid. I will post the same message I have put on the previous colleague box to answer him:  

Thanks for answering soon. I message of the event log:

Source IP and/or VLAN mismatch source_client_ip: xxxxxxx, source_client_mac: xxxxxxxx, source_client_assigned_vlan: 200 «
last_illegal_ip_mapped_vlan_id 201
client_total_illegal_packets 966
all_total_illegal_packets 615974
last_reported_total 615479

If I click on the client link it shows the following info:

Port 39:

Network
IPv4 address: xxxxxxxxx
IPv6 address (link-local): 
MAC address: 
VLAN: 200 
Port forwarding: none
1:1 NAT IPs: none

And also the MS appliance has two port with the following info: one as example por 39 has configured vlan 200 and port 40 has the vlan 201. 

In this port I have found mac customers that have correctly ip adrress, but too have wrong ip adress. A few days ago, customer noticed myself that there could be a wrong configuration on esx, but to be honest I don´t know what happenned at the end.

I don´t Know If I could do any change or not to try to solve it.

[GaryShainberg]

@alsavi1984 I think @PhilipDAth has added a comment below saying if all is physically working, ignore the error and hopefully it will sort its self out, however, if you want to look deeper, the first thing I would do is remove the connection to Port 40 from the Esxi box and see if the error clears, this way you know where the error is coming from.

If the error clears , great, if not then re-enable port 40 and remove 39 - again see what happens.

On both ports of the Esxi box are the IP's static or DHCP - I would make sure they are DHCP and then, when you see them appear in the client log's make then fixed assignments on the MX (in effect making them static) but this way you can also check that the esxi box is picking up the right IP's (and sitting in the right vLAN's)

[johnhinckley]

IMO, the MX VLAN mismatch behavior is a bit of a design flaw because it essentially breaks the default routing advantage.  You have 2 ways of dealing with this:

1.  Add VLAN SVIs for every subnet on the LAN and make sure those VLANs are trunked across all switches.  Even with this configuration you will still occasionally see VLAN mismatches. 

2. My preferred method - Create a Layer 3 separation between the MX and the LAN and then route all subnets to the MX from your core L3 device.  This will ensure that all LAN traffic destined for the MX will show up on L3 and can never trigger a VLAN mismatch.  It also prevents any LAN devices (other than L3 uplinked device) from being able to ARP to the MX.  From a security standpoint, option 2 is a much better practice.  

I commonly run into this problem on the MX platform.  It's extremely annoying and IMO, doesn't add any value to the product.  

-John

[PhilipDAth]

I'm not with you on that one @johnhinckley.  It's not about creating SVIs.  There is no default routing advantage.

All you have to do is have the same port VLAN configuration on both ends of a link.  It is only a point to point concept.

[johnhinckley]

@PhilipDAth I don't follow you.  If I have a voice subnet on my LAN that needs to traverse a L2L tunnel, I don't want to put an SVI for that subnet on the MX and expose L2 voice traffic to my edge device.  I would rather my core L3 device receive those packets first, apply any QoS and then route them (using default route) to the firewall.  But because the MX doesn't have an SVI on the voice subnet in this scenario, it won't like receiving packets stamped with a different VLAN. This effectively wastes the default route. 

Some topology for discourse:

data VLAN 1 = 192.168.1.0/24

voice VLAN 2 = 10.10.10.0/24

L3 gw = 10.10.10.1, 192.168.1.1  [default route: 0.0.0.0/0 192.168.1.2]

MX = 192.168.1.2 (assume it has route for voice sub)

phone 10.10.10.2 => L3 gw 10.10.10.1 => default route => MX 192.168.1.2 => ** VLAN mismatch**

An ASA does not have a VLAN mismatch problem when packets from other subnets are routed to it.  Routing is a function of L3, not L2, so why is the MX looking at VLAN tags on L3?

Routing happens at L3 so I don't see the value in enforcing the VLAN match.