Beruflich Dokumente
Kultur Dokumente
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.
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.
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.
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.
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.
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