Buy or Renew
Buy or Renew
Duo Security forums now LIVE! Get answers to all your Duo Security questions. Learn more

Security Knowledge Base

cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Create a new article

Cisco CyberSecurity
Labels

Knowledge Base Articles

Create a new article

ZONE BASED FIREWALL IMPLEMENTATION

                                                                                    Zone-Based FireWall (ZBFW)IntroductionRules for applying ZBFWZBFW TerminologyZBFW ActionsZBFW ConfigurationIntroduction:The Cisco IOS Zone-Based Firewall is a statefu...

Gopinath_Pigili_0-1713354075409.png Gopinath_Pigili_1-1713354134355.png Gopinath_Pigili_2-1713354571115.png Gopinath_Pigili_3-1713354736036.png
View All
Getting Started

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

Top Contributors
Featured Article

Group-Based Policy SXPv5 Guide

jeavesciscocom_0-1666172730314.png

 

Jonothan Eaves
Input and review by Darrin Miller
October 2022

 

 

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.

jeavesciscocom_0-1666173163233.png

 

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:

 

jeavesciscocom_1-1666173317891.png

 

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):

 

jeavesciscocom_2-1666173351342.png

 

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:

 

jeavesciscocom_3-1666173388113.png

 

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:

 

jeavesciscocom_4-1666173490820.png

 

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

 

jeavesciscocom_5-1666173575875.pngNote: 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
 vrf BuildingMgmt
!
cts sxp export-import-group speaker speaker-grp-BM
 export-list BM-export
 peer 10.3.25.2

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

 

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
 vrf BuildingMgmt
 vrf BuildingSecurity
 vrf Default-vrf
!
cts sxp export-import-group speaker To-Cat9k-border
 export-list multiple-VRFs
 peer 10.3.25.2

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

 

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
 vrf BuildingMgmt
!
cts sxp export-import-group listener listener-grp-BM
 import-list BM-import
 peer 10.3.23.2

 

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
 binding-source-type local cli
!
cts sxp export-import-group speaker speaker-grp-bindings
 export-list export-localANDcli
 peer 10.3.25.2

 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

 

jeavesciscocom_0-1666175513615.pngNote: 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
 vrf IOT
!
cts sxp export-import-group speaker To-Cat9k-border
 export-list SXPv5-to-Cat9k-border
 peer 1.1.1.8
!
interface Vlan100
 vrf forwarding IOT

 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

 

jeavesciscocom_0-1666176194510.pngNote: 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
  vrf all
!
cts sxp export-import-group speaker All-VRFs
  export-list export-all
  peer 10.3.25.2

 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 BuildingSecurity
vrf definition IOT
!
cts sxp export-list export-all
 vrf all
!
cts sxp export-import-group speaker All-VRFs
 export-list export-all
 peer 10.3.25.2

 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
 vrf all
!
cts sxp export-import-group speaker All-VRFs
 export-list export-all
 peer 10.3.25.2

 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
 vrf all
!
cts sxp export-import-group speaker All-VRFs
 export-list export-all
 peer 10.3.25.2

 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
 vrf all
cts sxp export-import-group speaker global 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:

 

jeavesciscocom_0-1666178817952.png

 

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.

 

Operate

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

 

Deployment Guide Summary

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
 
jeavesciscocom_0-1666179664332.pngNote: 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

 

jeaves@cisco.com
Cisco Employee
Cisco Employee