TrustSec Equivalent for Meraki

Here to help

TrustSec Equivalent for Meraki

I'm just curious does the MS series work with TrustSec? If not is there a way to get the same features using a MS350?
Head in the Cloud

Hello @Jklein To my knowledge none of the MS line supports Cisco TrustSec.

Eliot F | Simplifying IT with Cloud Solutions
Found this helpful? Give me some Kudos! (click on the little up-arrow below)
Head in the Cloud

@Jklein wrote:
I'm just curious does the MS series work with TrustSec? If not is there a way to get the same features using a MS350?

I'm not a Cisco guy (we use HPE/Aruba/Procurve). Quickly looking at the specs, it uses Cisco ISE right? Most of the Meraki lineup does have some support for Cisco ISE. This document seems to have a pretty up to date listing of the capabilities:

BHC Resorts IT Department
Meraki Employee

@Jklein  They do, and they don't.  

Let's cover the simple part first - Meraki switches do not support Secure Group Tags.  Meraki switches are unable to provide host to host segmentation in the same VLAN using SGTs.

However, TrustSec  has a process to enable a TrustSec fabric to extend to a non-SGT enabled edge.  This capability leverages ISE to make IP-SGT mappings and pass them to SGT enforcement points in the network.  Meraki has the ability to send the necessary information to ISE, allowing a Meraki L2 edge to support a TrustSec enabled network from datacenter, WAN, and core.

Here is a whitepaper example:




Ok so ultimately it can be done it's just a little trickier with Meraki


If I'm reading the diagram correctly basically it consists of using a Nexus 7k at the network border. I'm guessing we're using something similar to OTV similar to how you use it for DCI?
However it works that's going to give us the the information for the IP tags that will be fed to the Access Switch Say a MS 350. Then we use 802.1x?




Consider if the Meraki MS switch is at the access layer, and the Nexus 7k is the core.  Ignore the ASR for this scenario.  We aren't using OTV or anything crazy like that.  A user authenticates on the MS switch with 802.1(x), and the MS passes the client's IP address over RADIUS to ISE.  ISE then sends the IP to SGT mapping to the Nexus over SXP.  

The MS350 is unaware of the SGT enforcement at the core.  It authenticates a user via 802.1(x) and places that user in a VLAN.  The L3 boundary is at the Nexus, and that is where the SGT / TrustSec magic happens.  This actually isn't technically in the whitepaper, but I hope you can see that the SVI for the VLANs on the MS could easily reside on the Nexus for a campus deployment.


The ASR allows this document to also show a case where the Meraki switch is multiple hops from the datacenter core, for instance over a WAN.  In that case, the same scenario happens, with SGT encapsulation and enforcement at the datacenter.  The traffic runs across the network represented by the ASR un-SGT-encapsulated, until the Nexus applies SGT and enforces policy.

So basically forget the OTV reverse the position of the Switches. The Meraki MS would be a the network border and the 7700 would be the core switch.

So it's kind of like a leaf and spine configuration. Except the leaf is the MS at the network edge and the spine is a 7700 series?
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.