Showing results for 
Search instead for 
Did you mean: 
Cisco Employee
Cisco Employee
Segmentation Strategy - An ISE Prescriptive Guide





image.png For an offline or printed copy of this document, simply choose ⋮ Options > Printer Friendly Page. You may then Print, Print to PDF or copy and paste to any other document format you like.


Jonothan Eaves 







About Segmentation

Software defined segmentation simplifies the provisioning and management of network access control through the use of groups to classify network traffic and enforce policies. Traffic classification is based on endpoint identity and context not IP address, enabling policy change without network redesign. A centralized policy management platform gathers advanced contextual data about who and what is accessing your network, uses security group tags (SGTs) to define roles and access rights and then pushes the associated policy to your network devices such as switches, routers and security platforms. This provides better visibility through richer contextual information and allows an organization to be better able to detect threats and accelerate remediation, reducing the impact and costs associated with a potential breach.


Software defined segmentation technology is embedded within network switches, routers, wireless LAN infrastructure and firewalls and is defined by three primary concepts; classification, propagation and enforcement. When users connect to the network, they are authenticated using methods such as 802.1X, MAC authentication bypass (MAB), web authentication or Passive authentication. 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.

There are some new functions required to implement the technology, but subsequently the effort for adds, moves and changes is dramatically reduced once deployed.


About This Guide

This guide is intended to provide technical guidance for a segmentation strategy, as well as providing advice on how to get started. The guide covers design topics, deployment best practices and how to get the most out of the technology operation.


Figure 1: Guide workflow for segmentation


As highlighted in figure 1 above, there are four major sections in this document. The initial, define part talks about defining the problem area, planning for deployment, and other considerations. Next, in the design section, we will see how to design for a segmentation project. Third, in the deploy part, the various configuration and best practice guidance will be provided for key components such as Cisco Identity Services Engine (ISE) and Cisco Catalyst Center if orchestrated within a Software Defined Access (SDA) network. Lastly, in the operate section, we will learn how best to manage a segmented network.



Many people understand the importance of segmentation as a means to reduce the threat landscape. However, traditional segmentation techniques are commonly configured manually per device, have network infrastructure and local addressing significance (VLANs and IP Subnets), are static in operation and are not scalable leading to higher OpEx.

Cisco recommends an alternative approach called software defined segmentation. This is centrally managed by Cisco Identity Services Engine (ISE), orchestrated by Cisco Catalyst Center if deployed within an SDA network, is based on security groups (using security group tags (SGTs)) which are abstracted from locally significant entities such as VLANs and IP Subnets, is dynamic and scalable.


When deciding on a software defined segmentation strategy, there are some steps to consider:

  • There must be a clearly defined use-case, and a priority list if there are multiple use-cases at the outset. It is recommended to start with a specific use-case to prove value and provide an operational understanding. Some example use-cases are:
    1. Reducing the number of IP access lists in the network on devices such as routers and switches
    2. Reducing and simplifying Firewall rules
    3. Segregating user groups
    4. Segregating IOT devices from user groups
    5. Reducing scope for regulation (such as PCI, HIPAA etc.) and therefore reducing cost of audits
    6. User to DC access control
    7. DC segmentation; controlling server to server communication
    8. Limiting access to cloud workloads
    9. Limiting the attack surface for lateral movement
  • Within each use-case it must be clear what resources are needed to be protected. Protection may be required for applications or servers from user access, for users from receiving payloads from other users or data center repositories from being accessed by machine to machine (M2M) communications.
  • The components of software defined segmentation need to be understood (classification, propagation and enforcement).



Before designing your software defined segmentation strategy, the following points should be considered:

  • Start with desired business goals in mind
  • Many use-cases can be localized and do not need to be deployed globally
  • Solving problems where OpEx is high can give max ROI (measure OpEx first)
  • Unlike traditional segmentation/access control…
    1. Adding dynamically assigned groups later should be easy
    2. Dynamic operation allows separation of duties between network infrastructure and policy deployment teams
  • Keep groups as simple as possible whilst still meeting policy requirements
  • It should not be necessary to transfer complexity, e.g. extensive AD groups, into security Groups
  • Consider if all roles need a tag assigned as non-tagged assets can assume a default role (providing scalability)
  • Remember that group membership may often change but the technology will dynamically cater for the transition
  • Within an SDA network, consider what segmentation is required at the Macro-Level (Virtual Network (VN)/VRF Level) and what is required at the Micro-Level within the VN/VRF using Security Group Tags (SGT’s).


When designing your strategy:

  • Discuss and determine the assets which need protecting
  • Define asset groups (and VN’s if SDA) and choose mechanisms for classifying systems (assigning security groups to assets)
  • Based on the policy goals, choose where policy enforcement is needed
  • Decide on the best methods to propagate the security group tags for policy enforcement


These four design strategy steps are shown here in figure 2:




Figure 2: Approaching a Segmentation Design

Discuss Assets to Protect

There may be multiple assets which need protecting in an organization. Examples are servers/endpoints for regulation (PCI, HIPAA etc.), production users and servers, developers and development servers, other user groups, medical, financial or personal records and so on. This will vary from one organization to another.


Classification Mechanisms

Once it is known which assets need protecting, classification groups and mechanisms can be designed.

Group names can be used which are meaningful to the organization and to the protected asset. For example, if production servers need protecting then a likely name for that group could be production_servers. The security policy which will be defined later will reference these group names so using meaningful names makes policy management very simple and straight forward.


Machines providing critical services typically would not be setup to authenticate with an authenticating server, so static classification would be utilized for such systems. Different static classification methods are shown on the right of figure 3 below.


Users such as employees, guests and contractors can be dynamically classified utilizing AAA services from ISE as shown on the left of figure 3. If a supplicant is available on the clients then 802.1x can be utilized and if no supplicant is available then MAC Authentication Bypass (MAB) or PassiveID/Easy Connect can be used. Guests typically use an ISE web portal to register and access the network (Web-Auth). With all these methods, ISE can dynamically assign the users into the appropriate groups.


Screenshot 2022-08-16 at 18.46.11.png


Figure 3: Classification Types With Example Locations


Classification means assigning an SGT to an IP address. IPv4 and IPv6 IP addresses are supported. See the latest platform capability matrix for classification support here:


Where the classification is assigned in the network depends on the type of classification and the use-case being deployed. The platform type is also a consideration. Platforms like the 3560x, 3560-CX, 3750x and the Industrial Ethernet products use an ASIC which requires the MAC address of the endpoint to be learned for successful classification (IP Device Tracking entry is required). This means that endpoints needing classification have to be L2-adjacent to the switch. For further limitations of these switch types, see this link:

It is therefore recommended to use switch types like the 3650, 3850, Cat4k, Cat6k and Cat9k family where possible. These use ASICs which are IP-based and do not exhibit the same limits as the products requiring L2 adjacency.

For NX-OS platform classification capabilities (this refers to the N7k, N5k, N2k products, the N9k does not support classifiction or enforcement using SGTs), please see the Data Center Segmentation Guide:


Dynamic Classification

For dynamic classification, some possibilities are A to G, as shown below:


A. For wired 802.1x or MAB, the access switch will typically receive the assigned SGT from ISE and classify traffic being received from the host.


B. For wireless connectivity, the WLC will typically receive the assigned SGT from ISE and classify traffic being received from the AP.
C. From code version 8.4 and later, Wave 1 (1700, 2700, 3700) and Wave 2 (1800, 2800, 3800) Access Points can receive the assigned SGT from ISE (via the WLC) and classify traffic immediately when it is received by the AP. 5520, 8540 and 3504 WLC’s are required for this function.
D. For remote access VPN, the ASA will typically receive the assigned SGT from ISE and classify traffic being received from the remote host.
Figure 4 shows wired, wireless and remote access VPN dynamic classification with ISE:Figure4.png
Figure 4: Dynamic SGT Assignment with Classification Sent to Access


  1. Wired, Wireless and Remote Access catered for.
  2. Switch/WLC/ASA sends RADIUS request to ISE when user/endpoint connects.
  3. Through conditions set in ISE authorization rules, SGT assigned and sent in the authorization reply to the access device.
  4. IP to SGT mapping on the access device received from ISE is used to classify traffic from user/endpoint.
  5. Classification information is propagated towards an enforcement point in one of a number of different ways (see methods later in this document). Option from wireless 8.4 to send classification information from the 8540/5520/3504 WLC to the Wave1/Wave2 AP where the AP is then the enforcement point.
  6. A device, set as an enforcement point, either permits or denies traffic based on the classification and enforcement information it receives.


E. For all cases above, it is also possible for ISE to dynamically assign an SGT to a learned IP from a session and send the mapping to any device for classification anywhere in the network via SXP (explained in figure 18) or pxGrid (explained in figure 21).


F. If there is no 802.1x Supplicant deployed to a number of Windows endpoints then secure connectivity can still be provided as shown in figure 5. This feature is called PassiveID (otherwise known as Easy Connect). When users connect (without using a Supplicant), the access switch authenticates the endpoint using MAC Authentication Bypass (MAB), and ISE authorizes that session by initially allowing access to essential network services (including the ability to logon to the Microsoft Domain). The user then logs onto the Domain and ISE learns the user details by monitoring Windows Management Instrumentation (WMI) messages from Microsoft Active Directory. ISE then re-authorizes the user, provides full access and assigns an SGT based on the policy defined.


Note: Microsoft recently confirmed the architectural failings of WMI and stated an alternative protocol for Easy Connect - known as the 'EVT’ (Eventing Remote Protocol) or 'Eventing' API, which is more efficient. So, ISE supports EVT from release 3.0 for monitoring AD logon events.



Figure 5: PassiveID Operation


  1. Switch sends MAB RADIUS request to ISE when user/endpoint connects (restricted access granted)
  2. User logs onto Windows Domain
  3. ISE learns the user details by monitoring WMI messages from AD (see note above about EVT use from ISE 3.0)
  4. ISE re-authorizes the user (using RADIUS CoA), provides full access and assigns an SGT
  5. The IP to SGT assignment is sent to network devices via SXP


G. When ISE has Application Centric Infrastructure (ACI) Policy Element Exchange enabled (as shown in figure 6), then EndPoint Groups (EPG’s) and group membership information learned from Application Policy Infrastructure Controller (APIC) can be shared with network devices in the Campus for dynamic classification (and therefore enforcement) across domains. Note that ISE also sends information to APIC for policies to be built in the ACI domain based on security Group Tags (SGT’s) and group membership from the Campus. This integration allows any automation introduced to be effective across domains.




Figure 6: ISE to APIC Integration, Mapping SGTs from/to EPGs


Static Classification

For static classification of SGTs to users/endpoints there may be multiple network locations for assignment:

  • On the Campus or DC access switch you may implement L2 interface classification.

              To configure L2 interface classification:

                        cts manual

                          policy static sgt x           [where x is the SGT for classifying the endpoint/user]

                          no propagate sgt           [Propagation is to be disabled, only classification enabled]


  • IP, VLAN and Subnet classification is typically assigned on the Campus access or distribution layer and also in the DC on platforms that support them.

              To configure IP to SGT mappings in the default VRF:

IOS cts role-based sgt-map <ip> sgt x
NXOS cts role-based sgt-map <ip> x


              To configure IP to SGT mappings in a VRF:

IOS cts role-based sgt-map vrf <vrf> <ip> sgt x
NXOS cts role-based sgt-map <ip> x (under the VRF)


              To configure Subnet to SGT mappings in the default VRF:

IOS cts role-based sgt-map <ip/mask> sgt x
NXOS cts role-based sgt-map <ip/mask> x


              To configure Subnet to SGT mappings in a VRF:

IOS cts role-based sgt-map vrf <vrf> <ip/mask> sgt x
NXOS cts role-based sgt-map <ip/mask> x (under the VRF)


              To configure VLAN to SGT mappings:

IOS cts role-based sgt-map vlan-list <vlan list> sgt x
NXOS cts role-based sgt x (under the VLAN)


              The bindings for each mapped VLAN are inserted into the IP-to-SGT table associated with the VRF the VLAN is mapped to, by either its SVI or by the following command:

                        cts role-based l2-vrf <vrf> vlan-list <vlan list>


  • L3 interface classification is typically used for partner connectivity, mergers or acquisitions and is commonly configured on switches or routers in the Campus.

              To configure L3 interface classification:

                        int <int>

                          no switchport

                          ip add <ip> <mask>

                          cts role-based sgt-map sgt x


  • Virtual Port Profile is used on the Nexus 1000v / Nexus 1000VE so that virtual machines inherit the SGT from the assigned profile.

              To configure a port-profile:

                        port-profile type vethernet <name>

                          switchport mode access

                          switchport access vlan <vlan>

                            cts manual

                            policy static sgt x                     [Where x is added in hex in this format: ‘0xb’ for SGT 11]

                          role-based enforcement

                          no shutdown

                          state enabled

                          vmware port-group


  • IP and Subnet classifications can be centrally managed in ISE and pushed to network devices either using SSH or by using Security Group Tag Exchange Protocol (SXP - see the Propagation section later for a description). ISE supports IPv6 static mappings in release 2.4 along with IPv4 and IPv6 FQDN lookup from DNS when deploying mappings. An ISE utility is available to check IP to SGT mapping synchronization with network devices which is particularly useful when importing a large number of mappings into ISE and conflicts or duplicates are a concern. Figure 7 shows the ‘Check Status’ function:


Figure 7: ISE Check Status function for Static Mappings


Note: When configuring IP:SGT mappings via SSH, ISE is not VRF aware. So, if mappings are required within an SDA Border for example, the ISE SSH function cannot be used as mappings need to be provisioned within the individual Virtual Networks / VRFs.


See the following for an example output for checking status, ISE logs into each network device and notifies the administrator if any anomalies are detected:


Found 2 devices to process

Check status process started

About to connect to: Kernow-4500x

About to connect to: Kernow-6500

Kernow-4500x-IP( Configuration downloaded

ERROR: Conflict: On device Kernow-4500x, is mapped to multiple SGTs: Contractors (5/0005), Auditors (9/0009), BYOD (15/000F). Remove conflicting mappings or modify scope of deployment.

Kernow-6500-IP( Configuration downloaded

ERROR: Kernow-6500-IP( Configuration needs to be updated. Found 3 missing, 0 with incorrect tag and 0 redundant mappings

Check status process finished


  • If utilizing Cisco Catalyst Center within SDA, then:

Classification Precedence

When designing for classification choices, using the classification precedence can really help when rolling out services. There is a strict order of precedence for classification methods as documented in the TrustSec Troubleshooting Guide:


An example of using the precedence to your advantage is when rolling out an 802.1x supplicant to employees. Plan to deploy VLAN to SGT or Subnet to SGT mapping initially, to provide a coarse-grained classification and then slowly roll out 802.1x supplicants to employees where dynamic SGT assignment will take precedence.

Another example is with SGT fallback mechanisms, see the following section.


SGT Fallback Mechanisms

From the precedence list linked above, it can be seen for Cisco IOS devices that IP to SGT mappings added via the CLI is a low precedence compared to mappings learned from SXP or dynamic sessions. This allows CLI mappings to be configured as a fallback in case the SXP or dynamic mappings disappear for any reason.


Note: By default, the Nexus 7000 prioritizes CLI mappings over mappings received by SXP or dynamic sessions. However, in release 8.0(1), an option has been added to change this prioritization to make the operation equivalent to Cisco IOS. To enable this change of prioritization, use the following command in the Nexus 7000 from release 8.0(1):

no cts role-based priority-static


While discussing fallback mechanisms, it is worth mentioning the capabilities of Identity-Based Networking Services (IBNS) 2.0. This enhanced access session manager provides a policy and identity-based framework for flexible and scalable services using Cisco Common Classification Policy Language (C3PL).

An example for activating a service template for SGT fallback can be found at the following link:

Basically, the example configuration is as follows:


service-template FALLBACK                                            [Configure a fallback template]

 description fallback service

 access-group ACL_2

 redirect url

 inactivity-timer 15

 absolute-timer 15

 tag TAG_2                                                                      [Assign an SGT to be used in a fallback scenario]


policy-map type control subscriber POSTURE_VALIDATION

 event session-started match-all

  10 class always do-all

   10 authenticate using dot1x                                          [Try dot1x authentication first]

 event authentication-failure match-all

  10 class DOT1X do-all

   10 authenticate using mab                                            [Try MAB if dot1x authentication fails]

  20 class MAB do-all

   10 activate service-template FALLBACK                       [Default authorization profile assigned using the FALLBACK

                                                                                       template if MAB authentication fails]



When deploying Port to SGT or VLAN to SGT mapping then IP Device Tracking is a prerequisite. Traditional IP Device Tracking is configured with the following command:

‘ip device tracking’.

A feature called Switch Integrated Security Features (SISF) has been implemented more recently. This is an infrastructure built to take care of security, address assignment, address resolution, neighbor discovery, exit point discovery, and so on. For more details see the following link:

The Cat6k has been migrated to use SISF since release 15.2(1)SY for both IPv4 and IPv6. For the rest of the Catalyst switches, IPDT is used for IPv4 & SISF used for IPv6. In Polaris code (from release 16.x), SISF is used across all routers & switches for both IPv4 and IPv6. See the following for how to configure SISF:


device-tracking tracking


device-tracking policy config_sisf

  limit address-count x

  tracking enable


interface gigabitEthernet 2/7

  device-tracking attach-policy config_sisf


vlan configuration 56

  device-tracking attach-policy config_sisf


Policy Enforcement Points

Now that the assets needing protection are known along with the groups and classification methods, documentation can be created depicting group to group interaction and policy required, whether that policy is to deny all traffic between certain groups, permit traffic, or to deny or permit certain TCP/UDP ports. Figure 8a shows an example with Software Defined Access (SDA) deployed and 8b without SDA.


Screen Shot 2018-12-18 at 11.08.11.png


Figure 8a: Diagram Showing Classification and Intended Policy in SDA




Figure 8b: Diagram Showing Classification and Intended Policy, non-SDA

Figures 8a and 8b depict examples of a very simple design where groups have been defined and a policy specified denying traffic from the Production_User group to the Development_Srvr group. Examples of both an SDA deployment and a non-SDA deployment have been provided.


Deciding where to enforce the policy is largely down to the platform types in the network and the location of the enforcement point within the network:

a) Different platform types have different segmentation capabilities. To enforce, the platform needs to support either SGACL downloads from ISE or SGFW rules as depicted in the last column of the capability matrix:


b) The location in the network is very important. Take the network switch connected to the Directory_Services group in the Data Center of the figures above. This is the only switch connected to the Directory_Services group and as such would typically have the classification mapping for servers in that group provisioned on that switch. If a Directory_Services server had an IP address of, that would be mapped to the Directory_Services group in the switch, creating what is known as an IP to SGT mapping. As soon as the switch learns of this mapping, the switch will send a RADIUS request to ISE to request the policy matrix column for traffic destined to that group. Note, assuming this is the only switch in the whole network that has this mapping in its database then this is the only switch in the whole network that will download this policy protecting the Directory_Services group. If the enforcement point was closer to the user then it would need to protect more destination groups and therefore need to download more policies. This is why the recommendation is to enforce as close to the destination as possible (egress enforcement) and is how the technology scales. Having said that, ingress enforcement is not precluded; one use-case being to optionally enforce on a Branch router before sending out to the WAN – if the platform acting as the Branch router can handle the scale required for the particular deployment then that is certainly supported. For enforcement within the SDA fabric, egress enforcement is always administered.


The use-case shown above is based on User to DC access control with enforcement within the DC. Other use-cases could be User to User enforcement or to segregate building management systems from building security systems. In those cases, the assets to protect are in the Campus/Branch access layer so the enforcement points would be the Campus/Branch access or aggregation layers instead.


Segmentation and Enforcement Within SDA

Within SDA, segmentation is built using a 2-layer approach. The first layer is segmenting between Virtual Networks (which are synonymous to VRFs). Traffic would need to leave the fabric (via the Border) and be routed back again in order to flow from one VN to another. This is known as Macro-segmentation. Within each VN is implemented Micro-segmentation which uses SGT’s to enforce from one security group to another. Figure 9 shows both methods:



Figure 9: Relationship Between SDA Virtual Networks and Security Group Tags


Use virtual networks when requirements dictate isolation at both the data plane and control plane. Some examples are shown above in figure 9 like segregating Campus users from building security and management systems. If communication is required between different virtual networks, you use an external firewall or other device outside of the fabric to enable inter-VN communication. Segmentation using SGTs allows for simple-to-manage group-based policies and enables granular data plane isolation between groups of endpoints within a virtualized network, accommodating many network policy requirements. Using SGTs also enables scalable deployment of policy, without having to do cumbersome updates for policies based on IP addresses. VNs support the transport of SGTs for group segmentation. You can choose either VN (Macro) or SGT (Micro) or both segmentation options to match your requirements


Remember that a small number of VN’s and SGT’s can initially be used to satisfy any immediate security concerns. It is very simple to add further VN’s and groups after an initial deployment.

Default Enforcement Policy

When designing the SGT policy, take into consideration that there is a default action which is to permit or deny everything undefined. If deploying within an existing network, it would seem safer to start with a default permit (deny list model). This means that the traffic denied will only be the traffic that is explicitly denied by the added policies. With a new installation (greenfield deployment) a default deny policy (allow-list model) can be used more confidently as policies can be built and tested while services are being rolled out.

Whether to choose a default permit or deny policy largely depends on the requirement. If the requirement is to permit most traffic on the network and deny a lesser extent then less policies will be needed by using a default permit with explicit deny rules. Conversely, if the requirement is to deny most traffic on the network and permit a lesser extent then less policies will be needed by using a default deny with explicit permit rules.


The following is an example of an SGACL using an allow list model (default deny) which is the basis for network zero trust initiatives:


permit icmp

permit udp dst eq domain

permit udp dst eq bootpc

Permit udp dst eq bootps

permit tcp dst eq www


In contrast, this is an example of an SGACL using a deny list model (default permit):


deny icmp 

deny udp src dst eq domain

deny tcp src dst eq 3389

deny tcp src dst eq 1433

deny tcp src dst eq 1521

deny tcp src dst eq 445

deny tcp src dst eq 137

deny tcp src dst eq 138

deny tcp src dst eq 139


A comparison of two matrices is shown in the following figure where the result would be the same. Consider what is best for your design to ensure least effort for maximum business value.




Figure 10: Keeping the Policy Matrix Simple


If a default deny policy is the desired goal within an existing network then consider starting with the following policy:




Figure 11: Existing Network Deployment with Default Deny

Unknown SGT

At the beginning of deployment, nothing will be classified and therefore the policy Unknown – Unknown will come into play which will permit all traffic with the policy as shown above. When the first endpoint is classified (for example into group Production_User), all other endpoints in the network will be unknown. So, policies Production_User to Unknown and Unknown to Production_User will come into play which again will permit traffic. As more and more endpoints are classified then the policy can be built slowly and traffic patterns monitored over time to ensure the requirements are being accommodated.


Note: To avoid issues with policy matching on legitimate traffic due to unknown SGT/DGT, or default deny policy, it is recommended to disable enforcement (no cts role-based enforcement) on uplinks (switch-to-switch or switch-to-router uplinks). This ensures enforcement occurs at the intended location i.e. generally at network egress.


Note: At the time of writing, Cisco switches and Routers do not support enforcement of multicast traffic, enforcement is by-passed completely for multicast. Additionally, before IOS-XE release 17.1.1 there was no option to enforce a specific policy for broadcast/DHCP traffic and it was subjected to ‘Default Policy’ or ‘Unknown’ as it could not be resolved to a specific SGT/DGT pair. For DHCP data plane before release 17.1.1, the only option was to explicitly allow the traffic within the default or Unknown SGACL. Since release 17.1.1 broadcast/DHCP also bypasses enforcement.


Policy Download Mechanism

When considering policy enforcement on network devices, note that policy will only be enforced if the ‘cts role-based enforcement’ configuration command(s) are applied to network devices.

Once applied, if there are IP to SGT mappings resident in the mapping table then policy protecting those SGT’s will be downloaded from ISE.

Only the required policy is downloaded as shown in the following diagram:




Figure 12: Only Required Policy is Downloaded


Once a network device learns of the first group membership (IP to SGT mapping), it will request policy from ISE. The request is only for policy to protect that particular SGT, so the matrix column is dynamically downloaded and applied for that SGT. The policy remains applied within the network device until all the relevant group memberships have been removed from the device at which time the policy is also removed. This ensures the controls and policies are managed centrally, the security policies are de-coupled from the network topology, policies are downloaded, applied and removed dynamically and there is no device specific security configuration needed.


Enforcement for groups containing IPv4 and IPv6 IP addresses are supported. See the latest platform capability matrix for enforcement support here:



Verifying Policy Downloads

One question frequently asked is how to check if policies have been downloaded successfully to network devices. One indication would be using the ISE notification indicator (shown below in figure 13). However, this only shows whether CoA messages have been sent and acknowledged and ISE logs would need to be investigated for details of any failures.




Figure 13: ISE Notifications for Policy Download

ISE 2.4 introduces a new feature to help in verifying whether policy downloads have been successful or not. This ‘Verify Deploy’ function can be accessed via TrustSec Settings and the matrix screen as shown below but also from the SGT and SGACL screens.




Figure 14: ISE Verify Deploy Function

When the function is initiated, ISE logs into each network device and retrieves the IP to SGT mappings as well as the role-based permissions (policies) deployed. From the resident mappings, ISE determines which policies should have been downloaded and compares with the policies retrieved. The results are placed in the ISE alarms log. An example is shown below:




Figure 15: ISE Alarms Log Showing Verify Deploy Results

 Details can be displayed of the policy difference by clicking on that alarm entry, as shown below:


Figure 16: ISE Verify Deploy Details


ISE 2.6 adds the ability to run a report on the deploy verification. Navigate to Operations > Reports > Export Summary > Reports > TrustSec > TrustSec Deployment Verification.

Port-Based vs IP-Based ASICs

In the classification section it was mentioned that platforms like the 3560x, 3560-CX, 3750x and the Industrial Ethernet products use an ASIC which require endpoints to be L2-adjacent to the switch. There are also enforcement limits with these products.

  • SXP cannot be used as a way to resolve source or destination addresses to SGT unless they are L2 adjacent.
  • There cannot be more than 1 SGT on a port and VLAN combination when enforcing. If a port is configured in Multi-Auth mode, all hosts connecting on that port within a certain VLAN must be assigned the same SGT if enforcement is enabled. When a host tries to authenticate, its assigned SGT must be the same as the SGT assigned to a previously authenticated host in the same VLAN. If a host tries to authenticate and its SGT is different from the SGT of a previously authenticated host in the same VLAN, an error-disabled event is generated: "PM-4-ERR_DISABLE_VP: sgacl_limitation:multiple-sgts-learnt-on-port-vlan error detected".
  • Enforcement is supported only on up to eight VLANs on a VLAN-trunk link. If there are more than eight VLANs configured on a VLAN-trunk link and enforcement is enabled on those VLANs, the switch ports on those VLAN-trunk links will be error-disabled.

For further limitations of these switch types, see this link:

It is therefore recommended to use switch types like the 3650, 3850, Cat4k, Cat6k and Cat9k family where possible. These use ASICs which are IP-based and do not exhibit the same limits as the products requiring L2 adjacency.

For NX-OS platform enforcement capabilities, please see the Data Center Segmentation Guide:


Product Specific Enforcement Notes

Regarding the Cat4k (all Supervisor types and the Cat4500x), the way destination SGT is derived for L2 switched traffic (i.e. traffic forwarded between ports in the same VLAN or subnet) is restricted to a maximum of 2000 IP to SGT mappings. A block of 2000 input ACLs are utilized for this. Though you can configure IP to SGT mappings above this limit, such mappings cannot be used to derive destination SGT for switched traffic. The limit does not apply for routed traffic or source SGT derivation because the Forwarding Information Base (FIB) is used in these cases.


As for the 3650, 3850 and current release of the Cat9k’s, up to 255 unique security group destination tags are supported for enforcing SGACL’s. If more than 255 are programmed, then the following event is generated:


%ACL_ERRMSG-4-HASH_FULL: Switch 1 R0/0: fed:  Output IPv4 SGACL ACL on cell <sgt x, dgt y> could not be programmed in hardware, SGACL table is full.


Security Policy Enforcement: Policy Based Routing (PBR)

Enforcement does not only control whether to purely permit or deny traffic. For the Cisco ASA, ISR and ASR, PBR can be used to enforce a routing decision based on the source or destinations SGT’s. One example may be to route Guest classified traffic directly out to the internet whereas employee traffic is routed internally. Example configuration for Cisco ISR and ASR follows:

route-map Guest_Traffic permit 10

 match security-group source tag Guest

 set vrf Guest


Security Policy Enforcement: Quality of Service (QoS)

In a similar fashion, the Cisco ISR and ASR can provide QoS service levels on a per user-group basis. Example configuration follows:

class-map Dev_AppX

  match security-group source tag 7

  match security-group destination tag 8


 policy-map Dev_Qos

  class Dev_AppX

   bandwidth percent 50

   set dscp ef


 interface gigabitEthernet0/0/0.1

  service-policy input Dev_Qos


Propagation Methods

A switch or router device that is enforcing traffic using SGACLs works on the principle of enforcing from a source group to a destination group.

If we take the example of the Development_Srvr group from figures 8a and 8b above, the connected switches in the DC would have the destination mapping added and the appropriate policies would be downloaded as previously described. The destination mappings for the server IP addresses mapped to the Development_Srvr SGT, could be:

  • Added to the DC switches manually via CLI.
  • Pushed to the DC devices via SSH from ISE.
  • Sent to the DC devices from ISE or other devices via SXP.
  • Shared via ISE pxGrid for network devices/systems that support that integration.
  • In the case of an ACI Domain DC, ISE can learn the Dynamic DC Workload mappings from APIC and send to network devices via SXP.
  • For SDA, the destination mappings could be manually configured on the Border or sent to the Border via SXP.


So, even before any user connects to the access layer of the network, the enforcement points in the DC (or SDA Border if applicable) have mappings resident and the required policy downloaded (or access rules configured in the case of a firewall).

The specified policy in figures 8a and 8b is to block members of the Production_User group from accessing the servers in the Development_Srvr group. The enforcement switches in the DC have the destination group information as described in the previous paragraph but how do the switches learn of the source group information in order to be able to enforce? The enforcement devices receive the source information via a choice of a number of different methods:


Inline Tagging

When the user in the Production_User group authenticates onto the network, the Production_User SGT is dynamically assigned by ISE and sent to the access switch within the authorization accept message. In this scenario, the IP (assigned to the user device) to Production_User SGT mapping dynamically becomes resident in the access switch. When the user starts to send traffic towards a development server, traffic initially exits the user device and enters the access switch. The switch determines the egress interface for the traffic (towards the DC) and inserts the source IP into the L3 packet and the source SGT into the CMD field of the L2 frame.


Note: Within an SDA fabric, propagation is accomplished using VXLAN only. See below for VXLAN propagation



Note: To support inline tagging, this specific point-to-point configuration needs to be added to the interfaces of both transmitting and receiving devices/interfaces:

cts manual
  policy static sgt x trusted    [where x is an SGT assigned to network links or typically devices]
  propagate sgt                     [This is the default and will not show in the running config]


Note: Many products require a shut / no shut on the interface when inline tagging is configured. The newer Cat9k products do not need this interface bounce to enable the feature.


If inline tagging is configured on every hop towards the DC switches then the source SGT will be propagated all the way to the enforcement point via this method. In an SDA deployment, VXLAN would be used to propagate the source SGT from Edge to Border and then inline tagging could be utilized from the Border to the destination DC switch. The enforcement point then has the destination group mapping (statically defined) and the source group mapping (received via inline tagging) and can enforce using the policy previously downloaded.


Note: An SDA Border can take the SGT from the VXLAN header and insert it into the L2 CMD field i.e. inline tag it to the likes of a connected fusion device. The same is true in the other direction. If the Border (or Fusion) is a switch then the above inline tagging configuration needs to be configured on the whole trunk. If the Border (or Fusion) is a router then the above inline tagging configuration needs to be configured on each of the sub-interfaces.


Note: When an SGT is received by a network device via inline tagging, it is used for policy source SGT derivation and also forwarded on appropriate interfaces. However, the SGT is not cached and is not by default placed in the SXP mapping table. There is a feature called SGT caching which was primarily built to support external services but a derivative of that is the SGT is placed in the SXP mapping table and therefore forwarded on the SXP connections set as speakers. To enable caching, use the following configuration:

cts role-based sgt-caching

Use this command with caution, it is CPU intensive and therefore not appropriate for heavily utilized devices or for caching a large amount of SGTs.


Note: When configuring ‘cts manual’ on port-channels, the configuration must be added to the member/physical interfaces and not the port-channel itself. Note also that this cannot be done while the interface is a part of the port-channel, the interface must first be removed from the port-channel, “cts manual” applied and then added back to the port-channel.



The source SGT can be embedded within the packets of these secure encryption protocols. This is one method by which the SGT can be propagated across a WAN such as shown in figures 8a and 8b. The WAN service provider does not need to support inline tagging by inserting the SGT into the L2 frame but can carry the SGT in the encrypted packets instead. This way we can still propagate the source SGT all the way from source switch (from Border in SDA) to enforcement point and enforce as above.



Note: To support inline tagging, there is just a single configuration entry to add with implied trust:

Over IPSec IKEv2 Networks there is a single line in global config:
crypto ikev2 cts sgt

Over GETVPN there is a single line in the security association in the key server:
crypto gdoi group x
  server local
    sa ipsec 1
      tag cts sgt

Over DMVPN and GRE there is a single line under the tunnel interface:
interface tunnel x
  cts sgt inline



Virtual Extensible Local Area Network (VXLAN)

If VXLAN is configured from source switch to enforcement point then the source SGT can be carried in every packet towards the enforcement point and enforced as previously described. VXLAN is the protocol used when propagating the SGT across a Software Defined Access (SDA) fabric as shown in the following figure:




Figure 17: VXLAN Propagation Across the SDA Fabric

Security Group Tag Exchange Protocol (SXP) Between Network Devices

SXP is a control plane method to propagate IP to SGT mappings to network devices when inline tagging is not available. SXP allows for identification and classification of IP packets to the corresponding SGT maintained in the mapping table within network devices. This is a peer-to-peer TCP connection using TCP port 64999. IP to SGT mappings are sent from the SXP speaker end of the connection to the SXP listener end. In our diagram 8b, if there was an SXP connection provisioned from the access switch in the Campus to the switch in the DC then the user mappings learned on the Campus access switch would immediately be sent to the DC switch over the SXP connection. When untagged data packets are sent from source to destination, they will enter the enforcement device in the DC, the DC switch will execute an internal lookup on the source IP to determine the source SGT and enforce from source group to destination group as before. SXP can be transferred over the WAN in the diagram above as well as transported by 3rd party devices as the information is just sent within TCP packets.

When SDA is deployed, device to device SXP connections could be configured from DC switches back to the Border for example, to allow the Border to enforce for User to DC flows if required.



Note: There are scale limits of SXP connections and SXP mappings per platform. See near the bottom of the latest platform capability matrix for scale numbers:



Security Group Tag Exchange Protocol (SXP) Involving ISE

ISE supports both the SXP speaker and listener functionality. One of the most useful features to simplify propagation design is to use ISE as an SXP speaker.

When users authenticate onto the network, ISE learns of the user IP and assigns an SGT via the authorization table. So, ISE is the first platform in the network which learns of the IP to SGT mapping for dynamically authenticated endpoints. If SXP is enabled on ISE and there is an SXP connection provisioned from ISE to the enforcement point then the IP to SGT mappings for the users will be directly sent to the enforcement point negating the need for inline tagging or multiple SXP connections from Campus to DC. See the following figure for this operation:




Figure 18: SXP on ISE simplifying Propagation Design



Note: The number of supported SXP connections on ISE can be thought of as limiting by some. However, sending mappings from ISE to more destinations is easily accomplished by using an SXP reflector. An SXP reflector is just a network device (typically a router like an ASR1k which can support a large number of SXP connections and mappings) that receives SXP mappings and ‘reflects’ them out again. If there is a requirement for ISE to send mappings to many destinations (more than the number of connections supported), then ISE can send mappings to a reflector and let that device send the mappings onto the high number of destinations. As a side-note, ISE itself can act as an SXP reflector if needed and scale requirement permits.


The method of sending out IP to SGT mappings from ISE is particularly useful if the access switch does not support TrustSec. Take a non-MS390 Meraki switch for example or a 3rd party switch that does not support TrustSec (Meraki MS390 release 14 supports Adaptive Policy which is TrustSec). However, as long as the switch supports RADIUS Authentication and Accounting with ISE, then an ISE session can be created, an SGT assigned accordingly, and the mapping sent towards an enforcement point via SXP as shown in figure 19:




Figure 19: SXP on ISE Allowing NAD Without TrustSec Support


This will work with any vendor switch or Access Point that is able to create and teardown sessions on ISE using RADIUS Authentication and Accounting.


For an SDA deployment as shown in figure 20, mappings can be sent from ISE (or from another network device) to the Border if enforcement on the Border is a requirement. The virtual network overlays will be manifested as VRF’s within the Border and as SXP is VRF aware, an SXP connection per VN will be needed. For more information on this see the following ISE Prescriptive Guide: Policy Enforcement Within SDA Border:


Screen Shot 2018-12-18 at 11.01.31.png


Figure 20: SXP on ISE Sending Mappings to an SDA Border

ISE Cisco Platform Exchange Grid (pxGrid)

ISE pxGrid is an open, scalable and IETF standards-driven data-sharing and threat control system. It allows multiple security products to work together and share context information for the benefit of all.

ISE pxGrid can send SGT and group membership information to Cisco platforms like Firepower Threat Defense (FTD), Cisco Web Security Appliance (WSA) and Cisco Secure Network Analytics (SNA) as well as to 3rd party platforms which subscribe to the service.

The following figure shows how SGT and group membership information can be shared with Cisco and Check Point Firewalls to enable group-based Access Rules to be utilized (firewall vendors such as Palo Alto and Fortinet also support this function):




Figure 21: pxGrid on ISE Sharing Context with Cisco and Check Point Firewalls



Note: The ASA has SXP implemented as the control-plane method of classification, and FTD via FMC (as well as other FW vendors) have pxGrid implemented.


Identity Services Engine (ISE) Design for Segmentation

ISE is central to a segmentation design. It handles secure communications with network devices for SGT transfer, server management, IP to SGT mapping propagation and policy and SGACL download. Secure communication is also established with many Security Technical Alliance Partners for context sharing and threat mitigation.

ISE scales by deploying service instances (called Personas) in a distributed architecture. Even though all services can be enabled within a single instance, it is recommended to separate the services for increased scale and performance. Figure 22 shows a distributed architecture although for high availability, two Policy Administration Nodes (PAN) and two Maintenance and Troubleshooting Nodes (MnT) will be deployed.

See the ISE performance and scalability guide here:


Figure 22: ISE Distributed Architecture


For a complete description of the different ISE Personas then review the latest Admin Guide: 


Network Device SGT

When thinking about assigning security groups, initial thoughts are typically for user groups or server groups. However, thought also needs to be given to ‘network device to network device’ and ‘network device to network services’ communications. Network device to network device communications could be EIGRP, OSPF, BGP, CDP, LACP, LLDP etc. and network device to network services could be DHCP, DNS, SNMP, RADIUS, SYSLOG etc.

For this reason, there is an SGT provided in ISE to assign to network devices themselves. By default, this is SGT 2 and is named TrustSec_Devices.

The best way to assign this TrustSec_Devices SGT to the network devices is within the environment-data download when the devices authenticate with ISE.

In ISE, navigate to Work Centers > TrustSec > TrustSec Policy > Network Device Authorization, edit the default rule and assign the TrustSec_Devices SGT as shown in figure 23. Alternatively, add further rules to the table if the network design calls for different device SGT’s to be used for different groups of devices.




Figure 23: Assign TrustSec_Devices SGT 2 in ISE Network Device Authorization Table


Subsequently, when network devices initially authenticate with ISE, the environment-data will be downloaded and will include the TrustSec_Devices SGT (SGT 2) set as the ‘Local Device SGT’ as highlighted in the following output from a network device:


Prompt-3850#show cts environment-data

CTS Environment Data


Current state = COMPLETE

Last status = Successful

Local Device SGT:

  SGT tag = 2-04:TrustSec_Devices

Server List Info:

Installed list: CTSServerList1-0001, 1 server(s):

  Server:, port 1812, A-ID 91EDAC79A55773C2FB818AC5865F1E9E

          Status = ALIVE

          auto-test = FALSE, keywrap-enable = FALSE, idle-time = 60 mins, deadtime = 20 secs

Multicast Group SGT Table:

Security Group Name Table:














Environment Data Lifetime = 86400 secs

Last update time = 15:23:43 UTC Tue Nov 20 2018

Env-data expires in   0:22:54:57 (dd:hr:mm:sec)

Env-data refreshes in 0:22:54:57 (dd:hr:mm:sec)

Cache data applied           = NONE

State Machine is running



Note: By default, ISE assigns the ‘Unknown’ SGT 0 to network devices within the Network Device
Authorization table. It is best practice to change this to TrustSec_Devices SGT 2 in ISE as
described above to allow specific policies to control device to device communications and not to
bundle this important traffic with traffic to/from endpoints that are classified as Unknown.




Note: The Device SGT can optionally be set in network devices by CLI if required. It is set by using the following command:

      cts sgt <sgt number>



Allow List Discussion Outside the SD-Access Fabric

Remember that if the default policy is to ‘permit’ traffic then network device to network device traffic as well as network device to network services traffic will not necessarily need an additional policy. However, if the default policy is to ‘deny’ traffic then utilizing additional policies is required to permit this important control traffic. The following policies ensure network device to network device traffic is always permitted and traffic between network devices and network services (such as RADIUS, DNS, SNMP etc.) will be permitted assuming those services/servers are classified into the Network_Services group:

Prompt-3850#show cts role-based permissions

IPv4 Role-based permissions default:

        Deny IP-00

IPv4 Role-based permissions from group 2:TrustSec_Devices to group 2:TrustSec_Devices:

        Permit IP-00

IPv4 Role-based permissions from group 2:TrustSec_Devices to group 3:Network_Services:

        Permit IP-00

IPv4 Role-based permissions from group 3:Network_Services to group 2:TrustSec_Devices:

        Permit IP-00

RBACL Monitor All for Dynamic Policies : FALSE

RBACL Monitor All for Configured Policies : FALSE


Note: RADIUS cannot express ordering constraints. ISE treats each individual RADIUS request as a transaction. Often the default policy is the quickest and simplest to download, whereas the other policies may span over multiple request/response transactions. Thus, the default policy may be installed into the network device hardware first as the other policies are still downloading. When implementing an allow list model this can be problematic as an active ‘default deny’ can block further policy downloads from ISE stopping the installation of more specific policies.
To alleviate this ‘race condition’ it is currently recommended to install some static policies on network devices to guarantee device to device communication as well as device to/from ISE.
The actual policies that need to be added depends on whether ISE has been classified and whether the network devices SGT has been changed from default settings (Unknown SGT of 0 would be the default, setting to TrustSec_Devices SGT 2 is good practice as stated above).
If ISE has not been classified and the Network Device SGT left at Unknown SGT 0, then the following static policy could be added into the network devices (as an example):

ip access-list role-based FallBackPolicy
  permit ip
cts role-based permissions from 0 to 0 FallBackPolicy


[Bear in mind that this policy permits all unclassified endpoints/users to communicate which contradicts the reason for using an allow list model in the first place. It is recommended to assign TrustSec_Devices SGT 2 to the network devices and also consider classifying ISE so that these functions are not bundled in with the Unknown traffic for policy operation].

If ISE has not been classified but the Network Device SGT set as TrustSec_Devices SGT 2, then the following static policy could be added into the network devices (as an example):

ip access-list role-based FallBackPolicy
  permit ip
cts role-based permissions from 2 to 2 FallBackPolicy
cts role-based permissions from 0 to 2 FallBackPolicy
cts role-based permissions from 2 to 0 FallBackPolicy


If ISE has been classified with SGT x and the Network Device SGT set as TrustSec_Devices SGT 2, then the following static policy could be added into the network devices (as an example):

ip access-list role-based FallBackPolicy
  permit ip
cts role-based permissions from 2 to 2 FallBackPolicy
cts role-based permissions from x to 2 FallBackPolicy
cts role-based permissions from 2 to x FallBackPolicy


Allow List Discussion Inside the SD-Access Fabric

SD-Access release 1.3.1 introduced a new policy management function that supports allow list operation (default deny) in the fabric.
Note that at the time of writing, the source SGT is not propagated across the fabric underlay. So, assigning an SGT to the Network Devices themselves (TrustSec_Devices SGT 2) seems inconsequential from a fabric point of view. However, assigning TrustSec_Devices SGT 2 to devices outside the fabric is important from a security point of view so as to not bundle this device traffic in with Unknown. It is my personal view that assigning TrustSec_Devices SGT 2 is best practice whether the device is inside or outside the fabric.


If there is a need to deploy SD-Access using an Allow list policy then follow the recommendations below:

1) To begin with, assume the Border is not set to enforce policies. Cisco Catalyst Center does not automate the enabling of enforcement on the Border, but it can be set to enforce manually and this option is discussed below.


2) First assign TrustSec_Devices SGT 2 to network devices within the ISE Network Device Authorization as described above. Deploy that change to network devices and ensure the devices show the change in the environment_data. As stated, this SGT will not be propagated across the underlay so will be rendered as Unknown SGT 0 when it travels across the underlay and enters the destination Fabric Edge/Border.


3) No enforcement should occur in SD-Access on the fabric facing interfaces of any Border or Fabric Edge. To ensure no enforcement takes place, provision 'no cts role-based enforcement' on these fabric facing interfaces on all Borders and Fabric Edges via the use of Cisco Catalyst Center templates. This may be automated in the future.


4) Within the fabric, no enforcement takes place from the underlay to internal IP addresses of an Edge (or Border) device. With disabling enforcement on the fabric facing interfaces and not enforcing from underlay to internal IP, management traffic within the underlay will not be enforced at all on the Edge. So, traffic to/from the Edge via the underlay i.e. traffic to/from other network devices, DNS, DHCP, ISE, Catalyst Center etc. will flow uninterrupted.


5) Add Group-Based Policies in Cisco Catalyst Center to permit what is required in the User/Device overlays.


6) If enforcement is required on the Border then this can be enabled manually (perhaps through the use of templates). Once enabled, if an allow list policy is deployed, management traffic from the Edges will be received by the Border in the underlay and will be classified with Unknown SGT 0 (as there is no SGT propagation across the underlay today). If services like DNS, DHCP, ISE, Catalyst Center etc. are also not classified then a policy of Unknown SGT 0 to Unknown SGT 0 will be required on the Border to permit that traffic. On the Border, if you reclassify the management traffic coming from the Edge (perhaps using Subnet:SGT or IP:SGT mapping) and also reclassify services then you can refrain from bundling this important management traffic in with Unknown.


7) Pay close attention to the fact that if Access points and/or Extended Nodes are present in the fabric then deploying an allow list policy model will drop all management traffic from the Fabric Edge towards those devices (effectively taking them, off the network). Disabling enforcement on those Fabric Edge interfaces may be an option if we can guarantee that any re-automation by Cisco Catalyst Center will not overwrite this setting. Another way is to reclassify the AP and/or Extended Node management IP’s into Groups on the appropriate Fabric Edges (via Cisco Catalyst Center templates or pushed via SSH from ISE) and permitting Unknown SGT 0 to those Groups. N.B. if the assigned Groups are unique for these Access Points / Extended Nodes then the downloaded policy sourced from Unknown SGT 0 will only be downloaded by these particular Fabric Edge devices.


8) Additionally, pay attention to LAN automation once the policy has been deployed (for example day N operations). Communications to new network devices must be permitted.



Network Device Admission Control (NDAC)


Assigning an SGT to network devices can be seen to be part of Network Device Admission Control (NDAC). NDAC builds secure networks by establishing domains of trusted network devices. The external facing interfaces from the trusted domain are configured with ‘cts dot1x’ such that device and link authentication are required for any new device to connect to the network.

The use of ‘cts dot1x’ is no longer recommended as it requires continual accessibility to ISE for network stability. The feature has not been ported to the new Cisco Internetwork Operating System (IOS) and is no longer actively supported by Engineering. MACsec with Security Association Protocol (SAP) along with ‘cts manual’ could be used as an alternative and standards based MACsec Key Agreement (MKA) is also now supported.


CTS AAA Servers

It has already been discussed that network devices download the environment-data when authenticating with ISE. As well as including the list of SGT’s and the Local Device SGT, the environment-data also includes the CTS Server list that the device uses to download policies. This server list is configured in ISE by navigating to Work Centers > TrustSec > Components > Trustsec AAA Servers, as shown in figure 24:




Figure 24: Add CTS AAA Servers in ISE


It is best practice to add multiple servers into this list and all will be downloaded to the network devices within the environment-data. However, all devices in the whole network will only download policy from the ISE Persona at the top of the list if that Persona is available. If that Persona is not available for any reason then the second in the list will be used, then the third etc. So, although high availability is configurable, there is no way currently for devices to download different priority lists and therefore no way to distribute policy download throughout the ISE deployment.

Some customers with a large number of network devices downloading policy, use a dedicated ISE Policy Services Node (PSN) Persona purely for this function. However, for the majority of customers, using an ISE PSN with shared services is sufficient but best practice is to choose a PSN which is central to the deployment and is not heavily burdened with other services (such as handling many user RADIUS sessions).


RADIUS Change of Authorization (CoA)

The operation and need for RADIUS Change of Authorization (CoA) can be found in the following IETF document:

In relation to segmentation functions, ISE uses CoA to inform network devices of changes in SGT details, environment-data and policy.

CoA’s can be sent by ISE after timer expiry as dictated by settings in the ISE network devices configuration (default every 24 hours). However, more controlled network device updates can be instigated from ISE by utilizing the ‘Push’ function found near the top of the Security Groups, Security Group ACLs, TrustSec AAA Servers and Network Device Authorization screens and by utilizing the ‘Deploy’ function found near the top of the TrustSec Policy Matrix/Tree screens. Figure 25 shows the ‘Push’ function near the top of the ISE Security Groups screen.


Additionally, after changes have been made, ISE informs the administrator that a change has been made by displaying a notification on the top menu bar. Figure 25 shows this notification and also shows the details when the mouse is hovered over the notification. The ‘Push’ function can be initiated from here as well.




Figure 25: Highlighting the ‘Push’ Function to Send CoA to Network Devices to Inform of Changes


For ISE release 2.3 and earlier, these CoA messages are generated and transmitted by the PAN (Policy Administration Node). This is not configurable. Generating the CoA messages takes CPU and Memory resources, this needs to be considered if the PAN is heavily utilized. Further CPU and Memory is consumed as a consequence of sending CoA messages because the result of network devices receiving these messages is a trigger to request updates from ISE.


The recommendation for large installations is to use a Dedicated deployment (Separate PAN, MnT, and PSN nodes). The CoA operation dictates that if nodes are not deployed on separate instances then for a large number of network devices (over 100 NADs), at least use a Hybrid deployment with dedicated PSNs. Then network devices can be instructed to send RADIUS requests to a PSN to download updates so the CPU and Memory utilization and subsequent latency of the PAN is not increased further whilst dealing with the CoA messages.


By default, ISE release 2.4 also sends these CoA messages from the PAN. So, without changing the default behaviour, the same recommendation can be provided as per the paragraph above. It is further recommended to change the default behaviour by sending CoA’s from local PSN’s (supported from ISE release 2.4) rather than the PAN to reduce load on the PAN and distribute CoA generation around the ISE nodes. This is configured in the Advanced TrustSec Settings under the Network Device.



Note: Rather than using CoA to inform network devices of configuration changes, ISE can be configured to use SSH instead. This option is set under the network device in ISE as shown in figure 26.




Figure 26: SSH Can Be Used to Send Configuration Changes Rather Than CoA


Deployment strategy can be best explained using the first 4 steps of the workflow shown in the figure below.





Figure 27: Deployment Workflow


Discover and Classify Assets

The first step in the deployment workflow is to discover what users and endpoints are on the network.

Once ISE has been installed and switches configured to send authentication to the ISE PSN’s (in SDA, Cisco Catalyst Center will orchestrate the switch configuration), the identity and location of the users are learned. For devices and endpoints that do not support 802.1x then MAC authentication bypass (MAB) or PassiveID can be used which uses the MAC address for authentication. Guests connect to the network using an ISE portal and Web Authentication.


As well as the identity being learned, ISE can determine the type of device or endpoint connecting to the network. Profiling is used for this which utilizes a choice of probes like DHCP, SNMP, Span, NetFlow, HTTP, RADIUS, DNS and NMAP to collect as much meta data as possible to learn the device finger print. The device meta data or attributes helps to automate “categorization of the device” or “classification of the device” and is used to assign appropriate access controls.


We need to be able to identify hosts based on what they do as well as what they are. Cisco SNA is typically deployed for this function which utilizes NetFlow to identify flow behaviour per asset. Cisco SNA performs flow de-duplication, flow stitching and flow anomaly detection for great visibility.


Understand Behavior

This is about understanding what constitutes business critical applications or processes so that effective policies can be built.

Cisco SNA monitors all the network activity between any endpoint, host server or application and creates a baseline based on that behavior.

For example, Cisco SNA can discover all hosts communicating with HTTP servers – who, what, when, where and how.   This information can be used to characterize normal use of the HTTP servers. Once the critical components of the business are understood then security policies can be built around this information. Additionally, alerts are generated for hosts behaving outside the baseline behavior and thresholds.

For further information on Cisco SNA see here:


Deploy and Model Policy

When deploying SGT’s, they are provisioned in ISE and are downloaded to network devices within the environment data.

Servers are classified into groups using static classification. IP and Subnet to SGT mappings can be centrally managed from ISE and pushed to relevant devices using SSH or SXP. Other methods of static classification need to be provisioned via CLI on the network devices.


Dynamic classification is typically used for user, endpoint or guest authentications utilizing 802.1x, MAB, WebAuth, PassiveID or learned from ACI. The access switch needs to have AAA, RADIUS and interface configuration deployed and ISE needs to have the network devices and authentication and authorization rules added. Within SDA, the total switch configuration is orchestrated by Cisco Catalyst Center as are the network devices in ISE.


802.1x Monitor Mode

It is recommended to deploy 802.1x in monitor mode initially so that users are not impacted while changes are being implemented. Monitor Mode allows network connectivity even if authentication fails. If there are any teething problems while rolling out authentication services, then the user will still be able to log into the network and the administrators will be able to gain visibility into any connectivity challenges.

More information can be found on Monitor Mode at the following location:



With classification visibility, and flow and host group knowledge, the policy can be provisioned. Initially though, it is recommended to just set permit entries in the ISE matrix (as shown below in figure 28) with the log keyword to just provide visibility. The log keyword on an access control entry generates a syslog message when the entry is matched. Actual enforcement should be enabled in the next phase once happy with the results.




Figure 28: 802.1x Monitor Mode and Permit Policies

Cisco SNA Policy Modeling

Before enabling enforcement on network devices, Cisco SNA can be used to model policy behavior using the custom event feature. Create a custom event as shown below, for Cisco SNA to trigger upon traffic being detected between two security groups:




Figure 29: Creating a Cisco SNA Custom Event


Once added, a list of the custom events can be displayed as shown here:




Figure 30: List of Cisco SNA Custom Events

When traffic is detected between the two defined groups, an alarm is generated, allowing administrators to decide on the required policy. An example is shown in figure 31:




Figure 31: Cisco SNA Custom Event Alarm

Active Policy Enforcement

Policy will only be enforced if the ‘cts role-based enforcement’ configuration command(s) are applied to network devices (Cisco Catalyst Center orchestrates this for Edge devices within an SDA fabric):


cts role-based enforcement                                             [To enable enforcement on L3 interfaces]

cts role-based enforcement vlan-list x                              [To enable enforcement on L2 interfaces]


Once applied, if there are IP to SGT mappings resident in the mapping table then policy protecting those SGT’s will be downloaded from ISE.

Only the required policy is downloaded as shown in figure 12.


For an SDA deployment, contracts and policies are added in Cisco Catalyst Center (see figure 32 for an example) and they are pushed into ISE via API. The matrix (added in release 1.3.1) displays source security groups down the left-hand side and destination security groups across the top. The intersection of the rows and columns are the actual enforcement instructions otherwise known as contracts with Cisco Catalyst Center or Security Group Access Control Lists (SGACLs) within ISE. The matrix can be viewed in ISE as shown in figure 33.


Screenshot 2020-10-26 at 12.19.37.png


Figure 32: Policy Definitions Within Cisco Catalyst Center


Screenshot 2020-10-26 at 12.36.15.png
Figure 33: Policy Definitions Within ISE (Matrix View)

ISE Multiple Matrices

ISE supports multiple policy matrices which are used to download a different set of policies to different network devices. Each network device downloads policy from one policy matrix at any one time. This is very useful when some sites or countries are in a heightened threat state, some sites are higher risk than others or downloading different policies to different geographical regions is helpful. If using different policy matrices for risk purposes for example, if a site is deemed to be at high risk, then an ISE administrator can move the network devices servicing that site to use the high-risk matrix and therefore download more strict policy rules. Figure 34 below shows where the use of multiple matrices is enabled.


ISE Policy Staging and Approval

For regulated industries like finance and healthcare, change control (approval) and incremental deployment (staging) capabilities are very important. Both of these functions are supported by ISE and are enabled by navigating to Work Centers > TrustSec > Settings > Work Process Settings as shown in figure 34 below. Note the ISE administrators that are needed to be entered for policy editors and approvers. For a full explanation of this workflow operation, please use the following link:




Figure 34: ISE Work Process Settings for Staging and Approval


Note: At the time of writing, ISE has no API for multi-matrix or work process support. Therefore, neither function on ISE can currently be used within an SDA deployment.


Policy Refresh

If adding policy entries directly into ISE, the changes are not immediately downloaded to network devices. Network devices will request an update on a periodic basis (default every 24 hours). Additionally, network devices can be solicited to request an update by ISE Administrators utilizing the Push/Deploy functions causing ISE to send a RADIUS Change of Authorization (CoA) message as described in the previous section. It is recommended to frequently press the Push/Deploy buttons so that small changes can be monitored in a controlled fashion. Within SDA, (from release 1.3.1), the ISE CoA function is triggered when the ‘Deploy’ function is selected within the Cisco Catalyst Center Policies screen.


A further option for network devices to download policy is for the following command to be entered into the network device via CLI (either manually or via some orchestration system):

cts refresh policy


If there are a mix of IOS/IOS-XE and NX-OS platforms in the network all downloading and enforcing policy, then ensure the contracts/SGACLs downloaded are supported by each platform. Review the information provided at the following link which shows this information:


Another recommendation is to start with using a default permit policy (deny-list) so that non-classified traffic with Unknown SGT will be permitted.


Security Group Firewall (SGFW) Policy

Of course, group-based enforcement is possible on firewalls, as well as switches and routers, but have the added benefit of providing stateful inspection functionality. See the ‘Security Group’ columns colored blue within the access rules of the ASA in figure 35 and the groups available in FTD in figure 36.

Firewalls are first and foremost security devices and as such adopt a default closed mode operation (which is the opposite of switches and routers).


Although Firewalls do download the environment-data and hence SGT’s from ISE, SGACLs are not downloaded; access rules are provisioned using the likes of ASDM, CSM, FMC etc.

One great feature of firewalls is that source and destination access rule criteria can be mixed and matched between group based and IP based attributes. For example, you can have an access rule which matches on a source security group and a destination which is IP ACL based.




Figure 35: ASA Security Group Access Rules



Note: By default, the ASA bypasses the local access rules for inbound VPN and Remote Access flows. To stop bypassing and to enforce using the access rules, set “no sysopt connection permit-vpn”. This can be found in ASDM under Configure > Remote Access VPN > Network (Client) Access > AnyConnect Connection Profiles; and unselect “Bypass interface access lists for inbound VPN sessions”.




Figure 36: FTD Security Group Access Rules



Note: FTD supports enforcement for destination SGT (as well as source SGT) from release 6.5, released in 2019. That release also supports static IP:SGT mappings from pxGrid.



Web Security Appliance (WSA) Policy

The WSA retrieves SGT group and membership information from ISE via pxGrid. The security groups can be used in the WSA policies to manage or control web requests based on group information rather than IP addresses. The top of Figure 37 shows SGT Employees being used in an access policy and the bottom shows the list of SGT’s available from pxGrid. Note that this example shows SGT’s with the EPG suffix so we know that these have been learned from APIC/ACI providing cross-domain security.




Figure 37: WSA Access Policy Utilizing SGT’s


SGACL Monitor Mode

It has been mentioned above that while initially deploying policy, perhaps start by just using permits in the contracts/SGACLs. This will allow monitoring of the operation without affecting user operation.

A second option is to use SGACL Monitor Mode. This allows the complete required SGACL to be used but in a monitor mode state so that traffic is still permitted in hardware.



Note: Cisco Catalyst Center does not currently support contract/SGACL Monitor Mode. Additionally, the Cat4k does not support Monitor Mode either.


As an example, initially showing the results without Monitor Mode. Take the following policy downloaded to an ASR, with the deny_log SGACL containing ‘deny ip log’:


Prompt-ASR1kx#show cts role-based permissions

IPv4 Role-based permissions default:

        Permit IP-00

IPv4 Role-based permissions from group 18:HVAC to group 14:PCI_Servers:


RBACL Monitor All for Dynamic Policies : FALSE

RBACL Monitor All for Configured Policies : FALSE


When traffic hits the policy and is denied, the log keyword instructs the router to generate a syslog entry:


Jul  5 13:02:10.196: %FMANFP-6-IPACCESSLOGSGDP:  SIP0: fman_fp_image:  ingress_interface='LISP0.4102' sgacl_name='deny_log-10' action='Deny' protocol='icmp' src-ip='' dest-ip='' type='8' code='0' sgt='18' dgt='14' logging_interval_hits='1'



Note: This rich logging capability is not available across the platform range. The Cat4k, Cat6k and pre-Polaris images of 3850, ASR, ISR, CSR do not provide all this rich contextual data.


The SGACL counters shows increments under the HW-Denied column showing that traffic is actually being denied by hardware:


Prompt-ASR1kx#show cts role-based counters

Role-based IPv4 counters

From    To      SW-Denied  HW-Denied  SW-Permitt HW-Permitt SW-Monitor HW-Monitor

*       *       0          0          5378666    6291399    0          0        

18      14      0          5          0          0          0          0        



Now, in ISE, we can set this SGACL to be in Monitor Mode instead on a per-cell basis in the matrix. Navigate to the Policy matrix, double click the required SGACL cell and select Monitor under the Status options as shown here:




Figure 38: Setting SGACL Monitor Mode


Once Monitor Mode is set, the matrix inserts the Monitor Mode icon to the left of the SGACL name (see figure 39):



Figure 39: Policy Matrix Entry/Cell Showing Monitor Mode Icon


The policy matrix change needs to be pushed to network devices by using the Deploy function at the top of the matrix. This utilizes RADIUS CoA to inform the devices that a change has been made.

Once the update has been downloaded to the ASR, the policy permissions shows the specific policy in Monitor Mode by appending the term (monitored):


Prompt-ASR1kx#show cts role-based permissions

IPv4 Role-based permissions default:

        Permit IP-00

IPv4 Role-based permissions from group 18:HVAC to group 14:PCI_Servers (monitored)


RBACL Monitor All for Dynamic Policies : FALSE

RBACL Monitor All for Configured Policies : FALSE



Now, the counters show hit counts in the HW-Monitor column showing the hits are just being monitored in hardware and not actually being enforced:


Prompt-ASR1kx#show cts role-based counters

Role-based IPv4 counters

From    To      SW-Denied  HW-Denied  SW-Permitt HW-Permitt SW-Monitor HW-Monitor

*       *       0          0          5378613    6291011    0          0        

18      14      0          0          0          0          0          84       


Router Zone-Based Firewall (ZBFW)

There is an option to deploy group-based policies on routers using zone-based firewall (ZBFW) configuration providing stateful inspection. The policy is entered manually into the routers, not downloaded from ISE and not orchestrated by Cisco Catalyst Center.

An example ISR-G2 configuration is shown here:


class-map type inspect match-any pci-sgts

 match security-group source tag 2001

 match security-group source tag 2002                            [matching SGT’s within a class-map]

 match security-group source tag 2003


policy-map type inspect branch-policy

 class type inspect pci-sgts                                              [policy-map to inspect the SGT’s within the class-map]


 class class-default



zone security lan                                                              [defining the security zones]

zone security pci

zone-pair security lan-pci source lan destination pci        [defining the source and destination zones for the ZBFW]

 service-policy type inspect branch-policy


interface GigabitEthernet0/1                                             [Assigning interfaces into the zones]

 zone-member security lan


interface GigabitEthernet0/2

 zone-member security pci



Note: In the past, the ISR-G2 routers could only match on the source group tag, not the destination. At the time of writing some work was being undertaken to include matching on the destination, see CSCuu43718 (Destination Security Group based classification in SG-Firewall)


ZBFW configuration for ISR4K’s, ASR1K’s and CSR’s use object-groups. An example configuration for these platforms follows:


object-group security destsgt

 security-group tag 2001                                                 [Assigning SGT’s within object-groups]


object-group security srcsgt

 security-group tag 2002

 security-group tag 2003


class-map type inspect match-any pci-sgts                       [Using the object-groups within the class-maps]

 match group-object security destination destsgt                [Matching on source as well as destination groups]

 match group-object security source srcsgt


policy-map type inspect branch-policy

 class type inspect pci-sgts                                              [policy-map to inspect the SGT’s within the class-map/object-groups]


 class class-default



zone security lan                                                               [defining the security zones]

zone security pci

zone-pair security lan-pci source lan destination pci         [defining the source and destination zones for the ZBFW]

 service-policy type inspect branch-policy


interface GigabitEthernet0/1                                             [Assigning interfaces into the zones]

 zone-member security lan

 cts manual                                                                      [‘cts manual’ is a requirement on these platforms]

  no propagate sgt                                                            [If not inline tagging, ensure ‘no propagate sgt’ is configured]


interface GigabitEthernet4/0

 zone-member security pci

 cts manual

  no propagate sgt




Active Monitoring

The last step of the deployment workflow is ‘Active Monitoring’ (see figure 40) which explains the best practices for operating the network.




Figure 40: Active Monitoring Within Deployment Workflow


Whether deploying new services or not, continuous network monitoring is key to providing a stable environment. Platform availability needs to be monitored along with SXP connections and links carrying the SGT in the L2 frame. Monitoring group membership via logging or the ISE dashboard could give insights into growth patterns and network use. ISE and switch logs will show authentication and authorization reliability and could provide trends in usage and service availability.


Within SDA, Cisco Catalyst Center Assurance will provide 360-degree contextual insights across users, devices, and applications. Network performance is assured with real-time and historical data analytics, which learns, adapts, and even detects problems before they happen. See figure 41 for example analytics:


Figure 41: Cisco Catalyst Center Assurance: End-to-end visibility and Client/Network Health


When adding explicit deny policies, make use of the log function, at least initially. For example, for totally blocking all traffic from one group to another, an SGACL of ‘deny ip log’ will generate syslog entries for traffic hits.


Note: Cisco Catalyst Center added support for the ‘log’ function when building contracts in release 1.3.1.


This is an example of a syslog entry generated (also generated when in Monitor Mode):


%FMANFP-6-IPACCESSLOGSGDP:  SIP0: fman_fp_image:  ingress_interface='LISP0.4102' sgacl_name='permit_web-10' action='Deny' protocol='icmp' src-ip='' dest-ip='' type='8' code='0' sgt='18' dgt='14' logging_interval_hits='1'


There are several good third-party products which collect and parse this data. Examples include Splunk and SolarWinds Loggly.


Netflow Records

While deploying, it is a good idea to keep an eye on the related flows across the network. It is best to use a NetFlow collector, something like Cisco SNA is preferred. However, even without a collector the NetFlow cache on the network devices can be a good source of flow information. Use of NetFlow records allows checking that only flows permitted in the policy are actually being permitted by the network device. An example output is shown below, note the source and destination SGT’s are displayed:


Prompt-ASR1kx#show flow monitor monitor_out cache filter ipv4 source address

  Cache type:                               Normal (Platform cache)

  Cache size:                               200000

  Current entries:                              13

  High Watermark:                               44


  Flows added:                              639717

  Flows aged:                               639704

    - Active timeout      (    60 secs)      55396

    - Inactive timeout    (    15 secs)     584308




TRNS SOURCE PORT:                0


INTERFACE INPUT:                 LI0.4102

FLOW DIRECTION:                  Output



IP PROTOCOL:                     1

ipv4 next hop address: 

tcp flags:                       0x00

interface output:                Gi0/0/5.3004

counter bytes:                   1080

counter packets:                 18

timestamp first:                 14:29:24.281

timestamp last:                  14:29:41.503

ip dscp:                         0x00

ip ttl min:                      125

ip ttl max:                      125

application name:                layer7 ping


Matched 1 flow



Cisco SNA can obtain additional information, or context if you will, about the endpoints, things like authenticated user id (learned from ISE), location, etc. to provide a more detailed view of the traffic flows on the network. Take the example above. With the information from ISE we could create custom views indicating that John Doe (authenticated user) using a MAC Book Air logged into a Catalyst9200 in bldg. 4 on port Gi0/0/5 using IP with SGT 18 was communicating with a DC Production Server with IP and SGT 14.


Anomaly Detection and Mitigation

Systems like Cisco SNA and FMC can monitor network behavior on your behalf.


Cisco SNA has a very extensive network behaviour and anomaly detection engine.  Behaviour detection requires understanding of known bad behavior and anomaly detection identifies a change from the norm. Custom events can trigger on traffic conditions such as traffic flowing between two specified groups, suspected data hoarding or detected data exfiltration.

Once suspicious hosts are identified, Cisco SNA can take action. A quarantine message can be sent to ISE via the Adaptive Network Control (ANC) function to reassign the security group of the host to ‘suspicious’ limiting access and perhaps forcing remediation. This process has become to be known as ‘Rapid Threat Containment’ (RTC) and is shown in figure 42. The new quarantine security group is maintained even after the host moves to another section of the network.


Firepower Management Center (FMC) can quarantine in a similar way but the trigger in that case is the detection of malware signatures within the data flow. Partners also utilize the functionality providing protection from a whole host of different kinds of threats.



Figure 42: Rapid Threat Containment (RTC)


Deployment Guide Summary

Many topics have been discussed within this prescriptive deployment guide with best practices provided. As a high-level summary, see the bullet-points below:


  • Start with desired business goals in mind.
  • Plan to ensure least effort, pick least deployment effort for maximum business value.
  • Use case(s) must be clearly defined. Can start with specific localized use-cases with minimal platform dependencies to prove value and give operational understanding.
  • Simplicity is important. Keeping groups simple, utilizing SXP for deployments and ASA use cases should prove especially easy. Segmentation within SDA is easy as it is orchestrated by Cisco Catalyst Center.
  • Phased deployments work best. Forklift upgrades should not be necessary.
  • Software defined segmentation provides non-disruptive deployments. Enforcement can be enabled incrementally and gradually.
  • It is easy to add groups and extend deployments later.
  • Monitor first and validate the application profile. NetFlow gives you visibility of SGT assignments
  • Moves, adds and changes effort is dramatically reduced



List of Acronyms

AAA                  Authentication, Authorization and Accounting

ACI                   Application Centric Infrastructure

ACL                  Access Control List

AD                    Active Directory (Microsoft)

ANC                  Adaptive Network Control

API                   Application Programming Interface

APIC                 Application Policy Infrastructure Controller (Cisco)

ASA                  Adaptive Security Appliance (Cisco)

ASDM               Adaptive Security Device Manager (Cisco)

ASIC                 Application-Specific Integrated Circuit

ASR                  Aggregation Services Router (Cisco)

BGP                  Border Gateway Protocol

C3PL                Cisco Common Classification Policy Language

CDP                 Cisco Discovery Protocol

CLI                   Command Line Interface

CMD                Cisco Meta Data

CoA                 Change of Authorization (RADIUS)

CSM                Cisco Security Manager (Cisco)

CSR                 Cloud Services Router (Cisco)

CTS                 Cisco TrustSec

dB                    Database

DC                   Data Center

DHCP               Dynamic Host Configuration Protocol

DGT                 Destination Group Tag

DOS                 Denial of Service

DMVPN            Dynamic Multipoint Virtual Private Network

DNS                 Domain Name System

EAP                  Extensible Authentication Protocol

EIGRP               Enhanced Interior Gateway Routing Protocol

EPG                  EndPoint Group

FIB                   Forwarding Information Base

FMC                 Firepower Management Center (Cisco)

FQDN               Fully Qualified Domain Name

FTD                  Firepower Threat Defense (Cisco)

GETVPN           Group Encrypted Transport Virtual Private Network

GRE                 Generic Routing Encapsulation

HIPAA              Health Insurance Portability and Accounting Act

HTTP               HyperText Transfer Protocol

IBNS                Identity-Based Networking Services

IETF                 Internet Engineering Task Force

IOS                  Internetwork Operating System (Cisco)

IP                     Internet Protocol

IPAM                IP Address Management

IPDT                 IP Device Tracking

IPS                   Intrusion Prevention System

IPSec               Internet protocol security

ISE                   Identity Services Engine (Cisco)

ISR                   Integrated Services Router (Cisco)

L2                    Layer 2

L3                    Layer 3

LACP                Link Aggregation Control Protocol

LAN                  Local Area Network

LDAP                Lightweight Directory Access Protocol

LLDP                 Link Layer Discovery Protocol

M2M                 Machine to machine

MAB,                MAC authentication bypass

MAC                 Media Access Control (Address)

MDM                Mobile Device Management

MKA                 MACsec Key Agreement

MnT                  Maintenance and Troubleshooting [Node] (ISE)

NBA                  Network Behavior Analysis

NDAC               Network Device Admission Control

NMAP               Network Mapper

OpEx                 Operational Expenditure

OSPF                Open Shortest Path First

OTP                  Over the Top (Protocol)

PAC                  Protected Access Credential

PAN                  Policy Administration Node (ISE)

PBR                  Policy Based Routing

PCI                   Payment Card Industry

PSN                  Policy Services Node (ISE)

pxGrid              Platform Exchange Grid (Cisco)

QoS                 Quality of Service

RAVPN             Remote Access Virtual Private Network

RADIUS            Remote Authentication Dial-In User Service

ROI                   Return on Investment

RTC                  Rapid Threat Containment

SAP                  Security Association Protocol

SDA                  Software Defined Access (Cisco)

SGACL              Security Group Access Control List

SGT                  Security Group Tag

SIEM                 Security Information and Event Management

SISF                  Switch Integrated Security Features

SNMP               Simple Network Management Protocol

SSH                  Secure Shell

SXP                  Security Group Tag Exchange Protocol

SXPSN              Security Group Tag Exchange Policy Services Node (ISE)

SYSLOG            System Log

TACACS           Terminal Access Controller Access Control System

TCP                  Transmission Control Protocol

UDP                  User Datagram Protocol

VLAN                Virtual Local Area Network

VN                    Virtual Network

VPN                  Virtual Private Network

VRF                   Virtual routing and forwarding

VXLAN              Virtual Extensible Local Area Network

WAN                 Wide Area Network

WLC                 Wireless Local Area Network Controller

WSA                 Web Security Appliance (Cisco)

WMI                  Windows Management Instrumentation (Microsoft)

ZBFW               Zone-Based Firewall



Level 1
Level 1



Could we get a PDF copy of this document?
Cisco Employee
Cisco Employee

Replied to Bern81 privately.

Level 1
Level 1

Hi Jonothan, I'm also interested in a PDF copy. Thanks

Cisco Employee
Cisco Employee

Jonothan, I'm also interested in a PDF copy. Thanks

Level 1
Level 1

Dear Jonothan, 

Could we get a PDF copy of this document?


Level 1
Level 1

Hi Jonothan, I'm also interested in a PDF copy. Thanks

Level 1
Level 1

Hi Jonathan, 


The above document is very useful and would like to have a PDF copy.


Many thanks.


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: