Jonothan Eaves
Input and review by Darrin Miller
October 2022
- Introduction
- About Group-Based Policy (GBP)
- About Security Group Tag Exchange Protocol (SXP)
- About This Guide
- What is covered in this document?
- What is not covered in this document?
- Define
- Design
- Topology
- Deploy
- Use-case, SXPv5 Speaker Communicating IP, SGT and VRF to Listener
- Use-case, SXPv5 Export/Import for Multiple VRFs
- Use-case, SXPv5 Import VRF Only
- Use-case, SXPv5 Utilizing Binding Source Type in Export-List
- Use-case, SXPv5 Utilizing Binding Source Type and VRF in Export-Lists (Mutually Exclusive)
- Use-case, SXPv5 Using Vlan-List in Import-List
- Use-case, SXPv5 Importing All VRFs
- Use-case, SXPv5 Receiving Mappings for a VRF That Does Not Exist
- Use-case, SXPv5 Not Specifying Peer in export-import-group listener
- Use-case, SXPv5 Not Specifying import-list in export-import-group listener
- Use-case, SXPv5 Using global export-import-group
- An Example Deployment Sending Static Mappings from ISE to Branches
- Operate
- Deployment Guide Summary
- Appendix
- List of Acronyms
Introduction
About Group-Based Policy (GBP)
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.
About Security Group Tag Exchange Protocol (SXP)
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. |
About This Guide
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:
- The Define section defines the problem being solved with SXPv5 and provides information about the use-cases covered.
- The Design section highlights the typical deployment topologies and discusses any known caveats.
- The Deploy section provides information about various procedures and configurations to deploy the solution along with recommended best practices.
- The Operate section shows how to verify the operation of SXPv5.
What is covered in this document?
SXPv5 configuration, use-cases, and operation.
What is not covered in this document?
Previous versions of SXP are not covered and neither is Group-Based Policy operation.
Define
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:
Design
SXPv5 has been designed to export and import SXP mappings between specified SXP peers:
- Export certain mappings on the SXP Speaker side based on binding source type and/or VRF.
- Import certain mappings on the SXP Listener side into the specified VRF.
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:
- For Speaker:
- cts sxp export-list (binding source type and/or Source VRF specified)
- cts sxp export-import-group speaker (export-list and peer defined)
- For Listener:
- cts sxp import-list (Destination VRF specified with optional vlan-list)
- cts sxp export-import-group listener (import-list and peer defined)
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.
Topology
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
Note: This SXP connection is terminated in the default VRF, but it doesn’t have to be to make use of the SXPv5 functionality.
Deploy
Use-case, SXPv5 Speaker Communicating IP, SGT and VRF to 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#
Use-case, SXPv5 Export/Import for Multiple VRFs
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
Use-case, SXPv5 Import VRF Only
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
Use-case, SXPv5 Utilizing Binding Source Type in Export-List
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 |
Note: Mappings from ALL VRFs are used with the binding-source-type option. The choices of binding-source-type and VRF are mutually exclusive.
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
Use-case, SXPv5 Utilizing Binding Source Type and VRF in Export-Lists (Mutually Exclusive)
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
Use-case, SXPv5 Using Vlan-List in Import-List
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
Note: The SXP listener must have the same VLAN present associated with either the default or non-default VRF.
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
Use-case, SXPv5 Importing All VRFs
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.
Use-case, SXPv5 Receiving Mappings for a VRF That Does Not Exist
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
Use-case, SXPv5 Not Specifying Peer in export-import-group listener
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.
Use-case, SXPv5 Not Specifying import-list in export-import-group listener
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.
Use-case, SXPv5 Using global export-import-group
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.
An Example Deployment Sending Static Mappings from ISE to Branches
This example will discuss the following network topology:
Note: You can configure multiple VRF statements under an export-list.
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.
Appendix
List of Acronyms
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