Showing results for 
Search instead for 
Did you mean: 

TrustSec Dynamic Classification - impact on ISE scaling

Michal Rzepecki

I’m planning TrustSec for a new network based on C9K switches.

If I would like to use 802.1x on access ports and dynamic classification with ISE, do I need SXP session from ISE to every access switch where dynamic classification occurs?

When endUser is authorized by ISE and dynamically classified (some SGT is applied), is the SXP only option to inform this switch about a tag?

I’m asking because I’m not sure if dynamic classification on access switches needs to take into consideration ISE scaling aspect.

In small ISE deployments very few SXP sessions are supported.


Accepted Solutions

I'm not aware of any third party switch that understands TrustSec, not to say they aren't out there (non Cisco firewalls have added support), but ISE will still be capable of assigning the user session an SGT and thus generate an IP to SGT binding. ISE will send the SGT as a radius attribute, the non trustsec switch usually ignores it since it doesn't know what to do with it. I've used this successfully but it really just depends on how the access switch handles unknown radius attributes.

In this case, you can build an SXP connection from ISE to an enforcement point upstream. In cases like this the typical is to enforce North South flows in to/ out of the DC, or across the WAN. No access switch East West enforcement since the access switch wouldn't be TrustSec capable.

View solution in original post

Damien Miller
VIP Advisor VIP Advisor
VIP Advisor
There is usually a large design component when implementing TrustSec. It's going to depend on what security goals you are trying to accomplish. TrustSec is typically looked at in a North-South, or East-West enforcement strategy, where East-West includes North-South. In my mind East-West is the ultimate goal when looking at segmentation with TrustSec, being able to restrict device communication on the same access switch.

TrustSec tags are propagated in three ways, and often an end to end solution involves all of them at various places.

1. Inline - Inline tagging is the ultimate and most scalable method of propagating SGT's. It is carried in the layer 2 header, but due to this also requires hardware/software support. It changes the header the same way a vlan tag does when you configure trunking. If you have an all Cisco LAN, and ISR's/ASR's at the WAN edge, then you can enable CTS manual on uplinks to carry the SGT's from the access layer upstream inline.

2. SXP - SXP is a method of communicating SGT's out of band and in large environments is introduces complicated scaling considerations. It works great up until the point that it doesn't. Places where it comes in very handy could include spanning a wireless bridge in the LAN, communicating SGT's from a WLC to the core switch, in some small environments across the WAN, or from ISE to an ASA. You typically use it where you can't leverage inline tagging. Honorable mention, SXP is also good at plugging "holes" in the TrustSec domain, defining Subnet to SGT mappings in ISE, and communicating those out as a stop gap.

3. PXGrid - You are able to integrate both Cisco and third party systems with PXG and communicate IP to SGT bindings or user context from ISE. Examples here include Web Security Appliances, Stealthwatch, or Checkpoint firewalls.

In order to accomplish end to end segmentation as I would like every environment to get to, you need network infrastructure capable of supporting it. At the scale I'm usually working at, this means #1 inline tagging in every possible location. In the LAN this is accomplished with Cat3k, Cat4k, Cat6k, Cat9k, IE series, and ISR/ASRs. A large piece that I hinted to with SXP section above was how you deal with the WAN. Most traditional WAN transports do not support inline tagging without an additional overlay. Inline tagging capable overlays for the WAN include GETVPN, DMVPN, and IWAN, but a major no show to the party right now is SDWAN(Viptela acquisition). How you handle the WAN is the hardest part in my mind.

As you already found, ISE communicates the SGT down to the access switch via RADIUS attributes during the authorization phase. As I have just tried to demonstrate, this is not the only place where you can begin to leverage it. ISE maintains the IP-SGT bindings locally and you can use SXP or PXG to introduce them in other areas of the network.

I recommend taking a look at at some of Darin Miller's or Kevin Regan's TrustSec/SGT/SXP related sessions. There are many ways to skin this cat, it really just comes down to what you want to accomplish and what's the best way to get there. Things are also changing a bit with the introduction of DNA's SD Access, but traditional TrustSec /w ISE is still a great mature and scalable solution.

View solution in original post


Aravind Ravichandran

You can use the inline tagging method.SXP can be used in case if the device doesn't support inline tagging & SXP is to advertise IP-to-SGT mappings.


Michal Rzepecki

I found information about how it works in 3750 config guide.


SGT is passed to the authenticator switch in the last packet of the 802.1x authentication session so no SXP session is needed here.


I have another question - if endUser_A is 802.1x authenticated on non Cisco (non trustSec) switch, and SXP session is estabilished from ISE to Cisco TrustSec capable switch,

-will Cisco switch be informed about IP-SGT binding through SXP?

-will Cisco switch propagate learned SGT, inline to other Cisco TrustSec switches in domain?