The Cisco Document Team has posted a video. This document describes a video transcript for steps on how to collect a support bundle in ISE. Know of something that needs documenting? Share a new document request to doc-ic-feedba...
The article you are trying to access is permanently deleted.
The Cisco Document Team has posted a video. This document describes a video transcript for steps on how to collect a support bundle in ISE. Know of something that needs documenting? Share a new document request to doc-ic-feedba...
I took some time to import and update quite a bit of RADIUS vendor dictionaries for 3rd party vendors into ISE. I grabbed this information from various community and open source sites but I obviously can't test it against every vendor out there since...
The Cisco Document Team has posted an article. This document describes how to configure Posture Agentless in ISE and what is required in the endpoint to run Agentless script. Know of something that needs documenting? Share a ne...
The Cisco Document Team has posted an article. This document describes how to troubleshoot and catch errors while they are occurring by running show logging commands through the CLI. Know of something that needs documenting? Sh...
The Cisco Document Team has posted an article. This document describes how to configure a regular database update schedule for Rule or VDB on FDM. Know of something that needs documenting? Share a new document request to doc-ic...
The Cisco Document Team has posted an article. This document describes how to deploy the Cisco Secure Client Network Access Manager (NAM) profile through Identity Services Engine (ISE). Know of something that needs documenting?...
IntroductionWhat is the Queue Link / Queue Link Error ?Troubleshooting - Queue Link ErrorCause=basic_cancelCause=TimeoutCause=EconnrefusedCause={tls_alert;"handshake failure"}Cause={tls_alert;"unknown Ca"}Generate Signing Requests (CSR)Other CausesEf...
The Cisco Document Team has posted an article. This document describes the actions that you can take to troubleshoot upgrade failures with Cisco Identity Services Engine. Know of something that needs documenting? Share a new do...
The Cisco Document Team has posted an article. This document describes how to onboard a device managed by Firepower Device Manager (FDM) to Cisco Defense Orchestrator (CDO) using registration key. Know of something that needs d...
The Cisco Document Team has posted an article. This document describes how to deploy Cisco Secure Client Icon customization objects using Cisco Secure Firewall managed by FMC. Know of something that needs documenting? Share a n...
If a trial expires and the customer has not claimed yet, can they still use the claim code?Customer added the trial with the claim code, but doesn't see the trial in the Security Cloud Control Dashboard.The trial or order was claimed and/or activated...
The Cisco Document Team has posted an article. This document describes the steps required to configure Two-Factor authentication with machine and dot1x authentication. Know of something that needs documenting? Share a new docum...
Here are some basic ASA firewall troubleshooting tips for network traffic passing through the ASA. You can use the commands for basic checks on ASA firewalls. Task1 : How to check interfaces and security levels in ASA firewall 1. Login to ASA ...
The Cisco Document Team has posted an article. This document describes how to configure OSPF routing on the Firepower Threat Defense (FTD) managed by the Firepower Device Manager (FDM). Know of something that needs documenting?...
The Cisco Document Team has posted an article. This document describes the procedure to configure Custom Local Snort Rules in Snort3 on Firewall Threat Defense (FTD). Know of something that needs documenting? Share a new docume...
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:
Jonothan Eaves
Input and review by Darrin Miller
October 2022
Group-Based Policy, or Software defined segmentation, simplifies the management and provisioning of network access control using groups to classify network traffic and enforce security policies. Traffic classification is not based purely on IP address but based on endpoint identity and context enabling policy change without network redesign. A centralized policy management platform (e.g., Cisco Identity Services Engine) 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, security platforms and the C9800 WLC (and access points when appropriate). This provides better visibility through richer contextual information and allows an organization to be better able to isolate threats and accelerate remediation, reducing the impact and costs associated with a potential breach.
Group-Based Policy 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 either enforce traffic flows directly or propagate the classification information towards a network device assigned to be an enforcement point. Wherever enforced, the dynamically downloaded policy dictates whether the traffic should be permitted or denied.
Some terms to be familiar with are CTS and TrustSec. CTS stands for ‘Cisco Trusted Security’ and is an acronym typically used in the IOS-XE CLI when configuring or showing Group-Based Policy commands. Commands using this acronym will be used throughout this document. TrustSec is a brand name created by Cisco to name the whole technology using SGTs. The brand name has now officially been released by Cisco and the term ‘Group-Based Policy’ is more often used now. However, the term TrustSec still resides in some ISE GUI pages.
There are some new functions required to implement the Group-Based Policy technology, but subsequently the effort for adds, moves and changes is dramatically reduced once deployed.
As mentioned above, there are three pillars within the Group-Based Policy technology, namely classification, propagation, and enforcement. SXP sits within the propagation pillar. The protocol is to allow IP:SGT mappings (sometimes called bindings) to be sent/propagated from one network device to another. The main use-case for this is to send mappings from a network device at the source of a traffic flow towards an enforcement point (when inline tagging methods are not available) and/or send mappings from a network device at the destination of a traffic flow back towards an enforcement point.
The end of the connection sending mappings is called the Speaker, the end receiving mappings the Listener. A connection can be setup to send mappings in both directions (bi-directional) in which case the ends of the SXP connection will be configured as ‘Both’.
SXP is simply configured with a peer-to-peer TCP connection using port 64999. As it uses TCP it has no hardware dependencies and can be transported by any networking device.
Authentication and Integrity is handled by implementing MD5 but TCP Authentication Option (TCP-AO) can also be utilized as documented within RFC5925.
Multiple SXP connections can be terminated on a single network device. SXP mappings received over multiple SXP connections can provide aggregation and mappings received and re-transmitted out over multiple SXP connections provides a ‘reflection’ service.
Up to this SXPv5 version, there have unsurprisingly been four versions. The functions provided within each release are as follows:
SXP Version 1 | Initial SXP version supporting IPv4 binding propagation. |
SXP Version 2 | Includes support for IPv6 binding propagation and version negotiation. |
SXP Version 3 | Adds support for Subnet:SGT binding propagation. If speaking to a lower version then the subnet will be expanded to individual IP:SGT entries. N.B. Subnet expansion needs to be enabled by the use of "cts sxp mapping network-map x" where x is the maximum number of host expansions and x=0 means no expansion |
SXP Version 4 | Loop detection and prevention, capability exchange and built-in keep-alive mechanism. |
This guide provides technical guidance on version 5 of the SXP protocol (SXPv5) and it’s use within Group-Based Policy (GBP) technology. As well as providing advice on best practices, the guide covers design topics, deployment configurations and how to get the most out of the technology operation.
This guide is intended to provide technical guidance to design, deploy and operate SXPv5 across an environment incorporating GBP. It focuses on the incremental steps to enable the functionality and shows the configuration necessary to handle various use-cases.
This guide contains four major sections:
SXPv5 configuration, use-cases, and operation.
Previous versions of SXP are not covered and neither is Group-Based Policy operation.
SXP features have evolved throughout the years. From purely supporting IPv4 mappings, to supporting IPv6, Subnet:SGT and loop detection and prevention.
One challenge that remains with SXPv4 is that SXP is not VRF aware. Although the limitation is not Software Defined Access (SD-Access) specific, the challenges are clearly understood when designing an IP-Transit between multiple sites in an SD-Access deployment.
An SD-Access fabric deployment is depicted below using an IP-Transit for transport across the WAN:
For Group-Based Policy (GBP) to be synchronized between sites over an IP-Transit, ISE sends IP:SGT mappings to the fabric site Borders. Now, this is relatively simple if there is just one Virtual Network (VRF) deployed at the fabric sites.
Remember, SXPv4 is not VRF aware. So, to make the topology above work, the SXP connections need to be terminated within the VN/VRF on the Border. SXP mappings received by the Border are received in the VN/VRF and are visible and operational only within that VN/VRF.
If there are multiple VNs/VRFs deployed within the fabric sites, and most deployments do utilize multiples, then the deployment diagram would look as follows (using an example of 3 VNs/VRFs):
Clearly, the more VNs/VRFs that are deployed, the more SXP connections are required and the more IP:SGT mappings need to be handled with duplicates inherent across the VNs/VRFs.
The conclusion is that creating GBP sync across an IP-Transit is possible using SXPv4 but it means increased configuration required on ISE and on the Border, more memory and CPU resources required and scale limits easily breached.
Again, to re-iterate, SXP not being VRF aware is also a constraint outside the fabric, it’s just often seen as a constraint by many customers when sending mappings to a Border in an SD-Access deployment.
To improve the situation, SXP version 5 has been created.
At the time of writing this guide, SXPv5 is only available on network devices, not on ISE. Ultimately, the goal is to have just one SXP connection from ISE to Borders and send mappings for every VRF. Currently, without ISE supporting SXPv5, we need to deploy an SXP Reflector for this use-case in order to make use of the SXPv5 savings:
SXPv5 has been designed to export and import SXP mappings between specified SXP peers:
SXPv5 is available on Cat9k Switches, ASR/ISR routers and the C9800 WLAN controllers in IOS-XE release 17.9.1
There are four new commands created to support SXPv5:
There is no specific command to enable SXPv5. If an SXP connection is created between two devices which support SXPv5 then the SXP connection will be negotiated to operate in SXPv5 mode. If a device at either end of the SXP connection supports a lower version of SXP, then the SXP connection will be negotiated to operate at the lowest of the supported versions.
The following topology has been used in this document to demonstrate how SXPv5 operates:
The generic SXP configuration used to demonstrate the SXPv5 operation is as follows:
For the SXP Speaker, Cat9k-reflector:
cts sxp enable
cts sxp default password 7 xxx
cts sxp connection peer 10.3.25.2 source 10.3.23.2 password default mode local speaker
For the SXP Listener, Cat9k-border:
cts sxp enable
cts sxp default password 7 xxx
cts sxp connection peer 10.3.23.2 source 10.3.25.2 password default mode local listener
In order to export the mappings from the BuildingMgmt VRF in Cat9k-reflector and import them into the same VRF in Cat9k-border, then the following commands can be added:
Cat9k-reflector, Speaker | Cat9k-border, Listener |
cts sxp export-list BM-export |
cts sxp import-list BM-import |
So, we are taking all the mappings in the BuildingMgmt VRF in Cat9k-reflector and exporting them to the peer. The peer (Cat9k-border) is then importing those mappings and putting them into the same VRF.
This is over an SXP connection which is terminated in the default VRF.
Kernow-Cat9300-reflector#show cts sxp export-import-group speaker detailed
Export-import-group: speaker-grp-BM
Export-list name: BM-export
vrf BuildingMgmt
peer 10.3.25.2
Kernow-C9k-border#show cts sxp export-import-group listener detailed
Export-import-group: listener-grp-BM
Import-list name: BM-import
vrf BuildingMgmt
peer 10.3.23.2
Mappings originally in the BuildingMgmt VRF in Cat9k-reflector (mapping was added via CLI):
Kernow-Cat9300-reflector#show cts role-based sgt-map vrf BuildingMgmt all
Active IPv4-SGT Bindings Information
IP Address SGT Source
============================================
10.1.1.1 10 CLI
IP-SGT Active Bindings Summary
============================================
Total number of CLI bindings = 1
Total number of active bindings = 1
Same mapping showing up in the peer (learned via SXP) now that the SXPv5 configuration commands have been added:
Kernow-C9k-border#show cts role-based sgt-map vrf BuildingMgmt all
Active IPv4-SGT Bindings Information
IP Address SGT Source
============================================
10.1.1.1 10 SXP
IP-SGT Active Bindings Summary
============================================
Total number of SXP bindings = 1
Total number of active bindings = 1
There are additional mappings in the other VRFs within Cat9k-reflector, but they are not propagated to Cat9k-border as there is no configuration to export or import them.
The reflector/speaker shows mappings in the BuildingSecurity and IOT VRFs:
Kernow-C9k-reflector#show cts role-based sgt-map vrf BuildingSecurity all
Active IPv4-SGT Bindings Information
IP Address SGT Source
============================================
20.1.1.1 20 SXP
IP-SGT Active Bindings Summary
============================================
Total number of SXP bindings = 1
Total number of active bindings = 1
Kernow-C9k-reflector#show cts role-based sgt-map vrf IOT all
Active IPv4-SGT Bindings Information
IP Address SGT Source
============================================
30.1.1.1 30 SXP
IP-SGT Active Bindings Summary
============================================
Total number of SXP bindings = 1
Total number of active bindings = 1
The border/listener however does not show these mappings:
Kernow-C9k-border#show cts role-based sgt-map vrf BuildingSecurity all
Active IPv4-SGT Bindings Information
IP Address SGT Source
============================================
Kernow-C9k-border#show cts role-based sgt-map vrf IOT all
Active IPv4-SGT Bindings Information
IP Address SGT Source
============================================
Kernow-C9k-border#
Multiple VRFs can be placed under an export-list as in this example:
Cat9k-reflector, Speaker | Cat9k-border, Listener |
cts sxp export-list multiple-VRFs |
cts sxp import-list BM-import |
Mappings within the reflector default VRF:
Kernow-C9k-reflector#show cts role-based sgt-map all
Active IPv4-SGT Bindings Information
IP Address SGT Source
============================================
1.1.1.8 2 INTERNAL
10.1.200.1 2 INTERNAL
10.1.210.1 2 INTERNAL
10.1.211.1 2 INTERNAL
10.3.23.2 2 INTERNAL
10.4.25.2 2 INTERNAL
10.6.50.100 28 LOCAL
10.6.50.254 2 INTERNAL
IP-SGT Active Bindings Summary
============================================
Total number of LOCAL bindings = 1
Total number of INTERNAL bindings = 7
Total number of active bindings = 8
Mappings within the reflector BuildingMgmt VRF:
Kernow-C9k-reflector#show cts role-based sgt-map vrf BuildingMgmt all
Active IPv4-SGT Bindings Information
IP Address SGT Source
============================================
10.1.1.1 10 CLI
Mappings within the reflector BuildingSecurity VRF:
Kernow-C9k-reflector#show cts role-based sgt-map vrf BuildingSecurity all
Active IPv4-SGT Bindings Information
IP Address SGT Source
============================================
20.1.1.1 20 CLI
The mapping in the one VRF that is missing from the export-list is as follows:
Kernow-Cat9300-reflector#show cts role-based sgt-map vrf IOT all
Active IPv4-SGT Bindings Information
IP Address SGT Source
============================================
30.1.1.1 30 CLI
The total mappings received by Cat9k-border in the BuildingMgmt VRF is shown here (which does not include the mapping from IOT):
Kernow-C9k-border#show cts role-based sgt-map vrf BuildingMgmt all
Active IPv4-SGT Bindings Information
IP Address SGT Source
============================================
1.1.1.8 2 SXP
10.1.1.1 10 SXP
10.1.200.1 2 SXP
10.1.210.1 2 SXP
10.1.211.1 2 SXP
10.3.23.2 2 SXP
10.4.25.2 2 SXP
10.6.50.100 28 SXP
10.6.50.254 2 SXP
20.1.1.1 20 SXP
IP-SGT Active Bindings Summary
============================================
Total number of SXP bindings = 10
Total number of active bindings = 10
The originating platform does not need to have any SXPv5 configuration at all. As long as the SXP Listener end receives mappings then import-lists and ‘export-import-group listener’ commands will direct the received mappings appropriately.
Take the following SXPv5 configurations:
Cat9k-reflector, Speaker | Cat9k-border, Listener |
<None> |
cts sxp import-list BM-import |
As the existing SXP connection is terminated in the default VRF on both platforms, it’s the mappings in the default VRF that are sent by the Speaker.
Mappings in the Cat9k-reflector Speaker:
Kernow-Cat9300-reflector#show cts role-based sgt-map all
Active IPv4-SGT Bindings Information
IP Address SGT Source
============================================
1.1.1.8 2 INTERNAL
10.1.200.1 2 INTERNAL
10.1.210.1 2 INTERNAL
10.1.211.1 2 INTERNAL
10.3.23.2 2 INTERNAL
10.4.25.2 2 INTERNAL
10.6.50.100 28 LOCAL
10.6.50.254 2 INTERNAL
IP-SGT Active Bindings Summary
============================================
Total number of LOCAL bindings = 1
Total number of INTERNAL bindings = 7
Total number of active bindings = 8
Mappings received by the Cat9k-border Listener are placed into the BuildingMgmt VRF due to the import-list and export-import-group listener:
Kernow-C9k-border#show cts role-based sgt-map vrf BuildingMgmt all
Active IPv4-SGT Bindings Information
IP Address SGT Source
============================================
1.1.1.8 2 SXP
10.1.200.1 2 SXP
10.1.210.1 2 SXP
10.1.211.1 2 SXP
10.3.23.2 2 SXP
10.4.25.2 2 SXP
10.6.50.100 28 SXP
10.6.50.254 2 SXP
IP-SGT Active Bindings Summary
============================================
Total number of SXP bindings = 8
Total number of active bindings = 8
Rather than source bindings from a number of VRFs, the Speaker export-list can utilize the binding source type instead. The list of binding source types can be seen via the CLI command:
Kernow-Cat9300-reflector#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Kernow-Cat9300-reflector(config)#cts sxp export-list BM-export
Kernow-Cat9300-reflector(config-export-list)#binding-source-type ?
all Export All bindings
caching export cached bindings to peer
cli export cli bindings to peer
l3if export l3if bindings to peer
lisp export lisp bindings to peer
local export local bindings to peer
vlan export vlan bindings to peer
Take the following configuration:
Cat9k-reflector, Speaker | Cat9k-border, Listener |
cts sxp export-list export-localANDcli |
cts sxp import-list BM-import vrf BuildingMgmt ! cts sxp export-import-group listener listener-grp-BM import-list BM-import peer 10.3.23.2 |
We are trying to send just the local and cli mappings to the BuildingMgmt VRF on the Listener.
At the Speaker end, we have the following mappings:
Default VRF:
IP Address SGT Source
============================================
1.1.1.8 2 INTERNAL
10.1.200.1 2 INTERNAL
10.1.210.1 2 INTERNAL
10.1.211.1 2 INTERNAL
10.3.23.2 2 INTERNAL
10.4.25.2 2 INTERNAL
10.6.50.100 28 LOCAL
10.6.50.254 2 INTERNAL
BuildingMgmt VRF:
IP Address SGT Source
============================================
10.1.1.1 10 CLI
BuildingSecurity VRF:
IP Address SGT Source
============================================
20.1.1.1 20 CLI
IOT VRF:
IP Address SGT Source
============================================
30.1.1.1 30 CLI
So, the Listener end should only show the Local mapping for SGT 28 and the CLI mappings for SGTs 10, 20 and 30, which it does:
Kernow-C9k-border#show cts role-based sgt-map vrf BuildingMgmt all
Active IPv4-SGT Bindings Information
IP Address SGT Source
============================================
10.1.1.1 10 SXP
10.6.50.100 28 SXP
20.1.1.1 20 SXP
30.1.1.1 30 SXP
IP-SGT Active Bindings Summary
============================================
Total number of SXP bindings = 4
Total number of active bindings = 4
Now, you cannot add both a binding-source-type and a VRF statement under the same export-list as they are mutually exclusive. If you do, you will experience the following errors:
% Remove binding-source configuration before enabling vrf
% Remove vrf configuration before configuring binding-source
You cannot add two export-lists (one specifying VRF and another specifying binding-source-group) in an export-import-group; only the last export-list entered will be present under the export-import-group configuration.
You cannot add two binding-source-groups using the same peer, an error is generated:
%Peer 10.3.25.2 is part of another group
If import-list contains ‘vlan-list’, then the incoming SXP information will be checked for the VLAN of the endpoint and placed into the same VRF at the destination.
The CLI help for vlan-list is “use VLAN recieved in binding to identify import VRF”.
Note: Yes, there is a spelling mistake in the CLI here.
Take the following configuration:
Cat9k-reflector, Speaker | Cat9k-border, Listener |
cts sxp export-list SXPv5-to-Cat9k-border |
cts sxp import-list From-Cat9k-reflector vlan-list ! cts sxp export-import-group listener From-Cat9k-reflector import-list From-Cat9k-reflector peer 1.1.1.6 ! interface Vlan100 vrf forwarding IOT |
The speaker side has a client authenticated into the IOT VRF with Doctors SGT 34 and VLAN 100 assigned:
Kernow-C9k-reflector#show authentication sessions interface g1/0/2 details
Interface: GigabitEthernet1/0/2
IIF-ID: 0x10423196
MAC Address: 0050.56a0.5622
IPv6 Address: Unknown
IPv4 Address: 9.9.9.10
User-Name: doctor1
Device-type: VMWare-Device
Device-name: VMWARE, INC.
VRF: IOT
Status: Authorized
Domain: DATA
Oper host mode: multi-auth
Oper control dir: both
Session timeout: N/A
Acct update timeout: 172800s (local), Remaining: 70339s
Common Session ID: 0601010100000011C4756D7E
Acct Session ID: 0x00000002
Handle: 0x80000007
Current Policy: PMAP_DefaultWiredDot1xOpenAuth_1X_MAB
Local Policies:
Server Policies:
Vlan Group: Vlan: 100
SGT Value: 34
The mapping shows up in the sgt-map table within the IOT VRF of the speaker:
Kernow-C9k-reflector#show cts role-based sgt-map vrf IOT all
Active IPv4-SGT Bindings Information
IP Address SGT Source
============================================
9.9.9.1 2 INTERNAL
9.9.9.10 34 LOCAL
10.3.25.2 2 INTERNAL
Now, with an SXPv5 connection from reflector to border, the mappings are received by the listener and the SXPv5 import-list is configured with the ‘vlan-list’ setting. This instructs the receiving network device to look in the received SXP information for an assigned VLAN for the source and place the associated mapping into the same VLAN/VRF on this receiving side.
Looking at the receiving side, the border in this case, the mapping has successfully been placed into the IOT VRF:
Kernow-Cat9300-border#show cts role-based sgt-map vrf IOT all
Active IPv4-SGT Bindings Information
IP Address SGT Source
============================================
9.9.9.10 34 SXP
10.3.23.2 2 INTERNAL
30.1.1.1 30 CLI
If we change the VRF that the VLAN resides in within the listener, it will be seen that it is indeed the VLAN that is used coming across the SXPv5 connection to steer the mapping to the correct VRF on the listener.
In the listener/border, change the VRF that VLAN 100 sits in:
Kernow-Cat9300-border#show running-config interface vlan 100
Building configuration...
Current configuration : 131 bytes
!
interface Vlan100
vrf forwarding BuildingMgmt
Now, when the mapping is received from the reflector, VLAN 100 is read off the SXPv5 information being received, and the mapping is placed into the local associated VRF for that VLAN (which is VRF BuildingMgmt):
Kernow-Cat9300-border#show cts role-based sgt-map vrf BuildingMgmt all
Active IPv4-SGT Bindings Information
IP Address SGT Source
============================================
9.9.9.10 34 SXP
10.1.1.1 10 CLI
To import all VRFs into the listener, just use ‘vrf’ under the import-list, as shown below:
Cat9k-reflector, Speaker | Cat9k-border, Listener |
cts sxp export-list export-all |
cts sxp import-list all-vrfs vrf ! cts sxp export-import-group listener From-Cat9k-reflector import-list all-vrfs peer 10.3.23.2 |
With the above configuration, all VRF mappings are sent by the Speaker and all mappings are placed in the matching VRFs in the Listener.
Mappings within the reflector/speaker:
Default VRF:
IP Address SGT Source
============================================
1.1.1.8 2 INTERNAL
10.1.200.1 2 INTERNAL
10.1.210.1 2 INTERNAL
10.1.211.1 2 INTERNAL
10.3.23.2 2 INTERNAL
10.4.25.2 2 INTERNAL
10.6.50.100 28 LOCAL
10.6.50.254 2 INTERNAL
BuildingMgmt VRF:
IP Address SGT Source
============================================
10.1.1.1 10 CLI
BuildingSecurity VRF:
IP Address SGT Source
============================================
20.1.1.1 20 CLI
IOT VRF:
IP Address SGT Source
============================================
30.1.1.1 30 CLI
Mappings within the Border/listener:
Kernow-C9k-border#show cts role-based sgt-map all
Active IPv4-SGT Bindings Information
IP Address SGT Source
============================================
1.1.1.6 2 INTERNAL
1.1.1.8 2 SXP
10.1.200.1 2 SXP
10.1.201.1 2 INTERNAL
10.1.202.1 2 INTERNAL
10.1.203.1 2 INTERNAL
10.1.210.1 2 SXP
10.1.211.1 2 SXP
10.3.23.2 2 SXP
10.3.25.2 2 INTERNAL
10.4.21.2 2 INTERNAL
10.4.25.2 2 SXP
10.6.5.111 34 LOCAL
10.6.5.254 2 INTERNAL
10.6.50.100 28 SXP
10.6.50.254 2 SXP
IP-SGT Active Bindings Summary
============================================
Total number of SXP bindings = 8
Total number of LOCAL bindings = 1
Total number of INTERNAL bindings = 7
Total number of active bindings = 16
Kernow-C9k-border#show cts role-based sgt-map vrf BuildingMgmt all
Active IPv4-SGT Bindings Information
IP Address SGT Source
============================================
10.1.1.1 10 SXP
Kernow-C9k-border#show cts role-based sgt-map vrf BuildingSecurity all
Active IPv4-SGT Bindings Information
IP Address SGT Source
============================================
20.1.1.1 20 SXP
Kernow-C9k-border#show cts role-based sgt-map vrf IOT all
Active IPv4-SGT Bindings Information
IP Address SGT Source
============================================
30.1.1.1 30 SXP
So, all the bindings in all VRFs can be sent by the speaker and those bindings can be received by the listener and put back into the same VRFs.
Take the following configuration (IOT VRF definition does not exist on the listener):
Cat9k-reflector, Speaker | Cat9k-border, Listener |
vrf definition BuildingMgmt |
vrf definition BuildingMgmt vrf definition BuildingSecurity ! cts sxp import-list all-vrfs vrf ! cts sxp export-import-group listener From-Cat9k-reflector import-list all-vrfs peer 10.3.23.2 |
What happens to the mappings in the IOT VRF when received by the Listener which does not have that VRF configured?
The answer is that those mappings are placed into the default VRF instead, just as if SXPv4 were being used:
On the Speaker, the mappings in the IOT VRF:
Kernow-Cat9300-reflector#show cts role-based sgt-map vrf IOT all
Active IPv4-SGT Bindings Information
IP Address SGT Source
============================================
30.1.1.1 30 CLI
IP-SGT Active Bindings Summary
============================================
Total number of CLI bindings = 1
Total number of active bindings = 1
On the Listener after receiving all mappings from the Speaker, check the mappings in the default VRF. The mapping from the IOT VRF is placed here as the IOT VRF does not exist in the Listener:
Kernow-C9k-border#show cts role-based sgt-map all
Active IPv4-SGT Bindings Information
IP Address SGT Source
============================================
1.1.1.6 2 INTERNAL
1.1.1.8 2 SXP
10.1.200.1 2 SXP
10.1.201.1 2 INTERNAL
10.1.202.1 2 INTERNAL
10.1.203.1 2 INTERNAL
10.1.210.1 2 SXP
10.1.211.1 2 SXP
10.3.23.2 2 SXP
10.3.25.2 2 INTERNAL
10.4.21.2 2 INTERNAL
10.4.25.2 2 SXP
10.6.5.111 34 LOCAL
10.6.5.254 2 INTERNAL
10.6.50.100 28 SXP
10.6.50.254 2 SXP
30.1.1.1 30 SXP
IP-SGT Active Bindings
Summary
============================================
Total number of SXP bindings = 9
Total number of LOCAL bindings = 1
Total number of INTERNAL bindings = 7
Total number of active bindings = 17
Configure the following without a peer configured in the export-import-group listener:
Cat9k-reflector, Speaker | Cat9k-border, Listener |
cts sxp export-list export-all |
cts sxp import-list BM-import vrf BuildingMgmt ! cts sxp export-import-group listener listener-grp-BM import-list BM-import |
Starting with the mappings within the speaker:
Default VRF:
IP Address SGT Source
============================================
1.1.1.8 2 INTERNAL
10.1.200.1 2 INTERNAL
10.1.210.1 2 INTERNAL
10.1.211.1 2 INTERNAL
10.3.23.2 2 INTERNAL
10.4.25.2 2 INTERNAL
10.6.50.100 28 LOCAL
10.6.50.254 2 INTERNAL
BuildingMgmt VRF:
IP Address SGT Source
============================================
10.1.1.1 10 CLI
BuildingSecurity VRF:
IP Address SGT Source
============================================
20.1.1.1 20 CLI
IOT VRF:
IP Address SGT Source
============================================
30.1.1.1 30 CLI
All the received mappings are received ok but they are put into the Default VRF in the listener:
Kernow-C9k-border#show cts role-based sgt-map all
Active IPv4-SGT Bindings Information
IP Address SGT Source
============================================
1.1.1.6 2 INTERNAL
1.1.1.8 2 SXP
10.1.1.1 10 SXP
10.1.200.1 2 SXP
10.1.201.1 2 INTERNAL
10.1.202.1 2 INTERNAL
10.1.203.1 2 INTERNAL
10.1.210.1 2 SXP
10.1.211.1 2 SXP
10.3.23.2 2 SXP
10.3.25.2 2 INTERNAL
10.4.21.2 2 INTERNAL
10.4.25.2 2 SXP
10.6.5.111 34 LOCAL
10.6.5.254 2 INTERNAL
10.6.50.100 28 SXP
10.6.50.254 2 SXP
20.1.1.1 20 SXP
30.1.1.1 30 SXP
IP-SGT Active Bindings Summary
============================================
Total number of SXP bindings = 11
Total number of LOCAL bindings = 1
Total number of INTERNAL bindings = 7
Total number of active bindings = 19
It is best practice to configure a peer IP but the above is what happens if you do not.
Configure the following without an import-list configured in the export-import-group listener:
Cat9k-reflector, Speaker | Cat9k-border, Listener |
cts sxp export-list export-all |
cts sxp import-list BM-import vrf BuildingMgmt ! cts sxp export-import-group listener listener-grp-BM peer 10.3.23.2 |
Starting with the mappings within the speaker/reflector:
Default VRF:
IP Address SGT Source
============================================
1.1.1.8 2 INTERNAL
10.1.200.1 2 INTERNAL
10.1.210.1 2 INTERNAL
10.1.211.1 2 INTERNAL
10.3.23.2 2 INTERNAL
10.4.25.2 2 INTERNAL
10.6.50.100 28 LOCAL
10.6.50.254 2 INTERNAL
BuildingMgmt VRF:
IP Address SGT Source
============================================
10.1.1.1 10 CLI
BuildingSecurity VRF:
IP Address SGT Source
============================================
20.1.1.1 20 CLI
IOT VRF:
IP Address SGT Source
============================================
30.1.1.1 30 CLI
All the mappings are received ok on the listener/border but they are put into the Default VRF:
Kernow-C9k-border#show cts role-based sgt-map all
Active IPv4-SGT Bindings Information
IP Address SGT Source
============================================
1.1.1.6 2 INTERNAL
1.1.1.8 2 SXP
10.1.1.1 10 SXP
10.1.200.1 2 SXP
10.1.201.1 2 INTERNAL
10.1.202.1 2 INTERNAL
10.1.203.1 2 INTERNAL
10.1.210.1 2 SXP
10.1.211.1 2 SXP
10.3.23.2 2 SXP
10.3.25.2 2 INTERNAL
10.4.21.2 2 INTERNAL
10.4.25.2 2 SXP
10.6.5.111 34 LOCAL
10.6.5.254 2 INTERNAL
10.6.50.100 28 SXP
10.6.50.254 2 SXP
20.1.1.1 20 SXP
30.1.1.1 30 SXP
IP-SGT Active Bindings Summary
============================================
Total number of SXP bindings = 11
Total number of LOCAL bindings = 1
Total number of INTERNAL bindings = 7
Total number of active bindings = 19
It is best practice to configure an import-list in the export-import-group listener, but the above is what happens if you do not.
Global can only be specified if no specific export-import-group has previously been defined, otherwise you see this error:
%Global group cannot be configured as other export-import-group is active
The global keyword is used on the Speaker and Listener as shown here, used if the export-import-group applies to all peers on the platform.
You’ll see no sub-config is required under the export-import-group; the import or export-list is set on the same line and there is no peer to set:
Cat9k-reflector, Speaker | Cat9k-border, Listener |
cts sxp export-list export-all |
cts sxp import-list all-vrfs vrf cts sxp export-import-group listener global all-vrfs |
This is simpler configuration as it applies to all peers in the deployment.
This example will discuss the following network topology:
Enterprise customers often want to be able to send static mappings to branch locations. This has become considerably easier using SXPv5 when VRFs are deployed.
As stated previously, ISE does not yet support SXPv5 (at the time of this document being written), but SXP aggregators or reflectors can be used to receive mappings from ISE over SXPv4 and propagate mappings outbound towards branches using SXPv5.
The first element to note is that ISE is not currently fully VRF aware, so how are mappings from different VRFs sent from ISE over different SXPv4 connections? ISE uses a concept called SXP domains which are VRF-like separated tables of IP:SGT mappings. Static mappings can be configured within ISE assigning the IP, the SGT as well as the SXP domain. Dynamic mappings learned by ISE are placed into the default SXP domain unless an SXP filter is added assigning a user-defined domain. An SXP filter can be created using IP prefixes, SGTs or Virtual Networks to put the IP:SGT into the desired SXP Domain.
These domains are then associated with certain SXP connections/peers via the connection configuration. These connections/peers are terminated at the destination aggregator/reflector in the corresponding VRFs. An example may be that static mappings added for data-center servers and services be placed into the Default domain whereas dynamic mappings learned via authenticated sessions are placed into user-defined domains.
The SXPv4 mappings are received by the aggregators/reflectors in the respective VRFs. The diagram above shows 4 VRFs are in use for this example, the default VRF plus 3 which are user defined. To reduce the number of SXP connections required down to the branches, SXPv5 can be used. Some branches may only require the static mappings for the datacenter and not the dynamic mappings from sessions. The filtering capability of SXPv5 can come in very useful to reduce unnecessary traffic. For example, branch2 in the diagram only requires mappings within the Default VRF and VRF X. In this case, the SXPv5 configuration in the aggregators/reflectors for branch2 may look something like the following:
cts sxp export-list SXPv5-export-to-branch2
vrf Default-vrf
vrf X
!
cts sxp export-import-group speaker SXPv5-speaker-to-branch2
export-list SXPv5-export-to-branch2
peer <branch2 IP address>
The corresponding SXPv5 configuration on the branch could look as follows:
cts sxp import-list SXPv5-import-from-reflectors
vrf
!
cts sxp export-import-group listener SXPv5-listener-from-refl1
import-list SXPv5-import-from-reflectors
peer <Reflector1 IP address>
!
cts sxp export-import-group listener SXPv5-listener-from-refl2
import-list SXPv5-import-from-reflectors
peer <Reflector2 IP address>
Another example is where a branch router requires the mappings from all other branches but not its own. There’s no harm sending its own mappings back to it, but it is redundant and wasteful on resources. The branch router already has the mappings for authenticated sessions within its own branch.
Again, using branch2 as an example, the endpoints within branch2 are all on subnet 10.10.2.0/24. SXP filters can be useful here, either on the aggregators/reflectors or on the branch router.
On the branch router, an example SXP filter could be as follows to deny its own prefixes from being received from both reflectors:
cts sxp filter-enable
!
cts sxp filter-list sxp-filter-deny-own-prefix
deny ipv4 10.10.2.0/24
permit sgt all
!
cts sxp filter-group listener sxp-filter-refl1-deny-prefix
filter sxp-filter-deny-own-prefix
peer ipv4 <reflector1 IP address>
!
cts sxp filter-group listener sxp-filter-refl2-deny-prefix
filter sxp-filter-deny-own-prefix
peer ipv4 <reflector2 IP address>
It may be more beneficial to place the SXP filter on the aggregators/reflectors, in which case the following may be suitable on each aggregator/reflector to deny sending branch2 prefix back to the same branch:
cts sxp filter-enable
!
cts sxp filter-list sxp-filter-deny-b2
deny ipv4 10.10.2.0/24
permit sgt all
!
cts sxp filter-group speaker sxp-filter-deny-b2
filter sxp-filter-deny-b2
peer ipv4 <Branch2 IP address>
These are just a couple of examples where using both SXPv5 configuration and SXP filters can reduce traffic on the network allowing resources to be utilised more effectively.
To check if SXPv5 is supported in the running image, the following command can be used:
Kernow-Cat9300-reflector#show cts | beg SXP
SXP Connections Summary
===================================
SXP : Enabled
Highest Version Supported: 5
The following command can be used to see if the current SXP connections have negotiated and come up using SXPv5:
Kernow-Cat9300-reflector#show cts sxp connections
SXP : Enabled
Highest Version Supported: 5
Default Password : Set
Default Key-Chain: Not Set
Default Key-Chain Name: Not Applicable
Default Source IP: 1.1.1.8
Connection retry open period: 120 secs
Reconcile period: 120 secs
Retry open timer is not running
Peer-Sequence traverse limit for export: Not Set
Peer-Sequence traverse limit for import: Not Set
----------------------------------------------
Peer IP : 10.3.25.2
Source IP : 10.3.23.2
Conn status : On
Conn version : 5
Conn capability : IPv4-IPv6-Subnet
Conn hold time : 120 seconds
Local mode : SXP Speaker
Connection inst# : 1
TCP conn fd : 1
TCP conn password: default SXP password
Keepalive timer is running
Duration since last state change: 0:01:57:57 (dd:hr:mm:sec)
Total num of SXP Connections = 1
To see the export-list configuration on the Speaker, use the following:
Kernow-Cat9300-reflector#show cts sxp export-list
Export-list-name: export-all
vrf all
To see the export-import-group information for a Speaker:
Kernow-Cat9300-reflector#show cts sxp export-import-group speaker
Export-import-group: All-VRFs
Export-list name: export-all
peer 10.3.25.2
If the ‘detailed’ keyword is used with the command above, the details of the attached export-list are also shown:
Kernow-Cat9300-reflector#show cts sxp export-import-group speaker detailed
Export-import-group: All-VRFs
Export-list name: export-all
vrf all
peer 10.3.25.2
Similar commands can be used for the Listener:
Kernow-C9k-border#show cts sxp import-list
Import-list-name: all-vrfs
Vrf
Kernow-C9k-border#show cts sxp export-import-group listener
Export-import-group: From-Cat9k-reflector
Import-list name: all-vrfs
peer 10.3.23.2
Kernow-C9k-border#show cts sxp export-import-group listener detailed
Export-import-group: From-Cat9k-reflector
Import-list name: all-vrfs
vrf
peer 10.3.23.2
When making use of SXPv5 enhancements, command constructs such as import and export-lists and export-import-groups are used which allow mappings from various VRFs to be sent and received over one SXP connection.
SXP filters can be used in conjunction with the SXPv5 commands to produce flexible filtering capabilities.
The following points need to be noted:
If the global export-import-group is configured, then no other defined export-import-group can be present. If one is present, then the following error will be generated:
%Global group cannot be configured as other export-import-group is active
If SXP is enabled, then you cannot configure or unconfigure the global export-import-group. If SXP is enabled, then one of the following events will be generated:
%SXP Enabled, Can not configure/unconfigure global import group
%SXP Enabled, Can not configure/unconfigure global export group
In order to configure an SXP peer under the export-import-group, the SXP connection must not be added or SXP needs to be disabled. One of the following errors is generated if this occurs:
% Disable the sxp connection for peer <peer-IP> before changing peer configuration
% Bring the sxp connection for peer <peer-IP> down before changing peer configuration
You cannot remove an export or import-list if it is referenced within an export-import-group. If attempted, the following will be shown:
Export-list <name> cannot be removed as it configured in other export-import-group(s)
Import-list <name> cannot be removed as it configured in other export-import-group(s)
You cannot edit an export or import-list if it is referenced within an export-import-group. If attempted, the following will be shown:
%Export-list <name> cannot be modified as it is configured in other export-import-group(s)
%Import-list <name> cannot be modified as it is configured in other export-import-group(s)
You can specify either a VRF or binding-source-type under the export-list. If you try to configure both the following will be generated:
% Remove binding-source configuration before enabling vrf
% Remove vrf configuration before configuring binding-source
You can specify either a VRF or vlan-list under the import-list but they are mutually exclusive. If you try to configure both the following will be generated:
%Please remove vlan-list configuration before enabling VRF
%Please remove VRF configuration before enabling vlan
You cannot specify multiple export-lists within an export-import-group. If you do, only the last export-list entered will be present under the export-import-group configuration.
You cannot specify multiple binding-source-types under an export-list. If you do, only the last binding-source-type entered will be present under the export-list configuration. If multiples are required, then configure the different binding-source-types within the same configuration statement, example:
binding-source-type local cli vlan
You cannot specify multiple VRF statements under an import-list. If you do, only the last VRF statement entered will be present under the import-list configuration.
You cannot delete an export-import-group listener without first removing the related SXP connection (or disabling SXP with ‘no cts sxp enable’. If you try:
% Remove the sxp connection for peer <peer-IP> before deleting expor-import configuration
If you try to configure >1 export-import-group with the same peer, the following error is generated:
%Peer <IP address> is part of another group
You cannot attach an export or import-list without any sub-configuration to an export-import-group:
%Export-list is empty, cannot be attached
%Import-list is empty, cannot be attached
The VRF must exist in order to provision it under the import or export-list. If you try to provision it when it doesn’t exist:
% VRF <name> doesn't exist.
AAA Authentication, Authorization and Accounting
CDP Cisco Discovery Protocol
CLI Command Line Interface
CMD Cisco Meta Data
CTS Cisco Trusted Security
DHCP Dynamic Host Configuration Protocol
DGT Destination Group Tag
(Cisco) DNA (Cisco) Digital Network Architecture
(Cisco) DNAC (Cisco) Digital Network Architecture Center
GBP Group-Based Policy
IOS Internetwork Operating System (Cisco)
IP Internet Protocol
ISE Identity Services Engine (Cisco)
ISR Integrated Services Router (Cisco)
L2 Layer 2
L3 Layer 3
LAN Local Area Network
MAC Media Access Control (Address)
SDA Software Defined Access (Cisco)
SD-Access Software Defined Access (Cisco)
SGT Security Group Tag
SXP Security Group Tag Exchange Protocol
SYSLOG System Log
TCP Transmission Control Protocol
UDP User Datagram Protocol
VLAN Virtual Local Area Network
VN Virtual Network
VRF Virtual routing and forwarding