VLAN Mismatch and Best Practices

[RobMcLean]

I have a MX84 connected to a MS125-24P, which feeds a MS220-8P and a MS120-8.  2 MR33 are directly connected to the MS125 and a 3rd is connected to the MS220.  There is also a 4th MR33 acting mesh mode usually connected to the MR33 connected to the MS220.

I have 6 VLANs defined on the MX:

2 -- MGMT -- X.X.2.0/24 -- DHCP on MX

5 -- Wireless -- X.X.5.0/24 -- DHCP server on internal LAN

10 -- Wired -- X.X.10.0/24 -- DHCP server on internal LAN

16 -- Prod -- X.X.16.0/24 -- NO DHCP

99 -- Guests -- X.X.99.0/24 -- DHCP on MX

666 -- Native --10.66.6.0/24 -- NO DHCP

The MX is connected to the ISPs router with a single ethernet connection with a DHCP private address and no VLAN set.

All switches and APs are set to management VLAN 2 and are pulling DHCP addresses from the MX.

The MS125 is connected to the MX with a single ethernet port set to trunk with native VLAN set to 666.

The MS125 is connected to the other 2 switches via 2 ethernet ports set as aggregates and trunked with the native VLAN set to 666.

Links to the APs are set to trunks with the native VLAN as 666.

Currently all trunk links are set to allow all.

I have 3 SSIDs setup: all VLAN tagged

CreepyCrawly -- for Guests -- DHCP coming from the MX and no access to the internal LAN (VLAN 99) and set to NAT Mode

BigBrother -- for internal LAN clients (VLAN 5) and set to Bridge Mode

KillTrees -- for a wireless printer that only supports 2.4G and no 802.11 r or w (VLAN 5) and set to bridge Mode.

Now to my issue.
I am seeing that I have a couple of Apple devices registering a 'Source IP and/or VLAN mismatch' in the MX event log about every 30 minutes.

source_client_ip: X.X.5.3, source_client_mac:AN:DC:HE:EE::EE:SE, source_client_assigned_vlan: 16
last_illegal_ip_mapped_vlan_id 5
client_total_illegal_packets 136
all_total_illegal_packets 136
last_reported_total 54

The above is for an iPhone that is connected to the 'BigBrother' SSID and is pulling an IP in VLAN 5. 

What exactly is mismatching here?  

How do I fix this?  Should I even worry about it if everything is working fine?

[PhilipDAth]

This happens when a client uses an IP address that doesn't belong to a VLAN it is in.

The most typical case is where someone uses a device attached to one device, the device goes to sleep/low power mode, and then wakes up in a new location with a new network.

It tries to use its existing IP address initially.  The DHCP renew fails (can't talk to the old DHCP server) and then it DHCPs a new IP address and everything works again.

Typically these cases are not resolvable.

In your case I guess it could also happen if the users are moving between the guest and internal WiFi SSIDs.

[RobMcLean]

All that makes sense, but does not apply here.

The iPhone is not moving between SSIDs and is always pulling .5.3 address.  I even have a reservation for it in DHCP.  Most of the time it dose not even move between APs.

Also the event is being logged every 30 minutes like clockwork. I have tried to do packet captures, but can not find anything that reveals why.

[BlakeRichardson]

@RobMcLean  That doesn't sound right, I would open a support case. 

[rhbirkelund]

May we see the vlan configuation on the ssid?

Stupid question here; if you have a reservation for the IP address in DHCP settings, have you verified that it's the correct DHCP server that the reservation is configured on?

[RobMcLean]

I know the IP is being served by the LAN DHCP server because I can look in the console and see the reservation is active, and I can see from the MX event logs entries for the client DHCP lease and it lists the server as the IP of the LAN server.

SSID VLAN Config:

VLAN tagging  Bridge mode and layer 3 roaming only

Use VLAN tagging

VLAN ID

AP tags VLAN ID Actions All other APs 5

[RobMcLean · Accepted solution]

I think I have solved the issue.  So far no more VLAN mismatch errors in the event log.

I ended up ensuring that only necessary VLANs were allowed on the trunk links instead of 'ALL'.