Hi Mike, Thanks for your time and contribution for our design question. Here we go;
1. Topology attached for one of our sites, assume two SD-WAN cEdge Routers northbound of that CP/B at the top. From what I can tell, you need SXP bindings in *each* VRF for it to work properly. Building a binding in global when the endpoints are landing in a VN/VRF will cause enforcement to not work properly. Assuming 3 VNs (VRFs) - Guest, Industrial, and Enterprise, that would mean 6 bindings for each VRF to a primary and secondary ISE node. This is under the assumption that I only need the bindings on the switch closest to egress and not all of the nodes. This could work, but it would be some manual effort to implement at every site around the world.
2. Regarding the endpoints that live outside of the Virtual Network, I'm speaking on the servers and workloads that live upstream in a datacenter. At present this is an ACI Fabric. I have toyed with the idea of running data plane integration, ie, full inline trustsec end to end since we utilize SD-WAN and can pass the tags. However, we are slowly moving to the cloud. As I move workloads up and out, this would break the model because we don't backhaul to a central fusion router in which I could enforce TrustSec, we utilize Multicloud SD-WAN Onramp for direct mesh to each Cloud Region. To that end, I believed that the simplest way to do it was closest to the site level SDA fabric itself.
It sounds like SXP might be my only way forward right now. However, out of professional curiosity, I'm still wondering what the point of the Virtual Network field is in ISE under the SGTs, SGT-IP mappings, and SGT mapping groups. Why is it there? What is its intended purpose? What would be really slick is if I could actually use it such that it would take the VN and inject the appropriate VRF into "cts role-based sgt-map vrf RED X.X.X.X sgt Y", and then I could deploy the mapping group to nodes of a specific category (ie, SDA Fabric Sites). Right now I can do pretty much all of that, in terms of deploying to specific category devices, except the Virtual Network has zero effect. It basically does nothing.
Looking forward to your feedback and insight,
Anthony
Great questions, I am going to share some information that I hope helps.
I'm still wondering what the point of the Virtual Network field is in ISE under the SGTs, SGT-IP mappings, and SGT mapping groups. Why is it there? What is its intended purpose?
-This is essentially the way ISE views the VN and IP Pool assigned to it. It binds the VN/IP pool to the SGT that is assigned to a given VN.
Right now I can do pretty much all of that, in terms of deploying to specific category devices, except the Virtual Network has zero effect. It basically does nothing.
-So you have a couple of ways to assign SGTs to clients based on radius authz policies. The two ways are as follows:
Option 1: Assign SGT via authz profile. Under common tasks within the authz profile you would select 'Security Group' + SGT + VN + Type + IP Pool. Then assign the respective authz profile as a result in the radius policies without the need of assigning an SGT in the SGT column. Looks like this in authz profile:
Option 2: Assign VN in authz profile. Under common tasks within the authz profile you would select 'VLAN'. You would assign the VN name (you can get this from DNAC or directly from the VN field under a given SGT. Then assign the respective authz profile as a result AND assign the respective SGT under the SGT column if wishing to assign an SGT.
Remember that macro segmentation is essentially assigning the VN and assigning an SGT is micro segmentation. So option 2 let's you do either or both. Whereas option 1 does both since macro/micro is defined in the authz profile. Looks like this in authz profile:
Now to tie it all together from an assignment/onboarding perspective:
If you rely on ISE to push policy down to interfaces that lets say are configured for 8021x Closed Auth, ISE will push the string that is configured in the matching policy authz profile that contains the unique string extracted from DNAC or SGT and configured in the authz profile (VN). It will get pushed in the radius packet as a radius attribute that the switch will use as the identifier. The attribute looks like this in detailed ISE logs: Tunnel-Private-Group-ID (tag=1) 192_168_0_0-VN1. This identifier attribute allows the switch to map either the name or vlan id to the proper vlan. Once this happens your Anycast gateway comes up/up. The string must match in ISE authz profiles. Run a show vlan on an EN deployed to your SDA fabric and you will see what I am talking about. HTH clarify the VN/SGT questions.
