Anyone else see wildly inaccurate client data on the "Clients" page of the dashboard?
My clients, almost always show on an incorrect switch, usually on the up link port. ie. ClientA, which is workstation plugged in to IDF1-02, shows connected to IDF5-01 (not at all the correct switch).
This is super frustrating and essentially makes the client page on the dashboard useless. We also see inaccurate client data.. ie. a computer named ComputerA, which has not physically been plugged in for over a year, shows connected, yet the MAC address is another device on the network.
We have a very simple deployment:
Cisco 9500 core switches (pair)
Cisco 9k TOR switches (two set up in a pair)
Two Meraki Stacks (MS225-48FP) both connected directly to core
Four other single switch deployments, all connected directly to core
+10 WAPs connected directly to Meraki switches
No other switches in the network, all clients are connected to Meraki switches or APs, with the exception of data-center things that are connected to the 9k stack.
I'm going to guess that for a specific layer 3 vlan, you have two or more Meraki switches plugging directly into the 9500 rather than each other?
What I'm guessing is happening is a client is generating multicast or broadcast traffic, and multiple Meraki switches are seeing it. The switches involved that are seeing it are not connected through a Meraki switch, so they are unable to determine the true source of the client traffic.
If you had a Meraki core switch this issue is unlikely to happen.
Are you able to configure thre VLAN trunking on the 9500 so that each IDF Meraki switch sees a unique set of VLANs, or operates in seperate layer 3 domains?
If you trunk all (or many) VLANs to all IDF switches, are you able to make a pair of Meraki switches a sub-core (distribution layer), so that all the other Meraki switches can plug into, and plug the sub-core into your 9500?
Correct, the 9500 is the core, and the RSTP root. All other switches are connected to the 9500 for redundancy. The two MS225-48fp stacks have two connections each to the core, and each of the other smaller idfs (single switches) have a single connection to the core.
VLANs are distributed to from the core outward to all switches, as this is a small corporate environment with a necessity of having most all VLANs available at each IDF for clients.
It would be difficult to create a "sub-core" as the Meraki infrastructure is designed for client access.
I could move the connections theoretically for the other IDFs into the Merakis, but that presents other problems like not having enough port density in the "sub-core" Meraki's for redundancy.
The idea with this design was easily manageable client access side, with a robust core that also serves the local datacenter.
Are your Catalyst switches being monitored in the dashboard? In my experience, for the client information to be accurate you either need the Meraki switches to be the L3 ones or monitor the Catalyst switches. Also if you use port channel trunks between the Catalyst and Meraki switches then it will still be inaccurate, as at the moment clients on these connections are not seen by the Meraki monitoring for Catalyst. Things are improving all the time, so I am sure it will get there.
@cmr : currently the 9500 and 9k switches are not monitored in the dashboard. Also, we for sure use port-channels on the 9500 at least to the two meraki stacks, because there are two 9500s configured together for redundancy, and each meraki stack has a connection into the core 9500.
Sounds like I will just have to continue to deal with inaccurate data for the time being. My setup doesn't seem like an edge-case. It's not very complicated.