Unique client identifier buggy

[GIdenJoe]

Hi all,

I recently got a ticket from a customer that I still need to get to about the inability to locate clients on a full Meraki network.
This is a customer that I migrated a year ago to a MX and MS network where the core switch is layer 3.
One of the issues back then was the fact that the MX sees traffic differently than the MS so you get a 'bonus' client carrying the core switch's mac address with a hole slew of traffic the MX saw differently than the switches.
Then they had a new feature called unique client identifier that is supposed to clear that mess up.

So I moved that customer to that option in the hope if fixing it.

However as I said in the beginning of this post there are new issues popping up.

Leaving this customer and now talk about my current project which is a nice Meraki project having 17 sites with all MX'es and a ton of MS switches and another ton of MR AP's :).

We are in the process of starting to migrate the client from brocade switches to Meraki.
To have the best possible start position we are building the Meraki stack next to the current infrastructure.
So the MX'es will have their own ISP internet connections with AutoVPN running across to serve as WAN.
And all devices will be migrated into a new IP numbering scheme and VLAN scheme.
However in the transition period we are having a port-channel link with trunk configuration carrying the old VLANs from Brocade to the Meraki switches and having the old VLANs on the Meraki switches so we can migrate the current devices.

So with unique client identifier we should only have clients visible to the switches, not so much to the MX'es since the VLANs are not stretched across.

Now I've first hand experienced the problems the other customer was having.

1) Clients are ONline, but appear OFFline in the clients view.  Some fluxing between the two states.

2) Clients are reported to be on the COREswitch Aggregation ports instead of on the access switches which causes the link view of the client connected to the switch say it's offline.  And it makes it hard to track where a client is connected to yourself.
3) Clients don't seem all to have IP addresses when they are actually sending IP packets.  Or even when you use the dashboard ping feature itself.

The appliance is on 14:42 and the MS's are on 12.28.

[cmr]

@GIdenJoe any reason why you are using such an old MX firmware, 14.53 is current and about 6 versions newer?

[Bruce]

If the clients are always incorrectly appearing on the aggregation (AGGR) port then I’d think that for some reason frames from the Meraki network to the Brocade are being reflected back to the Meraki switch again (although I’d have no idea why), and hence why you’re getting the client (which is identified by MAC address) appear on the AGGR port when it isn’t really there.

The other option is that you’re using MS390 switches... and that’s a completely different issue 🙂

[GIdenJoe]

First: I went out of my way to explain the first customer which is on full stack Meraki having the exact same problem 🙂
So I don't think the Brocade's have anything to do with it.

The network will receive the upgrade on Sunday 8PM.
They are slowly being installed and that is the firmware they were delivered on.

[BlakeRichardson]

Odd things happen if you have 3rd party switches sitting in between Meraki switches. My dashboard is reporting clients connected to port 25 on a 8 port switch....

Support has said this is a known issue and they can enable a setting that should fix it.

[GIdenJoe]

Once again, the Brocade switches are not sitting between anything.
They are only connected to allow the old VLANs to bleed over.

However the other customer who ONLY has Meraki has the exact same problem.