Table of Contents Table of ContentsSummaryACMEObtaining the CertificatesObtain the Certificate from Let's EncryptIdentify the Signing Certificate AuthoritiesObtain the ISRG Root X1 CertificateUploading the Certificates to ISEUpload the ISRG Root X1...
The Cisco Document Team has posted an article. This document describes the network information that is required to be added to your firewall for the Secure Malware Analytics to operate properly. Know of something that needs doc...
The Cisco Document Team has posted an article. This document describes the procedure for utilizing OpenAPI to manage Cisco Identity Services Engine (ISE) Policy. Know of something that needs documenting? Share a new document re...
The Cisco Document Team has posted an article. This document centralizes some of the most important Cisco links related to the documentation, configuration, and troubleshooting of Secure Firewall Know of something that needs do...
The Cisco Document Team has posted an article. This document describes the necessary steps to successfully configure Hairpin on a Firepower Threat Defense with Firepower Management Center. Know of something that needs documenti...
The Cisco Document Team has posted an article. This document describes the process of configuring threat detection for Remote Access VPN services on Cisco Secure Firewall Threat Defense (FTD). Know of something that needs docum...
The Cisco Document Team has posted an article. This document describes Cisco Secure Email Encryption (CRES) Secure Compose restrictions introduced on September 14, 2024 when using Websafe. Know of something that needs documenti...
Cisco Umbrella is making a big changes with additional features and components. Now you have two separate policies a DNS Policy and new Policy called Web Policy. So what policy should you use? In my opinion, there is a consideration when using DNS P...
The Cisco Document Team has posted an article. This document describes the steps to edit the IP address or hostname of the Secure Firewall Management Center on the Firepower Threat Defense. Know of something that needs document...
The Cisco Document Team has posted an article. This document describes how to upgrade from Snort 2 and Snort 3 version in Firepower Manager Center (FMC). Know of something that needs documenting? Share a new document request to...
The Cisco Document Team has posted an article. This document describes how to configure Automatic Updates for the Vulnerability Database (VDB) on FMC. Know of something that needs documenting? Share a new document request to do...
The Cisco Document Team has posted an article. This document describes how to change the management IP for the Firewall Threat Defense device managed by the Secure Firewall Management Center. Know of something that needs docume...
The Cisco Document Team has posted an article. This document describes the necessary steps to successfully configure Hairpin on a Cisco Adaptive Security Appliance (ASA). Know of something that needs documenting? Share a new do...
The Cisco Document Team has posted an article. This document describes how to troubleshoot Remediation Errors on Cisco Secure Email Threat Defense. Know of something that needs documenting? Share a new document request to doc-i...
In the ever-evolving landscape of cybersecurity, those responsible for critical infrastructures are no strangers to stringent processes and procedures. After years of established national regulations and industry standards like IEC 62443 and IEC 623...
Meddane
Marvin Rhoads
Julio Carvajal
Collin Clark
Jouni Forss
Gopinath_Pigili
Arne Bier
Karsten Iwen
Marius Gunnerud
jonas.resende
Dennis Mink
leimin fan
dhr.tech1
Tarik Admani
Seb Rupik
mikael.dautrey
Federico Coto Fajardo
smcnutt
Tagir Temirgaliyev
jj27
Sri Harsha Dasari
andy!doesnt!lik
Abheesh Kumar
MrBeginner
andre.ortega
Narayan Dev Sarma
MichelyLopez
Rahul Govindan
CiscoNet Training Solutions
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
Note: This SXP connection is terminated in the default VRF, but it doesn’t have to be to make use of the SXPv5 functionality.
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 |
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
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
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
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:
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.
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
.png "rwehe"){kind=avatar}
