Unique Client Identifier WAN ports connected to network switch

Bucket
Comes here often

Unique Client Identifier WAN ports connected to network switch

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? 

10 REPLIES 10
KarstenI
Kind of a big deal

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
Comes here often

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. 

UCcert
Kind of a big deal

@KarstenI  - sweaty feet to apocalypse 😂🤣

Darren O'Connor | uccert.co.uk
https://www.linkedin.com/in/darrenoconnor/

I'm not an employee of Cisco/Meraki. My posts are based on Meraki best practice and what has worked for me in the field.
PhilipDAth
Kind of a big deal

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
Conversationalist

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
Kind of a big deal
Kind of a big deal

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
Kind of a big deal

@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
Kind of a big deal
Kind of a big deal

@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
Kind of a big deal

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

cmr
Kind of a big deal
Kind of a big deal

@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).

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.