SD-Access TrustSec, VNs and SGs

Network Automation
1

Hello, everyone.

I have some questions regarding the SD-Access fabric that weren’t mentioned in the NW lessons.

From what I understand, the various security policies in the fabric can be either statically or dynamically configured via Cisco TrustSec, which I assume is configured on platforms such as ISE?

If I understand correctly, the benefit with TrustSec is that we can assign a tag to each user after they authenticate and based on the assigned tag we can process various security policies (allow/deny them access to certain parts of the network, etc.) instead of relying on IP addresses, MAC addresses, etc which is more easier to manage than the traditional ACL/VLAN segmentation way of applying policies.

So since we’re identifying users based off these tags, regardless of whether the user roams somewhere or connects wirelessly or to another switchport, they will still have the same policies applied because they have been tagged.

How is this tag applied? What makes logical sense to me is to apply it to the user credentials. Say, if someone with a name of John and a password of Cisco joins in, they should have the tag applied.

After the SGT tag is assigned, an access enforcement policy
based on the SGT tag can be applied at any egress point of the TrustSec network. In SD Access, Cisco TrustSec Security Group Tags are referred to as Scalable Group Tags

My next question is, why are packets filtered at the egress node? Imagine that a host connected to Edge1 talks to someone connected to Edge2. The policy states that this cannot be allowed. Does this mean that Edge2 would therefore filter this traffic? Why not Edge1? Edge1 will add the tag when forwarding the traffic over the VXLAN tunnel to Edge2, so why cannot it drop the traffic instead?

And I have a question about the following explanations from my book

A better understanding of the benefits and operation of Cisco SD-Access requires an examination of the following concepts related to the operation and interaction of the multiple technologies used by the SD- Access solution:

■ Virtual network (VN): The VN provides virtualization at the device level, using VRF
instances to create multiple Layer 3 routing tables. VRF instances provide segmenta-
tion across IP addresses, allowing for overlapped address space and traffic segmen-
tation. In the control plane, LISP instance IDs are used to maintain separate VRF
instances. In the data plane, edge nodes add a VXLAN VNID to the fabric encapsula-
tion.
■ Host pool: A host pool is a group of endpoints assigned to an IP pool subnet in the
SDA-Access fabric. Fabric edge nodes have a Switched Virtual Interface (SVI) for each
host pool to be used by endpoints and users as their default gateway. The SD-Access
fabric uses EID mappings to advertise each host pool (per instance ID), which allows
host-specific (/32, /128, or MAC) advertisement and mobility. Host pools can be
assigned dynamically (using host authentication, such as 802.1x) and/or statically
(per port)

■ Scalable group: A scalable group is a group of endpoints with similar policies. The
SD-Access policy plane assigns every endpoint (host) to a scalable group using
TrustSec SGT tags. Assignment to a scalable group can be either static per fabric edge
port or using dynamic authentication through AAA or RADIUS using Cisco ISE. The
same scalable group is configured on all fabric edge and border nodes. Scalable groups
can be defined in Cisco DNA Center and/or Cisco ISE and are advertised through
Cisco TrustSec.

There is a direct one-to-one relationship between host pools and scal-
able groups. Therefore, the scalable groups operate within a VN by default. The fabric
edge and border nodes include the SGT tag ID in each VXLAN header, which is car-
ried across the fabric data plane. This keeps each scalable group separate and allows
SGACL policy and enforcement.

The SD-Access fabric uses EID mappings to advertise each host pool (per instance ID), which allows host-specific (/32, /128, or MAC) advertisement and mobility.

Does this mean that each edge switch will report to the control nodes what hosts are connected to it or does it advertise the entire pool? Those two sentences feel like they counter eachother.

The SD-Access policy plane assigns every endpoint (host) to a scalable group using TrustSec SGT tags.

As for the scalable groups. It says that it’s a group of endpoints that have the same policies and that the group is assigned using tags. So if I assign a tag like “IT-DEPARTMENT” to some devices, will they all be in the same scalable group? Can I, on the other hand, assign them to different scalable groups and apply policies even if they are on the same subnet without the need of deploying VACLs, MAC ACLs, etc?

There is a direct one-to-one relationship between host pools and scal-
able groups. Therefore, the scalable groups operate within a VN by default. The fabric
edge and border nodes include the SGT tag ID in each VXLAN header, which is car-
ried across the fabric data plane. This keeps each scalable group separate and allows
SGACL policy and enforcement.

What do they mean by a one-to-one relationship? Do hosts in the same scalable groups share the same host pools, or? I thought they could still use the same one.

Virtual network (VN): The VN provides virtualization at the device level, using VRF
instances to create multiple Layer 3 routing tables. VRF instances provide segmenta-
tion across IP addresses, allowing for overlapped address space and traffic segmen-
tation. In the control plane, LISP instance IDs are used to maintain separate VRF
instances. In the data plane, edge nodes add a VXLAN VNID to the fabric encapsula-
tion.

I unfortunately don’t really get this concept of virtual networks. The Virtual network (VN) confuses me a bit when it says that it is similar to VRF and that more routing tables are created. How exactly is this implemented, respectively where is it useful/how does it work? Because the routing table is not used for communication in the fabric (if we ignore the underlay), is it? Fabric Edge Nodes always ask the Control Plane Node if it has an entry (EID/RLOC) for a given destination and then an L2 VXLAN tunnel is built.

Sorry for the large post and pool of questions, I find a lot of these things really hard to imagine, especially how they really work and what they are useful for.

Thank you.
David

2

Hello David

Yes, that is correct. ISE plays an important role by assigning the SGT during authentication, usually through 802.1X, MAB, or WebAuth. So yes, in your example, when “John” authenticates, ISE assigns the appropriate SGT (like “IT-Users”) based on his identity or group membership (e.g., via AD integration).

It’s a matter of which device is best positioned to perform the filtering. Edge1 doesn’t know the SGT of the destination device. It only knows the destination IP/MAC. Edge2 has full context (destination host, its SGT, etc.) and is best positioned to enforce the policy.
Also, applying policy only at egress scales better. You centralize enforcement based on known context rather than trying to predict policy at ingress.

Actually, Edge nodes can and do advertise both. They advertise the host pool/subnet to say: “I manage this IP space.” They also advertise the host-specific mapping to say: “These specific hosts are currently connected.”

This is not a contradiction, they actually serve different purposes. The host level advertising delivers host mobility and tracking while the pool level advertising allows routing awareness.

Yes, SGTs let you enforce identity-based policies, regardless of IP address, VLAN, or physical port. This means that devices in the same subnet (even the same VLAN) can be in different scalable groups. So you can apply SGACLs based on SGTs without relying on traditional VLAN or MAC ACLs.

This means that if you tag devices like “IT-DEPARTMENT” (SGT 10) and “INTERN” (SGT 20), you can enforce access policies even if they share an IP subnet or are plugged into the same switch.

Technically, you can assign multiple scalable groups within the same host pool. However, the default design and best practice suggests one host pool (subnet) maps to one scalable group. This simplifies the policy model (1:1 mapping). This is not a technical limitation, but a design recommendation for consistency. It’s probably not stated very well… You can override this via ISE and dynamically assign SGTs per host even within the same subnet.

A VN is not similar to a VRF. VNs are essentially created using VRFs. VRFs are configured on the fabric edge nodes, control plane nodes, and border nodes. The implementation maintains a separate routing table per VN or per VRF. Traffic routing takes place within the VN. And yes, the underlay (OSPF/IS-IS) gets the devices connected while the overlay (LISP and VXLAN) handles the host-to-host forwarding.

No need to apologize, your questions are excellent, and they show you’re truly trying to understand how SD-Access works under the hood, not just memorize concepts. SD-Access is complex because it combines multiple technologies (LISP, VXLAN, VRFs, SGTs, TrustSec, ISE, DNA Center…) into a fabric that abstracts traditional network boundaries. Just know that because they’re long, and many, there will be a delay in answering them…

I hope this has been helpful!

Laz