Buy or Renew
Buy or Renew
Cisco + Splunk: It’s a new day for your data. Learn more.
 
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Create a new article
4579
Views
4
Helpful
1
Comments

SD-Access Segmentation Design Guide

kadsteph
Cisco Employee
Cisco Employee

‎10-11-2023 03:29 PM - edited ‎10-12-2023 10:27 AM

 
 
07c1b4d3-f97c-4452-921b-ef298a7b80b1.png

 

 Cisco Public



SD-Access Segmentation Design Guide

 

Contents

 

Authors

Jonothan Eaves
Principal Technical Marketing Engineer

Introduction

An ever-growing number of cyberattacks are launched daily against organizations of all types, carried out by individuals, organized syndicates, and state-sponsored hackers. Whether for purposes of financial gain through acquiring credit card data, extortion through ransomware, access to personal data for identity theft, or disruption of services, these attacks are continually growing in frequency and sophistication. Furthermore, with the ever-growing availability of open-source codebases and tools, these attacks no longer require a high level of skill, enabling them to be launched by less sophisticated threat actors.

Organizations struggle to identify not only those technologies and products that will protect them but the budget necessary to acquire, implement, and operate them. Products such as Cisco Secure Firewall, Cisco Secure Web Appliance, Cisco Secure Endpoint, and Cisco Secure Network Analytics, providing network visibility, and Cisco Identity Services Engine providing policy and secured network access for authorized users, guests, and IoT devices to be effective in providing a “defense-in-depth” strategy to protect an organization. Once adopted, the focus shifts to defining an implementation strategy that will protect an organization’s critical assets and data by enforcing authorized access to the network while also monitoring communications for anomalous behavior from endpoint to data center.

Another very effective strategy to consider, underlying all other security products, is the use of network segmentation to reduce the scope of an attack. Network segmentation can be described as the process of breaking down or splitting up a single large network, with a single routing table, into any number of smaller networks or zones either virtually or logically. With a segmented network and security controls to enforce policies into and out of the segment, you:

  • Provide isolation between segments, supporting regulatory compliance.
  • Minimize the attack surface, limiting it to only one segment, thereby restricting the east/west propagation of malware.
  • Introduce enforcement points between segments where stateful packet inspection can be implemented.
  • Provide an environment where further micro-segmentation is possible.

The purpose of this document is to familiarize the reader with Cisco Software-Defined Access® and its unparalleled capabilities in implementing network segmentation in your network. Its intent is to assist you in better understanding the architecture and further assist in strategizing the approach to be taken.

If you are unfamiliar with network segmentation, before proceeding you may want to read Appendix A, which offers a brief overview of network segmentation. We also recommend that you read the User to DC Group-Based Policy Guide in order to understand the Cisco Group-Based Policy software-defined segmentation architecture. It is very important that you understand the Cisco Group-Based Policy solution because it is the basis for using Security Group Tags (SGTs) and their use in group-based access control policies found within SD-Access.

Companion deployment guides, design guides, and white papers, can also be found at the following pages:


Original Network Segmentation

Originally, network segmentation was aligned to a strategy for improving network stability and performance. Over time, it has evolved to reflect a security strategy in which the network is segmented or compartmentalized to enforce a policy by enabling controls within and between segments.

While VLANs and private VLANs still provide rudimentary Layer 2 segmentation of Layer 3 IP subnets for some organizations, many others have chosen to use VRFs or software-defined segmentation via Cisco Group-Based Policy as the primary means of segmenting a network. VRFs provide complete isolation of routing and switching environments, making it a common network segmentation technology for a substantial number of organizations. VRF-Lite (see reader tip below) can be implemented through either 802.1Q trunks or GRE or, in many cases, even MPLS as the underlying transport. Aside from VRFs, however, an increasing number of customers are using Cisco Group-Based Policy to provide logical, group-based segmentation without the need to support data plane isolation along with the routing/control plane considerations inherent to VRFs. As will be discussed in the section “Defining network segments” later in this document, both approaches offer their own unique benefits, and some customers have decided to implement both technologies. VRFs and Cisco Group-Based Policy software-defined segmentation will continue to be, both now and in the foreseeable future, extremely effective methods for segmenting the network and, through this segmentation whether virtual or logical, extending a security policy.

A network segmentation strategy developed to enforce security policy in support of an organization’s business requirements is typically not limited to a single location. It could be needed across a campus consisting of multiple buildings with thousands of devices or across remote sites such as stores or branches, each with a handful of devices. A given network segment, and the policies it represents, may be extended anywhere within an organization where one of the business-relevant applications or functions reside. Historically, when implementing VRFs or Cisco Group-Based Policy, manual configuration of the network infrastructure is unavoidable. Whether extending VRFs through VRF-Lite or MPLS or enabling the propagation of the Cisco Group-Based Policy SGTs outside a fabric, configuration must be completed manually, often on a hop-by-hop basis.

With the introduction of Cisco Software-Defined Access (SD-Access) and, more broadly Cisco’s Digital Network Architecture (DNA), how network segmentation can be implemented are once again evolving. To quote the “Cisco Group-Based Policies for Zero-Trust Security” white paper:

Intent-based networking (IBN) is an industry-accepted framework that lets networks do just that. IBN transforms a hardware and CLI-centric, manual network into a controller-led network that captures business intent and translates it into policies that can be automated and applied consistently across the network. The goal is for the network to continuously monitor and adjust network performance to help ensure desired business outcomes.

 

Reader tip
VRF-Lite can be seen as a subset of VRF without MPLS and MP-BGP.

 

Reader tip

For more information about Cisco’s intent-based networking architecture, visit https://www.cisco.com/c/en/us/solutions/intent-based-networking.html

For Cisco DNA Software, visit https://www.cisco.com/c/en_ca/products/software/dna-software/index.html

For Cisco SD-Access information, visit https://www.cisco.com/c/en/us/solutions/enterprise-networks/software-defined-access/index.html

Click here for the Cisco Group-Based Policies for Zero-Trust Security White Paper

One of the key benefits realized through Cisco Intent-Based Networking (IBN) and enabling technologies such as SD-Access is the ability to ensure that a security policy for compliance exists throughout the organization. The scope of an IBN thus extends from the data center and cloud environments all the way to the campus and remote locations, and encompasses even remote access to the network, whether for employees, contractors, or vendors. Those controllers, which provide the automation and controls that make up the IBN, reduce risk by assuring that security policies are being applied consistently across the network, and help ensure that policies are compliant with business requirements. They capture and translate business intent into network policies and activate them across the infrastructure.

A similar example in the data center, Cisco Application Centric Infrastructure (Cisco ACI™), powered by the Cisco Application Policy Infrastructure Controller (APIC), offers an architecture that can translate business requirements into secured zones or enclaves. With Cisco ACI deployed, contracts or policies can be created that allow only specific communications between tiered applications, as well as access to external resources, whether applications or users, while blocking all other unauthorized access. Within the Cisco ACI policy model, both VRFs as well as group-based endpoint groups (EPGs)—similar in many ways to SGTs, even to the extent that they can be translated—are used to provide segmentation. Contracts, defined using EPG security policies and application network profiles, are applied to control communications, both into and out of the data centers as well as within it between applications and data repositories.

Reader tip
For more information regarding ACI, refer to this site: https://www.cisco.com/site/us/en/products/networking/cloud-networking/application-centric-infrastructure/index.html


Within the SD-Access architecture, Catalyst Center™ and Cisco ISE work in unison to provide the automation for planning, configuration, segmentation, identity, and policy services. Cisco ISE is responsible for network access, identity services, and policy services, dynamically exchanging information with Catalyst Center. Catalyst Center consists of the automation and assurance components that work in unison to form a closed-loop automation system, enabling the configuration, monitoring, and reporting required to realize the full extent of the Cisco IBN in campus environments.

When Catalyst Center is implemented, ISE is deployed as an integrated appliance providing identity and policy services for the SD-Access campus fabric. When creating SGTs, contracts and Group-Based Policies through Catalyst Center user interface, these constructs are immediately sent to ISE utilizing REpresentational State Transfer Application Programming Interface (REST API) calls. ISE then serves as the policy engine for the solution, dynamically distributing policy to the network infrastructure.

Segmentation within SD-Access is enabled through the combined use of both virtual networks (VNs), which are synonymous with VRFs, and Cisco Group-Based Policy Security Group Tags (SGTs). Whereas segmentation can be accomplished using intent-driven or purpose-built virtual networks alone, Cisco Group-Based Policy SGTs provide logical segmentation based on group membership. Cisco Group-Based Policy provides an additional layer of granularity, allowing you to use multiple SGTs within a single VN providing micro-segmentation within the VN.

Reader tip
For more information on SD-Access, refer to https://www.cisco.com/c/en/us/solutions/enterprise-networks/software-defined-access/index.html as well as the Cisco SD-Access Validated Design Guide at https://www.cisco.com/c/en/us/solutions/design-zone/networking-design-guides/digital-network-architecture-design-guides.html


Although this design guide focuses specifically on segmentation and policy constructs in SD-Access, it is important to understand how SD-Access and other technologies, such as SD-WAN, interact with data centers based on Cisco ACI, as well as with other infrastructure that has implemented either Cisco Group-Based Policy or VRFs. The importance of understanding how these technologies intersect and how policies are translated between environments cannot be overlooked as organizations begin the process of migrating to a full IBN model. Existing segmentation strategies, whether Cisco ACI, VRFs, or Cisco Group-Based Policy, will influence decisions regarding how virtual networks at the macro-segmentation level and Security groups at a micro-segmentation level should be organized and populated within an SD-Access fabric.


Understanding virtual networks and SGTs in SD-Access

Virtual networks

Virtual networks, like VRFs described earlier, provide complete isolation between traffic and devices in one VN and those in other VNs. Within the SD-Access fabric, information identifying the virtual network is carried in the VXLAN Network Identifier (VNI) field within the VXLAN header as seen in Figure 1.

  1. VXLAN-GPO header

image1.png

 

Unlike its legacy VRF counterparts, the SD-Access fabric does not require a separate routing table per virtual network within the SD-Access fabric, as LISP is used to provide control plane forwarding information. External to the SD-Access fabric, at the SD-Access border, the virtual networks map directly to VRF instances, which may be extended beyond the fabric. Path isolation techniques such as VRF-Lite or MPLS may be used to maintain the isolation between VRFs. Additionally, SD-Access IP addressing information represented by the fabric endpoint identifier (EID) can be redistributed into a routing protocol such as BGP, EIGRP, or OSPF for use in extending the virtual networks.

By default, Catalyst Center has a single virtual network, the DEFAULT_VN, that all users and endpoints could use. Further VN’s can be added and named appropriately for the types of endpoints or users that will be placed within those VN’s. Typically, admins rename the DEFAULT_VN to something more appropriate or just delete it if not used. There also exists a VN called INFRA_VN which contains the global routing table. This is used in Catalyst Center / SD-Access for items such as Access Point and Extended Node management.

Because VRFs external to the fabric isolate communications between them by using separate routing tables per VRF, it is necessary to forward traffic to an external network device to enable these communications if desired. A firewall, Layer 3 switch, or router can then be used to leak routing information, maintained in each VRF, thus enabling communication between virtual networks while also providing a control point to enforce established security policies. As discussed earlier, these network devices are commonly referred to as “fusion” firewalls or network devices. Today these fusion devices and firewalls are external to the fabric. In SD-Access version 2.3.4, a feature called Extranet is introduced. This simplifies the SD-Access fabric deployment and provides a more efficient policy-based method of automating route-leaking on the Border Node to access Shared services and the Internet.

Reader tip
The SD-Access Extranet feature introduces virtual network policies based on subscribers and providers. See this section of the 2.3.4 user guide for details.


Security Group Tags

As discussed previously, Security Group Tags (SGTs) are represented by a 16-bit group identifier that is associated with the Security Groups, the membership of which is based on business roles or functions. By default, there are several predefined Security Groups (both in Catalyst Center and in ISE) along with an associated hexadecimal tag ID. You also can define new Security Groups along with a tag ID of your choosing. If we think of user roles in a healthcare environment as an example, we could organize users into doctors, nurses, imaging technicians, pharmacy, patients, and guests. Likewise, we could assign unique SGTs to different devices, such as IP cameras, HVAC control, keypads/swipes, MRI machines and digital signage. The Cisco Group-Based Policy operation behaves the same whether used within an SD-Access fabric or used outside in a non-fabric environment. Catalyst Center and SD-Access bring great advantages though providing configuration automation and seamless SGT propagation across the fabric using VXLAN in the data-plane. SGTs continue to provide a means by which devices or users can be logically segmented from one another; the technology continues to evolve providing more and more intent derived from an SGT.

An admin can choose to either manage Group-Based Policy within Catalyst Center or manage policy directly in ISE. Managing policy in ISE would be necessary if there are required policy features which are not supported within Catalyst Center. An example is multiple Group-Based Policy matrices which is supported in ISE but not in Catalyst Center at the time of writing this guide. The reason for no support in Catalyst Center is due to a lack of APIs to manage the function within ISE. Providing APIs for this is on the ISE roadmap and the plan is to provide support in an ISE 3.x version. If the decision is made to manage policy within Catalyst Center, then create, update, and delete functions for the associated policy constructs are disabled within ISE. If the decision is made to manage policy within ISE, then the Security Group Tags are read only, and the Contracts and Policies are not displayed at all within Catalyst Center. This is done to restrict policy management to a single location to enforce best practice policy administration.

When managing Group-Based Policy in Catalyst Center, adding Security Groups, Access Contracts or Policies will add those entries into Catalyst Center but also push them into ISE immediately save is executed. For network devices to be aware of the changes, the ‘Deploy’ function on the Security Groups, Access Contracts and Policies pages, within Catalyst Center can be utilized, and this instructs ISE to send a RADIUS Change of Authorization (CoA) message to the network devices to inform them of the change. When managing Group-Based Policy in ISE, adding, and saving Security Groups will add those groups into ISE but also push them into Catalyst Center. They are then available for functions within Catalyst Center, for instance in the Fabric Host Onboarding VLAN/IP Pool association with a VN (creates a VLAN to SGT mapping) and in Fabric Host Onboarding Port Assignment (creates a Port to SGT mapping). Additionally, adding and saving Contracts (known as SGACLs) and Policies in ISE are only viewable in ISE, not in Catalyst Center.

Propagation of the source SGT in an SD-Access network is no longer performed on a hop-by-hop basis as with Group-Based Policy inline tagging, but is carried within the VXLAN header, as shown earlier in Figure 1. As can be seen in the figure, the SGT and VNI are both maintained in the VXLAN header for communication between VXLAN tunnel endpoints in the SD-Access fabric.

From a Group-Based Policy point of view, Catalyst Center supports integrating with Cisco ISE even if ISE has already been deployed with SGTs outside a fabric. Upon integration, any SGTs, Contracts/SGACLs and Policies that exist in ISE that do not already exist in Catalyst Center will be copied over to Catalyst Center. If there are conflicts in the contents of the entries, then the ISE configuration will prevail.

Defining network segments

The decision to create network segments, whether virtual or logical, should be driven by the organization’s business requirements. But what does that really mean? First and foremost, what are the goals of segmenting the network?

Implementing network segmentation allows you to define segments, whether virtual (virtual networks) or logical (SGTs), that are dedicated to a specific business application or function for security reasons. These segments can have well-defined policies governing access to a segment and the ability to limit communications between them. When implementing segmentation, you minimize the network attack surface to, at most, that segment, while additionally defining security policies within and outside of the network segments in the case of virtual networks, or between and within logical segments in the case of SGTs.

As previously discussed, SD-Access offers both network segmentation using virtual networks as well as “logical” segmentation using SGTs within each virtual network. Realistically, you could decide to use just virtual networks or, alternatively, a single “user” virtual network with multiple Security groups.

The approach taken will depend largely on whether there is a need for complete isolation of an application or business function. In cases such as Payment Card Industry (PCI) and guest networks, the complete isolation found with a virtual network is likely the best choice. When using a virtual network, the scope of regulatory compliance, for example, is limited to access to the virtual network and communications within it. Alternatively, Security Groups with policies controlling communications between Security Group Tags can provide the necessary segmentation “logically” for point-of-sale (POS) machines and card readers. In the case of PCI, though, you will need to be prepared to demonstrate isolation between the PCI tag and other Security Group Tags belonging to that virtual network. There is no single correct answer, and most customers will likely choose a combination.

Some examples of where virtual networks might be used are:

  • PCI: POS machines, card readers, and payment card gateways.
  • Electrical power: Separation of generation, transmission, and corporate networks.
  • Building controls: Heating, cooling, lighting, and security systems.
  • Manufacturing floors: Isolating the floor from the corporate network.
  • Stock Exchange trading floors.
  • Management of network infrastructure.
  • Research and development: Isolating the research environment from the corporate network.
  • University dormitories: Isolating them from the campus network and applications.
  • Healthcare clinical environments: Bedside monitors, infusion pumps, MRI, ultrasound, and X-ray.
  • Guest networks.

Some examples of where SGTs might be used are:

  • PCI: Inventory scanners, card readers, POS.
  • Healthcare clinical environments: Bedside monitors, infusion pumps, MRI, ultrasound, X-ray, doctors, nurses, building controls.
  • University: Students, professors, guests, building controls, and security systems.
  • Business functions such as human resources or finance.
  • Security systems and other business controls.
  • Guest access.
  • Contractor access.
  • Business partners.
  • Quarantine and remediation.
  • Network administration.

As can be seen from the above examples, there may be a great deal of overlap where virtual networks, SGTs, or a combination may be used to segment the network. Hence, as we discuss the topic of segmentation, we really need to be able to make a distinction as to which methods will satisfy the business security requirements without creating unnecessary design complexity.


Virtual Networks or Security Groups

In the previous sections, we have gone through the various segmentation technologies used both with and without SD-Access. What are the business requirements driving the need for segmentation?

 

Virtual networks

It is often very easy to identify those requirements that compel an organization to completely isolate segments from one another, as in virtual networks and VRFs. Typically, this requirement is established to attain regulatory compliance by maintaining security controls between various types of business communications. When evaluating whether a specific business function or application warrants its own virtual network, it is important to assess the following criteria:

  • Does the application or business function as well as the devices accessing it extend from the edge of the network into the core?
  • Are the user and device communications primarily limited to that segment, with only limited access required in or out of the segment?
  • Within a segment, will communications between devices be allowed?
  • Will the scope of a network audit for regulatory compliance be reduced with the isolation enabled by a virtual network or VRF?

Generally, if the answers to all the above are yes, this may sway the decision to define a virtual network or VRF for these applications and functions. When SD-Access has been deployed, routing complexity within the fabric is eliminated by virtue of the overlay’s VXLAN data plane and LISP control plane; the routing considerations are moved to the edge of the fabric. When egressing the fabric at the border there will still be a need to use either a fusion network device or firewall for any necessary route leaking between SD-Access virtual networks and the external networks. As described previously, from SD-Access release 2.3.4 the Extranet function is also available which is another option for providing a flexible and scalable method for providing access to shared services.

An example of when a separate virtual network would be useful is for PCI Data Security Standard (PCI-DSS) compliance, where security controls must be implemented restricting all access to cardholder data and transmissions. Placing all devices that will either collect, store, or transmit credit card transactions within a virtual network will drastically reduce the scope of a PCI audit, providing limited access to that environment with the appropriate policy enforcement logging capabilities.

A second example of the use of virtual networks can likewise be found in the electrical power industry. In this industry, a need exists to maintain complete isolation between networks identified as supporting critical infrastructure, namely power generation and transmission, and normal corporate operations. In this example the extremely limited communications that are required between networks is permissible only through stateful firewalls.

Other similar examples of the use of virtual networks and the need to isolate communications within them can be found in manufacturing floors, building systems, and guest networks. From a manufacturing perspective, the threat of loss of intellectual property is one of the main issues, but of equal concern is the need to isolate the factory floor because the Internet of Things (IoT) is vulnerable to malware that may literally take a company’s manufacturing hostage. Building systems such as HVAC, secure entry, and video surveillance should likewise be isolated from the rest of an organization’s networks, providing only limited access to those in maintenance or security. Finally, facilitating a guest network is a perfect example of an instance where the isolation offered by a virtual network enables the organization to grant only Internet access and nothing else.

In all these examples it is apparent that the use of virtual networks reduces the complexity of enforcing a security policy by strategically limiting access to only those that need it, using only specific protocols, while also offering rich logging capabilities when firewalls are used as fusion devices controlling inter-virtual network or traffic destined for outside the SD-Access fabric.

When considering the number of virtual networks that need to be defined, the most important consideration is the number of virtual networks supported across the network devices comprising the SD-Access fabric. Virtual networks are a fabric-wide construct. As such, if you define 15 virtual networks, for example, all fabric devices regardless of definition as an edge node or border node must be able to support this number. This consideration will typically come into play at the edge nodes where there may be platforms such as the Catalyst 9200. The Catalyst 9200-L Switches support a maximum of 1 user-defined virtual network, whereas the Catalyst 9300 supports 256. Hence with Catalyst 9200-L installed in a fabric you will be limited to 1 user-defined virtual network.

Also, when considering the number of virtual networks that need to be defined, another important consideration is that if communications between virtual networks is a requirement, some form of route leaking will be required on the fusion device. For example, if a virtual network was dedicated to employee devices only and a second virtual network was established for collaboration devices only, it would be necessary to provide a means of route leaking for collaboration applications on employee devices to communicate with IP phones, or video endpoints for example. In essence, you need to concern yourself not only with ensuring that route leaking is enabled for the appropriate address ranges, but also, from a policy perspective, with ensuring that you have identified all the UDP and TCP ports that will have to be allowed for successful communications. Likewise, the creation of separate virtual networks based on business functions such as HR, finance, and accounting, or on types of users such as students, faculty, and administration, the associated route leaking that would be required could become quite cumbersome. In these examples, the use of Security Groups to segment the users within a single virtual network should be considered as well.

As part of the routing considerations with SD-Access, you also need to understand that new IP addressing strategies may need to be implemented for the creation of the underlay network as well as for use within each of the virtual networks you may choose to create.

The best approach to creating dedicated virtual networks is to start small and grow into it. The examples highlighted above are very easily identified in that strict isolation is required with only minimal access required into and out of the segment.

Security Groups

Security Groups offer an effective segmentation strategy when dealing with applications or business requirements that do not need isolation at the network layer but require security policy controls within the same virtual network. Endpoints or users are placed into Security Groups by being assigned with a Security Group Tag (SGT). One of the main benefits of using SGTs as opposed to using virtual networks alone is the ability to micro-segment the network, even within a virtual network in SD-Access. Here, for example, policies and contracts can be created that restrict what communications are allowed between devices with different SGTs or with the same SGT, even when attached to the same switch. This capability reduces the attack surface through the ability to limit the horizontal spread of malware not only between Security Groups but even between members of the same group based on the contract and the Layer 4 access control entries within a policy.

As an example of the use of SGTs for segmentation, consider a university environment in which there are different types of users and devices such as faculty, employees, students, printers, and even campus facilities and security controls. Here the need for segmentation, even between students and campus facilities or security systems, may be addressed through the isolation offered by Security Groups.

Another example can be found in the Manufacturing Industry where many IoT devices are deployed. The IoT devices could be placed within a VN, yet micro-segmentation deployed within the VN to protect different IoT device types from each other. This reduces the attack surface, diminishes the possibility of privilege escalation, and limits the damage any malware can inflict.

During corporate mergers and acquisitions, the addition of new employees, or even the transfer of employees during or after a corporation divesture of a portion of the business, can easily be accommodated using Security Groups. The ability to then create policies granting the affected employees’ access to applications and resources they still need, while isolating them from the unaffected employees, assists in providing the policy-based controls necessary to restrict access to proprietary information.

As can be seen in these examples, there may not be a compelling reason to implement the network isolation provided using virtual networks. In all these examples, the segmentation requirements may be adequately met with the security controls available with Group-Based Policies based on Security Groups. In fact, as discussed earlier, only the use of Security Groups within a virtual network or legacy VRF can minimize the horizontal attack surface between members of the same virtual network or Security Group.

When evaluating the segmentation strategy in an SD-Access fabric, for the creation of virtual networks and subsequently the Security Groups used within the virtual network, you have the flexibility to create virtual networks with no Security Groups, or a single virtual network with many Security Groups used within that single virtual network. This decision will obviously be affected by what, if any, segmentation strategy you currently have deployed.

When considering the use of Security Groups within an SD-Access virtual network, there are several factors to consider:

  • Policies with contracts implementing numerous Layer 4-based access control entries applied to source/destination pairs (cell in a policy matrix) should be the exception and not the norm.
  • As it is not possible today to implement a firewall within a virtual network of an SD-Access fabric, stateful packet inspection between SGTs is not possible; stateless SGT-based policies and associated contracts will be used. A new feature called Security Service Insertion is a function currently in design, whereby the SGT will be used to steer traffic towards a firewall and back again so that stateful inspection is supported within a fabric. Keep an eye out for feature enhancement announcements for when this will be supported in a fabric.
  • Careful consideration of the criteria requiring a unique SGT should be defined, as well as the overall number of SGTs to be supported.
  • Not all endpoints/users need be assigned an SGT, if unassigned then the Unknown (SGT 0) will be allocated.

It is important to understand that the policies and the contracts (known as SGACLs in ISE) they consist of, will consume switch TCAM. The use of contracts or SGACLs with numerous access control entries may result in TCAM exhaustion, after which new policies may not be programmed. When possible, keep the policies as simple as possible. Understand also that Group-Based Policies will not provide the same stateful packet inspection and guaranteed logging capabilities offered by a firewall.

That said, it is equally important to understand that in most cases the segmentation offered using Security Groups provides excellent security controls between users and devices in the same virtual network. Today, many organizations and government agencies have been implementing Cisco Group-Based Policy as either the sole or at least the major technology in addressing their segmentation strategy.

Reader tip
The use of SGTs as a security control for POS machines and card readers is solely at the discretion of the PCI assessor for the audit. The use of SGTs in past audits, however, has been accepted as evidence of a security control. Any organization preparing for a PCI audit should discuss this beforehand with its assessor. For one story, please refer to the following URL https://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise-networks/Group-Based Policy/Group-Based Policy_pci_validation.pdf


Although it is possible to deploy virtual networks without using Security Groups in an SD-Access fabric, a virtual network must exist to deploy endpoints/users assigned to SGTs in the fabric. By default, the DEFAULT_VN is provided within Catalyst Center, but best practice is to either rename DEFAULT_VN to something more appropriate for your deployment or add further user defined virtual networks.

Since Catalyst Center release 2.3.3, a decision was made to disassociate the virtual networks and security groups. Network devices have always supported VRF-agnostic SGTs and there was no need to keep the constraint within Catalyst Center. However, the coordinated change in ISE could not be provided until release 3.2. The result is that Catalyst Center still sends the virtual network and security group association to ISE if the integrated ISE release is older than 3.2. From ISE 3.2, integrated releases of Catalyst Center 2.3.3 or later do not send the virtual network and security group associations. The effect of this is what is seen within the ISE SGT construct and how the SGT, VN and VLAN are provisioned within the ISE authorization profile. When integrated with ISE 3.1 or older, the SGT construct within ISE shows the virtual network and the VLAN associations. This feeds onto the ISE authorization profile where the Security Group Common Task allows the admin to select an SGT, then restricts selection to only an associated virtual network, further restricting selection to only an associated VLAN. When integrated with ISE 3.2 or newer, the SGT construct within ISE does not show any associations to a virtual network or VLAN. This feeds onto the ISE authorization profile where the Security Group Common Task allows the admin to select an SGT, then select any virtual network, then enter the text of any VLAN name.

When assigning a Security Group within a virtual network, the use of that SGT for the creation of Group-Based Policies is not limited to that SD-Access virtual network or indeed to that SD-Access fabric. An SGT is VN-agnostic, and endpoints/users can be classified into that group within different virtual networks, different SD-Access fabrics or even outside a fabric. As traffic egresses a virtual network at the border node, a Group-Based Policy can be enforced for external destinations, either at the border, depending on the platform, or at a device closer to the destination provided that the enforcing device has knowledge of both the source and destination IP to SGT mappings. Source mappings are carried across the fabric to the Border within VXLAN and then best carried in the data-plane from Border to enforcement device outside the fabric using inline tagging. This relies on manual hop-by-hop configuration from Border to that enforcement device outside the fabric. Alternatively, both source and destination mappings can be sent to the enforcement device via Security Group Tag Exchange Protocol (SXP) or pxGrid depending on the feature support of that device.

When implementing an SD-Access Distributed Campus deployment configured with an SD-Access transit, the SGT will be communicated seamlessly without the need to use Cisco Group-Based Policy inline tagging or SXP, because the SGT will be carried in the VXLAN header between the border nodes of each fabric. Similarly, if an SD-WAN transit is deployed, the SGT will be transferred end to end over IPsec.

Reader tip

For more information about SD-Access Distributed Campus Deployment using SD-Access Transits, refer to the SD-Access for Distributed Campus Prescriptive Deployment Guide.

For more information on using SD-WAN as a transit, refer to this guide on independent domain pairwise integration.


Catalyst Center uses a default permit group-based policy setting. This means traffic will always be permitted unless there is a specific group to group policy denying the communication between those groups. This is simple to deploy, is fully automated, and any policy discrepancies can be managed as new groups are added and endpoints/users classified. There is an option to set default deny instead but bear in mind the required fabric configuration is not fully automated for this today and there is potential to block endpoints and users from gaining access to required services unless every communication path has been understood and allowed for by adding specific permit policies. Also remember that downloaded policy is implemented platform-wide across all VNs including the Global VRF. This means even routing protocols will go down if not catered for when implementing a default deny policy. This sounds catastrophic but is in fact fairly simple to overcome but it is a roadmap item (at the time of writing) for automation to take care of the needs. Note the following:

  • Catalyst Center does not provision the SD-Access border node to enforce.
  • The Catalyst 9000 series does not enforce traffic destined towards an internal IP.
  • When implementing a default deny policy, always manually provision ‘no cts role-based enforcement’ on the fabric-facing interfaces.

Taking those notes in mind, just think about the fabric edges. In a pure fabric deployment, any traffic being sent towards the fabric will not be enforced as the platform has been set to not enforce on those interfaces. Any traffic being received and destined for internal IP addresses, routing protocols in the underlay for example, will not be enforced either. So, with the simplicity of manually disabling enforcement on the fabric uplinks, the basic fabric operation will continue to function. This includes communication to/from Catalyst Center, Cisco ISE and any services required across the underlay. Of course, if enforcement has been manually enabled on the SD-Access border then flows north bound through that border will need to be catered for and required permit policies would need to be managed for the endpoints and users in the overlays. It is very important to note that Access Point and Extended Node management is carried out in the underlay, using the INFRA_VN. This means that management traffic will be denied south bound on the fabric edge towards these devices using a default deny. Consequently, management of these devices need to be handled with permitting specific group to group policies or by disabling enforcement on those downlinks for example. To summarize, implementing a default deny policy is much more difficult and hazardous today without automation capabilities. Default deny can be implemented using manual intervention as explained but some customers may want to wait until the capability can be automated.

One final point to consider is that much like the consideration paid to the number of virtual networks created the number of Security Groups to create must be evaluated. Although assigning an SGT to each major department within an organization is quite normal and acceptable, you should not try to subdivide departments into hundreds of other roles within that department.

Taking a university environment as an example, you may define an SGT for “professor.” You then might realize that you want to break that down into departments such as math, physics, biology, and languages. The question you should ask yourself is if there really is a need to create multiple department based SGTs for professors, each with unique policies, or whether it really matters that all of these departments share a common SGT with the same access to servers and other data.

The best approach to defining Security Groups is not to create a group for every possible role, function, device type, etc., upfront. Doing so will not only lead to extensive policy creation but will additionally require more TCAM and memory resources for SGACL storage on switches and routers. In almost all cases, extensive group definitions and the ensuing policy creation will minimally slow down any segmentation project as all contributors discuss the benefit of one policy versus another, also known as “analysis paralysis.” Then, even if you are fortunate enough to agree quickly on groups and policies, as the policy is implemented, changes will inevitably need to be made to address an oversight, resulting in a possible denial of service and a ripple effect of policy changes.

Like evaluating a virtual network (VN) strategy, start out small and start slowly. Identify those groups for which tangible benefits can be derived immediately from the ability to limit access to specific applications and data. Once the effectiveness of the initial policies has been determined, you can easily modify them as necessary while also determining whether additional group definitions may be necessary.

Macro segmentation: Virtual Network considerations

Macro segmentation is accomplished using virtual networks (VN’s) within Catalyst Center but manifests itself as VRFs on the network devices. Segmentation is inherent within the network devices due to the segregation of the network routes. The configuration necessary is easily automated by Catalyst Center providing security without needing to administer additional groups or policies.

Cisco SD-Access provides an underlay for global routing, plus VN/VRF overlays for the onboarding of users and endpoints. Catalyst Center also provides a virtual network construct for the underlay, called the INFRA_VN. It is this construct which is used at the SD-Access Border to communicate the global routes. Additionally, management of network devices such as Access Points and Extended Nodes is carried out via the underlay INFRA_VN.

Consequently, there exists an INFRA_VN plus one or more user or endpoint VN’s within an SD-Access fabric. Entities within one VN cannot communicate with entities in another across the fabric. However, these entities will inevitably need to communicate with users, endpoints, servers, services etc. outside the fabric. Therefore, these VN’s are automated onto the SD-Access Border for hand-off to the rest of the network. As an example, figure 2 shows the Catalyst Center automation GUI for an interface being handed off to the rest of the network, with VN’s BuildingMgmt, BuildingSecurity and INFRA_VN being handed off.

  1. SD-Access Border automation showing assigned virtual networks.

image2.png

 

The Border itself has this configuration automated but the up-stream network device the Border is connected to, is not automated by Catalyst Center. That up-stream network device, often called a fusion device, must be manually configured to receive the corresponding VRFs and accompanying routes. Often the configuration practice is to first automate the Border configuration and then copy that configuration from the Border to the Fusion but transposing the relevant arguments. As well as managing the VRFs on the Fusion device, an administrator may also have to manage route-leaking and route redistribution. Routes within VRFs are learned from the Border via BGP. If the Fusion then forwards traffic (say towards a data center) in the global routing table using OSPF, then the Fusion must be configured to route-leak the routes from the VRFs received from the Border to the global routing table and must route redistribute from BGP to OSPF.

Using these VRF-Lite techniques is the basis for multiple hand-off types like hand-off to a Router, Firewall, Cisco SD-WAN Edge or to a data center. Border connectivity via VRF-Lite is not the only method of connectivity to transport the Macro segmentation context. Take an SD-Access transit for example. Two or more SD-Access fabrics can be connected via an SD-Access transit which basically consists of a Transit Control-Plane node. Once a LISP lookup has been accomplished, data flows end-to-end between these fabric sites, across the transit, with the VN information intact transported within VXLAN.

All macro-segmentation (VN) and IP Pool related configuration need not be provisioned on all fabric edges/extended nodes within an SD-Access site. The SD-Access fabric zone feature was released in version 2.2.3 of Catalyst Center which allows virtual network and IP pool provisioning to be limited to selected fabric edges/extended nodes rather than provisioning those constructs into all fabric edges in the site. This provides scale benefits as configuration is only provisioned where it is needed. There is no impact to macro segmentation if fabric zones are used, the same concepts apply whether zones are configured or not.

Catalyst Center release 2.3.3 introduced automated provisioning of end-to-end Macro segmentation between an SD-Access fabric and a data center Application Centric Infrastructure (ACI) fabric. Again, this uses VRF-Lite to join the two domains, but automation is the key here to provide seamless multi-domain macro segmentation.

The conclusion is that Macro segmentation is straight forward to implement and provides a resilient and robust method of segmentation. It is effective within an SD-Access fabric and can be conveyed to network devices and systems outside the fabric to maintain the required segregation throughout an enterprise.

Tech tip
For more information refer to the SD-Access Macro-Segmentation Prescriptive Deployment Guide

 

Micro Segmentation: Security Group Tag considerations

Micro segmentation simplifies the provisioning and management of network access control using groups to classify network traffic and enforce policies. This allows more granular security policies within the virtual networks in an SD-Access fabric.

Catalyst Center automates the security policy including Security Groups, Contracts and Policies and pushes these into Cisco Identity Services Engine (ISE). The assignment of Security Groups and handling of policy downloads is the responsibility of Cisco ISE – it is the policy engine for the solution.

When scale is a factor, it may be necessary to deploy more than one Catalyst Center cluster. Multiple independent clusters connected to a single ISE is supported but SD-Access constructs will not be shared, and group-based policy will need to be managed in ISE. For a dependent integrated approach, Catalyst Center clusters can share SD-Access constructs and group-based policy, but this deployment model is not yet generally available and a request to download a software package to enable the function needs to be made. When the package is installed, the first cluster to connect to ISE is made the author (where policy, VNs, SD-Access Transit information and VN extranet policy can be created, edited, and deleted) and the subsequent clusters are denoted as readers. Currently, with the multi–Catalyst Center package, up to five clusters are supported integrated with a single Cisco ISE.

See the reader tip below for Catalyst Center scale supported and a guide for deploying multiple Catalyst Center clusters to single ISE.

Reader tip

Appliance scale supported by Catalyst Center can be found in the latest data sheet.

Guide for Multiple Catalyst Center clusters to single ISE.


Traffic classification is based on endpoint identity and context not IP address, enabling policy management without the constraints of local constructs such as VLAN and Subnet. Cisco ISE gathers advanced contextual data about who and what is accessing your network, uses the defined Security Group Tags (SGTs) from Catalyst Center to assign roles and access rights and then handles the policy download to the network devices. This makes use of rich contextual information to provide simpler security policy management, and policies which are dynamic more suitable to today’s needs.

The micro segmentation technology is defined by three primary concepts: classification, propagation, and enforcement, each of which will be discussed within the sections below. When users connect to the network, they are authenticated using methods such as 802.1X and MAC authentication bypass (MAB). Network authorization follows which entails classifying the user’s traffic leveraging rich contextual information such as identity, LDAP group membership, location, access type for example. After the user’s traffic is classified, network devices propagate the classification information towards a network device assigned to be an enforcement point where the dynamically downloaded policy dictates whether the traffic should be permitted or denied.

Classifying Users and Endpoints into Groups

For when users or endpoints connect to the network, an admin needs to decide which Security Groups to assign plus what conditions to use for that assignment. Remember, Micro segmentation is a group-based technology, so the idea is to group entities together requiring a similar security need. For example, an enterprise may decide all Guests have a similar requirement and Contractors and Employees together may have a similar requirement. This would equate to two groups, one containing Guests and another containing Contractors and Employees. The requirements will depend on the needs of different organizations.

The admin would then check in Catalyst Center if those group definitions were already available. The Security Group named Guests is already available pre-defined, but a second group could be created within Catalyst Center, perhaps called Employees_and_Contractors. Once defined and saved in Catalyst Center, these definitions are pushed into ISE to be available for assignment. Using ISE is not the only way to assign an SGT to users and endpoints. Using ISE is the best and recommended way to assign SGTs as it is dynamic and flexible. However, you could deploy the Authentication template called ‘None’ to switch ports in which case there will be no authentication to ISE and therefore no way for ISE to assign an SGT via Authorization. In this case, there are two ways detailed below how Catalyst Center can be used instead to statically assign SGTs to users and endpoints.

Reader tip
When classifying endpoints/users into groups within an SD-Access fabric, the ONLY attribute that a group is bound to is the IP address. This creates a mapping or binding of the endpoint/user IP address (static or dynamic via DHCP) to the SGT assigned. This leads to a concept of an IP to SGT mapping or binding. We will learn that Catalyst Center can statically assign VLAN to SGT and Port to SGT classification configuration but in both cases, groups are assigned to IP addresses which are learned via those mechanisms.


Dynamic Classification using Cisco ISE

Once the grouping has been decided, the admin would then choose specific context to use in ISE to assign the users into their respective groups. There are hundreds of conditions and attributes available within ISE but the determination for this example is straight forward i.e., if the user is making use of the ISE Guest Flow, then the Guest SGT assignment would be appropriate. If the user’s username is in the Employees or Contractors Active Directory User Group, then the Employees_and_Contractors SGT assignment would be appropriate. These conditions are built into ISE Authorization rules with the appropriate SGT assigned.

Now, when a Guest connects to the network, a RADIUS Access-Request would be sent to ISE, he/she would be authenticated and authorized with a RADIUS Access-Accept by matching the condition of using the ISE Guest Flow and assigning the Guests SGT. Additionally, part of authorization is to also assign the appropriate VLAN the Guest should be using which has already been placed in the correct VN via automation on the network device.

Similarly, when an Employee or Contractor connects to the network, a RADIUS Access-Request would be sent to ISE, he/she would be authenticated and authorized with a RADIUS Access-Accept by matching the condition of username being present in an Active Directory group lookup and assigning the Employees_and_Contractors SGT. Again, part of authorization is to also assign the appropriate VLAN the Employees and Contractors should be using which has already been placed in the correct VN via automation on the network device.

That concludes how an SGT is dynamically assigned to users and endpoints connecting to the network. It is accomplished through RADIUS between the network access device and Cisco ISE when the users and endpoints connect to the network.

As a sidenote, it is perfectly acceptable and supported for Catalyst Center to manage the policy and ISE to classify endpoints and users with an SGT even if they are outside a fabric. If the associated network access device is not known by Catalyst Center, then ISE will need to have the Network Device entry manually entered. Once SGTs, policies and contracts are added into Catalyst Center, they are all pushed into ISE, and are then ready for devices inside and outside a fabric to be used for endpoint classification and enforcement. One note of caution for migrating brownfield group-based policy deployments to being managed in Catalyst Center. For releases before 2.3.3, Catalyst Center would overwrite the CTS credentials on the network device disconnecting the CTS communications between the device and ISE. From release 2.3.3, Catalyst Center now checks the ISE Network Device entry for a particular device and if CTS credentials are already provisioned then the CTS credentials on the network device are not overwritten.

Static Classification using Catalyst Center

Sometimes there are occasions where ISE does not play a part in endpoint onboarding. For example, an authentication template exists called ‘None’ where no authentication commands are automated on the access port. In this case, endpoints could just connect to the network and gain full access with no authentication or authorization. In this case, an SGT can still be assigned to those endpoints, but they are assigned using a static approach using Catalyst Center.

There are two methods of assigning static SGTs within Catalyst Center, one to assign an SGT to endpoints on a VLAN, and the other to assign an SGT to endpoints on a single fabric edge interface/port.

Static SGT Assignment Using VLAN to SGT Mapping.

Within Catalyst Center, when navigated to Provision > SD-ACCESS > Fabric Sites > Site_Name > Host Onboarding > Virtual Networks > VN_Name, this is where VLANs/IP Pools are added to the virtual network. If a VLAN/IP Pool has already been added, then it is not possible to edit the Security Group assigned. If an SGT is needed to be assigned to an existing VLAN/IP Pool entry, then it will need to be deleted and re-added. When you add a VLAN/IP Pool association, a Security Group (SGT) can be assigned to that VLAN, as shown in figure 3:

  1. SGT assignment under the VLAN/IP Pool to VN association:

image3.png

 

Once assigned and deployed, the CLI is automated on the fabric edges as follows:

cts role-based sgt-map vlan-list <VLAN ID> sgt <SGT ID>

This instructs the fabric edges to assign the SGT to any learned IP communicating inbound through that VLAN. IP Device Tracking is essential for this operation, the configuration for which is already automated by Catalyst Center. This VLAN to SGT mapping has the lowest precedence for all classification methods; if SGT static classification is also provisioned for an associated Interface/Port (Port to SGT described below) or dynamically assigned by ISE, dynamic from ISE takes precedence, then Interface/Port, then VLAN.

One important use-case for Catalyst Center utilizing static VLAN to SGT mapping is when non-policy extended nodes are deployed. Extended nodes are not equipped for group-based policy functions and as such, segmentation is purely handled by using VLANs on these nodes. The nodes are connected to fabric edges via a trunk so even though there can be no group-based enforcement between endpoints on the same VLAN on an extended node, we can use group-based micro segmentation on the fabric edge for inter-vlan extended node communications. Catalyst Center can be used to provision static VLAN to SGT mappings on the fabric edge for these extended node VLANs and enforce as required.

  1. Static VLAN to SGT Assignment for Extended Node use.

image4.png

 

When an extended node is capable of group-based policy functions, the node is called a ‘Policy Extended Node’. Hardware platforms such as the Catalyst 9300 and the Industrial Ethernet 3400 can be policy extended nodes. In this case, the policy boundary does not end at the fabric edge as in the case with a non-policy extended node but is moved down from the fabric edge to include the policy extended node. SGTs are assigned on the policy extended node, group-based policy is downloaded, and policy is enforced at egress on the platform, just as if it were a fabric edge. To propagate the SGT between the policy extended node and the fabric edge, inline tagging is utilized, the configuration for which is as follows (configuration is automated by Catalyst Center on the conjoined interfaces of both the fabric edge and the policy extended node):

cts manual
policy static sgt 8000 trusted

There is a difference between a policy extended node and a fabric edge with respect to policy. Any statically assigned SGT from Catalyst Center IP Pool/VLAN to VN onboarding, the VLAN to SGT configuration is not provisioned on the PEN, only on the fabric edge.

Reader tip
We have discussed VLAN to SGT static classification not being provisioned on the PEN, being automated from Catalyst Center fabric onboarding, and adding an SGT under IP Pool/VLAN to VN. This is a note to say Port to SGT is assigned to a PEN interface if assigned under onboarding > Port Assignment and assigning an SGT to an interface for User Devices. Port to SGT static classification assignment is described below.

Static SGT Assignment Using Port to SGT Mapping.

Within Catalyst Center, when navigated to Provision > SD-ACCESS > Fabric Sites > Site_Name > Host Onboarding > Port Assignment, this is where individual ports can be statically configured. Select the relevant fabric edge from the search panel on the left and then select the individual port in question and select ‘Assign’:

  1. Configuring Individual Fabric Edge Interface/Port under Onboarding

image5.png

 

In the following pop-up screen, assign the connected device type, VLAN name and Security Group:

  1. SGT Assignment under individual port

image6.png

 

 

Set the Security Group as shown in the figure above (the example uses HVAC SGT 18), but note, the authentication template must be set to None for the static SGT to be set. Once saved and deployed, DNAC will automate the following highlighted configuration on the selected network device interface:

interface GigabitEthernet1/0/2

switchport access vlan <VLAN number>

switchport mode access

device-tracking attach-policy IPDT_POLICY

load-interval 30

cts manual

policy static sgt <SGT_Number>

no propagate sgt

no macro auto processing

spanning-tree portfast

spanning-tree bpduguard enable

This instructs the fabric edge interface/port to assign the static SGT to any learned IP communicating inbound through that interface/port. IP Device Tracking is essential for this operation, the configuration for which is already automated by Catalyst Center. This Port to SGT mapping has a precedence between the dynamic SGT assignment method and the static VLAN to SGT assignment method, where dynamic assignment from ISE has highest priority. Additionally, traffic exiting the port will have no CMD field in the L2 frame due to the configuration ‘no propagate sgt’.

Propagating Source Security Group Information

For a group-based enforcement point to enforce traffic, that platform needs to have knowledge of which group the source endpoint/user is a member of, plus which group the destination endpoint/user is a member of. Understanding a flow’s source and destination groups is a prerequisite for an enforcement point to be able to enforce using Group-Based Policies.

An enforcement point/device may natively know which group an endpoint or user is a member of. As an example, if a user connects directly to a fabric edge, authentication and authorization will take place with Cisco ISE and an SGT will be assigned. That assignment will be communicated to the fabric edge where it will be used to classify the traffic coming into the fabric edge from that user. The consequence of this is that the fabric edge will then understand which group that user is a member of. If a second user connects to that same fabric edge, then that fabric edge will become to understand which groups both users are members of and will then be capable of enforcing traffic from one to the other without the need of any membership propagation.

Propagation comes into play when endpoints/users are connected to different network devices, or where enforcement is required elsewhere in the network. As an example, user1 connects to fabric edge 1 with SGT10 assigned, user2 connects to fabric edge 2 in the same fabric site, with SGT20 assigned. Fabric edge 1 has knowledge of the group user1 is a member of, but it does not natively have knowledge of the group user2 is a member of. Within a fabric, the SGT (SGT10) is propagated from fabric edge 1 to fabric edge 2 within VXLAN of every packet sent from user1 to user2. This will inform fabric edge 2 of the group user1 is a member of and can subsequently enforce the traffic from SGT10 to SGT20. Reversely, the SGT (SGT20) is propagated from fabric edge 2 to fabric edge 1 within VXLAN of every packet sent from user2 to user1. This will inform fabric edge 1 of the group user2 is a member of and can subsequently enforce the traffic from SGT20 to SGT10.

When source and destination are discussed with respect to propagation, it is in relation to the flow of traffic. The source SGT is defined as the group unidirectional traffic is sourced from. The destination SGT as the group unidirectional traffic is sent to. So, in a bidirectional flow, both ends are a source and destination, it depends which direction is of interest. From a network device point of view, if it is an enforcement point, it will initially carry out a source SGT lookup to determine what group the source is a member of. After determining the routing and egress interface, that enforcing network device will carry out a destination SGT lookup and then enforce from source SGT to destination SGT if appropriate.

How source and/or destination SGT are propagated are discussed in the following sections:

Native Propagation Across an SD-Access Fabric Using VXLAN

If two endpoints are connected to the same fabric edge, then no propagation is necessary. The first endpoint will have an SGT assigned, as will the second, and the fabric edge can enforce traffic from one to the other without needing to propagate any SGT information to any other platform.

If endpoints are connected to different fabric edges within the same fabric site, then the first fabric edge will have knowledge of the SGTs assigned to the connected endpoints but will not natively know of SGTs assigned to endpoints on different fabric edges. If/when traffic flows from an endpoint on one fabric edge to an endpoint on another fabric edge, the source SGT is propagated from the source fabric edge to the destination fabric edge within every VXLAN packet transmitted. When the VXLAN packets are received, the destination fabric edge carries out a source lookup for the SGT from the source, it already understands the destination SGT, so it can enforce as defined.

If traffic flows north bound within a virtual network overlay i.e., from fabric edge to border, then the same occurs, the source SGT of the endpoint/user is inserted into every VXLAN packet transmitted by the fabric edge sourced from the endpoint/user. If the traffic flows south bound within a virtual network overlay i.e., from some server via border to fabric edge, then again, the source SGT of the server is inserted into every VXLAN packet transmitted by the border towards the endpoint/user (classification of the server in this case would need to be applied somewhere in the path from the server).

As a summary, source SGT is always carried in the VXLAN packets in the SD-Access overlay, and traffic towards endpoints/users in the fabric is enforced at egress i.e., at the destination fabric edge.

Propagation Between Fabric Sites Using SD-Access Transit

An SD-Access transit utilizes VXLAN to transport packets from one fabric to another. This means the source SGT is propagated end to end within VXLAN. When traffic is sent from user1 in fabric1 to user2 in fabric2, then the SGT assigned to user1 is inserted into VXLAN and carried from the fabric edge to the border of fabric1, across the SD-Access transit and from the border to the fabric edge of fabric2 where enforcement will take place.

Reader tip
This guide will show you how to deploy unified and consistent policy across a metro area SD-Access deployment consisting of multiple, independent fabric sites utilizing SD-Access transits: https://cs.co/sda-distrib-pdg


Propagation From/to Fabric Sites Using SD-WAN

Similarly, to an SD-Access transit, the SGT can be carried end to end when Cisco SD-WAN is integrated.

Reader tip

These are the design guides for SD-Access and SD-WAN end to end segmentation.

This first guide is utilizing independent domains where the SD-Access border and SD-WAN cEdge are separate devices and the SGT is preserved using inline tagging in the L2 frame: https://cs.co/independent-domain

This second guide is utilizing integrated domains where the SD-Access border and SD-WAN cEdge are the same device: https://cs.co/integrated-domain


Propagation Between Fabric Sites Using IP Transit

Unlike the SD-Access Transit or SD-WAN integrated domain multi-fabric scenarios, the SGT is not preserved natively when an IP transit is deployed between fabric sites. This section describes two methods of carrying the source SGT over an IP Transit to facilitate Group-Based Policy enforcement between sites.

Using Inline Tagging within IP Transit

Much like the SD-WAN independent domain, one solution is to enable inline tagging (insert the source SGT into the L2 frame) to preserve the SGT where native propagation is not available.

Reader tip
This guide will show you how to deploy unified and consistent policy across an SD-Access deployment consisting of multiple, independent fabric sites utilizing IP transits: https://cs.co/sda-distrib-pdg


If you want to be able to propagate the source SGT from one fabric site to another over an IP Transit, then inline tagging will be most efficient method. This does require inline tagging to be enabled on every hop between the sites, but once deployed the source SGT will be carried over the data-plane with no sharing of out of band control-plane mappings required. The following diagram shows inline tagging being utilized to carry the source SGT from one site to another.

  1. Inline tagging enabled between fabric sites.

image7.png

 

 

Reader tip
For more information about Group-Based Policy inline tagging, please refer to the User-to-Data-Center Access Control Using Group-Based Policy Deployment Guide

Using SXP within IP Transit

If enabling inline tagging between fabric sites is not possible or not desired, then SXP can be utilized to share the mappings from site to site.

When users/endpoints authenticate and are authorized onto the network, ISE assigns the SGT via the authorization table and learns the user/endpoint IP address via accounting. ISE therefore learns of the IP to SGT mapping of that user/endpoint.

For ISE to send the mappings for IP Transit communication, the SXP function would need to be enabled within ISE under Administration > System > Deployment > ISE_Persona > General Settings:

  1. Enable SXP within ISE.

image8.png

 

The dynamic mappings would also need to be placed into the ISE SXP table. Ensure the option is selected in ISE under Work Centers > TrustSec > Settings > SXP Settings:

  1. ISE setting to place dynamic mappings into SXP table.

image9.png

 

In ISE, navigate to Work Centers > TrustSec > SXP > All SXP Mappings to see the dynamic mappings learned:

  1. ISE SXP mapping table

image10.png

 

 

Reader tip
Mappings will only show up in the ISE SXP Mappings table if there are SXP Devices configured to consume those mappings


These mappings learned, say from site A, can be sent to site B via SXP. SXP connections (called SXP Devices in the ISE GUI), can be added from ISE to the site B border. This allows traffic flowing from Site A to Site B to be reclassified on the Site B border with the original source SGT, be carried over VXLAN and enforced on the fabric edge.

Mappings reside within VRFs/VNs in network devices so the mappings will need to be sent to each VN on the border that requires traffic to be reclassified. This entails creating one SXPv4 connection per VN.

  1. Sending SXP Mappings to remote border

image11.png

 

SXP version 4 has been prevalent in the last few years. It carries IP to SGT mappings plus also provides loop detection and prevention and keep alive mechanisms. SXP version 5 was released with IOS-XE 17.9.1 and that enhances the protocol by additionally carrying the VLAN and VN of the source. This helps in an SD-Access deployment because only one SXP connection is required to be sent to an SD-Access border to propagate all the required mappings in all VNs on the border. At the time of writing, Cisco ISE does not yet support SXPv5 but deploying an IOS-XE reflector could significantly help simplifying the deployment requirements (see the following Reader tip for details).

Reader tip
SXPv5 is explained within this document along with details of how it helps with deploying mappings to an SD-Access border in an IP Transit scenario.


Enforcement Based on Security Group Information

Enforcement within an SD-Access Fabric

For a group-based enforcement point to enforce traffic, that platform needs to have knowledge of which group the source endpoint/user is a member of, plus which group the destination endpoint/user is a member of. Understanding the source and destination groups for a flow is a prerequisite for an enforcement point to be able to enforce using Group-Based Policies. Other prerequisites are that the platform needs to be configured to enforce both at L3 and L2 if appropriate, and a related Group-Based Policy needs to be downloaded from Cisco ISE.

Reader tip
Network devices such as routers and switches require both the source and destination group information to be able to enforce. Firewalls on the other hand, can mix and match group information with traditional IP based controls. For instance, an SGT can be used within a Firewall access rule for indicating the source criteria and an IP/subnet can be used for indicating the destination. Equally, the SGT can be used to indicate the destination and IP/subnet as the source.


Catalyst Center automates all the configuration necessary for an SD-Access fabric edge to enable enforcement, plus ultimately to carry out enforcement using downloaded Group-Based Policies. To enable enforcement at L3 and L2 the following two lines of CLI are pushed to the fabric edges via automation:

cts role-based enforcement
cts role-based enforcement vlan-list x

The first command enables enforcement globally and on all L3 interfaces, the second enables enforcement on the L2 interfaces/VLANs that are listed within the command.

When endpoints/users connect to the fabric edges, and authentication and authorization occurs with Cisco ISE, SGTs are assigned to the learned IP addresses of those endpoints/users. The fabric edge subsequently learns of the IP to SGT mappings present and downloads policy from Cisco ISE for traffic destined towards these SGTs. This coincides with the policy matrix columns for these SGTs. With these policies downloaded, enforcement can take place for any traffic sourced elsewhere in the network and destined at egress towards these endpoints/users. Remember from the propagation section in this document, each of these fabric edges learns of the source group membership from VXLAN, knows the destination group membership from authorization with Cisco ISE, has a policy downloaded and so can enforce.

Traffic can also flow from outside the fabric, destined towards endpoints/users on a fabric edge. Enforcement works in the same way in that SGTs are assigned to the endpoints/users on the fabric edge and policy is downloaded to protect those SGTs. When traffic flows from outside but towards the fabric, perhaps from a server, the server source SGT could possibly be propagated via inline methods from the server’s access switch towards the fabric. If then inline tagged from fusion to border it could be sent to the fabric edge via VXLAN to be used in egress enforcement at the fabric edge. If the server is not classified at the server’s access switch, then maybe it can be classified somewhere on the path towards the fabric. This includes the fusion device, the server could be classified here, inline tagged towards the border and then sent via VXLAN in the overlay to be used in egress enforcement at the fabric edge. If not classified anywhere along the path from server to border, then the server could be classified on the border with the resulting SGT enforced on the fabric edge as explained previously. The following figure shows these scenarios:

  1. Classifying endpoints and enforcing fabric destined traffic on the egress fabric edge

image12.png

 

As mentioned previously, the SD-Access fabric zones feature was released in Catalyst Center version 2.2.3. This feature allows virtual network and IP pool provisioning to be limited to a certain number of fabric edges rather than provisioning those constructs into all fabric edges in the site. There is no impact to micro segmentation if fabric zones are used, the same concepts apply whether zones are configured or not.

Enforcement Between Fabric Sites with SD-Access Transit

As has been mentioned in the propagation section, the source SGT of an endpoint/user in one SD-Access fabric is carried via VXLAN end to end across the SD-Access Transit and to the fabric edge in the destination fabric site. The destination fabric edge then has knowledge of the source SGT (from VXLAN) and the destination SGT (through authorization typically) and can enforce.

Enforcement Between Fabric Sites with SD-WAN Transit

This is similar to using an SD-Access Transit in that the SGT is carried end to end, but the SGT between the SD-Access fabric sites is carried within IPsec in SD-WAN. As with SD-Access transit, enforcement is carried out at the destination fabric edge.

Enforcement Between Fabric Sites with IP Transit

When there is no automation available to deploy the WAN services between fabric sites then a non-automated method must be deployed. This interconnection is called an IP Transit and some decisions and manual configuration must be made. The recommendation is to try to find a supported method of transporting the source SGT within the data-plane i.e., use inline tagging where the SGT is inserted into the CMD field of each L2 frame. This requires hop by hop interface configuration across the transit and has limited support from non-Cisco vendors but allows enforcement to be carried out at the egress fabric edge as is best practice. If Cisco routers are used to connect to the WAN, then protocols such as GRE, IPsec, DMVPN or GETVPN could be deployed and is able to carry the source SGT within the protocol headers to provide end to end policy as described before. These inline methods should be deployed where possible.

If it is not possible to transport the SGT within the data-plane, then control-plane methods are also possible. Security Group Tag Exchange Protocol (SXP) is one such method where a TCP overlay transports SGTs and their associated IP addresses from one location to another. Typically, the SGTs and IP memberships are sent from Cisco ISE to the border of the destination fabric where traffic received from remote sites is reclassified and forwarded onto the fabric edge for enforcement.

Egressing an SD-Access Fabric Enforcing Near the Destination

There are scenarios where traffic exits a fabric and is destined towards non-fabric locations such as cloud providers, traditional data centers and services/endpoints/users on traditional networking infrastructure. The Group-Based Policy technology is designed to be best enforced near network egress, i.e., near the destination. The reason is due to scale. The nearer enforcement is to the destination, the less SGTs that need protection which leads to less policies needing to be downloaded per network device.

For enforcement at the destination, or at a device along the path toward the destination, the IP to SGT mapping of that destination endpoint must be present at the enforcement device. If enforcement is on the network device that the destination is attached to, that endpoint must be “classified” or associated with an SGT. Classification or creation of the IP to SGT mapping can be performed locally on the network device dynamically through 802.1x or MAB; or statically through IP to SGT, Subnet to SGT, VLAN to SGT, or Port to SGT through the device CLI, based on the capabilities of the platform. Alternatively, the destination IP to SGT or Subnet to SGT mappings could be created at ISE and advertised through SXP to the destination network device. If enforcement is desired at a network device along the path to the destination, SXP or static classification at an intermediate device will be required, and best practice is to choose a device as close to the destination as possible, as explained.

As a last resort, enforcement can be carried out on the Border of an SD-Access fabric for traffic egressing the fabric. Bear in mind this is much closer to the source than the destination and therefore there is a potential need to enforce many destination SGTs leading to many policies being downloaded. This is supported but scale is on obvious factor; check the reader tip below.

Reader tip
It is important to consider the number of IP to SGT and SGT/DGT policies supported per platform type for any deployment. It is particularly pertinent when enforcing fabric egress traffic on a border due to the border being close to the source. Being close to the source means there are potentially many SGTs outside this fabric to protect and therefore many policies to download. The scale supported per platform can be seen in the latest SD-Access data sheet.


In addition to the destination IP to SGT mapping, the enforcement point also requires the source IP to SGT mapping. The source mapping of the SD-Access endpoint/user will need to be propagated to the enforcement point and this can be achieved in the following ways.

Benefits of Inline Tagging

Inline tagging is always the most preferred approach to carry the source security group information because the SGT is embedded in the Ethernet header of every packet sent toward the destination. Unlike SXP, all processing of the SGT is performed in hardware, whereas SXP will consume memory and processor cycles to store and update the mappings. To support inline tagging, all links between the border to the enforcement point must be manually enabled for inline tagging. This enablement is performed on each device on a hop-by-hop basis.

  1. Group-Based Policy inline tagging enabled in non-SD-Access infrastructure.

image13.png

 

Note the figure above shows you will not only be able to enforce Group-Based Policy for traffic sourced from the fabric at the external destination, but you will also be able to enforce return traffic from servers to fabric endpoints at the fabric edge nodes. This is possible if servers or other external destinations are classified with an SGT and propagated back toward the fabric over the non-fabric infrastructure enabled for inline tagging.

<

Reader tip

For more information regarding Group-Based Policy inline tagging configuration, please refer to the User-to-Data-Center Access Control Using Group-Based Policy Deployment Guide and the User-to-Data-Center Control Using Group-Based Policy Design Guide.

For additional information regarding platform support for inline tagging, refer to the latest Group-Based Policy capability matrix.

Use of SXP

If you decide to use SXP as a control-plane propagation method as opposed to inline tagging, you will need to configure ISE to advertise the IP to SGT mappings created during endpoint AAA authorization, as we have discussed. You will then need to configure the SXP TCP overlay connection(s) from ISE to the enforcement point(s) over which the IP to SGT mappings will be transferred.

  1. SXP to enforcement point external to the fabric

image14.png

 

Consider the server connected to the enterprise network as depicted on the right in the figure above. Servers do not normally make use of dynamic network access methods as they need to provide service 100% of the time. Connectivity is permanent and without interacting with Cisco ISE, the assigned SGT must be provided statically. Static mappings such as IP to SGT, Subnet to SGT, VLAN to SGT, or Port to SGT can be deployed through the device CLI, based on the capabilities of the platform. Alternatively, the destination IP to SGT or Subnet to SGT mappings could be created at ISE and advertised through SXP to the destination switch.

There are scale considerations to keep in mind as you select those devices that require SXP mappings for enforcement purposes. There’s the IP to SGT mappings themselves, plus the policies downloaded as a subsequence of the device learning of those SGTs that require protecting.

Reader tip

For the latest information regarding platform Group-Based Policy scalability for the number of mappings supported, SXP, and SGACLs, please refer to the latest capability matrix.

For additional information regarding SXP, please refer to the Using SXP and SXP Reflectors document.

Use of pxGrid

IP to SGT mappings could be propagated to the enforcement device at the destination using pxGrid if that enforcement device supports that publication/subscription mechanism from Cisco ISE. Cisco Secure Firewall supports pxGrid via Firepower Management Center but other main Firewall vendors also support pxGrid. Both source and destination IP to SGT mappings can be propagated using this method if required.

Egressing an SD-Access Fabric Enforcing on Border or Fusion

The previous section discussed enforcing near the destination or network egress. This is desirable for scalability reasons. The nearer the destination enforcement is, the less SGTs that need protecting and therefore less policies are needed to be downloaded. Conversely, the closer to the source enforcement is, the more SGTs that need protecting and more policies are needed to be downloaded, possibly exhausting resources on the enforcing device. If enforcement cannot be carried out near the destination for any reason, then enforcement must be moved back towards the source, the last options being the fusion device or the SD-Access Border of the fabric where the source resides.

Enforcing on the Fusion

If the fusion device is chosen to be the enforcement point for certain traffic exiting a fabric, then the source and destination IP to SGT mappings must be understood by the fusion device. The source mapping can be sent to the fusion via inline methods or via control plane mechanisms. Via inline is often best because the source SGT is already propagated from the fabric edge to the border within the VXLAN overlay, so configuring inline tagging from the border to the fusion is all that is necessary to extend that propagation to the fusion.

Reader tip
At the time of writing, Cisco products encompassing the Silicon One ASIC do not support inline tagging. These include the C9500X-28C8D, C9500X-60L4D and any C9600X Sup2 (with any line card). Engineering work is ongoing to support inline tagging on these products in the future.


The destination mapping can be sent to the fusion via control-plane methods; typically, SXP is used. If the fusion is a firewall such as the Cisco Secure Firewall, or firewalls from Check Point, Fortinet or Palo Alto, then pxGrid is utilized. With Cisco Secure Firewall, you must be running version 6.5 or later for destination SGT support. There are obvious benefits to using a firewall as a fusion, such as deep packet stateful inspection, but there is another reason with respect to SGTs. Firewalls can mix and match source and destination criteria. For example, an access rule can match a source group based on SGT, and an IP based destination. Conversely, an access rule can match an IP based source and a group-based destination. Cisco routers and switches do not support this mix and match capability, they purely support both source and destination as SGT groups within their group-based policies.

  1. Enforcement on the fusion for traffic exiting a fabric.

image15.png

 

Enforcing on the Border

The use of the SD-Access border node for SGT-based enforcement is applicable only for fabric traffic destined outside of the fabric. For traffic entering the fabric at the border, enforcement is always carried out on the fabric edge.

When traffic from a fabric overlay enters the border, the source SGT is always received via VXLAN. To enable the border to enforce, the border must be configured to enforce (the enforcement commands are not automated by Catalyst Center), plus some method of assigning the destination IP mapping must be employed.

Commands required to enable enforcement on the border:

cts role-based enforcement
cts role-based enforcement vlan-list <List of VLANs or ‘all’)

To inform the border of any destination IP to SGT mappings, CLI or SXP can be used to deploy IP or Subnet to SGT mappings.

Reader tip
This Cisco Communities guide displays commands and SXP guidance when enforcing on the border.


As when enforcing on any network device, care must be taken to ensure resources are not breached. There are always limits to the number of IP to SGT mappings and policies supported.

Reader tip
The SD-Access data sheet informs of how many IP to SGT mappings/bindings, SGT/DGT policies and SGACE entries are supported on the different border hardware types.


Enforcement Ingressing an SD-Access Fabric

When traffic flows from outside an SD-Access fabric to inside, the best scenario is that the source SGT is being carried in the data-plane before reaching the border. Then the border would receive the source SGT within every frame and pass it over VXLAN to the fabric edge where it would be enforced.

Ideally, the source endpoint would be classified on the access device that source endpoint is connected to, with the SGT propagated inline in the data-plane all the way from that access device to the border and over VXLAN to the fabric edge. Sometimes though, this is not possible, the next best scenario being to work forward from the source and classify the source endpoint at the next available classification point. If the endpoint were a server in a data center for example, this next available classification point may be a router interconnecting the data center to the rest of the Campus network. If still not available or desired to classify there, then classification can be carried out anywhere on the path from endpoint to fabric including the fusion or border.

If classifying the source endpoint on the fusion, CLI or SXP can be utilized to add the IP or Subnet to SGT mapping. In that case, inline tagging would need to be configured between the fusion and the border to carry that classification information in the data-plane towards the border and then over VXLAN to be enforced at the fabric edge.

If classifying the source endpoint on the border, CLI or SXP can be utilized to add the IP or Subnet to SGT mapping.

  1. Tagging external traffic destined to fabric

image16.png

 

Enforcement Between Two Virtual Networks in the same Fabric Site

You can also enforce policies using SGTs to permit or deny traffic between virtual networks. Typically, macro-segmentation using virtual networks in the campus is generally intended to provide complete isolation. However, occasionally there is a need to allow some traffic between them such as allowing certain admin group access to IoT management for example. As we know, traffic cannot flow from one VN to another within the fabric, so VN to VN traffic must flow to the fusion device in the source VN and back again in the destination VN.

If inline tagging is deployed between the border and fusion device, then the source SGT of an endpoint in the source VN, can be carried to the fusion and then carried from the fusion back in the destination VN where it will then be sent over VXLAN to the fabric edge to be enforced.

If inline tagging is not deployed between the border and fusion device, then the source SGT will need to be reclassified on the border as traffic re-enters the destination VN. Static mappings or mappings from SXP can be used for this purpose.

  1. Enforcement of Traffic Between VNs

image17.png

 

Appendix A: Cisco Group-Based Policy—Software-defined segmentation

While VRF-Lite and MPLS were starting to be adopted by non-service provider enterprises to provide network segmentation as a means of enforcing a security policy, an alternate means, using logical or software-defined constructs, was developed by Cisco known as Cisco Group-Based Policy. Unlike VRF-Lite or MPLS, the Cisco Group-Based Policy architecture is not reliant upon IP addressing and unique routing instances to provide isolation. Cisco Group-Based Policy can be implemented without the need for VRFs. Group-Based Policy is completely topology-independent.

At the heart of the Cisco Group-Based Policy architecture are Security Group Tags (SGT). SGTs allow for the abstraction of a host’s IP address through the arbitrary assignment to a closed user group represented by a defined SGT. Typically, these groups can make use of groups already created in Microsoft Active Directory or Lightweight Directory Access Protocol (LDAP). In the case of IoT, devices will be organized independently, based on purpose or type of device.

For centralized management of a Cisco Group-Based Policy deployment, the Cisco Identity Services Engine (ISE) is required for both RADIUS-based identity services and SGT-based policy handling. Within SD-Access, the SGTs and policies are typically created and centrally managed in Catalyst Center, but they are pushed into ISE for operation. There is also an option to create and manage SGTs and policies within ISE itself if required.

Dynamic SGT assignment occurs upon successful authentication and authorization to the network through 802.1X, MAC Authentication Bypass (MAB), or WebAuth, or using Active Directory passive monitoring. Once authorization is complete, ISE communicates the SGT associated with that device via RADIUS to the network device to which they are attached. This results in the mapping of an IP address to an SGT at the network device; this mapping is then used for device communications and policy enforcement. SGTs can also be manually defined on Cisco Group-Based Policy capable switches and routers for a port, VLAN, subnet, or individual IP address, for those devices where dynamic authentication is either undesirable or not possible.

The SGT can be either advertised as an IP address to SGT mapping via a control-plane TCP-based protocol known as the Security Group Tag Exchange Protocol (SXP) or communicated over pxGrid. Alternatively, it can be carried in the data-plane as a 16-bit value within a Cisco proprietary field known as Cisco Metadata (CMD) inserted into an Ethernet frame, as seen in the following figure. This is known as inline tagging.

  1. EtherType 0x8909 showing CMD Field facilitating inline tagging.

image18.png

 

Inline tagging is performed on a hop-by-hop basis on Cisco Group-Based Policy capable switches and line cards. Once a switch receives an IP to SGT mapping from ISE, from a static configuration, or even from having learned it via SXP, it will insert the CMD shown in the figure into the Ethernet frame and forward it in that endpoint’s traffic out a Cisco Group-Based Policy enabled interface. Upon arrival at the upstream switch, the CMD will be extracted, and the SGT derived. At this point either it can be forwarded along with the same tag enroute to the destination or policy enforcement based on the SGT may occur.

Group-Based Policies can be assigned within ISE authorization rules and distributed dynamically for use in enforcing policy on supporting routers and switches using security group ACLs (SGACLs) (otherwise known as Contracts within Catalyst Center). A matrix automated by Catalyst Center and residing in ISE is based on source and destination groups and is used for policy creation, as seen in the Figure below. Additionally, security group firewalls (SGFWs) such as the Cisco Adaptive Security Appliances (ASA) or Firepower NGFWs, as well as the Cisco IOS® Zone-Based Firewall (ZBFW) on Integrated Services Routers (ISRs) or ASR routers, can make use of locally created firewall rules based on the SGT for policy decisions. Group-Based policies on firewalls provide stateful inspection whereas SGACLs on routers and switches are stateless.

  1. Policy Matrix shown in ISE.

image19.png

 

Policy enforcement occurs at the first network device where both the source SGT can be derived, either through its presence in the Ethernet frame or due to SXP advertisement, and the destination’s IP to SGT mapping exists. Typically, this will be at the device to which the destination is attached, but it may be on a device in the path between source and destination if SXP or static mappings have been used to create the IP to SGT mapping on the intermediary device.

For policy enforcement to occur, the SGACLs configured at the ISE must be downloaded to the network devices. With local resource limitations (TCAM and memory) for storing these SGACLs in mind, only the policies for those SGTs with a mapping on a network device will be downloaded from the ISE. This results in only the policies to be used for traffic destined for a device with an SGT mapping being downloaded, thus conserving local resources. This is also why Cisco Group-Based Policy is known to enforce policies upon egress from the network.

Unlike VRF-Lite or MPLS, Cisco Group-Based Policy does not rely on multiple VLANs or routing tables providing isolation and control. Instead, only a single routing table for all forwarding is required, with isolation enabled by virtue of group membership, the SGT representative of that group and assigned to the device, and the group-based policy centrally managed and distributed by Cisco ISE to the network infrastructure.

Cisco Group-Based Policy and VRFs can be used together and are not mutually exclusive. When using Cisco Group-Based Policy and VRFs together, macro-segmentation is possible by virtue of the isolation between VRFs, while further micro-segmentation is then possible with the use of Cisco Group-Based Policy within the VRFs.

Although Cisco Group-Based Policy inline tagging can be supported when VRF-Lite is used for network connectivity, it not supported in MPLS environments where both Label Distribution Protocol and Cisco Group-Based Policy are required on the interface. This is not a configuration limitation but an architectural one, whereby the label forwarding information base (FIB) is used for next-hop processing, unlike the standard FIB, and hence the SGT and its IP association can’t be learned. In MPLS networks it is necessary to use SXP to “propagate” or communicate the IP to SGT mapping across the MPLS portion of the network.

Reader tip

For more information about Cisco Group-Based Policy, please visit https://www.cisco.com/go/Group-Based Policy.

For platform support and scale information please see the latest SD-Access data sheet: https://www.cisco.com/c/en/us/products/cloud-systems-management/dna-center/datasheet-listing.html


Appendix B: References

SD-Access Capability Guide: https://www.cisco.com/c/dam/en/us/td/docs/Website/enterprise/sda_compatibility_matrix/index.html

Latest SD-Access data sheet including platform support and scale: https://www.cisco.com/c/en/us/products/cloud-systems-management/dna-center/datasheet-listing.html

SD-Access validated design guides: https://community.cisco.com/t5/networking-knowledge-base/cisco-en-amp-c-validated-design-and-deployment-guides/ta-p/3777320

SD-Access Design Guide: https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Campus/sda-sdg-2019oct.pdf.

Enforcing Policy on an SD-Access Border Node: https://communities.cisco.com/docs/DOC-77432

Cisco’s intent-based networking architecture: https://www.cisco.com/c/en/us/solutions/intent-based-networking.html

Group-Based Policy on CCO: https://www.cisco.com/go/Group-Based Policy

Group-Based Policy Platform Capability Matrix: https://www.cisco.com/c/en/us/solutions/enterprise-networks/trustsec/solution-overview-listing.html

Group-Based Policy User-to-Data-Center Access Control Using Group-Based Policy Deployment Guide: https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Apr2016/User-to-DC_Access_Control_Using_Group-Based Policy_Deployment_April2016.pdf

Access Control Using Security Group Firewall: https://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise/design-zone-security/access_control_using_security.pdf

Feedback

For comments and suggestions about this guide and related guides, join the discussion on Cisco Community at https://cs.co/en-cvds.

image20.jpeg

 

Comments
kadsteph
Cisco Employee
Cisco Employee
‎10-11-2023 03:32 PM

Comments on this article have been closed.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Customers Also Viewed These Support Documents