SD-Access, the hidden TrustSec requirement

[jose.tamayo.segarra]

Hi everyone,

I have been reading about DNA-Center for some days now, and I guess that TrustSec is a strong requirement to use the Policy feature, and I did not find it clearly stated. Without this, DNA-Center just creates an insecure, flat single-VLAN LAN.

In DNA-Center, the Policy app make sense only on a SD-Access LAN, correct me if not. From what I see, Policy definitions need ISE to be fully  integrated, fully configured to the TrustSec level (groups created, SGT Tags). So I can see 4 cases, please correct me if I missed something:

• If the LAN is legacy, no TrustSec, then the only thing DNA-Center will do is put all SW access ports to the site VLAN, and that is it. Not even default ACL on ports, or 801.X authentication on SWports.
• If the traditional (not SD-Access) LAN is TrustSec-ready, then I will have an ISE properly prepared and DNA-Center will ease the task of creating the policies, but I can do already this without DNA-Center. Will DNA-Center import also the defined policies from ISE, or only the group definitions?
• In case of an SD-Access LAN, if there is no TrustSec ISE prepared (policies, groups, pxGrid, etc), then my LAN cannot have any policies, so back to single VLAN LAN.
• Only in the case of SD-Access with a fully powered TrustSec-ready ISE, only then the LAN can enforce the security policies.

I know, lots of questions... but not having DNA-Center to play with, relying only on videos/pres/marketing material ... I sincerely felt I had to work out the guts of DNA-Center out of a bunch of marketing talk.

I would like to have this clear to make a solid business-case (a real one, with design architecture and process behind), that will choose the correct elements and appliances for the specific client needs. Perhaps SD-Access makes sense only for companies using or willing to fully integrate ISE and TrustSec (DNA-Center has its own benefits alone, of course)

Sorry for the long post

[Shawn Wargo · Accepted solution]

Hi Jose.

I was browsing the Communities and saw that your post was never answered. You raise some good questions, so you deserve an answer. Some parts of your assessment are correct, and others are not. Let me try to clarify some.

The long-term vision of Cisco DNA (and Intent Based Networking in general) requires key capabilities like 'host mobility' with 'dynamic authentication & identity' and 'address-independent policy enforcement', and an infrastructure to support that.

For those reasons... you are quite right that DNA (and DNA Center) favors SD-Access fabric overlay with full-blown ISE and CTS for Policy administration. Without those, we will forever be tied to IP subnets, VLANs and IP-based ACLs (circa 1990).

However, SD-Access separates IP subnets & VLANs (called Pools) from group-based policy enforcement (called Scalable Groups). Furthermore, the fabric overlay is routed and does not use "VLAN" to forward traffic. VLANs (and corresponding SVI with Anycast IP) terminate at the first-hop edge device, and are then routed via the fabric to the remote edge device.

Also, as you noted: DNA Center does support both fabric & non-fabric Provision and Assurance workflows. Similarly, the Policy workflow does actually support IP-based ACLs for non-fabric designs. Of course, you also take on the additional complexity.

For example - DNA Center Policy > Policy Administration

We understand that this will be a journey... and it will take time to reach the long-term goal. You may want to start out non-fabric, with IP-based policy... and then move on to fabric and group-based policy later.

The important thing is to decide if that's the direction you will eventually go... and then build the infrastructure to support it!