Design

DNA SD-Access segmentation

Introduction
Cisco DNA SD-Access can provide segmentation between multiple user groups and devices within your campus access network.
Segmentation can be achieved in different ways based on the given scenario. This document will provide the brief idea on how
segmentation can be planned and elements to be considered for segmentation.

Intend Audience
The engineers and administrators who are planning and deploying SDA solutions and looking for guidance on how segmentation can
be designed to their network. This document will provide guidance on how VNs, SGTs, and host-pools can be designed with example
use cases. However, the use cases are not limited to examples explained in the document, the users can resonate to their
requirements based on their environment and requirement with this guidance. The audiences are expected to have a good
understanding of how the overall SDA solutions work.

When to use Segmentation(s)

Cisco DNA SD-Access does provide segmentation that enables an organization to implement security between different user groups
and devices in the network. This is very similar to what industry has been doing for many years based on the IPs with ACLs, whereas
in SD-Access the same can be achieved based on the user identity and irrespective of IP (subnet).

If an organization does not have a requirement of providing different network access privileges based on user identity and isolation
between users/groups, then segmentation based on the user identity profile is not mandatory to adopt SDA access solution. It is fine
to keep all the users in one security group and devices in another security group. At the same time, an organization can still take
advantage of the benefits of secure network login, dynamic provisioning of the network and many other features of the SD-Access
solution.

Note: Segmentation is based on an organization's requirements, but is not mandatory to adopt SD-Access as a solution.

Macro and Micro-Segmentation

Segmentation in SD-Access takes place at both a macro and a micro level through Virtual Networks (VN) and Secure Group Tags
(SGT), respectively. Virtual Networks or VRFs, (Virtual Routing and Forwarding), as we have traditionally known them as VRF, will
provide routing isolation between the different entity and Secure Group Tag(SGT) provides isolation within the routing entity within
the device.

Macro (Routing) Segmentation

The VNs in the fabrics are used to isolate IP reachability or routing table visibility between two segments. Examples of use cases to
deploy multiple VNs in a network can be one of the following.
Firewall as an entry point to Fabric
In an organization where a firewall acts as an entry point to the fabric (due to north-south traffic firewalling compliance), VNs can be
used to create multiple internal zones of the firewall. This will allow the firewall administrator to control the north-south and internal
zones (between different VNs outside fabric).

The Firewall gives the routing visibility of all the zones (based on the routing protocol choice) and security access policy will enable
communication between zones. In a scenario where shared services (DNS, DHCP, AD and etc) are available from northbound, the
firewall makes it easier to provide access to all user segments in the fabric. Similarly, when certain zones need to be restricted from
Internet access but allow corporate access or any requirement specific to a zone becomes easy.

This model will be easy to manage, if IP Pools for each VN planned well and when Administrator can have summary IP visibility in
the Firewall.

Note: This scenario is based on where firewall does not support SGACLs or deployment is IP based. The SGTs visibility can be
extended until the firewall and SGACLs can be used as well for traffic restriction. Refer SD-Access CVDs for more details on this.

End to End Routing Isolation

VNs can be used, in scenarios where destinations of the user groups or devices in the fabric have different WAN exit points. From
the fabric, Administrator will deploy VRF-lite between Fabric border and external router. The routing in the external WAN device will
be controlled within the VRF for the desired destination. The shared services, which are common for all the users of different VNs
may be available in Global Routing Table (GRT), dedicated services per VRF or in a dedicated VRF in the external router. The Route
leaking between individual user VRFs and shared services can provide access to the common services.

Another example could be guest network, which you want to isolate within the fabric network and terminate in the DMZ VRF of
external router directly.

Caution: VNs are finite resources in switching platforms and in DNAC. The number of supported VNs in DNAC and platforms needs
to be validated while adopting segmentation based on VNs.
Micro-Segmentation
Secure Group Tags (SGT) will provide micro-segmentation within the VN (within routing visibility or Partition). That is, IP reachability
is available within subnets of the VN or hosts within the VN, However, based on the user’s identity profile traffic flow needs to be
controlled between different groups using permit/deny SGACLs.

In ISE (Identity Service Engine), authorization profile defines the VLAN and SGT for a user upon successful authentication. It is
important to understand SGT to VLAN (Host IP Pool) relationship in micro-segmentation design. The different authorization profile
can result to same VLAN but different SGTs. That is users will be in the same VLAN/Subnet but will have different SGT based on
the policy.

Multiple SGTs in a Host Pool

As discussed in the previous section, micro-segmentation provides isolation between user groups (SGTs) even when they are in the
same routing VN or in IP reachability, by using SGACLs. When the requirement is to provide segmentation between user groups
and the IP subnet of the user is not significant, (even beyond fabric), then it is good to have large IP subnet and multiple SGTs in it.

For example, an organization has a couple of third-party vendors, all these vendors are allowed to access the internet when they
exit the fabric. However, within the fabric, they have to be restricted from communicating with each other. To achieve this requirement,
SGT profiles will be created for each vendor and all of them will be mapped to the same VLAN.

One:One SGT to Host Pool Mapping

In the use case where a user group is treated based on SGTs within the fabric and has IP based treatment outside the fabric (e.g.
NAT/PAT, IP ACLs, etc.), then that user group will be assigned a 1:1 SGT to VLAN mapping.

In the scenario above, a group of users requires a remote location access, which permits only IP address 200.200.200.200 as a
trusted network. However, not all the users in the group can have the same IP address to reach the remote location. The organization
decides to use NAT/PAT at the perimeter edge.
To fulfil this requirement, a 1:1 host pool to SGT mapping can be configured for hostpool2 and SGT4. All the users in the group will
be placed on the specific subnet always and based on the source subnet, NAT/PAT will be deployed in the external router. Also, note
it is assumed that all the in this group should have access to the “Remote Location” and do not need segmentation among themselves
within the fabric. If that is not the case, then multiple SGTs should be created using same Host Pool and micro-segmentation policy
should be applied as per access requirement.

SGTs within VN
In the scenario where ISE (Identity Service Engine) PxGrid Policy deployment has default permit policy (blacklist policy model
deployment), All the SGTs are allowed to communicate with each other within VN. So, if a SGT has to be restricted access to the
rest of the SGTs then 1:n access policy has to be created. This will be an administrative challenge when we have more SGTs within
a VN and/or SGTs are added/removed to the VN frequently.

In a requirement depicted in the figure above shows that each vendor has to be isolated from one another. On the day-1
implementation of the configuration, the Security administrator has deployed the deny policy between V1(Vendor1) to V2 and V3 and
similarly for V2 and V3 as well. This will create two SGACL entries in switch memory (plus reverse entries allowing return traffic) for
each vendor in each switch where the policy is applied.

During the course of the time, if the organization onboarding a new SGT (vendor4) to the VN, (and assuming Vendor4 has the same
requirement like other Vendors in the VN), then the policy has to created similarly as other three Vendors in the VN. So, the Vendor4
policy has to restrict the access the rest of the Vendors in the VN, at the same time for all the existing vendors (1,2 and 3). The policy
will have to be applied to existing Vendors in conjunction with Vendor4. This will create three SGACLs (plus reverse) for each vendor
in the switch. Thus, in this model of the deployment administrator should take care of the policy for the newly created SGTs and its
relation to all the existing SGTs within the VNs.

Conclusion
Cisco DNA SD-Access provides macro and micro level segmentation. A thoughtful design on segmentation will help us to improve
routing management and SGACL managements in the fabric network. Key take ways are
1. Use Macro segmentation (VN), when you need routing isolation or end-to-end Isolation(LAN to WAN)
2. Use Micro segmentation (SGT) for the users within subnet or in same routing domain (VN)
3. Do not always map one SGT to VLAN(subnet) this will defeat the purpose of micro-segmentation
4. Dedicated VLAN(subnet) to a SGT is fine as long as there is a dependency of source subnet in the IP network beyond fabric