Unique Client Identifier WAN ports connected to network switch

[Bucket]

Regarding Unique Client Identifier, the documentation states follwing:

• Do not use Unique Client Identifier in a dashboard network where the MX's WAN ports are connected to a Meraki switch in the same Dashboard network. If you need to use a Meraki switch in between your ISP and the MX WAN please separate this switch from both the dashboard and physical network.

What happens if you do it anyway? 

[KarstenI]

Actually I don't know but I would expect anything from sweaty feet to apocalypse. With unique client identifier there is a correlation done between seen IP- and MAC-addresses. I expect for this to work all switches have to be on the LAN side where the Meraki switches can see both of these. On the WAN side the switch sees the WAN-MAC addresses and public IPs and probably does not know how to correlate them.

And personally, I would not waste a shiny Meraki-switch for that. Nowadays I typically use Catalyst 1000 switches on the WAN side.

[Bucket]

The thing. It's is already running this way 🙂

Bare in mind that there is a dedicated VLAN for the WAN subnet between the ISP and the MXs WAN ports. 

I'm just wondering if it could have performance impact or if client identifier is only used for monitoring purpose. 

[DarrenOC]

@KarstenI  - sweaty feet to apocalypse 😂🤣

[PhilipDAth]

I don't know the answer.

I suspect you'll just get some "muddied" statistics with the outside NATed traffic of the MX also showing as a client in the client statistics.

In other words, the MX will itself show up as a client.

If may cause some traffic to be counted twice, and traffic analysis might show double what it should be.  This is because the network will see the traffic entering the MX, and then see it again leaving the MX.

I don't think it is that big of a deal if this is the case.

[turipriv]

It will simply mess with your client statistics, as every hop seen by you ISP devices will be seen as client associated with the MAC address of those devices.

[cmr]

To be honest unique client identifier doesn't work on either of our full stack sites and we have an open support case from March last year where support are still working on it...  I would love it to work, maybe one day 🤞

[KarstenI]

@cmr that's interesting. I also had a case open because it did not work as expected. For example in the summary report for the appliance, the "Top clients" only had the MAC-address of the Meraki Core stack. Support told me that it can not work as there was another L3 device in the network. Well, that was the VPN-ASA and this device definitely did not play any role here. I told Support that I have the same observation on pure Meraki networks where the only L3-devices are the Meraki Core stack and the MXes. But support insisted that it is caused by the additional L3 device ...

[cmr]

@KarstenI at the site I originally reported we have a stack of MS210s in L3 mode, a pair of MXs connected by a transit VLAN and a 3rd MX acting as a DHCP server.  No 3rd party L3 there...

[KarstenI]

Oh, that's interesting, why did you go for an additional MX for DHCP?

[cmr]

@KarstenI we wanted to trunk all the VLANs that need DHCP to it as an MX needs an interface to create a DHCP scope and our main data MX pair use a transit VLAN between them and the L3 MS210 stack to keep the site to site routing simple (a class b range that is broken down into multiple class c VLANs on the L3 stack).