Cloud Track

RaphaelL
Kind of a big deal
Kind of a big deal

Cloud Track

Hi guys ,

 

This is fairly new right ? : 

 

https://documentation.meraki.com/MX/Monitoring_and_Reporting/Client_Tracking_Options

 

Spoiler

Cloud Track

Cloud Track is a Meraki technology that leverages network topology and device information to uniquely identify and track clients. It uses an algorithm that intelligently correlates client MAC and IP addresses seen across the Meraki stack, allowing the security appliance to generate a unique identifier for each client in a combined network with other Meraki devices. This is specifically useful when there are Meraki MS switches routing layer 3 between end clients and the security appliance, which segregates broadcast traffic containing the client's MAC address.

This method should be used only if the network has downstream layer 3 routing devices that are all Meraki devices. In this deployment scenario, tracking by IP would otherwise require the security appliance to be split into a separate dashboard network, as tracking by IP is not supported in combined networks. Tracking by MAC would fail to identify end client devices due to the layer 3 boundary, associating downstream client traffic to the routing switch and negatively affecting network usage numbers in dashboard

6 REPLIES 6
NolanHerring
Kind of a big deal

Yup. Fine print notes mention that you have to have a L3 switch downstream of the MX. I don't, so I don't see the option at all.

I would prefer they simply gray out the option with a 'note' about why its grayed out, so that I would at least know it existed.
Nolan Herring | nolanwifi.com
TwitterLinkedIn

More specific, a Meraki L3 switch 😉

 

I've got a 2960x as layer3 switch and still can't use it.

Nash
Kind of a big deal

I think it wants the L3 switch to be in a central location, too. I've got a network that goes:

MX -> MS120 -> MR74 ~ ~ wireless bridge ~ ~ MS210

Clients end up showing up very strangely. Things on the MX side weren't always identifying by device name. The clients that weren't identifying correctly, I couldn't assign a group policy to them - the option was completely missing from the client page. 

 

I wish I had a network that was a little more standard to test it on, but alas.

Roger_Beurskens
Building a reputation

no possibility to connect the ms210 wired? or just swap the 210 and 120 as test?

Nope, no chance at all. Client didn't want to dig a trench across the parking lot.

 

Which... ended up being a good thing, since the original remote building was a little bit completely destroyed by flooding this summer, and no longer exists. My remote end is currently a converted shipping container. 🙂

GIdenJoe
Kind of a big deal
Kind of a big deal

I have a few customers where I use an external VLAN on the same switches to split an ISP modem into two ports for both MX'es.  According to the docu, I should add another switch that's not in the same dashboard network.
So for those customers the feature cannot be used because I don't intend to introduce other switches just for this feature to work.  I hope they find a way around that.

But all in all it's a move in the right direction since having an L3 switch behind the firewall has always been best practice design in campus environments.

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels