Fabric Underlay Connectivity and TrustSec Default Deny

[dm2020]

Hi All,

I operate a small number of SDA fabrics that all use the Deny-List (default Allow) Group-Based Access Control/TrustSec Model. I am not considering changing these to use the Allow-List (default Deny) model, however I'm aware that if the Default action if ever changed to Deny by mistake within DNA Center or ISE, the entire fabric would become unavailable with no ability to recover without reverting the change and rebooting all fabric devices (as they would not be able to contact ISE to retrieve the updated policy until the cached policy is cleared). 

Although this should never happen in practice with proper controls in place, I want to ensure that if the Default action is every changed to Deny, that the fabric underlay is always available so that the change can be easily reverted centrally from DNA Center or ISE.

I've tested and I could do one of two things (or possibly both)

1) Configure policies to always permit traffic between SGTs Unknown and Unknown, TrustSec_Devices and TrustSec_Devices and Unknown and TrustSec_Devices

2) Disable CTS enforcement on all fabric underlay routed interfaces using command (no cts role-based enfocement). I could do this using a template.

Has anyone looked at this before? 

[Boort]

I run a fabric with default deny and this is what i did to ensure connectivity to the underlay in case ISE brakes or becomes unavailable for an extended amount of time.

1. On ISE change NAD SGT from Unkown to TrustSec devices.

2. Run no cts role-based enfocement on border node uplinks towards fabric edge nodes and on all fabric edge node downstream interfaces.

3. Create static IP to SGT mappings on all fabric nodes. Classify switches, access point and WLC networks as TrustSec devices (sgt 2) and all external infra services as sgt 1000 for example.

4. Create SGACLs which allow traffic to and from the staticly defined IP to SGT mappings. This also needs to be pushed to all fabric nodes.

A great writeup for this process can be found here.
https://www.cisco.com/c/en/us/support/docs/cloud-systems-management/dna-center/215516-trustsec-whitelist-model-with-sda.html#anc9

If you do all the pre-config steps you should still be able to connect to your fabric in case someone enables default deny.

Keep in mind that the SGT cache from ISE lasts for 24 hours before being deleted. During those 24 hours your local SGT mappings are ignored since ISE trustsec policy takes precedence.
I would consider applying contracts from your SGT's to and from unkown even tho you are running deny list. If someone switches to default deny the impact will be greatly reduced.

But at this point you might as well try to switch to default deny if you would like... if it becomes unmanageable you can always switch back, correct the issues and turn on default deny again.

Hope this helps

[dm2020]

Thanks for the reply.

Do you have to disable CTS enforcement on all intermediate switch underlay interfaces as well or is it just on fabric border and fabric edge underlay interfaces?

[jedolphi]

If the intermediate switches have or will have CTS policy enforcement enabled (see verify section of the URL shared by Boort) then yes it would be wise to disable on the intermediate switch routed interfaces serving the SD-Access underlay.