Enforcing SGT Based Policy Between Virtual Networks in SD-Access

[wojtek.siodelski]

I would like to enable SGT based policy between Virtual Networks based on SGTs. The fusion device is a 9300s switch and I understand I have two options:

1. SXP between the fusion device and ISE to receive IP to SGT mappings + Enable Enforcement of the policy on the fusion device by downloading TrustSec Policy from ISE

2. Per VRF SXP between Borders and ISE that allows re-inserting of SGT tag to VXLAN header (that is lost when the packet routes via the fusion device) and the policy can be enforced at egress Edge node as usual

Both of those solutions work but I would like to understand the caveats of each especially regarding the scalability of those options.

Option 1 means that all the rules + SGT mapping for all sources and destinations is going to be stored in the fusion device memory.

Option 2 means that each border will have to run per VRF SXP session but it wouldn't need to download all the rules because those would be enforced at egress.

If any of the statements I made here are incorrect please let me know

Thanks

[Mike.Cifelli · Accepted solution]

My opinion/questions on your design considerations:
Why not rely on bgp and route leaking to meet your requirement. SGTs get assigned to IP pools, so the thought is you have the ability to utilize policy routing with prefix lists & route leaking. I feel that enforcing SGT policy at the fusion is not necessary and could introduce additional admin workload. In order to allow one IP pool in VN-A to talk to another ip pool VN-B and vice versa you have to leak the traffic between the two at your fusion since the two are already logically segregated and restricted from communication. If there is a huge push for separate IP pools/SGTs to communicate often put them in the same VN and rely on trustsec for east/west control. I usually tell people to consider this: do you want to perform more work on fusions to leak between many VNs from a north/south aspect with more hops OR do you want to rely on managing CTS with many pools+SGTs from an east/west perspective. Obviously, decisions are contingent upon what the actual requirements are. Good luck & HTH!

[wojtek.siodelski]

Thanks Mike, 

Route leaking or lack of is just connectivity ON & OFF which doesn't solve the problem.  I don't want to rely on any prefix lists in SD-Access because the main advantage of it is abstracting IP addresses from the endpoint.

I suspect that in the future the traffic between VNs won't have to traverse via the Fusion device but will be sorted by the border itself. Unfortunately right now it has to go via fusion hence we are losing VXLAN header and SGT with it.

I solved the problem in two different ways just not sure which one is more common or recommended in the scenario where you don't have a fusion firewall but a standard switch.

[Mike.Cifelli]

I believe you are right in the fact that EBNs in the future may be capable of consuming the fusion role as well. The term virtual network is synonymous to VRF in the fact that each SDA VN you deploy is a virtually segregated routing instance. I agree that the two options could work from a CTS perspective. However, either way you will not be able to avoid route leaking and prefix lists to get from VN1 <--> VN2 as of today. Also, the fusions we run in our fabric are not firewalls. They are cat 9500-16x. Good luck & HTH!

[wojtek.siodelski]

Thanks Mike

Well, I avoid route leaking in my setup because traffic out of the fabric routes out to the legacy core by following default route and if the destination is in the fabric but different VN it simply hairpins back. The route leaking would allow it to stay within the fusion device but as we are getting ready for the firewall I didn't bother configuring it at this stage.

I found some documentation where it says that 9500 switch for example can hold 40k IP-SGT mappings while 9300 switch can do 10k so depending on the number of endpoints it is possible to enforce the policy on the fusion or border with SXP and I think I will leave it at the bigger box for now - until we get inter VN firewall like Firepower that can take 1M IP-SGT mappings.

thanks