cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2206
Views
20
Helpful
5
Replies

IP-SGT Static Mappings "Virtual Network" Field

anthony.wild
Level 1
Level 1

Hello All,

 

I apologize if this has been asked before. We're currently deploying SD-Access for all new greenfield deployments and looking to leverage Group Based Access Control (TrustSEC). We obviously have some workloads external to the fabric and will want to pin these to SGTs by virtue of the IP-SGT binding feature in ISE, and then push these down to the respective fabric switching.

 

The challenge is that ISE does indeed push statements "cts role-based sgt-map X.X.X.X sgt X" but it does it outside of the target VRF that correlate to the Virtual Networks DNA creates for Fabric. Thus, enforcement doesn't work right.

 

I would assume the purpose of the "Virtual Network" aware SGT would function such that it would sandwich the target VRF right into that cts role-based sgt-map command. The only other workaround I see is to either build SXP bindings out that land in the target VRF, but thats pretty cumbersome at scale.

 

Am I missing something? What is the true purpose of that Virtual Network field then if so?

 

Thanks in advance!

5 Replies 5

Mike.Cifelli
VIP Alumni
VIP Alumni

I think some sort of network topology may better assist the community in fully understanding the issue at hand.  I am going to hit on the following:

We obviously have some workloads external to the fabric and will want to pin these to SGTs by virtue of the IP-SGT binding feature in ISE, and then push these down to the respective fabric switching.

-Depending on size, and overall layout of your network I dont see any issues with relying on SXP to push the static mappings.  I have relied on SXP several times with little issue.  The only kicker is the necessary manually cts configuration on the respective gear that will be a listener.

The challenge is that ISE does indeed push statements "cts role-based sgt-map X.X.X.X sgt X" but it does it outside of the target VRF that correlate to the Virtual Networks DNA creates for Fabric. Thus, enforcement doesn't work right.

-I am not sure I am following this one.  Those fabric VNs live inside your fabric and are not present outside of it in your so called legacy network.  Without knowing much on your environment it sounds like you need to deploy cts enforcement on respective legacy nets where you have gear that you wish to assign static mappings to.

I would suggest taking a peek at some of the docs here: Cisco SD-Access Fabric Resources - Cisco Community

HTH!

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

 

Topology.jpg

anthony.wild
Level 1
Level 1

I did arrive at one other theoretical solution.... running SXP bindings on the SD-WAN Routers and network virtual appliances (8000V) closest to datacenter and cloud ingress.

 

Then either each SD-WAN router would have to be enabled to pass tags so that the endpoint tag would carry across to the one of the cloud or datacenter adjacent routers and then act on enforcement supplemented with the SXP learned bindings where I keyed in Server IP to SGT mappings ... OR ... I'd have to check the box in ISE that tells it to publish radius mappings into SXP IP SGT mapping table so that the cloud/datacenter adjacent routers would have knowledge of both the manual IP-SGT bindings plus the endpoints themselves to make an enforcement decision. I would be worried about the limitations of each router for that latter option.

 

Looking forward to further dialogue.

 

https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/security/ios-xe-17/security-book-xe/cisco-trustsec-integration.html#Cisco_Concept.dita_422a480d-36d7-45d4-bd37-9ff1c77b1f0f

Mike.Cifelli
VIP Alumni
VIP Alumni

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:

authz_sgt_LI.jpg

 

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:

authz_vn_only1.PNG

 

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.

Hi Mike,

 

Thanks for your time again! I'll take a closer look at your thoughts for #1. I do in fact see your point of the SGTs showing the associated virtual networks in the lower part of the screen. I had thought that maybe if I push a similar manual SGT-IP mapping and click the dropdown field and select the VN, then the corresponding VRF would be inserted as well. We are on ISE 3.0 P4 by the way.

 

For point 2, that makes perfect sense. We are implementing that technique that to do some AAA overrides for wireless clients as well as assigning individual SGTS in the policy sets themselves based on profiling techniques. My only hang up would again be for those datacenter workloads on the other side of the equation. For method 2 to work, I would have to implement ISE in the datacenter fabric so that servers could be tagged on onboarding, OR rely in ACI to ISE integration to correlate SGT to EPG mappings. Thinking forward, the only problem then becomes cloud hosted workloads where neither of those two aforementioned techniques would work and I'd be right back where I started in trying manually keyed in SGT-IP mappings and trying to get them in the target VRF, or relying on SXP bindings in the target VRF on the SD-WAN routers adjacent to those Cloud vNets.

 

I'll keep at it and let you know which technique we decide to implement.

 

Thanks!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: