Jklein,     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. ... View more

@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: https://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise-networks/trustsec/trustsec-meraki-ms-switch.pdf     ... View more