Page 1
Cisco TrustSec Switch Configuration
Guide
For Cisco Catalyst Switches
Updated: October 2013
Americas Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 527-0883
Text Part Number: OL-22192-02
Page 2
CCVP, the Cisco logo, and Welcome to the Human Network are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn is a service mark of
Cisco
Systems, Inc.; and Access Registrar, Aironet, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, Cisco, the Cisco Certified Internetwork Expert logo,
IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step,
Cisco
Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study,
LightStream, Linksys, MeetingPlace, MGX, Networkers, Networking Academy, Network Registrar, PIX, ProConnect, ScriptShare, SMARTnet, StackWise, The Fastest Way
to Increase Your Internet Quotient, and TransPath are registered trademarks of Cisco
All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply a partnership relationship
between Cisco and any other company. (0711R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display
output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in
illustrative content is unintentional and coincidental.
Cisco TrustSec Switch Configuration Guide
© 2010-2013 Cisco Systems, Inc. All rights reserved.
Systems, Inc. and/or its affiliates in the United States and certain other countries.
Page 3
Preface ix
Cisco TrustSec Overview 1-1
Information about Cisco TrustSec Architecture 1-1
Authentication 1-3
Cisco TrustSec and Authentication 1-3
Device Identities 1-6
Device Credentials 1-6
User Credentials 1-6
Security Group-Based Access Control 1-7
Security Groups and SGTs 1-7
SGACL Policies 1-7
Ingress Tagging and Egress Enforcement 1-8
Determining the Source Security Group 1-9
Determining the Destination Security Group 1-10
SGACL Enforcement on Routed and Switched Traffic 1-10
Authorization and Policy Acquisition 1-10
Environment Data Download 1-11
RADIUS Relay Functionality 1-12
Link Security 1-12
CONTENTS
OL-22192-01
Using Cisco TrustSec-Incapable Devices and Networks in a Cisco TrustSec Network 1-13
SXP for SGT Propagation Across Legacy Access Networks 1-13
Layer 3 SGT Transport for Spanning Non-TrustSec Regions 1-14
Cisco TrustSec Reflector for Cisco TrustSec-Incapable Switching Modules 1-15
Ingress Reflector 1-16
Egress Reflector 1-16
VRF-Aware SXP 1-17
Layer 2 VRF-Aware SXP and VRF Assignment 1-17
Cisco TrustSec Configuration Guide
iii
Page 4
Contents
Configuring the Cisco TrustSec Solution 2-1
Configuration Overview 2-1
Cisco TrustSec Configuration How-to Documents 2-1
Supported Hardware and Software 2-2
Prerequisites for Cisco TrustSec 2-2
Cisco TrustSec Guidelines and Limitations 2-3
Default Settings 2-3
Additional Documentation 2-3
Release-Specific Documents 2-3
Platform-Specific Documents 2-4
Cisco IOS TrustSec Documentation Set 2-5
Configuring Identities, Connections, and SGTs 3-1
Cisco TrustSec Identity Configuration Feature Histories 3-1
Configuring Credentials and AAA for a Cisco TrustSec Seed Device 3-2
Configuration Examples for Seed Device 3-3
Configuring Credentials and AAA for a Cisco TrustSec Non-Seed Device 3-3
Configuration Examples for Non-Seed Device 3-4
Enabling Cisco TrustSec Authentication and MACsec in 802.1X Mode on an Uplink Port 3-5
Configuration Examples for 802.1X on Uplink Port 3-6
Configuring Cisco TrustSec and MACsec in Manual Mode on an Uplink Port 3-6
Configuration Examples for Manual Mode and MACsec on an Uplink Port 3-8
Regenerating SAP Key on an Interface 3-9
Verifying the Cisco TrustSec Interface Configuration 3-9
Manually Configuring a Device SGT 3-11
Configuration Examples for Manually Configuring a Device SGT 3-11
Manually Configuring IP-Address-to-SGT Mapping 3-12
Subnet to SGT Mapping 3-12
Default Settings 3-12
Configuring Subnet to SGT Mapping 3-12
Verifying Subnet to SGT Mapping Configuration 3-15
Configuration Examples for Subnet to SGT Mapping 3-15
VLAN to SGT Mapping 3-16
Default Settings 3-17
Configuring VLAN to SGT Mapping 3-17
Verifying VLAN to SGT Mapping 3-19
Configuration Example for VLAN to SGT Mapping for a Single Host Over an Access Link 3-19
Cisco TrustSec Configuration Guide
iv
OL-22192-01
Page 5
Layer 3 Logical Interface to SGT Mapping (L3IF–SGT Mapping) 3-20
Feature History for L3IF-SGT Mapping 3-21
Default Settings 3-21
Configuring L3IF to SGT Mapping 3-21
Verifying L3IF to SGT Mapping 3-21
Configuration Example for L3IF to SGT Mapping on an Ingress Port 3-22
Binding Source Priorities 3-22
Configuring Additional Authentication Server-Related Parameters 3-23
Automatically Configuring a New or Replacement Password with the Authentication Server 3-24
Configuring SGT Exchange Protocol over TCP (SXP) and Layer 3 Transport 4-1
Cisco TrustSec SGT Exchange Protocol Feature Histories 4-1
Configuring Cisco TrustSec SXP 4-2
Enabling Cisco TrustSec SXP 4-2
Configuring an SXP Peer Connection 4-2
Contents
Configuring the Default SXP Password 4-4
Configuring the Default SXP Source IP Address 4-4
Changing the SXP Reconciliation Period 4-5
Changing the SXP Retry Period 4-5
Creating Syslogs to Capture Changes of IP Address to SGT Mapping Learned Through SXP 4-5
Verifying the SXP Connections 4-6
Configuring Layer 3 SGT Transport Between Cisco TrustSec Domains 4-6
Configuring Cisco TrustSec Reflector for Cisco TrustSec-Incapable Switching Modules 4-8
Configuring Cisco TrustSec Caching 4-9
Enabling Cisco TrustSec Caching 4-9
Clearing the Cisco TrustSec Cache 4-10
Configuring SGACL Policies 5-1
Cisco TrustSec SGACL Feature Histories 5-1
SGACL Policy Configuration Process 5-2
Enabling SGACL Policy Enforcement Globally 5-2
Configuration Examples for Enabling SGACL Policy Enforcement Globally 5-2
Enabling SGACL Policy Enforcement Per Interface 5-3
Configuration Examples for Enabling SGACL Policy Enforcement Per Interface 5-3
Enabling SGACL Policy Enforcement on VLANs 5-3
Configuration Examples for Enabling SGACL Policy Enforcement on VLANs 5-3
OL-22192-01
Cisco TrustSec Configuration Guide
v
Page 6
Contents
Manually Configuring SGACL Policies 5-4
Manually Configuring and Applying IPv4 SGACL Policies 5-4
Configuration Examples for Manually Configuring SGACL Policies 5-5
Displaying SGACL Policies 5-6
Refreshing the Downloaded SGACL Policies 5-7
Configuring Endpoint Admission Control 6-1
Information About Endpoint Admission Control 6-1
Basic EAC Configuration Sequence 6-2
802.1X Authentication Configuration 6-2
Verifying the 802.1X Configuration 6-2
MAC Authentication Bypass Configuration 6-3
Verifying the MAB Configuration 6-3
Web Authentication Proxy Configuration 6-4
Verifying Web Authentication Proxy Configuration 6-4
Flexible Authentication Sequence and Failover Configuration 6-5
802.1X Host Modes 6-5
Pre-Authentication Open Access 6-5
DHCP Snooping and SGT Assignment 6-6
Verifying the SGT to Endpoint Host Binding 6-6
Cisco TrustSec Endpoint Access Control Feature Histories 6-7
Cisco TrustSec Command Summary 7-1
Notes for Catalyst 3000 and 2000 Series Switches and WLC 5700 Series Wireless LAN
Controllers A-1
Supported Hardware and Software A-1
Configuration Guidelines and Restrictions A-1
Global Cat3K Restrictions A-1
Catalyst 3850 and Catalyst 3650 Switches, and WLC 5700 Wireless LAN Controllers A-2
Catalyst 3750-X and Catalyst 3560-X switches A-2
Notes for Catalyst 4500 Series Switches B-1
Supported Hardware and Software B-1
TrustSec SGT and SGACL Configuration Guidelines and Limitations B-1
Cisco TrustSec Configuration Guide
vi
OL-22192-01
Page 7
Notes for Catalyst 6500 Series Switches C-1
TrustSec Supported Hardware C-1
Flexible NetFlow Support C-1
Sample Configurations C-2
Configuration Excerpt of an IPV4 Flow Record (5-tuple, direction, SGT, DGT) C-2
Configuration Excerpt of an IPV6 Flow Record (5-tuple, direction, SGT, DGT) C-2
Configuration Excerpt of an IPv4 Flow Monitor C-2
Configuration Excerpt of an IPv6 Flow Monitor C-3
Configuration Excerpt of the Global Flow Monitor (IPv4 and IPv6) C-3
Configuration Excerpt of the Interface Monitor C-3
Flexible NetFlow Show Commands C-3
TrustSec System Error Messages C-4
FIPS Support C-4
TrustSec Considerations when Configuring FIPS C-4
Licensing Requirements for FIPS C-4
Prerequisites for FIPS Configuration C-5
Guidelines and Limitations for FIPS C-5
Default Settings for FIPS C-5
Contents
I
NDEX
OL-22192-01
Cisco TrustSec Configuration Guide
vii
Page 8
Contents
Cisco TrustSec Configuration Guide
viii
OL-22192-01
Page 9
Preface
Revised: October 16, 2013, OL-22192-02
Organization
This guide includes the following chapters and appendixes:
Chapter or Appendix Title Description
Chapter 1, “Cisco TrustSec
Overview”
Chapter 2, “Configuring the Cisco
TrustSec Solution”
Chapter 3, “Configuring Identities,
Connections, and SGTs”
Chapter 4, “Configuring SGT
Exchange Protocol over TCP (SXP)
and Layer 3 Transport”
Chapter 5, “Configuring SGACL
Policies”
Chapter 6, “Configuring Endpoint
Admission Control”
Chapter 7, “Cisco TrustSec
Command Summary”
Appendix A, “Notes for Catalyst
3000 and 2000 Series Switches and
WLC 5700 Series Wireless LAN
Controllers”
Appendix B, “Notes for Catalyst
4500 Series Switches”
Appendix C, “Notes for Catalyst
6500 Series Switches”
Describes the elements and processes that create
the Cisco TrustSec network.
Provides an overview of configuration tasks
required to implement a Cisco TrustSec Network.
Provides NDAC and TrustSec seed device
configuration procedures.
Provides SGT over TCP Protocol (SXP)
configuration procedures.
Provides Security Group ACL configuration
procedures from the switch CLI.
Provides 802.1X, MAB, and WebAuth
configuration procedures for a TrustSec context.
Provides a list of Cisco TrustSec CLI commands
with brief descriptions.
Describes constraints, limitations, or
considerations pertaining to TrustSec
implementation of Catalyst 3000 and 2000 Series
Switches and WLC 5700 Series Wireless LAN
Controllers.
Describes constraints, limitations, or
considerations pertaining to TrustSec
implementation of Catalyst 4500 Series Switches.
Describes constraints, limitations, or
considerations pertaining to TrustSec
implementation of Catalyst 6500 Series Switches.
OL-22192-02
Cisco TrustSec Switch Configuration Guide
ix
Page 10
Conventions
This document uses the following conventions:
Preface
Convention Indication
bold font Commands and keywords and user-entered text appear in bold font.
italic font Document titles, new or emphasized terms, and arguments for which you supply
values are in italic font.
[ ] Elements in square brackets are optional.
{x | y | z } Required alternative keywords are grouped in braces and separated by
vertical bars.
[ x | y | z ] Optional alternative keywords are grouped in brackets and separated by
vertical bars.
string A nonquoted set of characters. Do not use quotation marks around the string or
the string will include the quotation marks.
courier font Terminal sessions and information the system displays appear in courier font.
< > Nonprinting characters such as passwords are in angle brackets.
[ ] Default responses to system prompts are in square brackets.
!, # An exclamation point (!) or a pound sign (#) at the beginning of a line of code
indicates a comment line.
Note Means reader take note.
Tip Means the following information will help you solve a problem.
Caution Means reader be careful. In this situation, you might perform an action that could result in equipment
damage or loss of data.
Timesaver Means the described action saves time. You can save time by performing the action described in
the paragraph.
Warning
Means reader be warned. In this situation, you might perform an action that could result in
bodily injury.
Cisco TrustSec Switch Configuration Guide
x
OL-22192-02
Page 11
Preface
Obtaining Documentation and Submitting a Service Request
For information on obtaining documentation, using the Cisco Bug Search Tool (BST), submitting a
service request, and gathering additional information, see What’s New in Cisco Product Documentation
at: http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html.
Subscribe to What’s New in Cisco Product Documentation, which lists all new and revised Cisco technical
documentation, as an RSS feed and deliver content directly to your desktop using a reader application. The
RSS feeds are a free service.
OL-22192-02
Cisco TrustSec Switch Configuration Guide
xi
Page 12
Preface
Cisco TrustSec Switch Configuration Guide
xii
OL-22192-02
Page 13
CHAP T ER
Cisco TrustSec Overview
Revised: June 16, 2011, OL-22192-01
This chapter contains the following topics:
• Information about Cisco TrustSec Architecture, page 1-1
• Using Cisco TrustSec-Incapable Devices and Networks in a Cisco TrustSec Network, page 1-13
Information about Cisco TrustSec Architecture
The Cisco TrustSec security architecture builds secure networks by establishing domains of trusted
network devices. Each device in the domain is authenticated by its peers. Communication on the links
between devices in the domain is secured with a combination of encryption, message integrity check,
and data-path replay protection mechanisms. Cisco TrustSec uses the device and user credentials
acquired during authentication for classifying the packets by security groups (SGs) as they enter the
network. This packet classification is maintained by tagging packets on ingress to the Cisco TrustSec
network so that they can be properly identified for the purpose of applying security and other policy
criteria along the data path. The tag, called the security group tag (SGT), allows the network to enforce
the access control policy by enabling the endpoint device to act upon the SGT to filter traffic.
The Cisco TrustSec architecture incorporates three key components:
• Authenticated networking infrastructure—After the first device (called the seed device)
authenticates with the authentication server to begin the Cisco TrustSec domain, each new device
added to the domain is authenticated by its peer devices already within the domain. The peers act as
intermediaries for the domain’s authentication server. Each newly-authenticated device is
categorized by the authentication server and assigned a security group number based on its identity,
role, and security posture.
• Security group-based access control—Access policies within the Cisco TrustSec domain are
topology-independent, based on the roles (as indicated by security group number) of source and
destination devices rather than on network addresses. Individual packets are tagged with the security
group number of the source.
• Secure communication—With encryption-capable hardware, communication on each link between
devices in the domain can be secured with a combination of encryption, message integrity checks,
and data-path replay protection mechanisms.
1
OL-22192-01
Cisco TrustSec Configuration Guide
1-1
Page 14
Information about Cisco TrustSec Architecture
Figure 1-1 shows an example of a Cisco TrustSec domain. In this example, several networking devices
and an endpoint device are inside the Cisco TrustSec domain. One endpoint device and one networking
device are outside the domain because they are not Cisco TrustSec-capable devices or because they have
been refused access. The authentication server is considered to be outside of the Cisco TrustSec domain;
it is either a Cisco Identities Service Engine (Cisco ISE), or a Cisco Secure Access Control System
(Cisco ACS).
Figure 1-1 Cisco TrustSec Network Domain Example
Chapter 1 Cisco TrustSec Overview
Authentication
Server (AS)
Switch 1
Switch 2
Cisco TrustSec
Switch
Protected
Unprotected link
Host 1
253096
Each participant in the Cisco TrustSec authentication process acts in one of the following roles:
• Supplicant—An unauthenticated device connected to a peer within the Cisco TrustSec domain, and
attempting to join the Cisco TrustSec domain.
• Authentication server—The server that validates the identity of the supplicant and issues the policies
that determine the supplicant’s access to services within the Cisco TrustSec domain.
• Authenticator—An authenticated device that is already part of the Cisco TrustSec domain and can
authenticate new peer supplicants on behalf of the authentication server.
When the link between a supplicant and an authenticator first comes up, the following sequence of events
typically occurs:
1. Authentication (802.1X)—The supplicant is authenticated by the authentication server, with the
authenticator acting as an intermediary. Mutual authentication is performed between the two peers
(supplicant and authenticator).
2. Authorization—Based on the identity information of the supplicant, the authentication server
provides authorization policies, such as security group assignments and ACLs, to each of the linked
peers. The authentication server provides the identity of each peer to the other, and each peer then
applies the appropriate policy for the link.
3. Security Association Protocol (SAP) negotiation—When both sides of a link support encryption, the
supplicant and the authenticator negotiate the necessary parameters to establish a security
association (SA).
When all three steps are complete, the authenticator changes the state of the link from the unauthorized
(blocking) state to the authorized state, and the supplicant becomes a member of the Cisco TrustSec
domain.
Cisco TrustSec Configuration Guide
1-2
OL-22192-01
Page 15
Chapter 1 Cisco TrustSec Overview
Cisco TrustSec uses ingress tagging and egress filtering to enforce access control policy in a scalable
manner. Packets entering the domain are tagged with a security group tag (SGT) containing the assigned
security group number of the source device. This packet classification is maintained along the data path
within the Cisco TrustSec domain for the purpose of applying security and other policy criteria. The final
Cisco TrustSec device on the data path, either the endpoint or network egress point, enforces an access
control policy based on the security group of the Cisco TrustSec source device and the security group of
the final Cisco TrustSec device. Unlike traditional access control lists based on network addresses, Cisco
TrustSec access control policies are a form of role-based access control lists (RBACLs) called security
group access control lists (SGACLs).
Note Ingress refers to packets entering the first Cisco TrustSec-capable device encountered by a packet on its
path to the destination and egress refers to packets leaving the last Cisco TrustSec-capable device on the
path.
Authentication
This section includes the following topics:
• Cisco TrustSec and Authentication, page 1-3
Information about Cisco TrustSec Architecture
• Device Identities, page 1-6
• Device Credentials, page 1-6
• User Credentials, page 1-6
Cisco TrustSec and Authentication
Using Network Device Admission Control (NDAC), Cisco TrustSec authenticates a device before
allowing it to join the network. NDAC uses 802.1X authentication with Extensible Authentication
Protocol Flexible Authentication via Secure Tunnel (EAP-FAST) as the Extensible Authentication
Protocol (EAP) method to perform the authentication. EAP-FAST conversations provide for other EAP
method exchanges inside the EAP-FAST tunnel using chains. Administrators can use traditional
user-authentication methods, such as Microsoft Challenge Handshake Authentication Protocol Version
2 (MSCHAPv2), while still having security provided by the EAP-FAST tunnel. During the EAP-FAST
exchange, the authentication server creates and delivers to the supplicant a unique protected access
credential (PAC) that contains a shared key and an encrypted token to be used for future secure
communications with the authentication server. Figure 1-2 shows the EAP-FAST tunnel and inner
methods as used in Cisco TrustSec.
OL-22192-01
Cisco TrustSec Configuration Guide
1-3
Page 16
Information about Cisco TrustSec Architecture
Figure 1-2 Cisco TrustSec Authentication
Chapter 1 Cisco TrustSec Overview
Switch 1 (supplicant)
EAP-FAST in 802.1X
Policy acquisition
Key establishment (SAP)
Ongoing key refresh (SAP)
Switch 2 (authenticator)
EAP-FAST Tunnel establishment
EAP-FAST in RADIUS
One time provisioning
Device authentication
User authentication
EAP-FAST tunnel tear down
Policy acquisition (RADIUS)
Cisco TrustSec
AS
AS
Switch 1
Switch 2
187008
Cisco TrustSec Configuration Guide
1-4
OL-22192-01
Page 17
Chapter 1 Cisco TrustSec Overview
This section includes the following topics:
• Cisco TrustSec Enhancements to EAP-FAST, page 1-5
• 802.1X Role Selection, page 1-5
• Cisco TrustSec Authentication Summary, page 1-5
Cisco TrustSec Enhancements to EAP-FAST
The implementation of EAP-FAST for Cisco TrustSec has the following enhancements:
• Authenticate the authenticator—Securely determines the identity of the authenticator by requiring
the authenticator to use its PAC to derive the shared key between itself and the authentication server.
This feature also prevents you from configuring RADIUS shared keys on the authentication server
for every possible IP address that can be used by the authenticator.
• Notify each device of the identity of its peer—By the end of the authentication exchange, the
authentication server has identified both the supplicant and the authenticator. The authentication
server conveys the identity of the authenticator, and whether the authenticator is Cisco
TrustSec-capable, to the supplicant by using additional type-length-value parameters (TLVs) in the
protected EAP-FAST termination. The authentication server also conveys the identity of the
supplicant, and whether the supplicant is Cisco TrustSec-capable, to the authenticator by using
RADIUS attributes in the Access- Accept message. Because each device knows the identity of its
peer, it can send additional RADIUS Access-Requests to the authentication server to acquire the
policy to be applied on the link.
Information about Cisco TrustSec Architecture
802.1X Role Selection
In 802.1X, the authenticator must have IP connectivity with the authentication server because it has to
relay the authentication exchange between the supplicant and the authenticator using RADIUS over
UDP/IP. When an endpoint device, such as a PC, connects to a network, it is obvious that it should
function as a supplicant. However, in the case of a Cisco TrustSec connection between two network
devices, the 802.1X role of each network device might not be immediately apparent to the other network
device.
Instead of requiring manual configuration of the authenticator and supplicant roles for two adjacent
switches, Cisco TrustSec runs a role-selection algorithm to automatically determine which switch
functions as the authenticator and which functions as the supplicant. The role-selection algorithm
assigns the authenticator role to the switch that has IP reachability to a RADIUS server. Both switches
start both the authenticator and supplicant state machines. When a switch detects that its peer has access
to a RADIUS server, it terminates its own authenticator state machine and assumes the role of the
supplicant. If both switches have access to a RADIUS server, the first switch to receive a response from
the RADIUS server becomes the authenticator and the other switch becomes the supplicant.
Cisco TrustSec Authentication Summary
By the end of the Cisco TrustSec authentication process, the authentication server has performed the
following actions:
• Verified the identities of the supplicant and the authenticator.
• Authenticated the user if the supplicant is an endpoint device.
OL-22192-01
Cisco TrustSec Configuration Guide
1-5
Page 18
Information about Cisco TrustSec Architecture
At the end of the Cisco TrustSec authentication process, both the authenticator and the supplicant know
the following:
• Device ID of the peer
• Cisco TrustSec capability information of the peer
• Key used for the SAP
Device Identities
Cisco TrustSec does not use IP addresses or MAC addresses as device identities. Instead, you assign a
name (device ID) to each Cisco TrustSec-capable switch to identify it uniquely in the Cisco TrustSec
domain. This device ID is used for the following:
• Looking up the authorization policy
• Looking up passwords in the databases during authentication
Device Credentials
Cisco TrustSec supports password-based credentials. Cisco TrustSec authenticates the supplicants
through passwords and uses MSCHAPv2 to provide mutual authentication.
Chapter 1 Cisco TrustSec Overview
User Credentials
The authentication server uses these credentials to mutually authenticate the supplicant during the
EAP-FAST phase 0 (provisioning) exchange where a PAC is provisioned in the supplicant. Cisco
TrustSec does not perform the EAP-FAST phase 0 exchange again until the PAC expires, and only
performs EAP-FAST phase 1 and phase 2 exchanges for future link bringups. The EAP-FAST phase 1
exchange uses the PAC to mutually authenticate the authentication server and the supplicant. Cisco
TrustSec uses the device credentials only during the PAC provisioning (or reprovisioning) steps.
When the supplicant first joins the Cisco TrustSec domain, the authentication server authenticates the
supplicant and pushes a shared key and encrypted token to the supplicant with the PAC. The
authentication server and the supplicant use this key and token for mutual authentication in all future
EAP-FAST phase 0 exchanges.
Cisco TrustSec does not require a specific type of user credential for endpoint devices. You can choose
any type of user authentication method that is supported by the authentication server, and use the
corresponding credentials. For example, the Cisco Secure Access Control System (ACS) version 5.1
supports MSCHAPv2, generic token card (GTC), or RSA one-time password (OTP).
Cisco TrustSec Configuration Guide
1-6
OL-22192-01
Page 19
Chapter 1 Cisco TrustSec Overview
Security Group-Based Access Control
This section includes the following topics:
• Security Groups and SGTs, page 1-7
• SGACL Policies, page 1-7
• Ingress Tagging and Egress Enforcement, page 1-8
• Determining the Source Security Group, page 1-9
• Determining the Destination Security Group, page 1-10
• SGACL Enforcement on Routed and Switched Traffic, page 1-10
Security Groups and SGTs
A security group is a grouping of users, endpoint devices, and resources that share access control
policies. Security groups are defined by the administrator in the Cisco ISE or Cisco Secure ACS. As new
users and devices are added to the Cisco TrustSec domain, the authentication server assigns these new
entities to appropriate security groups. Cisco TrustSec assigns to each security group a unique 16-bit
security group number whose scope is global within a Cisco TrustSec domain. The number of security
groups in the switch is limited to the number of authenticated network entities. You do not have to
manually configure security group numbers.
Once a device is authenticated, Cisco TrustSec tags any packet that originates from that device with a
security group tag (SGT) that contains the security group number of the device. The packet carries this
SGT throughout the network within the Cisco TrustSec header. The SGT is a single label that determines
the privileges of the source within the entire enterprise.
Because the SGT contains the security group of the source, the tag can be referred to as the source SGT.
The destination device is also assigned to a security group (the destination SG) that can be referred to
for simplicity as the destination group tag (DGT), although the actual Cisco TrustSec packet tag does
not contain the security group number of the destination device.
Information about Cisco TrustSec Architecture
SGACL Policies
OL-22192-01
Using security group access control lists (SGACLs), you can control the operations that users can
perform based on the security group assignments of users and destination resources. Policy enforcement
within the Cisco TrustSec domain is represented by a permissions matrix, with source security group
numbers on one axis and destination security group numbers on the other axis. Each cell in the body of
the matrix can contain an ordered list of SGACLs which specifies the permissions that should be applied
to packets originating from the source security group and destined for the destination security group.
Figure 1-3 shows an example of a Cisco TrustSec permissions matrix for a simple domain with three
defined user roles and one defined destination resource. Three SGACL policies control access to the
destination server based on the role of the user.
Cisco TrustSec Configuration Guide
1-7
Page 20
Information about Cisco TrustSec Architecture
Figure 1-3 SGACL Policy Matrix Example
Egress Policy
Role
(Security Group)
User A (10)
User B (20)
Source
User C (30)
User D (30)
By assigning users and devices within the network to security groups and applying access control
between the security groups, Cisco TrustSec achieves role-based topology-independent access control
within the network. Because SGACLs define access control policies based on device identities instead
of IP addresses as in traditional ACLs, network devices are free to move throughout the network and
change IP addresses. As long as the roles and the permissions remain the same, changes to the network
topology do not change the security policy. When a user is added to the switch, you simply assign the
user to an appropriate security group and the user immediately receives the permissions of that group.
Destination
Server X (111)
SGACL-A
SGACL-B
SGACL-C
Chapter 1 Cisco TrustSec Overview
SGACL-A
permit ip
SGACL-B
permit tcp src dst eq 80
deny ip
SGACL-C
permit tcp dst eq 1433
permit tcp src eq 1433
permit tcp dst eq 80
permit tcp dst eq 433
deny ip
276898
Using role-based permissions greatly reduces the size of ACLs and simplifies their maintenance. With
Cisco TrustSec, the number of access control entries (ACEs) configured is determined by the number of
permissions specified, resulting in a much smaller number of ACEs than in a traditional IP network. The
use of SGACLs in Cisco TrustSec typically results in a more efficient use of TCAM resources compared
with traditional ACLs.
Ingress Tagging and Egress Enforcement
Cisco TrustSec access control is implemented using ingress tagging and egress enforcement. At the
ingress point to the Cisco TrustSec domain, traffic from the source is tagged with an SGT containing the
security group number of the source entity. The SGT is propagated with the traffic across the domain.
At the egress point of the Cisco TrustSec domain, an egress device uses the source SGT and the security
group number of the destination entity (the destination SG, or DGT) to determine which access policy
to apply from the SGACL policy matrix.
Cisco TrustSec Configuration Guide
1-8
OL-22192-01
Page 21
Chapter 1 Cisco TrustSec Overview
Figure 1-4 shows how the SGT assignment and the SGACL enforcement operate in a Cisco TrustSec
domain.
Figure 1-4 SGT and SGACL in a Cisco TrustSec Domain
Information about Cisco TrustSec Architecture
SGACL enforcement
SGT = 3
Host
user PC
SGT imposition
Step 1 The host PC transmits a packet to the web server. Although the PC and the web server are not members
of the Cisco TrustSec domain, the data path of the packet includes the Cisco TrustSec domain.
Step 2 The Cisco TrustSec ingress switch modifies the packet to add an SGT with security group number 3, the
security group number assigned by the authentication server for the host PC.
Step 3 The Cisco TrustSec egress switch enforces the SGACL policy that applies to source group 3 and
destination group 4, the security group number assigned by the authentication server for the web server.
Step 4 If the SGACL allows the packet to be forwarded, the Cisco TrustSec egress switch modifies the packet
to remove the SGT and forwards the packet to the web server.
Determining the Source Security Group
A network device at the ingress of Cisco TrustSec domain must determine the SGT of the packet entering
the Cisco TrustSec domain so that it can tag the packet with that SGT when it forwards it into the Cisco
TrustSec domain. The egress network device must determine the SGT of the packet in order to apply an
SGACL.
The network device can determine the SGT for a packet in one of the following methods:
33
Cisco TrustSec
33
DGT = 4
Web server
187009
• Obtain the source SGT during policy acquisition—After the Cisco TrustSec authentication phase, a
network device acquires policy information from the authentication server, which indicates whether
the peer device is trusted or not. If a peer device is not trusted, then the authentication server can
also provide an SGT to apply to all packets coming from the peer device.
• Obtain the source SGT from the packet—If a packet comes from a trusted peer device, the packet
carries the SGT. This applies to a network device that is not the first network device in Cisco
TrustSec domain for the packet.
• Look up the source SGT based on the source identity—With Identity Port Mapping (IPM), you can
manually configure the link with the identity of the connected peer. The network device requests
policy information, including SGT and trust state, from the authentication server.
• Look up the source SGT based on the source IP address—In some cases, you can manually configure
the policy to decide the SGT of a packet based on its source IP address. The SGT Exchange Protocol
(SXP) can also populate the IP-address-to-SGT mapping table.
OL-22192-01
Cisco TrustSec Configuration Guide
1-9
Page 22
Information about Cisco TrustSec Architecture
Determining the Destination Security Group
The egress network device in a Cisco TrustSec domain determines the destination group (DGT) for
applying the SGACL. The network device determines the destination security group for the packet using
the same methods used for determining the source security group, with the exception of obtaining the
group number from a packet tag. The destination security group number is not included in a packet tag.
In some cases, ingress devices or other non-egress devices might have destination group information
available. In those cases, SGACLs might be applied in these devices rather than egress devices.
SGACL Enforcement on Routed and Switched Traffic
SGACL enforcement is applied only on IP traffic, but enforcement can be applied to either routed or
switched traffic.
For routed traffic, SGACL enforcement is performed by an egress switch, typically a distribution switch
or an access switch with a routed port connecting to the destination host. When you enable SGACL
enforcement globally, enforcement is automatically enabled on every Layer 3 interface except for SVI
interfaces.
For switched traffic, SGACL enforcement is performed on traffic flowing within a single switching
domain without any routing function. An example would be SGACL enforcement performed by a data
center access switch on server-to-server traffic between two directly connected servers. In this example,
the server-to-server traffic would typically be switched. SGACL enforcement can be applied to packets
switched within a VLAN or forwarded to an SVI associated with a VLAN, but enforcement must be
enabled explicitly for each VLAN.
Chapter 1 Cisco TrustSec Overview
Authorization and Policy Acquisition
After device authentication ends, both the supplicant and authenticator obtain the security policy from
the authentication server. The two peers then perform link authorization and enforce the link security
policy against each other based on their Cisco TrustSec device IDs. The link authentication method can
be configured as either 802.1X or manual authentication. If the link security is 802.1X, each peer uses
a device ID received from the authentication server. If the link security is manual, you must assign the
peer device IDs.
The authentication server returns the following policy attributes:
• Cisco TrustSec trust—Indicates whether the peer device is to be trusted for the purpose of putting
the SGT in the packets.
• Peer SGT—Indicates the security group to which the peer belongs. If the peer is not trusted, all
packets received from the peer are tagged with this SGT. If the device does not know whether any
SGACLs are associated with the peer’s SGT, the device may send a follow-up request to the
authentication server to download the SGACLs.
• Authorization expiry time—Indicates the number of seconds before the policy expires. A Cisco
TrustSec device should refresh its policy and authorization before it times out. The device can cache
the authentication and policy data and reuse it after a reboot if the data has not expired. In Cisco IOS
Release 12.2(33)SXI, only policy data and environment data is cached.
Tip Each Cisco TrustSec device should support some minimal default access policy in case it is not able to
contact the authentication server to get an appropriate policy for the peer.
Cisco TrustSec Configuration Guide
1-10
OL-22192-01
Page 23
Chapter 1 Cisco TrustSec Overview
SAP negotiation
authentication
authorization
authorization
authentication
supplican
Supplicant
Authentication Authentication
Authorization
Authorization
SAP negotiation
authentication
authorization
AT AS
Authentication Authentication
Authorization
Authorization
187007
The NDAC and SAP negotiation process is shown in Figure 1-5.
Figure 1-5 NDAC and SAP Negotiation
Information about Cisco TrustSec Architecture
Environment Data Download
The Cisco TrustSec environment data is a collection of information or policies that assists a device to
function as a Cisco TrustSec node. The device acquires the environment data from the authentication
server when the device first joins a Cisco TrustSec domain, although you might also manually configure
some of the data on a device. For example, you must configure the seed Cisco TrustSec device with the
authentication server information, which can later be augmented by the server list that the device
acquires from the authentication server.
The device must refresh the Cisco TrustSec environment data before it expires. The device can also cache
the environment data and reuse it after a reboot if the data has not expired.
The device uses RADIUS to acquire the following environment data from the authentication server:
• Server lists—List of servers that the client can use for future RADIUS requests (for both
authentication and authorization).
• Device SG—Security group to which the device itself belongs.
• Expiry timeout—Interval that controls how often the Cisco TrustSec device should refresh its
environment data.
OL-22192-01
Cisco TrustSec Configuration Guide
1-11
Page 24
Information about Cisco TrustSec Architecture
RADIUS Relay Functionality
The switch that plays the role of the Cisco TrustSec authenticator in the 802.1X authentication process
has IP connectivity to the authentication server, allowing the switch to acquire the policy and
authorization from the authentication server by exchanging RADIUS messages over UDP/IP. The
supplicant device may not have IP connectivity with the authentication server. In such cases,
Cisco TrustSec allows the authenticator to act as a RADIUS relay for the supplicant.
The supplicant sends a special EAPOL message to the authenticator that contains the RADIUS server IP
address and UDP port and the complete RADIUS request. The authenticator extracts the RADIUS
request from the received EAPOL message and sends it over UDP/IP to the authentication server. When
the RADIUS response returns from the authentication server, the authenticator forwards the message
back to the supplicant, encapsulated in an EAPOL frame.
Link Security
When both sides of a link support 802.1AE Media Access Control Security (MACsec), a security
association protocol (SAP) negotiation is performed. An EAPOL-Key exchange occurs between the
supplicant and the authenticator to negotiate a cipher suite, exchange security parameters, and manage
keys. Successful completion of all three tasks results in the establishment of a security association (SA).
Depending on your software version, crypto licensing, and link hardware support, SAP negotiation can
use one of the following modes of operation:
• Galois/Counter Mode (GCM)—Specifies authentication and encryption
Chapter 1 Cisco TrustSec Overview
• GCM authentication (GMAC)—Specifies authentication and no encryption
• No Encapsulation—Specifies no encapsulation (clear text)
• Null—Specifies encapsulation, no authentication and no encryption
All modes except No Encapsulation require Cisco TrustSec-capable hardware.
For Cisco Catalyst 6500 series switches, Cisco IOS Release 12.2(50)SY and later releases, Cisco
TrustSec uses AES-128 GCM and GMAC, compliant with the IEEE 802.1AE standard.
Cisco TrustSec Configuration Guide
1-12
OL-22192-01
Page 25
Chapter 1 Cisco TrustSec Overview
Using Cisco TrustSec-Incapable Devices and Networks in a Cisco TrustSec Network
Using Cisco TrustSec-Incapable Devices and Networks in a
Cisco TrustSec Network
This section includes the following topics:
• SXP for SGT Propagation Across Legacy Access Networks, page 1-13
SXP for SGT Propagation Across Legacy Access Networks
Tagging packets with SGTs requires hardware support. You might have devices in your network that,
while capable of participating in Cisco TrustSec authentication, lack the hardware capability to tag
packets with SGTs. By using the SGT Exchange Protocol (SXP), these devices can pass
IP-address-to-SGT mappings to a Cisco TrustSec peer device that has Cisco TrustSec-capable hardware.
SXP typically operates between ingress access layer devices at the Cisco TrustSec domain edge and
distribution layer devices within the Cisco TrustSec domain. The access layer device performs Cisco
TrustSec authentication of external source devices to determine the appropriate SGTs for ingress
packets. The access layer device learns the IP addresses of the source devices using IP device tracking
and (optionally) DHCP snooping, then uses SXP to pass the IP addresses of the source devices along
with their SGTs to the distribution switches. Distribution switches with Cisco TrustSec-capable
hardware can use this IP-to-SGT mapping information to tag packets appropriately and to enforce
SGACL policies (see Figure 1-6).
Figure 1-6 SXP Protocol to Propagate SGT Information
SGT tagging
HostA
(1.1.1.2)
HostB
(1.1.1.1)
Cisco TrustSec capable software
Cisco TrustSec incapable hardware
Src IP =1.1.1.1
SXP protocol exchange
IP:1.1.1.1: SGT:3
IP:1.1.1.2: SGT:5
Cisco TrustSec enabled software
and hardware
Src IP=1.1.1.1/ SGT = 3
3
Cisco TrustSec
187011
OL-22192-01
Cisco TrustSec Configuration Guide
1-13
Page 26
Using Cisco TrustSec-Incapable Devices and Networks in a Cisco TrustSec Network
You must manually configure an SXP connection between a peer without Cisco TrustSec hardware
support and a peer with Cisco TrustSec hardware support. The following tasks are required when
configuring the SXP connection:
• If you require SXP data integrity and authentication, you must configure the same SXP password
on both peer devices. You can configure the SXP password either explicitly for each peer connection
or globally for the device. Although an SXP password is not required, we recommend its use.
• You must configure each peer on the SXP connection as either an SXP speaker or an SXP listener.
The speaker device distributes the IP-to-SGT mapping information to the listener device.
• You can specify a source IP address to use for each peer relationship or you can configure a default
source IP address for peer connections where you have not configured a specific source IP address.
If you do not specify any source IP address, the device will use the interface IP address of the
connection to the peer.
SXP allows multiple hops. That is, if the peer of a device lacking Cisco TrustSec hardware support also
lacks Cisco TrustSec hardware support, the second peer can have an SXP connection to a third peer,
continuing the propagation of the IP-to-SGT mapping information until a hardware-capable peer is
reached. A device can be configured as an SXP listener for one SXP connection as an SXP speaker for
another SXP connection.
A Cisco TrustSec device maintains connectivity with its SXP peers by using the TCP keepalive
mechanism. To establish or restore a peer connection, the device will repeatedly attempt the connection
setup using a configurable retry period until the connection is successful or until the connection is
removed from the configuration.
Chapter 1 Cisco TrustSec Overview
Layer 3 SGT Transport for Spanning Non-TrustSec Regions
When a packet leaves the Cisco TrustSec domain for a non-TrustSec destination, the egress Cisco
TrustSec device removes the Cisco TrustSec header and SGT before forwarding the packet to the outside
network. If, however, the packet is merely traversing a non-TrustSec domain on the path to another Cisco
TrustSec domain, as shown in Figure 1-7, the SGT can be preserved by using the Cisco TrustSec Layer 3
SGT Transport feature. In this feature, the egress Cisco TrustSec device encapsulates the packet with an
ESP header that includes a copy of the SGT. When the encapsulated packet arrives at the next Cisco
TrustSec domain, the ingress Cisco TrustSec device removes the ESP encapsulation and propagates the
packet with its SGT.
Cisco TrustSec Configuration Guide
1-14
OL-22192-01
Page 27
Chapter 1 Cisco TrustSec Overview
Protected link
Unprotected link
Switch 2
TrustSec
domain
253097
Non-TrustSec
domain
Switch 1
TrustSec
domain
Figure 1-7 Spanning a Non-TrustSec domain
Using Cisco TrustSec-Incapable Devices and Networks in a Cisco TrustSec Network
To support Cisco TrustSec Layer 3 SGT Transport, any device that will act as a Cisco TrustSec ingress
or egress Layer 3 gateway must maintain a traffic policy database that lists eligible subnets in remote
Cisco TrustSec domains as well as any excluded subnets within those regions. You can configure this
database manually on each device if they cannot be downloaded automatically from the
Cisco Secure ACS.
A device can send Layer 3 SGT Transport data from one port and receive Layer 3 SGT Transport data
on another port, but both the ingress and egress ports must have Cisco TrustSec-capable hardware.
Note Cisco TrustSec does not encrypt the Layer 3 SGT Transport encapsulated packets. To protect the packets
traversing the non-TrustSec domain, you can configure other protection methods, such as IPsec.
Cisco TrustSec Reflector for Cisco TrustSec-Incapable Switching Modules
A Catalyst 6500 series switch in a Cisco TrustSec domain may contain any of these types of switching
modules:
• Cisco TrustSec-capable—Hardware supports insertion and propagation of SGT.
• Cisco TrustSec-aware—Hardware does not support insertion and propagation of SGT, but hardware
can perform a lookup to determine the source and destination SGTs for a packet.
• Cisco TrustSec-incapable—Hardware does not support insertion and propagation of SGT and
cannot determine the SGT by a hardware lookup.
If your switch contains a Cisco TrustSec-capable supervisor engine, you can use the Cisco TrustSec
reflector feature to accommodate legacy Cisco TrustSec-incapable switching modules within the same
switch. Available in Cisco IOS Release 12.2(50)SY and later releases, Cisco TrustSec reflector uses
SPAN to reflect traffic from a Cisco TrustSec-incapable switching module to the supervisor engine for
SGT assignment and insertion.
OL-22192-01
Cisco TrustSec Configuration Guide
1-15
Page 28
Using Cisco TrustSec-Incapable Devices and Networks in a Cisco TrustSec Network
Two mutually exclusive modes, ingress and egress, are supported for the Cisco TrustSec reflector. The
default is pure mode, in which neither reflector is enabled. A Cisco TrustSec ingress reflector is
configured on an access switch facing a distribution switch, while a Cisco TrustSec egress reflector is
configured on a distribution switch.
Supported TrustSec Reflector Hardware
For further discussion of the Cisco TrustSec Reflector feature and a list of supported hardware, see the
document, “Cisco Catalyst 6500 Series with Supervisor Engine 2T: Enabling Cisco TrustSec with
Investment Protection,” at the following URL:
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper_c11-658388.html
Ingress Reflector
A Cisco TrustSec ingress reflector is implemented on an access switch, where the Cisco
TrustSec-incapable switching module is on the Cisco TrustSec domain edge and the Cisco
TrustSec-capable supervisor engine uplink port connects to a Cisco TrustSec-capable distribution
switch.
The following conditions must be met before the Cisco TrustSec ingress reflector configuration is
accepted:
Chapter 1 Cisco TrustSec Overview
Egress Reflector
• The supervisor engine must be Cisco TrustSec-capable.
• Any Cisco TrustSec-incapable DFCs must be powered down.
• A Cisco TrustSec egress reflector must not be configured on the switch.
• Before disabling the Cisco TrustSec ingress reflector, you must remove power from the
Cisco TrustSec-incapable switching modules.
A Cisco TrustSec egress reflector is implemented on a distribution switch with Layer 3 uplinks, where
the Cisco TrustSec-incapable switching module faces an access switch. The Cisco TrustSec egress
reflector is supported only on Layer 3 uplinks, and is not supported on Layer 2 interfaces, SVIs,
subinterfaces, or tunnels, and is not supported for NAT traffic.
The following conditions must be met before the Cisco TrustSec egress reflector configuration is
accepted:
• The supervisor engine or DFC switching module must be Cisco TrustSec-capable.
• Cisco TrustSec must not be enabled on non-routed interfaces on the supervisor engine uplink ports
or on the Cisco TrustSec-capable DFC switching modules.
• Before disabling the Cisco TrustSec egress reflector, you must remove power from the Cisco
TrustSec-incapable switching modules.
• A Cisco TrustSec ingress reflector must not be configured on the switch.
Cisco TrustSec Configuration Guide
1-16
OL-22192-01
Page 29
Chapter 1 Cisco TrustSec Overview
VRF-Aware SXP
The SXP implementation of Virtual Routing and Forwarding (VRF) binds an SXP connection with a
specific VRF. It is assumed that the network topology is correctly configured for Layer 2 or Layer 3
VPNs, with all VRFs configured before enabling Cisco TrustSec.
SXP VRF support can be summarized as follows:
• Only one SXP connection can be bound to one VRF.
• Different VRFs may have overlapping SXP peer or source IP addresses.
• IP–SGT mappings learned (added or deleted) in one VRF can be updated only in the same VRF
domain. The SXP connection cannot update a mapping bound to a different VRF. If no SXP
connection exits for a VRF, IP–SGT mappings for that VRF won’t be updated by SXP.
• Multiple address families per VRF is supported. Therefore, one SXP connection in a VRF domain
can forward both IPV4 and IPV6 IP-SGT mappings.
• SXP has no limitation on the number of connections and number of IP–SGT mappings per VRF.
Layer 2 VRF-Aware SXP and VRF Assignment
Using Cisco TrustSec-Incapable Devices and Networks in a Cisco TrustSec Network
VRF to Layer 2 VLANs assignments are specified with the cts role-based l2-vrf vrf-name vlan-list
global configuration command. A VLAN is considered a Layer 2 VLAN as long as there is no switch
virtual interface (SVI) with an IP address configured on the VLAN. The VLAN becomes a Layer 3
VLAN once an IP address is configured on its SVI.
The VRF assignments configured by the cts role-based l2-vrf command are active as long as a VLAN
remains a Layer 2 VLAN. The IP–SGT bindings learned while a VRF assignment is active are also added
to the Forwarding Information Base (FIB) table associated with the VRF and the IP protocol version. If
an SVI becomes active for a VLAN, the VRF to VLAN assignment becomes inactive and all the bindings
learned on the VLAN are moved to the FIB table associated with the SVI’s VRF.
The VRF to VLAN assignment is retained even when the assignment becomes inactive. It is reactivated
when the SVI is removed or when the SVI IP address is deconfigured. When reactivated, the IP–SGT
bindings are moved back from the FIB table associated with the SVI's VRF to the FIB table associated
with the VRF assigned by the cts role-based l2-vrf command.
OL-22192-01
Cisco TrustSec Configuration Guide
1-17
Page 30
Using Cisco TrustSec-Incapable Devices and Networks in a Cisco TrustSec Network
Chapter 1 Cisco TrustSec Overview
Cisco TrustSec Configuration Guide
1-18
OL-22192-01
Page 31
Configuring the Cisco TrustSec Solution
Revised: July 13, 2012, OL-22192-01
This chapter includes the following topics:
• Configuration Overview, page 2-1
• Default Settings, page 2-3
• Additional Documentation, page 2-3
Configuration Overview
This guide documents elementary Cisco TrustSec configuration procedures for Cisco Catalyst switches
and includes a TrustSec command reference.
For network-wide deployment configurations, see the section, “Cisco TrustSec Configuration How-to
Documents.”
A network-wide deployment includes the configuration, interoperability, and management of multiple
devices, which may include the Cisco Identity Services Engine (Cisco ISE), The Cisco Secure Access
Control System (Cisco ACS), Cisco IP Telephones, Cisco routers, Cisco network appliances, etc.
CHAP T ER
2
White papers and presentations explaining the Cisco TrustSec Solution are at the following URL:
http://www.cisco.com/en/US/netsol/ns1051/index.html
Cisco TrustSec Configuration How-to Documents
A series of “How-to” configuration documents provides deployment guidelines and best practices for
proven network architectures in complex scenarios. Find all Cisco TrustSec “How-To” documents at the
following URL:
http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns744/landing_DesignZone_TrustSec.html
TrustSec 2.1 Configuration How-to Guide topics include the following:
• Introduction
• Planning and Pre-Deployment Checklist
• ISE Base Configuration: ISE Bootstrapping
• Adding ID Stores and Creating Authentication
• Global Switch Configuration
OL-22192-01
Cisco TrustSec Configuration Guide
2-1
Page 32
Configuration Overview
Chapter 2 Configuring the Cisco TrustSec Solution
• Base configuration for the Wireless LAN Controller
• Phased Deployment Overview
• Monitor Mode
• Migrating from Monitor Mode
• Low Impact Mode
• Closed Mode
• ISE Profiling Services
• ISE Base Configurations: Promiscuous VMware
• Central Web Authentication
• User Authentication and Authorization to Multiple Active Directory Domains
• ISE Deployment Type and Guideline
• Using Certificates to Differentiate Access
• On-boarding and Provisioning
• Server to Server Segmentation using Security Group Access
• Deploying EAP Chaining with AnyConnect NAM and Cisco ISE
• Failed Authentications & Authorizations
Supported Hardware and Software
For a list of TrustSec supported hardware and software per TrustSec release, see,
Release Notes for Cisco TrustSec General Availability Releases at the following URL:
http://www.cisco.com/en/US/docs/switches/lan/trustsec/release/notes/rn_cts_crossplat.html
See also, the Release Notes, Configuration Guides, and Command References for your device.
Prerequisites for Cisco TrustSec
The following are the prerequisites for establishing a TrustSec network with Catalyst switches:
• TrustSec software on all network devices
• Connectivity between all network devices
• Network availability of the Cisco Secure ACS 5.1, or Cisco ISE operating with a TrustSec license
• Directory, DHCP, DNS, certificate authority, and NTP servers functioning in the network
Cisco TrustSec Configuration Guide
2-2
OL-22192-01
Page 33
Chapter 2 Configuring the Cisco TrustSec Solution
Cisco TrustSec Guidelines and Limitations
Cisco TrustSec has the following guidelines and limitations for Catalyst switches:
• AAA for Cisco TrustSec uses RADIUS and is supported only by the Cisco Secure Access Control
System (ACS), version 5.1 or later.
• You must enable the 802.1X feature globally for Cisco TrustSec to perform NDAC authentication.
If you disable 802.1X globally, you will disable NDAC.
• Cisco TrustSec is supported only on physical interfaces, not on logical interfaces.
• Cisco TrustSec does not support IPv6 in the releases referenced in this guide.
• If the default password is configured on a switch, the connection on that switch should configure the
password to use the default password. If the default password is not configured on a switch, the
connection on that switch should also not configure a password. The configuration of the password
option should be consistent across the deployment network.
• Configure the retry open timer command to a different value on different switches.
Default Settings
Additional Documentation
Table 2-1 lists the default settings for Cisco TrustSec parameters.
Table 2-1 Default Cisco TrustSec Parameters
Parameters Default
Cisco TrustSec Disabled.
SXP Disabled.
SXP default password None.
SXP reconciliation period 120 seconds (2 minutes).
SXP retry period 60 seconds (1 minute).
Cisco TrustSec Caching Disabled.
Additional Documentation
Release-Specific Documents
Release-Specific Document Title TrustSec Topics
Release Notes for Cisco TrustSec General
Availability Releases
• Open and resolved caveats
• Current hardware and software support
OL-22192-01
Cisco TrustSec Configuration Guide
2-3
Page 34
Additional Documentation
Platform-Specific Documents
Platform-Specific Document Title TrustSec Topics
Catalyst 3000 Series Switches
Release Notes for Catalyst 3560 and 3750
Switches
Catalyst 3560 Software Configuration Guides 802.1x configuration procedures
Catalyst 3750-E and 3560-E Switch
Software Configuration Guide
Cisco Catalyst 3560-X Series Switches
Software Configuration Guides
Catalyst 3750 Metro Series Switches
Software Configuration Guides
Cisco Catalyst 3750-X Series Switches
Software Configuration Guides
Catalyst 4500 Series Switches
Cisco Catalyst 4500 Series Switches
Release Notes
Catalyst 4500 Series Switches
Software Configuration Guides
Catalyst 6500 Series Switches
Cisco Catalyst 6500 Series Switches
Release Notes
Catalyst 6500 Release 12.2SXH and Later
Software Configuration Guide
Catalyst 6500 Release 12.2SY
Software Configuration Guide
Catalyst 6500 Release 15.0SY
Software Configuration Guide
Nexus 7000 Series Switches
Cisco Nexus 7000 Series Switches Release Notes Open and resolved caveats
Cisco Nexus 7000 Series Switches
Configuration Guides
Cisco Secure Access Control System and Cisco Identity Services Engine
Cisco Secure Access Control System
Release Notes
Chapter 2 Configuring the Cisco TrustSec Solution
Open and resolved caveats; supported features
Open and resolved caveats, supported features
802.1x configuration procedures
Open and resolved caveats, supported features
802.1x configuration procedures
• TrustSec feature configurations for Cisco
Nexus 7000 series switches, Release 4.1 and
later
• 802.1X configuration procedures
Open and resolved caveats
Cisco TrustSec Configuration Guide
2-4
OL-22192-01
Page 35
Chapter 2 Configuring the Cisco TrustSec Solution
Platform-Specific Document Title TrustSec Topics
Cisco Secure Access Control System
End-User Guides
Cisco Identity Services Engine TrustSec Configurations. TrustSec is referred to
Cisco IOS TrustSec Documentation Set
Cisco IOS Document Title
Cisco IOS Security Configuration Guide: Securing User Services, Release 12.2SX
Securing User Services Configuration Guide Library, Cisco IOS Release 15SY
Additional Documentation
TrustSec configurations for Cisco ACS 5.1 and
later
as SGA, or Security Group Access in ISE
documentation.
OL-22192-01
Cisco TrustSec Configuration Guide
2-5
Page 36
Additional Documentation
Chapter 2 Configuring the Cisco TrustSec Solution
Cisco TrustSec Configuration Guide
2-6
OL-22192-01
Page 37
CHAP T ER
3
Configuring Identities, Connections, and SGTs
Revised: October 7, 2013, OL-22192-02
This section includes the following topics:
• Cisco TrustSec Identity Configuration Feature Histories, page 3-1
• Configuring Credentials and AAA for a Cisco TrustSec Seed Device, page 3-2
• Configuring Credentials and AAA for a Cisco TrustSec Non-Seed Device, page 3-3
• Enabling Cisco TrustSec Authentication and MACsec in 802.1X Mode on an Uplink Port, page 3-5
• Configuring Cisco TrustSec and MACsec in Manual Mode on an Uplink Port, page 3-6
• Regenerating SAP Key on an Interface, page 3-9
• Verifying the Cisco TrustSec Interface Configuration, page 3-9
• Manually Configuring a Device SGT, page 3-11
• Manually Configuring IP-Address-to-SGT Mapping, page 3-12
• Manually Configuring a Device SGT, page 3-11
• Configuring Additional Authentication Server-Related Parameters, page 3-23
• Automatically Configuring a New or Replacement Password with the Authentication Server,
page 3-24
Cisco TrustSec Identity Configuration Feature Histories
For a list of supported TrustSec features per platform and the minimum required IOS release, see
the Cisco TrustSec Platform Support Matrix at the following URL:
http://www.cisco.com/en/US/solutions/ns170/ns896/ns1051/trustsec_matrix.html
Otherwise, see product release notes for detailed feature introduction information.
OL-22192-02
Cisco TrustSec Configuration Guide
3-1
Page 38
Chapter 3 Configuring Identities, Connections, and SGTs
Configuring Credentials and AAA for a Cisco TrustSec Seed Device
Configuring Credentials and AAA for a Cisco TrustSec Seed
Device
A Cisco TrustSec-capable device that is directly connected to the authentication server, or indirectly
connected but is the first device to begin the TrustSec domain, is called the seed device. Other Cisco
TrustSec network devices are non-seed devices.
To enable NDAC and AAA on the seed switch so that it can begin the Cisco TrustSec domain, perform
these steps:
Detailed Steps for Catalyst 6500, Catalyst 3K
Command Purpose
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
Step 10
Step 11
Router# cts credentials id device-id
password password
Router# configure terminal
Router(config)# aaa new-model
Router(config)# aaa authentication dot1x
default group radius
Router(config)# aaa authorization
network mlist group radius
Router(config)# cts authorization list
mlist
Router(config)# aaa accounting dot1x
default start-stop group radius
Router(config)# radius-server host
ip-addr auth-port 1812 acct-port 1813
pac key secret
Router(config)# radius-server vsa send
authentication
Router(config)# dot1x
system-auth-control
Router(config)# exit
Specifies the Cisco TrustSec device ID and password
for this switch to use when authenticating with other
Cisco TrustSec devices with EAP-FAST. The
device-id argument has a maximum length of 32
characters and is case sensitive.
Enters global configuration mode.
Enables AAA.
Specifies the 802.1X port-based authentication
method as RADIUS.
Configures the switch to use RADIUS authorization
for all network-related service requests.
• mlist—The Cisco TrustSec AAA server group.
Specifies a Cisco TrustSec AAA server group.
Non-seed devices will obtain the server list from the
authenticator.
Enables 802.1X accounting using RADIUS.
Specifies the RADIUS authentication server host
address, service ports, and encryption key.
• ip-addr—The IP address of the authentication
server.
• secret—The encryption key shared with the
authentication server.
Configures the switch to recognize and use
vendor-specific attributes (VSAs) in RADIUS
Access-Requests generated by the switch during the
authentication phase.
Globally enables 802.1X port-based authentication.
Exits configuration mode.
Cisco TrustSec Configuration Guide
3-2
OL-22192-02
Page 39
Chapter 3 Configuring Identities, Connections, and SGTs
Note You must also configure the Cisco TrustSec credentials for the switch on the Cisco Identity Services
Engine (Cisco ISE) or the Cisco Secure Access Control Server (Cisco ACS).
Configuration Examples for Seed Device
Catalyst 6500 configured as a Cisco TrustSec seed device:
Router# cts credentials id Switch1 password Cisco123
Router# configure terminal
Router(config)# aaa new-model
Router(config)# aaa authentication dot1x default group radius
Router(config)# aaa authorization network MLIST group radius
Router(config)# cts authorization list MLIST
Router(config)# aaa accounting dot1x default start-stop group radius
Router(config)# radius-server host 10.20.3.1 auth-port 1812 acct-port 1813 pac key AbCe1234
Router(config)# radius-server vsa send authentication
Router(config)# dot1x system-auth-control
Router(config)# exit
Configuring Credentials and AAA for a Cisco TrustSec Non-Seed Device
Configuring Credentials and AAA for a Cisco TrustSec Non-Seed
Device
To enable NDAC and AAA on a non-seed switch so that it can join the Cisco TrustSec domain, perform
these steps:
Detailed Steps for Catalyst 6500
Command Purpose
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Router# cts credentials id device-id
password password
Router# configure terminal
Router(config)# aaa new-model
Router(config)# aaa authentication dot1x
default group radius
Router(config)# aaa authorization
network mlist group radius
Router(config)# aaa accounting dot1x
default start-stop group radius
Specifies the Cisco TrustSec device ID and password
for this switch to use when authenticating with other
Cisco TrustSec devices with EAP-FAST. The
device-id argument has a maximum length of 32
characters and is case sensitive.
Enters global configuration mode.
Enables AAA.
Specifies the 802.1X port-based authentication
method as RADIUS.
Configures the switch to use RADIUS authorization
for all network-related service requests.
• mlist—Specifies a Cisco TrustSec AAA server
group.
Enables 802.1X accounting using RADIUS.
OL-22192-02
Cisco TrustSec Configuration Guide
3-3
Page 40
Configuring Credentials and AAA for a Cisco TrustSec Non-Seed Device
Command Purpose
Step 7
Router(config)# radius-server vsa send
authentication
Configures the switch to recognize and use
vendor-specific attributes (VSAs) in RADIUS
Access-Requests generated by the switch during the
authentication phase.
Step 8
Step 9
Note You must also configure the Cisco TrustSec credentials for the switch on the Cisco Identity Services
Router(config)# dot1x
system-auth-control
Router(config)# exit
Globally enables 802.1X port-based authentication.
Exits configuration mode.
Engine, or the Cisco Secure ACS.
Configuration Examples for Non-Seed Device
Catalyst 6500 example:
Router# cts credentials id Switch2 password Cisco123
Router# configure terminal
Router(config)# aaa new-model
Router(config)# aaa authentication dot1x default group radius
Router(config)# aaa authorization network MLIST group radius
Router(config)# aaa accounting dot1x default start-stop group radius
Router(config)# radius-server vsa send authentication
Router(config)# dot1x system-auth-control
Router(config)# exit
Chapter 3 Configuring Identities, Connections, and SGTs
Catalyst 3850/3650 example for access VLAN, where propagate SGT is not the default:
switch(config-if)# switchport access vlan 222
switch(config-if)# switchport mode access
switch(config-if)# authentication port-control auto
switch(config-if)# dot1x pae authenticator
switch(config-if)# cts dot1x
switch(config-if)# propagate sgt
Cisco TrustSec Configuration Guide
3-4
OL-22192-02
Page 41
Chapter 3 Configuring Identities, Connections, and SGTs
Enabling Cisco TrustSec Authentication and MACsec in 802.1X Mode on an Uplink Port
Enabling Cisco TrustSec Authentication and MACsec in 802.1X
Mode on an Uplink Port
You must enable Cisco TrustSec authentication on each interface that will connect to another Cisco
TrustSec device. To configure Cisco TrustSec authentication with 802.1X on an uplink interface to
another Cisco TrustSec device, perform this task:
Detailed Steps for Catalyst 6500
Command Purpose
Step 1
Step 2
Step 3
Step 4
Router# configure terminal
Router(config)# interface type slot/port
Router(config-if)# cts dot1x
Router(config-if-cts-dot1x)# [no] sap
mode-list mode1 [mode2 [mode3 [mode4]]]
Enters global configuration mode.
Enters interface configuration mode for the uplink
interface.
Configures the uplink interface to perform NDAC
authentication.
(Optional) Configures 802.1AE MACsec with the SAP
operation mode on the interface. The interface will
negotiate with the peer for a mutually-acceptable
mode. List the acceptable modes in your order of
preference. Choices for mode are:
• gcm— Authentication and encryption
• gmac— Authentication, no encryption
Step 5
Step 6
Step 7
Step 8
Router(config-if-cts-dot1x)# [no] timer
reauthentication seconds
Router(config-if-cts-dot1x)# [no]
propagate sgt
Router(config-if-cts-dot1x)# exit
Router(config-if)# shutdown
• no-encap— No encapsulation
• null— Encapsulation, no authentication,
no encryption
Note MACsec with SAP is not supported on the
Catalyst 3K switches.
Note If the interface is not capable of SGT insertion
or data link encryption, no-encap is the default
and the only available SAP operating mode.
(Optional) Configures a reauthentication period to be
used if the authentication server does not specify a
period. If no reauthentication period is specified, the
default period is 86400 seconds.
(Optional) The no form of this command is used when
the peer is incapable of processing an SGT. The no
propagate sgt command prevents the interface from
transmitting the SGT to the peer.
Exits Cisco TrustSec 802.1X interface configuration
mode.
Disables the interface.
OL-22192-02
Cisco TrustSec Configuration Guide
3-5
Page 42
Configuring Cisco TrustSec and MACsec in Manual Mode on an Uplink Port
Command Purpose
Step 9
Router(config-if)# no shutdown
Enables the interface and enables Cisco TrustSec
authentication on the interface.
Step 10
Router(config-if)# exit
Exits interface configuration mode.
Configuration Examples for 802.1X on Uplink Port
Catalyst 6500 Cisco TrustSec authentication in 802.1X mode on an interface using GCM as the preferred
SAP mode; the authentication server did not provide a reauthentication timer:
Router# configure terminal
Router(config)# interface gi2/1
Router(config-if)# cts dot1x
Router(config-if-cts-dot1x)# sap mode-list gcm null no-encap
Router(config-if-cts-dot1x)# timer reauthentication 43200
Router(config-if-cts-dot1x)# propagate sgt
Router(config-if-cts-dot1x)# exit
Router(config-if)# shutdown
Router(config-if)# no shutdown
Router(config-if)# exit
Router(config)# exit
Chapter 3 Configuring Identities, Connections, and SGTs
Configuring Cisco TrustSec and MACsec in Manual Mode on an
Uplink Port
You can manually configure Cisco TrustSec on an interface. You must manually configure the interfaces
on both ends of the connection. No authentication occurs; policies can be statically configured or
dynamically downloaded from an authentication server by specifying the server’s device identity.
Detailed Steps for Catalyst 6500
Command Purpose
Step 1
Step 2
Step 3
Router# configure terminal
Router(config)# interface type slot/port
Router(config-if)# cts manual
Enters global configuration mode.
Enters interface configuration mode for the uplink
interface.
Enters Cisco TrustSec manual configuration mode.
Cisco TrustSec Configuration Guide
3-6
OL-22192-02
Page 43
Chapter 3 Configuring Identities, Connections, and SGTs
Command Purpose
Step 4
Router(config-if-cts-manual)# [no] sap pmk
key [mode-list mode1 [mode2 [mode3
[mode4]]]]
Configuring Cisco TrustSec and MACsec in Manual Mode on an Uplink Port
(Optional) Configures the SAP pairwise master key
(PMK) and operation mode. SAP is disabled by
default in Cisco TrustSec manual mode.
• key—A hexadecimal value with an even number
of characters and a maximum length of 32
characters.
The SAP operation mode options are:
• gcm— Authentication and encryption
• gmac— Authentication, no encryption
• no-encap— No encapsulation
• null— Encapsulation, no authentication or
encryption
Note MACsec with SAP is not supported on the
Catalyst 3K switches.
Step 5
Step 6
Step 7
Step 8
Router(config-if-cts-manual)# [no] policy
dynamic identity peer-name
Router(config-if-cts-manual)# [no] policy
static sgt tag [trusted]
Router(config-if-cts-manual)# [no]
propagate sgt
Router(config-if-cts-manual)# exit
Router(config-if)# shutdown
Note If the interface is not capable of SGT
insertion or data link encryption, no-encap
is the default and the only available SAP
operating mode.
(Optional) Configures Identity Port Mapping (IPM)
to allow dynamic authorization policy download
from authorization server based on the identity of
the peer. See the additional usage notes following
this task.
• peer-name—The Cisco TrustSec device ID for
the peer device. The peer name is case sensitive.
Note Ensure that you have configured the Cisco
TrustSec credentials (see “Configuring
Credentials and AAA for a Cisco TrustSec
Seed Device” section on page 3-2).
(Optional) Configures a static authorization policy.
See the additional usage notes following this task.
• tag—The SGT in decimal format. The range is
1 to 65533.
• trusted—Indicates that ingress traffic on the
interface with this SGT should not have its tag
overwritten.
(Optional) The no form of this command is used
when the peer is incapable of processing an SGT.
The no propagate sgt command prevents the
interface from transmitting the SGT to the peer.
Exits Cisco TrustSec manual interface configuration
mode.
Disables the interface.
OL-22192-02
Cisco TrustSec Configuration Guide
3-7
Page 44
Configuring Cisco TrustSec and MACsec in Manual Mode on an Uplink Port
Command Purpose
Step 9
Step 10
Router(config-if)# no shutdown
Router(config-if)# exit
Identity Port Mapping (IPM) configures a physical port such that a single SGT is imposed on all traffic
entering the port; this SGT is applied on all IP traffic exiting the port until a new binding is learned. IPM
is configured as follows:
• CTS Manual interface configuration mode with the policy static sgt tag command
• CTS Manual interface configuration mode with the policy dynamic identity peer-name command
where peer-name is designated as non-trusted in the Cisco ACS or Cisco ISE configuration.
IPM is supported for the following ports:
• Routed ports
• Switchports in access mode
• Switchports in trunk mode
When manually configuring Cisco TrustSec on an interface, consider these usage guidelines and
restrictions:
• If no SAP parameters are defined, no Cisco TrustSec encapsulation or encryption will be performed.
Chapter 3 Configuring Identities, Connections, and SGTs
Enables the interface and enables Cisco TrustSec
authentication on the interface.
Exits interface configuration mode.
• If the selected SAP mode allows SGT insertion and an incoming packet carries no SGT, the tagging
policy is as follows:
–
If the policy static command is configured, the packet is tagged with the SGT configured in the
policy static command.
–
If the policy dynamic command is configured, the packet is not tagged.
• If the selected SAP mode allows SGT insertion and an incoming packet carries an SGT, the tagging
policy is as follows:
–
If the policy static command is configured without the trusted keyword, the SGT is replaced
with the SGT configured in the policy static command.
–
If the policy static command is configured with the trusted keyword, no change is made to the
SGT.
–
If the policy dynamic command is configured and the authorization policy downloaded from
the authentication server indicates that the packet source is untrusted, the SGT is replaced with
the SGT specified by the downloaded policy.
–
If the policy dynamic command is configured and the downloaded policy indicates that the
packet source is trusted, no change is made to the SGT.
Configuration Examples for Manual Mode and MACsec on an Uplink Port
Catalyst 6500 TrustSec interface configuration in manual mode:
Router# configure terminal
Router(config)# interface gi 2/1
Router(config-if)# cts manual
Router(config-if-cts-manual)# sap pmk 1234abcdef mode-list gcm null no-encap
Router(config-if-cts-manual)# policy static sgt 111
Router(config-if-cts-manual)# exit
Cisco TrustSec Configuration Guide
3-8
OL-22192-02
Page 45
Chapter 3 Configuring Identities, Connections, and SGTs
Router(config-if)# shutdown
Router(config-if)# no shutdown
Router(config-if)# end
Catalyst 3850 TrustSec interface configuration in manual mode:
Switch# configure terminal
Switch(config)# interface gig 1/0/5
Switch(config-if)# cts manual
Switch(config-if-cts-manual)# policy dynamic identity my_cisco_ise_id
Switch(config-if-cts-manual)# exit
Switch(config-if)# shutdown
Switch(config-if)# no shutdown
Router(config-if)# end
Regenerating SAP Key on an Interface
The ability to manually refresh encryption keys is often part of network administration security
requirements. SAP key refresh ordinarily occurs automatically, triggered by combinations of network
events and non-configurable internal timers.
Regenerating SAP Key on an Interface
Detailed Steps for Catalyst 6500, Catalyst 3850/3650
Command Purpose
Step 1
cts rekey interface interface_type
slot/port
Example:
c6500switch# cts rekey int gig 1/1
Forces renegotiation of SAP keys on MACsec link.
Verifying the Cisco TrustSec Interface Configuration
To view the TrustSec-relate interface configuration, perform this task:
Detailed Steps for Catalyst 6500
Command Purpose
Step 1
show cts interface [interface_type
slot/port | brief | summary]
Example:
c6500switch# show cts interface brief
Displays TrustSec-related interface configuration.
Example: Show Cisco 6500 TrustSec interface configuration:
Router# show cts interface interface gi3/3
Global Dot1x feature is Enabled
Interface GigabitEthernet3/3:
CTS is enabled, mode: DOT1X
IFC state: OPEN
Authentication Status: SUCCEEDED
OL-22192-02
Cisco TrustSec Configuration Guide
3-9
Page 46
Verifying the Cisco TrustSec Interface Configuration
Peer identity: "sanjose"
Peer's advertised capabilities: ""
802.1X role: Supplicant
Reauth period applied to link: Not applicable to Supplicant role
Authorization Status: SUCCEEDED
Peer SGT: 11
Peer SGT assignment: Trusted
SAP Status: NOT APPLICABLE
Configured pairwise ciphers:
gcm-encrypt
null
Replay protection: enabled
Replay protection mode: OUT-OF-ORDER
Selected cipher:
Cache Info:
Expiration : 23:32:40 PDT Jun 22 2009
Cache applied to link : NONE
Expiration : 23:32:40 PDT Jun 22 2009
Statistics:
authc success: 1
authc reject: 0
authc failure: 0
authc no response: 0
authc logoff: 0
sap success: 0
sap fail: 0
authz success: 1
authz fail: 0
port auth fail: 0
Chapter 3 Configuring Identities, Connections, and SGTs
Dot1x Info for GigabitEthernet3/1
----------------------------------PAE = SUPPLICANT
StartPeriod = 30
AuthPeriod = 30
HeldPeriod = 60
MaxStart = 3
Credentials profile = CTS-ID-profile
EAP profile = CTS-EAP-profile
Dot1x Info for GigabitEthernet3/1
----------------------------------PAE = AUTHENTICATOR
PortControl = FORCE_AUTHORIZED
ControlDirection = Both
HostMode = SINGLE_HOST
QuietPeriod = 60
ServerTimeout = 0
SuppTimeout = 55
ReAuthMax = 2
MaxReq = 2
TxPeriod = 30
Example: Cisco 3850 TrustSec interface query:
Edison24U> show cts interface gig 1/0/6
Global Dot1x feature is Disabled
Interface GigabitEthernet1/0/6:
CTS is enabled, mode: MANUAL
IFC state: INIT
Authentication Status: NOT APPLICABLE
Cisco TrustSec Configuration Guide
3-10
OL-22192-02
Page 47
Chapter 3 Configuring Identities, Connections, and SGTs
Peer identity: "unknown"
Peer's advertised capabilities: ""
Authorization Status: NOT APPLICABLE
SAP Status: NOT APPLICABLE
Propagate SGT: Enabled
Cache Info:
Expiration : N/A
Cache applied to link : NONE
Statistics:
authc success: 0
authc reject: 0
authc failure: 0
authc no response: 0
authc logoff: 0
sap success: 0
sap fail: 0
authz success: 0
authz fail: 0
port auth fail: 0
L3 IPM: disabled.
Manually Configuring a Device SGT
Manually Configuring a Device SGT
In normal Cisco TrustSec operation, the authentication server assigns an SGT to the device for packets
originating from the device. You can manually configure an SGT to be used if the authentication server
is not accessible, but an authentication server-assigned SGT will take precedence over a
manually-assigned SGT.
To manually configure an SGT on the device, perform this task:
Detailed Steps for Catalyst 6500, 3850, 3750-X
Command Purpose
Step 1
Step 2
Step 3
Configuration Examples for Manually Configuring a Device SGT
Switch# configure terminal
Switch(config)# cts sgt tag
Enters global configuration mode.
Configures the SGT for packets sent from the device.
The tag argument is in decimal format. The range is 1
to 65533.
Switch(config)# exit
Exits configuration mode.
Catalyst 6500, Catalyst 3850, and Catalyst 3750-X:
Switch# configure terminal
Switch(config)# cts sgt 1234
Switch(config)# exit
OL-22192-02
Cisco TrustSec Configuration Guide
3-11
Page 48
Chapter 3 Configuring Identities, Connections, and SGTs
Manually Configuring IP-Address-to-SGT Mapping
Manually Configuring IP-Address-to-SGT Mapping
This section discusses SGTs to source IP address mapping as follows:
• Subnet to SGT Mapping, page 3-12
• VLAN to SGT Mapping, page 3-16
• Layer 3 Logical Interface to SGT Mapping (L3IF–SGT Mapping), page 3-20
For Identity Port Mapping in cts interface manual mode, see the following section:
• Configuring Cisco TrustSec and MACsec in Manual Mode on an Uplink Port, page 3-6
Subnet to SGT Mapping
Subnet to SGT mapping binds an SGT to all host addresses of a specified subnet. TrustSec imposes the
SGT on an incoming packet when the packet’s source IP address belongs to the specified subnet. The
subnet and SGT are specified in the CLI with the cts role-based sgt-map net_address/prefix sgt
sgt_number global configuration command. A single host may also be mapped with this command.
In IPv4 networks, SXPv3, and more recent versions, can receive and parse subnet net_address/prefix
strings from SXPv3 peers. Earlier SXP versions convert the subnet prefix into its set of host bindings
before exporting them to an SXP listener peer.
For example, the IPv4 subnet 198.1.1.0/29 is expanded as follows (only 3 bits for host addresses):
• Host addresses 198.1.1.1 to 198.1.1.7–tagged and propagated to SXP peer.
• Network and broadcast addresses 198.1.1.0 and 198.1.1.8— not tagged and not propagated.
To limit the number of subnet bindings SXPv3 can export, use the cts sxp mapping network-map global
configuration command.
Subnet bindings are static, there is no learning of active hosts. They can be used locally for SGT
imposition and SGACL enforcement. Packets tagged by subnet to SGT mapping can be propagated on
Layer 2 or Layer 3 TrustSec links.
For IPv6 networks, SXPv3 cannot export subnet bindings to SXPv2 or SXPv1 peers.
Default Settings
There are no default settings for this feature.
Configuring Subnet to SGT Mapping
This section includes the following topics:
• Verifying Subnet to SGT Mapping Configuration, page 3-15
• Configuring Subnet to SGT Mapping, page 3-12
Cisco TrustSec Configuration Guide
3-12
OL-22192-02
Page 49
Chapter 3 Configuring Identities, Connections, and SGTs
Restrictions
• An IPv4 subnetwork with a /31 prefix cannot be expanded.
• Subnet host addresses cannot be bound to SGTs when the network-map bindings parameter is less
than the total number of subnet hosts in the specified subnets, or when bindings is 0.
• IPv6 expansions and propagation only occurs when SXP speaker and listener are running SXPv3,
or more recent versions.
Detailed Steps for Catalyst 6500
Command Purpose
Step 1
Step 2
Step 3
config t
Example:
switch# config t
switch(config)#
[no] cts sxp mapping network-map bindings
Example:
switch(config)# cts sxp mapping network-map 10000
[no] cts role-based sgt-map
ipv4_address/prefix sgt number
Example:
switch(config)# cts role-based sgt-map
10.10.10.10/29 sgt 1234
Manually Configuring IP-Address-to-SGT Mapping
Enters global configuration mode.
Configures the Subnet to SGT Mapping host count
constraint. The bindings argument specifies the
maximum number of subnet IP hosts that can be
bound to SGTs and exported to the SXP listener.
• bindings—(0 to 65,535)
default is 0 (no expansions performed)
(IPv4) Specifies a subnet in CIDR notation. Use the
[no] form of the command to unconfigure the Subnet
to SGT mapping. The number of bindings specified
in Step 2 should match or exceed the number of host
addresses in the subnet (excluding network and
broadcast addresses). The sgt number keyword
specifies the Security Group Tag to be bound to
every host address in the specified subnet.
• ipv4_address—Specifies the IPv4 network
address in dotted decimal notation.
• prefix—(0 to 30). Specifies the number of bits in
the network address.
• sgt number (0–65,535). Specifies the Security
Group Tag (SGT) number.
OL-22192-02
Cisco TrustSec Configuration Guide
3-13
Page 50
Manually Configuring IP-Address-to-SGT Mapping
Command Purpose
Step 4
Step 5
[no] cts role-based sgt-map
ipv6_address::prefix sgt number
Example:
switch(config)# cts role-based sgt-map
2020::/64 sgt 1234
exit
Chapter 3 Configuring Identities, Connections, and SGTs
(IPv6) Specifies a subnet in colon hexadecimal
notation. Use the [no] form of the command to
unconfigure the Subnet to SGT mapping.
The number of bindings specified in Step 2 should
match or exceed the number of host addresses in the
subnet (excluding network and broadcast
addresses). The sgt number keyword specifies the
Security Group Tag to be bound to every host
address in the specified subnet.
• ipv6_address—Specifies IPv6 network address
in colon hexadecimal notation.
• prefix—(0 to128). Specifies the number of bits
in the network address.
• sgt number—(0 to 65,535). Specifies the
Security Group Tag (SGT) number.
Exits global configuration mode.
Step 6
Step 7
Example:
switch(config)# exit
switch#
s
how running-config | include search_string
Example:
switch# show running-config | include sgt 1234
switch# show running-config | include network-map
copy running-config startup-config
Example:
switch# copy running-config startup-config
Verifies that the cts role-based sgt-map and the
cts sxp mapping network-map commands are in
the running configuration.
Copies the running configuration to the startup
configuration.
Cisco TrustSec Configuration Guide
3-14
OL-22192-02
Page 51
Chapter 3 Configuring Identities, Connections, and SGTs
Verifying Subnet to SGT Mapping Configuration
To display Subnet to SGT Mapping configuration information, perform one of the following tasks:
Command Purpose
show cts sxp connections Displays the SXP speaker and listener
show cts sxp sgt-map Displays the IP to SGT bindings exported to the
show running-config Verifies that the Subnet to SGT configurations
For detailed information about the fields in the output from these commands, refer to Chapter 7, “Cisco
TrustSec Command Summary.”
Configuration Examples for Subnet to SGT Mapping
Manually Configuring IP-Address-to-SGT Mapping
connections with their operational status.
SXP listeners.
commands are in the running configuration file.
The following example shows how to configure IPv4 Subnet to SGT Mapping between two
Catalyst 6500 series switches running SXPv3 (Switch1 and Switch2):
Step 1 Configure SXP speaker/listener peering between Switch1 (1.1.1.1) and Switch 2 (2.2.2.2).
Switch1# config t
Switch1(config)# cts sxp enable
Switch1(config)# cts sxp default source-ip 1.1.1.1
Switch1(config)# cts sxp default password 1syzygy1
Switch1(config)# cts sxp connection peer 2.2.2.2 password default mode local speaker
Step 2 Configure Switch 2 as SXP listener of Switch1.
Switch2(config)# cts sxp enable
Switch2(config)# cts sxp default source-ip 2.2.2.2
Switch2(config)# cts sxp default password 1syzygy1
Switch2(config)# cts sxp connection peer 1.1.1.1 password default mode local listener
Step 3 On Switch2, verify that the SXP connection is operating:
Switch2# show cts sxp connections brief | include 1.1.1.1
1.1.1.1 2.2.2.2 On 3:22:23:18 (dd:hr:mm:sec)
Step 4 Configure the subnetworks to be expanded on Switch1.
Switch1(config)# cts sxp mapping network-map 10000
Switch1(config)# cts role-based sgt-map 10.10.10.0/30 sgt 101
Switch1(config)# cts role-based sgt-map 11.11.11.0/29 sgt 11111
Switch1(config)# cts role-based sgt-map 192.168.1.0/28 sgt 65000
Step 5 On Switch2, verify the subnet to SGT expansion from Switch1. There should be two expansions for the
10.10.10.0/30 subnetwork, six expansions for the 11.11.11.0/29 subnetwork, and 14 expansions for the
192.168.1.0/28 subnetwork.
Switch2# show cts sxp sgt-map brief | include 101|11111|65000
IPv4,SGT: <10.10.10.1 , 101>
IPv4,SGT: <10.10.10.2 , 101>
IPv4,SGT: <11.11.11.1 , 11111>
IPv4,SGT: <11.11.11.2 , 11111>
OL-22192-02
Cisco TrustSec Configuration Guide
3-15
Page 52
Manually Configuring IP-Address-to-SGT Mapping
IPv4,SGT: <11.11.11.3 , 11111>
IPv4,SGT: <11.11.11.4 , 11111>
IPv4,SGT: <11.11.11.5 , 11111>
IPv4,SGT: <11.11.11.6 , 11111>
IPv4,SGT: <192.168.1.1 , 65000>
IPv4,SGT: <192.168.1.2 , 65000>
IPv4,SGT: <192.168.1.3 , 65000>
IPv4,SGT: <192.168.1.4 , 65000>
IPv4,SGT: <192.168.1.5 , 65000>
IPv4,SGT: <192.168.1.6 , 65000>
IPv4,SGT: <192.168.1.7 , 65000>
IPv4,SGT: <192.168.1.8 , 65000>
IPv4,SGT: <192.168.1.9 , 65000>
IPv4,SGT: <192.168.1.10 , 65000>
IPv4,SGT: <192.168.1.11 , 65000>
IPv4,SGT: <192.168.1.12 , 65000>
IPv4,SGT: <192.168.1.13 , 65000>
IPv4,SGT: <192.168.1.14 , 65000>
Step 6 Verify the expansion count on Switch1:
Switch1# show cts sxp sgt-map
IP-SGT Mappings expanded:22
There are no IP-SGT Mappings
Chapter 3 Configuring Identities, Connections, and SGTs
Step 7 Save the configurations on Switch 1 and Switch 2 and exit global configuration mode.
Switch1(config)# copy running-config startup-config
Switch1(config)# exit
Switch2(config)# copy running-config startup-config
Switch2(config)# exit
VLAN to SGT Mapping
The VLAN to SGT mapping feature binds an SGT to packets from a specified VLAN. This simplifies
the migration from legacy to TrustSec-capable networks as follows:
• Supports devices that are not TrustSec-capable but are VLAN-capable, such as, legacy switches,
wireless controllers, access points, VPNs, etc.
• Provides backward compatibility for topologies where VLANs and VLAN ACLs segment the
network, such as, server segmentation in data centers.
The VLAN to SGT binding is configured with the cts role-based sgt-map vlan-list global configuration
command.
When a VLAN is assigned a gateway that is a switched virtual interface (SVI) on a TrustSec-capable
switch, and IP Device Tracking is enabled on that switch, then TrustSec can create an IP to SGT binding
for any active host on that VLAN mapped to the SVI subnet.
IP-SGT bindings for the active VLAN hosts are exported to SXP listeners. The bindings for each mapped
VLAN are inserted into the IP-to-SGT table associated with the VRF the VLAN is mapped to by either
its SVI or by a cts role-based l2-vrf cts global configuration command.
VLAN to SGT bindings have the lowest priority of all binding methods and are ignored when bindings
from other sources are received, such as from SXP or CLI host configurations. Binding priorities are
listing in the “Binding Source Priorities” section on page 3-22.
Cisco TrustSec Configuration Guide
3-16
OL-22192-02
Page 53
Chapter 3 Configuring Identities, Connections, and SGTs
Default Settings
There are no default settings.
Configuring VLAN to SGT Mapping
This section includes the following topics:
• Task Flow for Configuring VLAN-SGT Mapping, page 3-17
Task Flow for Configuring VLAN-SGT Mapping
• Create a VLAN on the TrustSec switch with the same VLAN_ID of the incoming VLAN.
• Create an SVI for the VLAN on the TrustSec switch to be the default gateway for the endpoint
clients.
• Configure the TrustSec switch to apply an SGT to the VLAN traffic.
• Enable IP Device tracking on the TrustSec switch.
• Verify that VLAN to SGT mapping occurs on the TrustSec switch.
Manually Configuring IP-Address-to-SGT Mapping
Detailed Steps for Catalyst 6500
Command Purpose
Step 1
Step 2
Step 3
Step 4
Step 5
config t
Example:
TS_switchswitch# config t
TS_switchswitch(config)#
vlan vlan_id
Example:
TS_switch(config)# vlan 100
TS_switch(config-vlan)#
[no] shutdown
Example:
TS_switch(config-vlan)# no shutdown
exit
Example:
TS_switch(config-vlan)# exit
TS_switch(config)#
interface type slot/port
Enters global configuration mode.
Creates VLAN 100 on the TrustSec-capable
gateway switch and enters VLAN configuration
submode.
Provisions VLAN 100.
Exits VLAN configuration mode into Global
Configuration mode.
Enters interface configuration mode.
Example:
TS_switch(config)# interface vlan 100
TS_switch(config-if)#
Step 6
OL-22192-02
ip address slot/port
Example:
TS_switch(config-if)# ip address 10.1.1.2 255.0.0.0
Configures Switched Virtual Interface (SVI) for
VLAN 100.
Cisco TrustSec Configuration Guide
3-17
Page 54
Manually Configuring IP-Address-to-SGT Mapping
Command Purpose
Step 7
Step 8
Step 9
Step 10
[no] shutdown
Example:
TS_switch(config-if)# no shutdown
exit
Example:
TS_switch(config-if)# exit
TS_switch(config)#
cts role-based sgt-map vlan-list vlan_id
sgt sgt_number
Example:
TS_switch(config)# cts role-based sgt-map
vlan-list 100 sgt 10
ip device tracking probe [count count |
delay seconds | interval length]
Chapter 3 Configuring Identities, Connections, and SGTs
Enables the SVI.
Exits VLAN Interface Configuration mode into
Global Configuration mode.
Assigns the specified SGT to the specified VLAN.
Enables IP device tracking. When active hosts are
detected, the switch adds the following entries to an
IP Device Tracking table:
• IP address of host
Step 11
Step 12
Example:
TS-switch(config)# ip device tracking
exit
Example:
TS_switch(config)# exit
TS_switch#
show cts role-based sgt-map {ipv4_netaddr
| ipv4_netaddr/prefix | ipv6_netaddr|
ipv6_netaddr/prefix | all [ipv4 | ipv6] |
host {ipv4__addr | ipv6_addr} | summary
[ipv4 | ipv6]
Example:
TS_switch# cts role-based sgt-map all
• MAC address of host
• VLAN of the host
• The interface on which the switch detected the
host
• The state of the host (Active or Inactive)
The host added to the IP Device Tracking table is
monitored with periodic ARP probes. Hosts that fail
to respond are removed from the table.
Exits Global configuration mode.
(Optional) Displays the VLAN to SGT mappings.
Cisco TrustSec Configuration Guide
3-18
OL-22192-02
Page 55
Chapter 3 Configuring Identities, Connections, and SGTs
Command Purpose
Step 13
Step 14
show ip device tracking {all|interface|ip|mac}
Example:
TS_switch# show ip device tracking all
copy running-config startup-config
Example:
TS_switch# copy running-config
startup-config
Verifying VLAN to SGT Mapping
To display VLAN to SGT configuration information, use the following show commands:
Command Purpose
show ip device tracking Displays the status of IP Device Tracking which
show cts role-based sgt-map Displays IP address to SGT bindings.
Manually Configuring IP-Address-to-SGT Mapping
(Optional) Verifies the operational status of IP
Device tracking.
(Optional) Copies the running configuration to the
startup configuration.
identifies the IP addresses of active hosts on a
VLAN.
For detailed information about the fields in the output from these commands, refer to Chapter 7, “Cisco
TrustSec Command Summary,” or the “Cisco IOS 15.0SY Security and VPN Command Reference.”
Configuration Example for VLAN to SGT Mapping for a Single Host Over an Access Link
In the following example, a single host connects to VLAN 100 on an access switch. The access switch
has an access mode link to a Catalyst 6500 series TrustSec software-capable switch. A switched virtual
interface on the TrustSec switch is the default gateway for the VLAN 100 endpoint (IP Address
10.1.1.1). The TrustSec switch imposes Security Group Tag (SGT) 10 on packets from VLAN 100.
Step 1 Create VLAN 100 on an access switch.
access_switch# config t
access_switch(config)# vlan 100
access_switch(config-vlan)# no shutdown
access_switch(config-vlan)# exit
access_switch(config)#
Step 2 Configure the interface to the TrustSec switch as an access link. Configurations for the endpoint access
port are omitted in this example.
access_switch(config)# interface gigabitEthernet 6/3
access_switch(config-if)# switchport
access_switch(config-if)# switchport mode access
access_switch(config-if)# switchport access vlan 100
Step 3 Create VLAN 100 on the TrustSec switch.
TS_switch(config)# vlan 100
TS_switch(config-vlan)# no shutdown
TS_switch(config-vlan)# end
TS_switch#
OL-22192-02
Cisco TrustSec Configuration Guide
3-19
Page 56
Manually Configuring IP-Address-to-SGT Mapping
Step 4 Create an SVI as the gateway for incoming VLAN 100.
TS_switch(config)# interface vlan 100
TS_switch(config-if)# ip address 10.1.1.2 255.0.0.0
TS_switch(config-if)# no shutdown
TS_switch(config-if)# end
TS_switch(config)#
Step 5 Assign Security Group Tag (SGT) 10 to hosts on VLAN 100.
TS_switch(config)# cts role-based sgt-map vlan 100 sgt 10
Step 6 Enable IP Device Tracking on the TrustSec switch. Verify that it is operating.
TS_switch(config)# ip device tracking
TS_switch# show ip device tracking all
IP Device Tracking = Enabled
IP Device Tracking Probe Count = 3
IP Device Tracking Probe Interval = 100
-------------------------------------------------------------------- IP Address MAC Address Vlan Interface STATE
--------------------------------------------------------------------Total number interfaces enabled: 1
Vlan100
Chapter 3 Configuring Identities, Connections, and SGTs
Step 7 (Optional). PING the default gateway from an endpoint (in this example, host IP Address 10.1.1.1).
Verify that SGT 10 is being mapped to VLAN 100 hosts.
TS_switch# show cts role-based sgt-map all
Active IP-SGT Bindings Information
IP Address SGT Source
============================================
10.1.1.1 10 VLAN
IP-SGT Active Bindings Summary
============================================
Total number of VLAN bindings = 1
Total number of CLI bindings = 0
Total number of active bindings = 1
Layer 3 Logical Interface to SGT Mapping (L3IF–SGT Mapping)
L3IF-SGT mapping can directly map SGTs to traffic of any of the following Layer 3 interfaces
regardless of the underlying physical interface:
• Routed port
• SVI (VLAN interface)
• Layer3 subinterface of a Layer2 port
• Tunnel interface
Cisco TrustSec Configuration Guide
3-20
OL-22192-02
Page 57
Chapter 3 Configuring Identities, Connections, and SGTs
Use the cts role-based sgt-map interface global configuration command to specify either a specific
SGT number, or a Security Group Name (whose SGT association is dynamically acquired from a Cisco
ISE or a Cisco ACS access server).
In cases where Identity Port Mapping (cts interface manual sub mode configuration) and L3IF-SGT
require different IP to SGT bindings, IPM takes precedence. All other conflicts among IP to SGT binding
are resolved according to the priorities listing in the “Binding Source Priorities” section on page 3-22.
Feature History for L3IF-SGT Mapping
Default Settings
There are no default settings.
Configuring L3IF to SGT Mapping
Detailed steps Catalyst 6500
Manually Configuring IP-Address-to-SGT Mapping
Command Purpose
Step 1
Step 2
Step 3
Step 4
Router# configure terminal
Router(config)# cts role-based sgt-map
interface type slot/port [security-group
name | sgt number]
Router(config)# cts role-based sgt-map
interface gigabitEthernet 1/1 sgt 77
Router(config)# exit
Router# show cts role-based sgt-map all
Verifying L3IF to SGT Mapping
To display L3IF to SGT configuration information, use the following show commands:
Command Purpose
show cts role-based sgt-map all Displays all IP address to SGT bindings.
Enters global configuration mode.
An SGT is imposed on ingress traffic to the specified
interface.
• interface type slot/port—Displays list of
available interfaces.
• security-group name— Security Group name to
SGT pairings are configured on the Cisco ISE or
Cisco ACS.
• sgt number—(0 to 65,535). Specifies the Security
Group Tag (SGT) number.
Exits configuration mode.
Verify that ingressing traffic is tagged with the
specified SGT.
OL-22192-02
Cisco TrustSec Configuration Guide
3-21
Page 58
Chapter 3 Configuring Identities, Connections, and SGTs
Manually Configuring IP-Address-to-SGT Mapping
Configuration Example for L3IF to SGT Mapping on an Ingress Port
In the following example a Layer 3 interface of a Catalyst 6500 series switch linecard is configured to
tag all ingressing traffic with SGT 3. Prefixes of attached subnets are already known.
Step 1 Configure the interface.
Switch# config t
Switch
(config)# interface gigabitEthernet 6/3 sgt 3
Switch(config)# exit
Step 2 Verify that the ingressing traffic to the interface is tagged appropriately.
Router# show cts role-based sgt-map all
IP Address SGT Source
============================================
15.1.1.15 4 INTERNAL
17.1.1.0/24 3 L3IF
21.1.1.2 4 INTERNAL
31.1.1.0/24 3 L3IF
31.1.1.2 4 INTERNAL
43.1.1.0/24 3 L3IF
49.1.1.0/24 3 L3IF
50.1.1.0/24 3 L3IF
50.1.1.2 4 INTERNAL
51.1.1.1 4 INTERNAL
52.1.1.0/24 3 L3IF
81.1.1.1 5 CLI
102.1.1.1 4 INTERNAL
105.1.1.1 3 L3IF
111.1.1.1 4 INTERNAL
IP-SGT Active Bindings Summary
============================================
Total number of CLI bindings = 1
Total number of L3IF bindings = 7
Total number of INTERNAL bindings = 7
Total number of active bindings = 15
Binding Source Priorities
TrustSec resolves conflicts among IP-SGT binding sources with a strict priority scheme. For example,
an SGT may be applied to an interface with the policy {dynamic identity peer-name | static sgt tag}
CTS Manual interface mode command (Identity Port Mapping).
from lowest (1) to highest (7), is as follows:
1. VLAN—Bindings learned from snooped ARP packets on a VLAN that has VLAN-SGT mapping
configured.
2. CLI— Address bindings configured using the IP-SGT form of the cts role-based sgt-map global
configuration command.
3. Layer 3 Interface—(L3IF) Bindings added due to FIB forwarding entries that have paths through
one or more interfaces with consistent L3IF-SGT mapping or Identity Port Mapping on routed ports.
4. SXP—Bindings learned from SXP peers.
5. IP_ARP—Bindings learned when tagged ARP packets are received on a CTS capable link.
The current priority enforcement order,
Cisco TrustSec Configuration Guide
3-22
OL-22192-02
Page 59
Chapter 3 Configuring Identities, Connections, and SGTs
Configuring Additional Authentication Server-Related Parameters
6. LOCAL—Bindings of authenticated hosts which are learned via EPM and device tracking. This type
of binding also include individual hosts that are learned via ARP snooping on L2 [I]PM configured
ports.
7. INTERNAL—Bindings between locally configured IP addresses and the device own SGT.
Configuring Additional Authentication Server-Related
Parameters
To configure the interaction between a switch and the Cisco TrustSec server, perform one or more of
these tasks:
Detailed Steps for Catalyst 6500
Command Purpose
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Router# configure terminal
Router(config)# [no] cts server deadtime
seconds
Router(config)# [no] cts server
load-balance method least-outstanding
[batch-size transactions]
[ignore-preferred-server]
Router(config)# [no] cts server test
{server-IP-address | all} {deadtime
seconds | enable | idle-time seconds}
Router(config)# exit
Router# show cts server-list
Enters global configuration mode.
(Optional) Specifies how long a server in the group
should not be selected for service once it has been
marked as dead. The default is 20 seconds; the range
is 1 to 864000.
(Optional) Enables RADIUS load balancing for the
Cisco TrustSec private server group and chooses the
server with the least outstanding transactions. By
default, no load balancing is applied. The default
transactions is 25.
The ignore-preferred-server keyword instructs the
switch not to try to use the same server throughout a
session.
(Optional) Configures the server-liveliness test for a
specified server or for all servers on the dynamic
server list. By default, the test is enabled for all
servers. The default idle-time is 60 seconds; the range
is from 1 to 14400.
Exits configuration mode.
Displays status and configuration details of a list of
Cisco TrustSec servers.
This example shows how to configure server settings and how to display the Cisco TrustSec server list:
Router# configure terminal
Router(config)# cts server load-balance method least-outstanding batch-size 50
ignore-preferred-server
Router(config)# cts server test all deadtime 20
Router(config)# cts server test all enable
Router(config)# cts server test 10.15.20.102 idle-time 120
Router(config)# exit
Router# show cts server-list
CTS Server Radius Load Balance = ENABLED
Method = least-outstanding
OL-22192-02
Cisco TrustSec Configuration Guide
3-23
Page 60
Automatically Configuring a New or Replacement Password with the Authentication Server
Batch size = 50
Ignore preferred server
Server Group Deadtime = 20 secs (default)
Global Server Liveness Automated Test Deadtime = 20 secs
Global Server Liveness Automated Test Idle Time = 60 mins
Global Server Liveness Automated Test = ENABLED (default)
Preferred list, 1 server(s):
*Server: 10.15.20.102, port 1812, A-ID 87B3503255C4384485BB808DC24C6F55
Status = ALIVE
auto-test = TRUE, idle-time = 120 mins, deadtime = 20 secs
Installed list: SL1-1E6E6AE57D4E2A9B320D1844C68BA291, 3 server(s):
*Server: 10.15.20.102, port 1812, A-ID 87B3503255C4384485BB808DC24C6F55
Status = ALIVE
auto-test = TRUE, idle-time = 60 mins, deadtime = 20 secs
*Server: 10.15.20.101, port 1812, A-ID 255C438487B3503485BBC6F55808DC24
Status = ALIVE
auto-test = TRUE, idle-time = 60 mins, deadtime = 20 secs
Installed list: SL2-1E6E6AE57D4E2A9B320D1844C68BA293, 3 server(s):
*Server: 10.0.0.1, port 1812, A-ID 04758B1F05D8C1439F27F9509E07CFB6.
Status = ALIVE
auto-test = TRUE, idle-time = 60 mins, deadtime = 20 secs
*Server: 10.0.0.2, port 1812, A-ID 04758B1F05D8C1439F27F9509E07CFB6.
Status = DEAD
auto-test = TRUE, idle-time = 60 mins, deadtime = 20 secs
Chapter 3 Configuring Identities, Connections, and SGTs
Automatically Configuring a New or Replacement Password
with the Authentication Server
As an alternative to manually configuring the password between the switch and the authentication server,
you can initiate a password negotiation from the switch. To configure the password negotiation, perform
this task:
Detailed Steps for Catalyst 6500
Command Purpose
Step 1
Router# cts change-password server
ip-address port {key secret | a-id a-id}
Initiates a password negotiation between the switch
and the authentication server.
• ip-address—The IP address of the authentication
server.
• port—The UDP port of the authentication server.
• key secret—The RADIUS shared secret of the
authentication server.
• a-id a-id—The A-ID associated with the
authentication server.
Cisco TrustSec Configuration Guide
3-24
OL-22192-02
Page 61
CHAP T ER
4
Configuring SGT Exchange Protocol over TCP
(SXP) and Layer 3 Transport
Revised: May 28, 2010, OL-22192-01
You can use the SGT Exchange Protocol (SXP) to propagate the SGTs across network devices that do
not have hardware support for Cisco TrustSec. This section describes how to configure Cisco TrustSec
SXP on switches in your network.
This section includes the following topics:
• Cisco TrustSec SGT Exchange Protocol Feature Histories, page 4-1
• Configuring Cisco TrustSec SXP, page 4-2
• Configuring the Default SXP Password, page 4-4
• Configuring the Default SXP Source IP Address, page 4-4
• Changing the SXP Reconciliation Period, page 4-5
• Changing the SXP Retry Period, page 4-5
• Creating Syslogs to Capture Changes of IP Address to SGT Mapping Learned Through SXP,
page 4-5
• Verifying the SXP Connections, page 4-6
• Configuring Layer 3 SGT Transport Between Cisco TrustSec Domains, page 4-6
• Configuring Cisco TrustSec Reflector for Cisco TrustSec-Incapable Switching Modules, page 4-8
• Configuring Cisco TrustSec Caching, page 4-9
Cisco TrustSec SGT Exchange Protocol Feature Histories
For a list of supported TrustSec features per platform and the minimum required IOS release, see
the Cisco TrustSec Platform Support Matrix at the following URL: (final URL posted with TS 4.0)
http://www.cisco.com/en/US/solutions/ns170/ns896/ns1051/trustsec_matrix.html
Otherwise, see product release notes for detailed feature introduction information.
Cisco TrustSec Configuration Guide
OL-22192-01
4-1
Page 62
Chapter 4 Configuring SGT Exchange Protocol over TCP (SXP) and Layer 3 Transport
Configuring Cisco TrustSec SXP
Configuring Cisco TrustSec SXP
To configure Cisco TrustSec SXP, follow these steps:
Step 1 Enable the Cisco TrustSec feature (see the “Configuring Identities, Connections, and SGTs” chapter).
Step 2 Enable Cisco TrustSec SXP (see the “Enabling Cisco TrustSec SXP” section on page 4-2).
Step 3 Configure SXP peer connections (see the “Configuring an SXP Peer Connection” section on page 4-2).
Enabling Cisco TrustSec SXP
You must enable Cisco TrustSec SXP before you can configure peer connections. To enable Cisco
TrustSec SXP, perform this task:
Detailed Steps for Catalyst 6500
Command Purpose
Step 1
Step 2
Step 3
Router# configure terminal
Router(config)# [no] cts sxp enable
Router(config)# exit
Configuring an SXP Peer Connection
You must configure the SXP peer connection on both of the devices. One device is the speaker and the
other is the listener. When using password protection, make sure to use the same password on both ends.
Note If a default SXP source IP address is not configured and you do not configure an SXP source address in
the connection, the Cisco TrustSec software derives the SXP source IP address from existing local IP
addresses. The SXP source address might be different for each TCP connection initiated from the switch.
Enters global configuration mode.
Enables SXP for Cisco TrustSec.
Exits configuration mode.
Cisco TrustSec Configuration Guide
4-2
OL-22192-01
Page 63
Chapter 4 Configuring SGT Exchange Protocol over TCP (SXP) and Layer 3 Transport
To configure the SXP peer connection, perform this task:
Detailed Steps for Catalyst 6500
Command Purpose
Step 1
Step 2
Router# configure terminal
Router(config)# cts sxp connection
peer peer-ipv4-addr
[source src-ipv4-addr]
password {default | none] mode {local |
peer} {speaker | listener}
[vrf vrf-name]
Configuring Cisco TrustSec SXP
Enters global configuration mode.
Configures the SXP address connection.
The optional source keyword specifies the IPv4
address of the source device. If no address is specified,
the connection will use the default source address, if
configured, or the address of the port.
The password keyword specifies the password that
SXP will use for the connection using the following
options:
• default—Use the default SXP password you
configured using the cts sxp default password
command.
Step 3
Step 4
• none—Do not use a password.
The mode keyword specifies the role of the remote
peer device:
• local—The specified mode refers to the local
device.
• peer—The specified mode refers to the peer
device.
• speaker—Default. Specifies that the device is the
speaker in the connection.
• listener—Specifies that the device is the listener
in the connection.
The optional vrf keyword specifies the VRF to the
peer. The default is the default VRF.
Router(config)# exit
Router# show cts sxp connections
Exits configuration mode.
(Optional) Displays the SXP connection information.
This example shows how to enable SXP and configure the SXP peer connection on Switch A, a speaker,
for connection to Switch B, a listener:
Router# configure terminal
Router(config)# cts sxp enable
Router(config)# cts sxp default password Cisco123
Router(config)# cts sxp default source-ip 10.10.1.1
Router(config)# cts sxp connection peer 10.20.2.2 password default mode local speaker
This example shows how to configure the SXP peer connection on Switch B, a listener, for connection
to Switch A, a speaker:
Router# configure terminal
Router(config)# cts sxp enable
Router(config)# cts sxp default password Cisco123
OL-22192-01
Cisco TrustSec Configuration Guide
4-3
Page 64
Chapter 4 Configuring SGT Exchange Protocol over TCP (SXP) and Layer 3 Transport
Configuring the Default SXP Password
Router(config)# cts sxp default source-ip 10.20.2.2
Router(config)# cts sxp connection peer 10.10.1.1 password default mode local listener
Configuring the Default SXP Password
By default, SXP uses no password when setting up connections. You can configure a default SXP
password for the switch. In Cisco IOS Release 12.2(50)SY and later releases, you can specify an
encrypted password for the SXP default password.
To configure a default SXP password, perform this task:
Detailed Steps for Catalyst 6500
Command Purpose
Step 1
Step 2
Step 3
Router# configure terminal
Router(config)# cts sxp default password
[0 | 6 | 7] password
Router(config)# exit#
Enters configuration mode.
Configures the SXP default password. You can enter
either a clear text password (using the 0 or no option)
or an encrypted password (using the 6 or 7 option).
The maximum password length is 32 characters.
Exits configuration mode.
This example shows how to configure a default SXP password:
Router# configure terminal
Router(config)# cts sxp default password Cisco123
Configuring the Default SXP Source IP Address
SXP uses the default source IP address for all new TCP connections where a source IP address is not
specified. There is no effect on existing TCP connections when you configure the default SXP source IP
address.
To configure a default SXP source IP address, perform this task:
Detailed Steps for Catalyst 6500
Command Purpose
Step 1
Step 2
Step 3
Router# configure terminal
Router(config)# cts sxp default
source-ip src-ip-addr
Router(config)# exit
Enters configuration mode.
Configures the SXP default source IP address.
Exits configuration mode.
This example shows how to configure an SXP default source IP address:
Router# configure terminal
Router(config)# cts sxp default source-ip 10.20.2.2
Cisco TrustSec Configuration Guide
4-4
OL-22192-01
Page 65
Chapter 4 Configuring SGT Exchange Protocol over TCP (SXP) and Layer 3 Transport
Changing the SXP Reconciliation Period
After a peer terminates an SXP connection, an internal hold-down timer starts. If the peer reconnects
before the internal hold-down timer expires, the SXP reconciliation period timer starts. While the SXP
reconciliation period timer is active, the Cisco TrustSec software retains the SGT mapping entries
learned from the previous connection and removes invalid entries. The default value is 120 seconds (2
minutes). Setting the SXP reconciliation period to 0 seconds disables the timer and causes all entries
from the previous connection to be removed.
To change the SXP reconciliation period, perform this task:
Detailed Steps for Catalyst 6500
Command Purpose
Step 1
Step 2
Step 3
Router# configure terminal
Router(config)# cts sxp reconciliation
period seconds
Router(config)# exit
Enters configuration mode.
Changes the SXP reconciliation timer. The default
value is 120 seconds (2 minutes). The range is from 0
to 64000.
Exits configuration mode.
Changing the SXP Reconciliation Period
Changing the SXP Retry Period
The SXP retry period determines how often the Cisco TrustSec software retries an SXP connection.
When an SXP connection is not successfully set up, the Cisco TrustSec software makes a new attempt
to set up the connection after the SXP retry period timer expires. The default value is 120 seconds.
Setting the SXP retry period to 0 seconds disables the timer and retries are not attempted.
To change the SXP retry period, perform this task:
Detailed Steps for Catalyst 6500
Command Purpose
Step 1
Step 2
Step 3
Router# configure terminal
Router(config)# cts sxp retry period
seconds
Router(config)# exit
Enters configuration mode.
Changes the SXP retry timer. The default value is 120
seconds (2 minutes). The range is from 0 to 64000.
Exits configuration mode.
Creating Syslogs to Capture Changes of IP Address to SGT
Mapping Learned Through SXP
When the cts sxp log binding-changes global configuration command is executed, SXP syslogs (sev 5
syslog) are generated whenever a change to IP address to SGT binding occurs (add, delete, change).
These changes are learned and propagated on the SXP connection.
The default is no cts sxp log binding-changes.
OL-22192-01
Cisco TrustSec Configuration Guide
4-5
Page 66
Chapter 4 Configuring SGT Exchange Protocol over TCP (SXP) and Layer 3 Transport
Verifying the SXP Connections
To enable logging of binding changes, perform the following task:
Detailed Steps for Catalyst 6500
Command Purpose
Step 1
Step 2
Router# configure terminal
Router(config)# cts sxp log binding-changes
Verifying the SXP Connections
To view the SXP connections, perform this task:
Command Purpose
Step 1
Router# show cts sxp connections [brief]
Enters configuration mode.
Turns on logging for IP to SGT binding changes.
Displays SXP status and connections.
This example shows how to view the SXP connections:
Router# show cts sxp connections
SXP : Enabled
Default Password : Set
Default Source IP: 10.10.1.1
Connection retry open period: 10 secs
Reconcile period: 120 secs
Retry open timer is not running
---------------------------------------------Peer IP : 10.20.2.2
Source IP : 10.10.1.1
Conn status : On
Conn Version : 2
Connection mode : SXP Listener
Connection inst# : 1
TCP conn fd : 1
TCP conn password: default SXP password
Duration since last state change: 0:00:21:25 (dd:hr:mm:sec)
Total num of SXP Connections = 1
Configuring Layer 3 SGT Transport Between Cisco TrustSec
Domains
Feature Name Releases Feature Information
L3 SGT Transport 12.2(50) SY This feature was introduced on the Catalyst 6500 series
You can configure Layer 3 SGT Transport on Cisco TrustSec gateway devices on the edges of a network
domain that has no Cisco TrustSec-capable devices.
Cisco TrustSec Configuration Guide
4-6
switches.
OL-22192-01
Page 67
Chapter 4 Configuring SGT Exchange Protocol over TCP (SXP) and Layer 3 Transport
To configure Layer 3 SGT Transport, perform this task:
Detailed Steps for Catalyst 6500
Command Purpose
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Router# configure terminal
Router(config)# [no] cts policy layer3
{ipv4 | ipv6} traffic acl-name
Router(config)# [no] cts policy layer3
{ipv4 | ipv6} exception acl-name
Router(config)# interface
type slot/port
Router(config-if)# [no] cts layer3
{ipv4 | ipv6} trustsec forwarding
Router(config-if)# [no] cts layer3
{ipv4 | ipv6} policy
Router(config-if)# end
Router(config)# end
Router# show cts policy layer3 {ipv4 |
ipv6}
Configuring Layer 3 SGT Transport Between Cisco TrustSec Domains
Enters global configuration mode.
(Optional) Specifies the fallback traffic policy to be
applied when the authentication server is not available
for downloading the traffic policy.
• acl-name—The name of a traditional interface
ACL already configured on the device.
See the additional usage notes following this task.
(Optional) Specifies the fallback exception policy to
be applied when the authentication server is not
available for downloading the exception policy.
See the additional usage notes following this task.
Specifies an interface and enters interface
configuration mode.
(Configured on a Cisco TrustSec-capable physical
port) Specifies that egress traffic on this interface will
use Cisco TrustSec Layer 3 SGT transport
encapsulation as determined by the traffic and
exception policies.
(Configured on a routed port or SVI) Specifies that
egress traffic on this interface will use Cisco TrustSec
Layer 3 SGT transport encapsulation as determined by
the traffic and exception policies.
Exits interface configuration and global configuration
modes.
(Optional) Displays the Layer 3 SGT transport
configuration on the interfaces.
When configuring Cisco TrustSec Layer 3 SGT transport, consider these usage guidelines and
restrictions:
• The Cisco TrustSec Layer 3 SGT transport feature can be configured only on ports that support
hardware encryption.
• Traffic and exception policies for Cisco TrustSec Layer 3 SGT transport have the following
restrictions:
–
The policies must be configured as IP extended or IP named extended ACLs.
–
The policies must not contain deny entries.
–
If the same ACE is present in both the traffic and exception policies, the exception policy takes
precedence. No Cisco TrustSec Layer 3 encapsulation will be performed on packets matching
that ACE.
OL-22192-01
Cisco TrustSec Configuration Guide
4-7
Page 68
Chapter 4 Configuring SGT Exchange Protocol over TCP (SXP) and Layer 3 Transport
Configuring Cisco TrustSec Reflector for Cisco TrustSec-Incapable Switching Modules
• Traffic and exception policies can be downloaded from the authentication server (if supported by
your Cisco IOS Release) or manually configured on the device. The policies will be applied based
on these rules:
–
If a traffic policy or an exception policy is downloaded from the authentication server, it will
take precedence over any manually configured traffic or exception policy.
–
If the authentication server is not available but both a traffic policy and an exception policy have
been manually configured, the manually configured policies will be used.
–
If the authentication server is not available but a traffic policy has been configured with no
exception policy, no exception policy is applied. Cisco TrustSec Layer 3 encapsulation will be
applied on the interface based on the traffic policy.
–
If the authentication server is not available and no traffic policy has been manually configured,
no Cisco TrustSec Layer 3 encapsulation will be performed on the interface.
This example shows how to configure Layer 3 SGT Transport to a remote Cisco TrustSec domain:
Router# configure terminal
Router(config)# ip access-list extended traffic-list
Router(config-ext-nacl)# permit ip any 10.1.1.0 0.0.0.255
Router(config-ext-nacl)# exit
Router(config)# ip access-list extended exception-list
Router(config-ext-nacl)# permit ip any 10.2.2.0 0.0.0.255
Router(config-ext-nacl)# exit
Router(config)# cts policy layer3 ipv4 traffic traffic-sgt
Router(config)# cts policy layer3 ipv4 exception exception-list
Router(config)# interface gi2/1
Router(config-if)# cts layer3 trustsec ipv4 forwarding
Router(config-if)# shutdown
Router(config-if)# no shutdown
Router(config-if)# exit
Router(config)# exit
Configuring Cisco TrustSec Reflector for Cisco
TrustSec-Incapable Switching Modules
Note The Cisco TrustSec supervisor ingress reflector and the Cisco TrustSec egress reflector are mutually
exclusive. Do not enable both functions.
Egress reflector should be disabled when ERSPAN is configured.
To configure the Cisco TrustSec supervisor ingress reflector function, perform this task.
Detailed Steps for Catalyst 6500
Command Purpose
Step 1
Step 2
Router# configure terminal
Router(config)# [no] platform cts ingress
Enters configuration mode.
Activates the Cisco TrustSec supervisor ingress
reflector.
Cisco TrustSec Configuration Guide
4-8
OL-22192-01
Page 69
Chapter 4 Configuring SGT Exchange Protocol over TCP (SXP) and Layer 3 Transport
Command Purpose
Step 3
Step 4
Router(config)# exit
Router# show platform cts
This example shows how to configure a Cisco TrustSec ingress reflector:
Router# configure terminal
Router(config)# platform cts ingress
Router(config)# exit
Router# show platform cts
CTS Ingress mode enabled
Note Before disabling the Cisco TrustSec ingress reflector, you must remove power from the Cisco
TrustSec-incapable switching modules.
To configure the Cisco TrustSec egress reflector function, perform this task.
Detailed Steps for Catalyst 6500
Configuring Cisco TrustSec Caching
Exits configuration mode.
Displays Cisco TrustSec reflector mode (Ingress,
Egress, Pure, or No CTS).
Command Purpose
Step 1
Step 2
Step 3
Step 4
Router# configure terminal
Router(config)# [no] platform cts egress
Router(config)# exit
Router# show platform cts
This example shows how to configure a Cisco TrustSec egress reflector:
Router# configure terminal
Router(config)# platform cts egress
Router(config)# exit
Router# show platform cts
CTS Egress mode enabled
Note Before disabling the Cisco TrustSec egress reflector, you must remove power from the Cisco
TrustSec-incapable switching modules.
Configuring Cisco TrustSec Caching
Enters configuration mode.
Activates the Cisco TrustSec egress reflector.
Exits configuration mode.
Displays Cisco TrustSec reflector mode (Ingress,
Egress, Pure, or No CTS).
Enabling Cisco TrustSec Caching
For quick recovery from brief outages, you can enable caching of authentication, authorization, and
policy information for Cisco TrustSec connections. Caching allows Cisco TrustSec devices to use
unexpired security information to restore links after an outage without requiring a full reauthentication
OL-22192-01
Cisco TrustSec Configuration Guide
4-9
Page 70
Configuring Cisco TrustSec Caching
of the Cisco TrustSec domain. The Cisco TrustSec devices will cache security information in DRAM. If
non-volatile (NV) storage is also enabled, the DRAM cache information will also be stored to the NV
memory. The contents of NV memory populate DRAM during a reboot.
Note During extended outages, the Cisco TrustSec cache information is likely to become outdated.
To enable Cisco TrustSec caching, perform this task:
Detailed Steps for Catalyst 6500
Command Purpose
Step 1
Step 2
Step 3
Step 4
Router# configure terminal
Router(config)# [no] cts cache enable
Router(config)# [no] cts cache
nv-storage {bootdisk: | bootflash: |
disk0:} [directory dir-name]
Router(config)# exit
Chapter 4 Configuring SGT Exchange Protocol over TCP (SXP) and Layer 3 Transport
Enters configuration mode.
Enables caching of authentication, authorization and
environment-data information to DRAM. The default
is disabled.
The no form of this command deletes all cached
information from DRAM and non-volatile storage.
When DRAM caching is enabled, enables DRAM
cache updates to be written to non-volatile storage.
Also enables DRAM cache to be initially populated
from non-volatile storage when the device boots.
Exits configuration mode.
This example shows how to configure Cisco TrustSec caching, including non-volatile storage:
Router# configure terminal
Router(config)# cts cache enable
Router(config)# cts cache nv-storage bootdisk:
Router(config)# exit
Clearing the Cisco TrustSec Cache
To clear the cache for Cisco TrustSec connections, perform this task:
Detailed Steps for Catalyst 6500
Command Purpose
Step 1
Router# clear cts cache
[authorization-policies [peer] |
environment-data | filename filename |
interface-controller [type slot/port]]
This example shows how to clear the Cisco TrustSec cache:
Router# clear cts cache
Clears the cache for Cisco TrustSec connection
information.
Cisco TrustSec Configuration Guide
4-10
OL-22192-01
Page 71
CHAP T ER
Configuring SGACL Policies
Revised: August 15, 2013, OL-22192-02
This section includes the following topics:
• Cisco TrustSec SGACL Feature Histories, page 5-1
• SGACL Policy Configuration Process, page 5-2
• Enabling SGACL Policy Enforcement Globally, page 5-2
• Enabling SGACL Policy Enforcement Per Interface, page 5-3
• Enabling SGACL Policy Enforcement on VLANs, page 5-3
• Manually Configuring SGACL Policies, page 5-4
• Displaying SGACL Policies, page 5-6
• Refreshing the Downloaded SGACL Policies, page 5-7
5
Cisco TrustSec SGACL Feature Histories
For a list of supported TrustSec features per platform and the minimum required IOS release, see
the Cisco TrustSec Platform Support Matrix at the following URL:
http://www.cisco.com/en/US/solutions/ns170/ns896/ns1051/trustsec_matrix.html
Otherwise, see product release notes for detailed feature introduction information.
OL-22192-02
Cisco TrustSec Switch Configuration Guide
5-1
Page 72
SGACL Policy Configuration Process
SGACL Policy Configuration Process
Follow these steps to configure and enable Cisco TrustSec SGACL policies:
Step 1 Configuration of SGACL policies should be done primarily through the Policy Management function of
the Cisco Secure ACS or the Cisco Identity Services Engine (see the Configuration Guide for the Cisco
Secure ACS or the Cisco Identity Services Engine User Guide).
If you are not using AAA on a Cisco Secure ACS or a Cisco ISE to download the SGACL policy
configuration, you can manually configure the SGACL mapping and policies (see the “Manually
Configuring SGACL Policies” section on page 5-4 and the “Manually Configuring SGACL Policies”
section on page 5-4).
Note An SGACL policy downloaded dynamically from the Cisco Secure ACS or a Cisco ISE will
override any conflicting locally-defined policy.
Step 2 To enable SGACL policy enforcement on egress traffic on routed ports, enable SGACL policy
enforcement globally as described in the “Enabling SGACL Policy Enforcement Globally” section on
page 5-2.
Step 3 To enable SGACL policy enforcement on switched traffic within a VLAN, or on traffic that is forwarded
to an SVI associated with a VLAN, enable SGACL policy enforcement for specific VLANs as described
in the “Enabling SGACL Policy Enforcement on VLANs” section on page 5-3.
Chapter 5 Configuring SGACL Policies
Enabling SGACL Policy Enforcement Globally
You must enable SGACL policy enforcement globally for Cisco TrustSec-enabled routed interfaces.
To enable SGACL policy enforcement on routed interfaces, perform this task:
Command Purpose
Step 1
Step 2
Configuration Examples for Enabling SGACL Policy Enforcement Globally
Router# configure terminal
Router(config)# cts role-based
enforcement
Catalyst 6500, Catalyst 3850:
Switch(config)# cts role-based enforcement
Enters global configuration mode.
Enables Cisco TrustSec SGACL policy enforcement
on routed interfaces.
Cisco TrustSec Switch Configuration Guide
5-2
OL-22192-02
Page 73
Chapter 5 Configuring SGACL Policies
Enabling SGACL Policy Enforcement Per Interface
Enabling SGACL Policy Enforcement Per Interface
You must first enable SGACL policy enforcement globally for Cisco TrustSec-enabled routed interfaces.
This feature is not supported on Port Channel interfaces.
To enable SGACL policy enforcement on Layer 3 interfaces, perform this task:
Detailed Steps Catalyst 6500
Command Purpose
Step 1
Step 2
Step 3
Step 4
Router# configure terminal
Router(config)# interface gigabit 6/2
Router(config-if)# cts role-based enforcement
Router(config-if)# do show cts interface
Enters global configuration mode.
Specifies interface on which to enable or
disable SGACL enforcement.
Enables Cisco TrustSec SGACL policy
enforcement on routed interfaces.
Verifies that SGACL enforcement is enabled.
Configuration Examples for Enabling SGACL Policy Enforcement Per Interface
Catalyst 3850:
Switch# configure terminal
Switch(config)# interface gigabit 1/0/2
Switch(config-if)# cts role-based enforcement
Switch(config-if)# end
Enabling SGACL Policy Enforcement on VLANs
You must enable SGACL policy enforcement on specific VLANs to apply access control to switched
traffic within a VLAN, or to traffic that is forwarded to an SVI associated with a VLAN.
To enable SGACL policy enforcement on a VLAN or a VLAN list, perform this task:
Detailed Steps Catalyst 6500
Command Purpose
Step 1
Step 2
Router# configure terminal
Router(config)# cts role-based
enforcement vlan-list vlan-list
Enters global configuration mode.
Enables Cisco TrustSec SGACL policy enforcement
on the VLAN or VLAN list.
Configuration Examples for Enabling SGACL Policy Enforcement on VLANs
Catalyst 3850:
Switch# configure terminal
Switch(config)# cts role-based enforcement vlan-list 31-35,41
Switch(config)# exit
OL-22192-02
Cisco TrustSec Switch Configuration Guide
5-3
Page 74
Manually Configuring SGACL Policies
Manually Configuring SGACL Policies
A role-based access control list bound to a range of SGTs and DGTs forms an SGACL, a TrustSec policy
enforced on egress traffic. Configuration of SGACL policies are best done through the policy
management functions of the Cisco ISE or the Cisco Secure ACS. To manually (that is, locally)
configure SGACL policies, do the following:
1. Configure a role-based ACL.
2. Bind the role-based ACL to a range of SGTs.
Note An SGACL policy downloaded dynamically from the Cisco ISE or Cisco ACS overrides any conflicting
manually configured policy.
Manually Configuring and Applying IPv4 SGACL Policies
Detailed Steps for Catalyst 3850
Chapter 5 Configuring SGACL Policies
Step 1
Step 2
Step 3
Step 4
Command Purpose
Router# configure terminal
ip access-list role-based rbacl-name
Enters global configuration mode.
Creates a Role-based ACL and enters Role-based ACL
configuration mode.
Example:
Switch(config)# ip access-list
role-based allow_webtraff
{[sequence-number] | default | permit |
deny | remark}
Specifies the access control entries (ACEs) for the
RBACL.
You can use most of the commands and options
allowed in extended named access list configuration
mode, with the source and destination fields omitted.
Press Enter to complete an ACE and begin the next.
For full explanations of ACL configuration, keywords,
and options, see, Security Configuration Guide:
Access Control Lists, Cisco IOS XE Release 3S.
The following ACE commands or keywords are not
supported:
Example:
Switch(config-rb-acl)#10 permit tcp dst
eq 80 dst eq 20
Switch(config-rb-acl)# exit
• reflect
• evaluate
• time-range
Exits to global configuration mode.
Cisco TrustSec Switch Configuration Guide
5-4
OL-22192-02
Page 75
Chapter 5 Configuring SGACL Policies
Command Purpose
Step 5
[no] cts role-based permissions {default
|[from {sgt_num | unknown} to {dgt_num |
unknown}]{rbacls | ipv4 rbacls}
Example:
Switch(config)# cts role-based
permissions from 55 to 66 allow_webtraff
Step 6
Step 7
Step 8
Switch(config)# end
Switch# show cts role-based permissions
Switch# show ip access-lists
allow_webtraff
Manually Configuring SGACL Policies
Binds SGTs and DGTs to the RBACL. The
configuration is analogous to populating the
permission matrix configured on the Cisco ISE or the
Cisco Secure ACS.
• Default—Default permissions list
• sgt_num—0 to 65,519. Source Group Tag
• dgt_num—0 to 65,519. Destination Group Tag
• unknown—SGACL applies to packets where the
security group (source or destination) cannot be
determined.
• ipv4—Indicates the following RBACL is IPv4.
• rbacls—Name of RBACLs
Exits to Privileged Exec mode.
Displays permission to RBACL configurations.
Displays ACEs of all RBACLs or a specified RBACL.
Configuration Examples for Manually Configuring SGACL Policies
Catalyst 3850 IPv4 Manual SGACL policy:
Switch(config)# ip access role allow_webtraff
Switch(config-rb-acl)# 10 permit tcp dst eq 80
Switch(config-rb-acl)# 20 permit tcp dst eq 443
Switch(config-rb-acl)# 30 permit icmp
Switch(config-rb-acl)# 40 deny ip
Switch(config-rb-acl)# exit
Switch(config)# cts role-based permissions from 55 to 66 allow_webtraff
Switch# show ip access allow_webtraff
Role-based IP access list allow_webtraff
10 permit tcp dst eq www
20 permit tcp dst eq 443
30 permit icmp
40 deny ip
Switch# show show cts role-based permissions from 50 to 70
XXX need output XX
OL-22192-02
Cisco TrustSec Switch Configuration Guide
5-5
Page 76
Displaying SGACL Policies
Displaying SGACL Policies
After configuring the Cisco TrustSec device credentials and AAA, you can verify the Cisco TrustSec
SGACL policies downloaded from the authentication server or configured manually. Cisco TrustSec
downloads the SGACL policies when it learns of a new SGT through authentication and authorization
on an interface, from SXP, or from manual IP address to SGT mapping.
To display the contents of the SGACL policies permissions matrix, perform this task:
Detailed Steps for Catalyst 6500
Command Purpose
Step 1
Router# show cts role-based permissions
default [ipv4 | ipv6 | details]
Router# show cts role-based permissions
[from {source-sgt | unknown}] [to {dest-sg
| unknown}] [ipv4 | ipv6] [details]
Chapter 5 Configuring SGACL Policies
Displays the list of SGACL of the default policy.
Displays the contents of the permissions matrix,
including SGACLs downloaded from the
authentication server and manually configured on
the switch.
Using the keywords, you can display all or part of the permissions matrix:
• If the from keyword is omitted, a column from the permissions matrix is displayed.
• If the to keyword is omitted, a row from the permissions matrix is displayed.
• If the from and to keywords are omitted, the entire permissions matrix is displayed.
• If the from and to keywords are specified, a single cell from the permissions matrix is displayed and
the details keyword is available. When details is entered, the ACEs of the SGACL of the single cell
are displayed.
This example shows how to display the content of the SGACL policies permissions matrix for traffic
sourced from security group 3:
Router# show cts role-based permissions from 3
Role-based permissions from group 3 to group 5:
SRB3
SRB5
Role-based permissions from group 3 to group 7:
SRB4
Cisco TrustSec Switch Configuration Guide
5-6
OL-22192-02
Page 77
Chapter 5 Configuring SGACL Policies
Refreshing the Downloaded SGACL Policies
Detailed Steps for Catalyst 6500, Catalyst 3850, Catalyst 3650
Command Purpose
Step 1
cts refresh policy {peer [peer-id]
| sgt [sgt_number|
default|unknown]}
Switch3850# cts refresh policy
peer my_cisco_ise
Performs an immediate refresh of the SGACL policies from
the authentication server.
• If a peer-id is specified, only the policies related to the
specified peer connection are refreshed. To refresh all
peer policies, press Enter without specifying an ID.
• If an SGT number is specified, only the policies related
to that SGT are refreshed. To refresh all security group
tag policies, press Enter without specifying an SGT
number. Select default to refresh the default policy.
Select unknown to refresh unknown policy.
Refreshing the Downloaded SGACL Policies
OL-22192-02
Cisco TrustSec Switch Configuration Guide
5-7
Page 78
Refreshing the Downloaded SGACL Policies
Chapter 5 Configuring SGACL Policies
Cisco TrustSec Switch Configuration Guide
5-8
OL-22192-02
Page 79
CHAP T ER
6
Configuring Endpoint Admission Control
Revised: May 28, 2010, OL-22192-01
This chapter contains the following sections:
• Information About Endpoint Admission Control
• Basic EAC Configuration Sequence
• 802.1X Authentication Configuration
• MAC Authentication Bypass Configuration
• Web Authentication Proxy Configuration
• Flexible Authentication Sequence and Failover Configuration
• 802.1X Host Modes
• Pre-Authentication Open Access
• DHCP Snooping and SGT Assignment
• Cisco TrustSec Endpoint Access Control Feature Histories
Information About Endpoint Admission Control
In TrustSec networks, packets are filtered at the egress, not the ingress to the network. In TrustSec
endpoint authentication, a host accessing the TrustSec domain (endpoint IP address) is associated with
a Security Group Tag (SGT) at the access device through DHCP snooping and IP device tracking. The
access device transmits that association (binding) through SXP to TrustSec hardware-capable egress
devices, which maintain a continually updated table of Source IP to SGT bindings. Packets are filtered
on egress by the TrustSec hardware-capable devices by applying security group ACLS (SGACLs).
Endpoint Admission Control (EAC) access methods for authentication and authorization can include the
following:
• 802.1X port-based Authentication
• MAC Authentication Bypass (MAB)
• Web Authentication (WebAuth)
All port-based authentication can be enabled with the authentication command. Each access method
must be configured individually per port. The flexible authentication sequence and failover features
permit the administrator to specify the failover and fallback sequence when multiple authentication
modes are configured and the active method fails. The 802.1X host mode determines how many endpoint
hosts can be attached per 802.1X port.
Cisco TrustSec Configuration Guide
OL-22192-01
6-1
Page 80
Basic EAC Configuration Sequence
Basic EAC Configuration Sequence
1. Configure the Cisco Secure ACS to provision SGTs to authenticated endpoint hosts.
2. Enable SXP on access switches. See the chapter, “Configuring SGT Exchange Protocol over TCP
(SXP) and Layer 3 Transport.”
3. Enable any combination of 802.1X, MAB, or WebAuth authentication methods on the access switch.
4. Enable DHCP and IP device tracking on access switches.
802.1X Authentication Configuration
The following example shows the basic 802.1x configuration on a Gigabit Ethernet port:
Router(config)# dot1x system-auth-control
Router(config)# interface GigabitEthernet2/1
Router(config-if)# authentication port-control auto
Router(config-if)# dot1x pae authenticator
For additional information on configuring 802.1x authentication, see the configuration guide for your
access switch.
Chapter 6 Configuring Endpoint Admission Control
Verifying the 802.1X Configuration
To verify 802.1X authentication configuration, use the show authentication interface command.
Router# show authentication interface gigabitEthernet 2/1
*May 7 11:22:06: %SYS-5-CONFIG_I: Configured from console by console
Client list:
Interface MAC Address Domain Status Session ID
Gi2/1 000c.293a.048e DATA Authz Success AC1AD01F0000000904BBECD8
Available methods list:
Handle Priority Name
3 0 dot1x
Runnable methods list:
Handle Priority Name
3 1 dot1x
And to verify the port has successfully authenticated:
Router# show dot1x interface gigabitEthernet 2/1 details
Dot1x Info for GigabitEthernet2/1
----------------------------------PAE = AUTHENTICATOR
PortControl = AUTO
ControlDirection = Both
HostMode = SINGLE_HOST
QuietPeriod = 60
ServerTimeout = 30
SuppTimeout = 30
ReAuthMax = 2
MaxReq = 2
TxPeriod = 30
Dot1x Authenticator Client List
Cisco TrustSec Configuration Guide
6-2
OL-22192-01
Page 81
Chapter 6 Configuring Endpoint Admission Control
------------------------------Supplicant = 000c.293a.048e
Session ID = AC1AD01F0000000904BBECD8
Auth SM State = AUTHENTICATED
Auth BEND SM State = IDLE
Port Status = AUTHORIZED
MAC Authentication Bypass Configuration
MAC Authentication Bypass (MAB) enables hosts or clients that are not 802.1X capable to join
802.1X-enabled networks. It is not required to enable 802.1X authentication prior to enabling MAB.
The following example is a basic MAB configuration on a Catalyst switch:
switch(config)# interface GigabitEthernet2/1
switch(config-if)# authentication port-control auto
switch(config-if)# mab
For additional information on configuring MAB authentication, see the configuration guide for your
access switch.
MAC Authentication Bypass Configuration
Verifying the MAB Configuration
To verify the MAC Authentication Bypass configuration, use the show authentication interface
command.
switch# show authentication interface gigabitEthernet 2/1
Client list:
Interface MAC Address Domain Status Session ID
Gi2/1 000c.293a.048e DATA Authz Success AC1AD01F0000000A04CD41AC
Available methods list:
Handle Priority Name
2 1 mab
Runnable methods list:
Handle Priority Name
2 0 mab
To verify that the port has successfully authenticated, use the show mab interface command.
switch# show mab interface gigabitEthernet 2/1 details
MAB details for GigabitEthernet2/1
------------------------------------Mac-Auth-Bypass = Enabled
MAB Client List
--------------Client MAC = 000c.293a.048e
Session ID = AC1AD01F0000000A04CD41AC
MAB SM state = ACQUIRING
Auth Status = UNAUTHORIZED
OL-22192-01
Cisco TrustSec Configuration Guide
6-3
Page 82
Web Authentication Proxy Configuration
Web Authentication Proxy Configuration
Web Authentication Proxy (WebAuth) allows the user to use a web browser to transmit their login
credentials to the Cisco Secure ACS though a Cisco IOS web server on the access device. WebAuth can
be enabled independently. It does not require 802.1X or MAB to be configured.
The following example is a basic WebAuth configuration on a Gigabit Ethernet port:
switch(config)# ip http server
switch(config)# ip access-list extended POLICY
switch(config-ext-nacl)# permit udp any any eq bootps
switch(config-ext-nacl)# permit udp any any eq domain
switch(config)# ip admission name HTTP proxy http
switch(config)# fallback profile FALLBACK_PROFILE
switch(config-fallback-profile)# ip access-group POLICY in
switch(config-fallback-profile)# ip admission HTTP
switch(config)# interface GigabitEthernet2/1
switch(config-if)# authentication port-control auto
switch(config-if)# authentication fallback FALLBACK_PROFILE6500(config-if)#ip access-group
POLICY in
For additional information on configuring web-based authentication, see the configuration guide for
your access switch.
For additional information on the ip http server command, see the Cisco IOS Network Management
Command Reference entry at the at the following URL:
Chapter 6 Configuring Endpoint Admission Control
http://www.cisco.com/en/US/docs/ios/netmgmt/command/reference/nm_08.html#wp1022387
Verifying Web Authentication Proxy Configuration
To verify the Web Authentication Proxy configuration, access the interface IP address with a web
browser. If configured correctly, the access device generates a challenge and accepts valid login
information.
To verify the Web Authentication proxy configuration with the CLI, use the show authentication
interface command.
switch# show authentication interface gigabitEthernet 2/1
Client list:
Interface MAC Address Domain Status Session ID
Gi2/1 000c.293a.048e DATA Authz Success AC1AD01F0000000904BBECD8
Available methods list:
Handle Priority Name
1 2 webauth
Runnable methods list:
Handle Priority Name
1 0 webauth
Cisco TrustSec Configuration Guide
6-4
OL-22192-01
Page 83
Chapter 6 Configuring Endpoint Admission Control
Flexible Authentication Sequence and Failover Configuration
Flexible Authentication Sequence and Failover Configuration
Flexible Authentication Sequence (FAS) allows the access port to be configured for 802.1X, MAB, and
WebAuth authentication methods, specifying the fallback sequence if one or more of the authentication
methods are not available. The default failover sequence is as follows:
• 802.1X port-based Authentication
• MAC Authentication Bypass
• Web Authentication
Layer 2 authentications always occur before Layer 3 authentications. That is, 802.1X and MAB must
occur before WebAuth.
The following example specifies the authentication sequence as MAB, dot1X, and then WebAuth.
switch(config)# interface gigabitEthernet 2/1
switch(config-if)# authentication order mab dot1x webauth
switch(config-if)^Z
For more detailed information on authentication method sequence configuration, see the configuration
guide for your access switch.
For additional information on FAS, see the Cisco document, Flexible Authentication Order, Priority, and
Failed Authentication at the following URL:
http://www.ciscosystems.com.pe/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6638/application_n
ote_c27-573287_ps6638_Products_White_Paper.html
802.1X Host Modes
Four host classification modes can be configured per port:
• Single Host —Interface-based session with one MAC address
• Multi Host—Interface-based session with multiple MAC addresses per port
• Multi Domain—MAC + Domain (VLAN) session
• Multi Auth—MAC-based session with multiple MAC address per port
For more detailed information on 802.1x Host Mode configurations, see the configuration guide for your
access switch.
Pre-Authentication Open Access
The Pre-Authentication Open Access feature allows clients and devices to gain network access before
port authentication is performed. This process is primarily required for the PXE boot scenario, where a
device needs to access the network before PXE times out and download a bootable image that may
contain a supplicant.
For more detailed information on Pre-authentication Open Access configuration, see the configuration
guide for your access switch.
OL-22192-01
Cisco TrustSec Configuration Guide
6-5
Page 84
DHCP Snooping and SGT Assignment
DHCP Snooping and SGT Assignment
After the authentication process, authorization of the device occurs (for example, dynamic VLAN
assignment, ACL programming, etc.). For TrustSec networks, a Security Group Tag (SGT) is assigned
per the user configuration in the Cisco ACS. The SGT is bound to traffic sent from that endpoint through
DHCP snooping and the IP device tracking infrastructure.
The following example enables DHCP snooping and IP device tracking on an access switch:
switch# conf t
Enter configuration commands, one per line. End with CNTL/Z.
switch(config)# ip dhcp snooping
switch(config)# ip dhcp snooping vlan 10
switch(config)# no ip dhcp snooping information option
switch(config)# ip device tracking
For more detailed information on DHCP snooping and IP device tracking configuration, see the
configuration guide for your access switch.
Verifying the SGT to Endpoint Host Binding
Chapter 6 Configuring Endpoint Admission Control
To verify that hosts are visible to DHCP Snooping and IP Device Tracking, use the
show ip dhcp snooping binding and show ip device tracking commands.
switch# show ip dhcp snooping binding
MacAddress IpAddress Lease(sec) Type VLAN Interface
------------------ --------------- ---------- ------------- ---- -------------------00:0C:29:3A:04:8E 10.252.10.10 84814 dhcp-snooping 10 GigabitEthernet2/1
Total number of bindings: 1
switch# show ip device tracking all
IP Device Tracking = Enabled
IP Device Tracking Probe Count = 3
IP Device Tracking Probe Interval = 30
------------------------------------------------------------- IP Address MAC Address Interface STATE
--------------------------------------------------------------
10.252.10.10 000c.293a.048e GigabitEthernet2/1 ACTIVE
To verify that the correct SGT is bound to an endpoint IP address, use the show cts role-based sgt-map
command.
switch# show cts role-based sgt-map all
Active IP-SGT Bindings Information
IP Address SGT Source
============================================
1.1.1.1 7 INTERNAL
10.252.10.1 7 INTERNAL
10.252.10.10 3 LOCAL
10.252.100.1 7 INTERNAL
172.26.208.31 7 INTERNAL
IP-SGT Active Bindings Summary
============================================
Total number of LOCAL bindings = 1
Total number of INTERNAL bindings = 4
Total number of active bindings = 5
Cisco TrustSec Configuration Guide
6-6
OL-22192-01
Page 85
Chapter 6 Configuring Endpoint Admission Control
Cisco TrustSec Endpoint Access Control Feature Histories
Cisco TrustSec Endpoint Access Control Feature Histories
For a list of supported platforms, supported features, and the minimum required IOS releases, see
the Cisco TrustSec Platform Support Matrix at the following URL:
http://www.cisco.com/en/US/solutions/ns170/ns896/ns1051/trustsec_matrix.html
Otherwise, see product release notes for detailed feature introduction information.
OL-22192-01
Cisco TrustSec Configuration Guide
6-7
Page 86
Cisco TrustSec Endpoint Access Control Feature Histories
Chapter 6 Configuring Endpoint Admission Control
Cisco TrustSec Configuration Guide
6-8
OL-22192-01
Page 87
CHAP T ER
7
Cisco TrustSec Command Summary
Revised: April 26, 2013, OL-22192-01
Cisco TrustSec Privileged EXEC Commands
cts change-password Initiate password change with AAA server.
cts credentials Inserts CTS device ID and password into the
keystore.
cts refresh Refresh environment, peer and RBACL policies.
cts rekey CTS SAP rekey
cts role-based policy trace TrustSec SGT and SGACL trace utility.
Cisco TrustSec Global Configuration Commands
cts authorization list Configures CTS global authorization
configuration.
cts cache Enables caching of TrustSec authorization and
environment-data information to DRAM and
NVRAM.
cts manual Define CTS keystore behavior
cts policy layer3 Specifies traffic and exception policies for CTS
Layer 3 Transport gateway interfaces.
cts role-based Maps IP addresses, L3 interfaces, and VRFs to
SGTs; enables CTS caching and
SGACL enforcement.
cts server Configures RADIUS server list configuration.
cts sgt Configures local device security group tag.
cts sxp Configures SGT exchange over TCP.
CTS Flexible NetFlow Commands
match flow cts
OL-22192-01
Cisco TrustSec Configuration Guide
7-1
Page 88
Chapter 7 Cisco TrustSec Command Summary
CTS Interface Configuration Commands
cts dot1x Enters CTS dot1x Interface Configuration mode
(config-if-cts-dot1x).
cts layer3 Enables and applies traffic and exception policies
to CTS Layer 3 Transport gateway interfaces.
cts manual (config-if) Supply local configuration for CTS
parameters
platform cts Enables the TrustSec egress or ingress reflector.
CTS dot1x Submode Commands
default (cts dot1x interface configuration
Restores defaults for CTS dot1x commands.
submode)
propagate (cts dot1x submode) Enables/disables SGT propagation in dot1x mode.
sap (cts dot1x interface submode) Configures CTS SAP for dot1x mode.
timer (cts do1x interface submode) Configures the CTS timer.
CTS Manual Interface Configuration Submode Commands
default (cts manual interface configuration
submode)
policy (cts manual interface configuration
Restores default configurations for CTS manual
mode.
Configures CTS policy for manual mode
submode)
propagate (cts manual interface configuration
submode)
Configures CTS SGT Propagation configuration
for manual mode
sap (cts manual interface submode) Configures CTS SAP for manual mode.
Cisco TrustSec Clear Commands
clear cts cache Clears TrustSec cache file by type, by filename or
all cache files.
clear cts counter Clears the counters for a single TrustSec interface
or for all interfaces
clear cts credentials Clears all CTS credentials, including all PACs.
clear cts environment-data Clears TrustSec environment data from cache.
clear cts macsec Clears MACsec counters for a specified interface.
clear cts pac Clears a PAC or all PACs from the keystore.
clear cts role-based counters Displays role-based access control enforcement
statistics for SGTs and DGTs.
clear cts server Removes the specified authentication server.
Cisco TrustSec Configuration Guide
7-2
OL-22192-01
Page 89
Chapter 7 Cisco TrustSec Command Summary
Cisco TrustSec Show Commands
show cts authorization entries Displays the authorization entries.
show cts credentials Displays credentials used for CTS authentication.
show cts environment-data Displays the CTS environment data.
show cts interface Displays CTS states and statistics per interface.
show cts macsec Displays crypto ASIC packet counters per
show cts pacs Displays the A-ID and PAC-info for PACs in the
show cts policy peer Displays the peer authorization policies of
show cts policy layer3 Displays the traffic and exception policies used in
show cts provisioning Displays outstanding CTS provisioning jobs
show cts role-based sgt-map Displays IP address to Security Group Tag
show cts role-based counters Displays role-based access control enforcement
show cts role-based sgt-map Displays IP to SGT bindings, permission lists, and
show cts server-list Displays lists of AAA servers and load balancing
show cts sxp Displays CTS SXP protocol information.
show platform cts reflector Displays the status of CTS reflector per interface.
Commands to Configure Endpoint Admission Control (EAC)
aaa accounting
aaa authorization
aaa authentication
order
priority
event
periodic
timer
host-mode
authorization
accounting
radius-server host
authentication port-control
interface.
keystore.
TrustSec peers.
CTS Layer3 Transport.
mappings.
statistics for SGTs and DGTs.
NetFlow statistics.
configurations.
OL-22192-01
Cisco TrustSec Configuration Guide
7-3
Page 90
Chapter 7 Cisco TrustSec Command Summary
Debug Commands
debug authentication event
debug authentication feature
debug condition cts peer-id
debug condition cts Filters CTS debugging messages by interface
name, peer-id, peer-SGT or Security Group name.
debug condition cts peer-id
debug condition cts security-group
debug cts aaa
debug cts authentication events
debug cts authorization
debug cts authorization events
debug cts authorization rbacl
debug cts authorization snmp
debug cts cache
debug cts coa events
debug cts dp errors
debug cts dp info
debug cts dp packets
debug cts environment-data
debug cts environment-data events
debug cts error
debug cts fips
debug cts ha
debug cts ha core
debug cts ha infra
debug cts ifc
debug cts ifc cache
debug cts ifc events
debug cts ifc snmp
debug cts layer3-trustsec
debug cts provisioning
debug cts provisioning event
debug cts provisioning pak
debug cts relay event
debug cts relay pak
debug cts sap events
debug cts sap packets
debug cts sap pakdump
Cisco TrustSec Configuration Guide
7-4
OL-22192-01
Page 91
Chapter 7 Cisco TrustSec Command Summary
debug cts server-list
debug cts states
debug cts sxp
debug cts sxp conn
debug cts sxp error
debug cts sxp internal
debug cts sxp mdb
debug cts sxp message
debug dot.1x
debug epm
debug event
debug mab
debug radius
debug rbm api
debug rbm cli
debug rbm bindings
debug rbm dp errors
debug rbm dp events
debug rbm dp packets
debug rbm platform
debug rbm policy
OL-22192-01
Cisco TrustSec Configuration Guide
7-5
Page 92
cts authorization list
cts authorization list
To specify a list of AAA servers to use by the TrustSec seed device, use the cts authorization command
on the TrustSec seed device in global configuration mode. Use the no form of the command to stop using
the list during authentication.
cts authorization list server_list
no cts authorization list server_list
Chapter 7 Cisco TrustSec Command Summary
Syntax Description
server_list Specifies a Cisco TrustSec AAA server group.
Defaults None
Command Modes Global configuration (config)
Supported User Roles Administrator
Command History
Release Modification
12.2 (33) SXI3 This command was introduced on the Catalyst 6500 series switches.
Usage Guidelines This command is only for the seed device. Non-seed devices obtain the TrustSec AAA server list from
their TrustSec authenticator peer as a component of their TrustSec environment data.
Examples The following example displays an AAA configuration of a TrustSec seed device:
Router# cts credentials id Switch1 password Cisco123
Router# configure terminal
Router(config)# aaa new-model
Router(config)# aaa authentication dot1x default group radius
Router(config)# aaa authorization network MLIST group radius
Router(config)# cts authorization list MLIST
Router(config)# aaa accounting dot1x default start-stop group radius
Router(config)# radius-server host 10.20.3.1 auth-port 1812 acct-port 1813 pac key
AbCe1234
Router(config)# radius-server vsa send authentication
Router(config)# dot1x system-auth-control
Router(config)# exit
Related Commands
Command Description
show cts server-list Displays RADIUS server configurations.
Cisco TrustSec Configuration Guide
7-6
OL-22192-01
Page 93
Chapter 7 Cisco TrustSec Command Summary
cts cache
To enable caching of TrustSec authorization and environment data information to DRAM and NVRAM,
use the cts cache global configuration command. Use the no form of the command to disable caching.
[no] cts cache {
enable |
nv-storage {bootflash: [
}
cts cache
dir] | disk0: [dir] | disk1: [dir] | sup-bootflash: [image]}
Syntax Description
Defaults The default is caching disabled.
Command Modes Global configuration (config)
Supported User Roles Administrator
Command History
enable Enables CTS cache support
nv-storage Causes DRAM cache updates to be written to non-volatile storage and
enables DRAM cache to be initially populated from nv-storage when the
network device boots.
bootflash: dir Specifies bootflash dir as the nv-storage location.
disk0: dir Specifies disk 0 directory as the nv-storage location.
disk1: dir Specifies disk 1 directory as the nv-storage location.
sup-bootflash: image Specifies a supervisor bootflash directory as the nv-storage location.
Release Modification
12.2(33) SXI This command was introduced on the Catalyst 6500 series switches.
12.2(50) SY PMK caching support is added for the Catalyst 6500 series switches.
Usage Guidelines The cts cache command enables caching of authentication, authorization and environment-data
information to DRAM. Caching is for the maintenance and reuse of information obtained through
authentication and authorization. Keystore provides for secure storage of a device's own credentials
(passwords, certificates, PACs) either in software or on a specialized hardware component. In the
absence of a dedicated hardware keystore, a software emulation keystore is created using DRAM and
NVRAM.
Cisco TrustSec creates a secure cloud of devices in a network by requiring that each device authenticate
and authorize its neighbors with a trusted AAA server (Cisco Secure ACS 5.1 or more recent) before
being granted access to the TrustSec network. Once the authentication and authorization is complete, the
information could be valid for some time. If caching is enabled, that information can be reused, allowing
the network device to bring up links without having to connect with the ACS, thus expediting the
OL-22192-01
Cisco TrustSec Configuration Guide
7-7
Page 94
cts cache
formation of the CTS cloud upon reboot, improving network availability, and reducing the load on the
ACS. Caching can be stored in volatile memory (information does not survive a reboot) or nonvolatile
memory (information survives a reboot).
Examples The following example enables cache support:
Router# config t
Router(config)# cts cache nv-storage disk0:
Router(config)# cts cache enable
Related Commands Command Description
clear cts cache Clears the content of the keystore.
show cts keystore Displays the content of the keystore.
cts rekey
cts credentials
Chapter 7 Cisco TrustSec Command Summary
Cisco TrustSec Configuration Guide
7-8
OL-22192-01
Page 95
Chapter 7 Cisco TrustSec Command Summary
cts change-password
To change the password between the local device and the authentication server, use the cts
change-password Privileged EXEC command.
cts change-password server ipv4_address udp_port {a-id hex_string | key radius_key } [source
interface_list ]
cts change-password
Syntax Description
Defaults There is no default for this command.
Command Modes Privileged EXEC (#)
Supported User Roles Administrator
Command Types Use the following command syntax
server Specifies the authentication server.
ipv4_address The IP address of the authentication server.
udp_port The UPD port of the authentication server.
a-id hex_string Specifies the identification string of the ACS server
key Specifies the RADIUS key to be used for provisioning
source Specifies the interface for source address in request packets
interface_list Specify the interface type and its identifying parameters per the displayed
list.
Command History
Usage Guidelines The cts change-password command allows an administrator to change the password used between the
Note The cts change-password is supported on Cisco Secure ACS, 5.1 and more recent versions.
OL-22192-01
Release Modification
12.2(50) SY This command was introduced on the Catalyst 6500 Series Switches.
local device the Cisco Secure ACS authentication server, without having to also reconfigure the
authentication server.
For Catalyst 6500 switches with dual-supervisor chassis, the hardware-based keystores must be
manually synchronized when inserting a second supervisor linecard. A password change process may be
invoked to make both active and standby supervisors have the same device password.
Cisco TrustSec Configuration Guide
7-9
Page 96
cts credentials
cts credentials
Use the cts credentials command in privileged EXEC mode to specify the TrustSec ID and password of
the network device. Use the clear cts credentials command to delete the credentials.
cts credentials id cts_id password cts_pwd
Chapter 7 Cisco TrustSec Command Summary
Syntax Description
Defaults None
Command Modes Privileged EXEC (#)
Supported User Roles Administrator
Command History
Usage Guidelines For use in TrustSec Network Device Admission Control (NDAC) authentication, the cts credentials
credentials id cts_id Specifies the Cisco TrustSec device ID for this device to use when
authenticating with other Cisco TrustSec devices with EAP-FAST. The cts-id
variable has a maximum length of 32 characters and is case sensitive.
password cts_pwd Specifies the password for this device to use when authenticating with other
Cisco TrustSec devices with EAP-FAST.
Release Modification
12.2(33) SXI This command was introduced on the Catalyst 6500 series switches.
command specifies the Cisco TrustSec device ID and password for this switch to use when
authenticating with other Cisco TrustSec devices with EAP-FAST. The CTS credentials state retrieval is
not performed by the nonvolatile generation process (NVGEN) because the CTS credential information
is saved in the keystore, not in the startup-config. The device can be assigned a CTS identity by the Cisco
Secure Access Control Server (ACS), or auto-generate a new password when prompted to do so by the
ACS. Those credentials are stored in the keystore, eliminating the need to save the running-config. To
display the CTS device ID, use the show cts credentials command. The stored password is never
displayed.
To change the device ID or the password, reenter the command. To clear the keystore, use the clear cts
credentials command.
Note When the CTS device ID is changed, all Protected Access Credentials (PACs) are flushed from the
keystore because the PACs are associated with the old device ID and are not valid for a new identity.
Cisco TrustSec Configuration Guide
7-10
OL-22192-01
Page 97
Chapter 7 Cisco TrustSec Command Summary
cts credentials
Examples The following example configures himalaya and cisco as the CTS device ID and password:
Router# cts credentials id himalaya password cisco
CTS device ID and password have been inserted in the local keystore. Please make sure that
the same ID and password are configured in the server database.
The following example changes the CTS device ID and password to atlas and cisco123:
Router# cts credentials id atlas pacssword cisco123
A different device ID is being configured.
This may disrupt connectivity on your CTS links.
Are you sure you want to change the Device ID? [confirm] y
TS device ID and password have been inserted in the local keystore. Please make sure that
the same ID and password are configured in the server database.
The following example displays the CTS device ID and password state:
Router# show cts credentials
CTS password is defined in keystore, device-id = atlas
Related Commands Command Description
clear cts credentials Clears the Cisco TrustSec device ID and password.
show cts credentials Displays the state of the current Cisco TrustSec device ID and password.
show cts keystore Displays contents of the hardware and software keystores.
OL-22192-01
Cisco TrustSec Configuration Guide
7-11
Page 98
cts dot1x
cts dot1x
Use the cts dot1x command to enter CTS dot1x interface configuration mode (config-if-cts-dot1x) to
configure the TrustSec reauthentication timer on an interface. Use the no form of the command to disable
the timers on an interface.
[no] cts dot1x
Syntax Description This command has no arguments or keywords.
Defaults CTS dot1x configuration on the interface is disabled by default.
Command Modes Interface configuration (config-if)
Chapter 7 Cisco TrustSec Command Summary
Supported User Roles Administrator
Command History
Release Modification
12.2 (33) SXI3 This command was introduced on the Catalyst 6500 series switches.
Usage Guidelines Before configuring the TrustSec dot1x reauthentication timer, configure dot1x globally from the
interface from the Interface Configuration mode. The CTS dot1x configuration governs TrustSec NDAC,
not TrustSec EAC processes.
Examples In the following example, a Catalyst 6500 Series switch enters CTS configuration mode without first
enabling dot1x in interface configuration mode:
Router(config-if)# cts dot1x
Warning: Global dot1x is not configured, CTS will not run until dot1x is enabled
. (Gi3/1)
Router(config-if-cts-dot1x)# ?
CTS dot1x configuration commands:
default Set a command to its defaults
exit Exit from CTS dot1x sub mode
no Negate a command or set its defaults
timer CTS timer configuration
Cisco TrustSec Configuration Guide
7-12
OL-22192-01
Page 99
Chapter 7 Cisco TrustSec Command Summary
Related Commands Command Description
default timer
Resets the CTS dot1x reauthentication timer to the default value.
reauthentication (cts
interface)
timer reauthentication
Sets the CTS dot1x reauthentication timer.
(cts interface)
show cts interface Displays CTS interface status and configurations.
show dotx interface Displays IEEE 802.1x configurations and statistics.
cts dot1x
OL-22192-01
Cisco TrustSec Configuration Guide
7-13
Page 100
Chapter 7 Cisco TrustSec Command Summary
default timer reauthentication (cts interface)
default timer reauthentication (cts interface)
Use the default timer reauthentication command in CTS interface configuration mode to reset the CTS
dot1x reauthentication timer to the default value.
default timer reauthentication
Syntax Description
timer reauthentication Sets the CTS reauthentication timer to the default values.
Defaults 3600 seconds
Command Modes CTS interface configuration (config-if-cts-dot1x)
Supported User Roles Administrator
Command History
Release Modification
12.2(33) SXI This command was introduced on the Catalyst 6500 series switches.
Usage Guidelines The default value of the CTS reauthentication timer is the global dot1x reauthentication default (3600
seconds). When this timer expires, the device reauthenticates to the CTS network (NDAC).
Examples The following example resets the CTS reauthentication timer to the global default values:
Router # configure terminal
Router(config)# interface gigabitEthernet 3/1
Router(config-if)# cts dot1x
Router(config-if-cts-dot1x)# default timer reauthentication
Related Commands
Command Description
cts dot1x Enters CTS dot1x interface configuration mode (config-if-cts-dot1x).
timer reauthentication
(cts interface)
show cts interface Displays CTS interface status and configurations.
show dotx interface Displays IEEE 802.1x configurations and statistics.
Cisco TrustSec Configuration Guide
7-14
Sets the CTS reauthentication timer.
OL-22192-01
Loading...