Cisco TrustSec Switch Configuration Guide

 

Syntax Description

 

Defaults

None

 

Command History

 

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:

 

Related Commands

 

Syntax Description

 

Defaults

Caching is disabled.

 

Command History

 

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 the 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. And expediting the formation of the Cisco TrustSec 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 shows how to enable cache support:

 

Related Commands

 

Syntax Description

 

Defaults

None.

 

Command History

 

Usage Guidelines

The cts change-password command allows an administrator to change the password used between the local device and the Cisco Secure ACS authentication server, without having to reconfigure the authentication server.

Note The cts change-password is supported on Cisco Secure ACS, 5.1 and later versions.

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.

Examples

The following example shows how to change the Cisco TrustSec password between a Catalyst 6500 switch and a Cisco Secure ACS:

 

Syntax Description

 

Defaults

None

 

Command History

 

Usage Guidelines

The cts credentials 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 Cisco TrustSec credentials state retrieval is not performed by the nonvolatile generation process (NVGEN) because the Cisco TrustSec credential information is saved in the keystore, and not in the startup configuration. The device can be assigned a Cisco TrustSec identity by the Cisco Secure Access Control Server (ACS), or a new password auto-generated when prompted to do so by the ACS. These credentials are stored in the keystore, eliminating the need to save the running configuration. To display the Cisco TrustSec 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 Cisco TrustSec device ID is changed, all Protected Access Credentials (PACs) are flushed from the keystore because PACs are associated with the old device ID and are not valid for a new identity.

Examples

The following example shows how to configure the Cisco TrustSec device ID and password:

The following example show how to change the Cisco TrustSec device ID and password to cts_new and password123, respectively:

The following sample output displays the Cisco TrustSec device ID and password state:

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Defaults

CTS dot1x configuration on the interface is disabled.

 

Command History

 

Usage Guidelines

Before configuring the TrustSec dot1x reauthentication timer, configure dot1x globally from the interface. The Cisco TrustSec dot1x configuration governs TrustSec NDAC, and not TrustSec EAC processes.

Examples

The following example shows a Catalyst 6500 Series switch enter Cisco TrustSec configuration mode without first enabling dot1x in interface configuration mode:

 

Related Commands

 

Syntax Description

 

Defaults

3600 seconds

 

Command History

 

Usage Guidelines

The default value of the Cisco TrustSec reauthentication timer is 3600 seconds. When this timer expires, the device reauthenticates to the Cisco TrustSec network (NDAC).

Examples

The following example shows how to reset the Cisco TrustSec reauthentication timer to the global default values:

 

Related Commands

 

Syntax Description

 

Defaults

The reauthentication timer is not configured.

 

Command History

 

Usage Guidelines

This command sets the TrustSec reauthentication timer. When this timer expires, the device reauthenticates to the Cisco TrustSec network (NDAC).

Examples

The following example shows how to set the reauthentication timer to 44 seconds:

 

Related Commands

 

Syntax Description

 

Defaults

Cisco TrustSec Layer3 Transport is not enabled.

 

Command History

 

Usage Guidelines

Use the cts policy layer3 global configuration command to specify which traffic and exception commands to apply to the Cisco TrustSec Layer 3 gateway. Use the cts layer3 interface configuration command to enable the Cisco TrustSec Layer 3 gateway interface and to apply the traffic and exception policies.

Examples

The following example shows how to enable a Cisco TrustSec Layer 3 Transport gateway interface:

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Defaults

None

 

Command History

 

Usage Guidelines

Use the cts manual command to enter the TrustSec manual interface configuration in which policies and the Security Association Protocol (SAP) are configured on the link. If the sap or policy sub-commands are not configured, it is as if the interface is not configured for TrustSec.

When cts manual command is configured, 802.1X authentication is not performed on the link. Use the policy subcommand to define and apply policies on the link. By default no policy is applied. To configure MACsec link-to-link encryption, the SAP negotiation parameters must be defined. By default SAP is not enabled. The same SAP Pairwise master key (PMK) should be configured on both sides of the link (that is, a shared secret).

Examples

The following example shows how to enter the Cisco TrustSec manual mode:

 

Related Commands

 

Syntax Description

 

Defaults

No policy is configured.

 

Command History

 

Usage Guidelines

The Cisco TrustSec Layer 3 transport permits Layer 2 SGT-tagged traffic from TrustSec-enabled network segments to be transported over non-TrustSec network segments by the application and removal of a Layer 3 encapsulation at specified Cisco TrustSec Layer 3 gateways. A traffic policy is an access list that lists all the TrustSec-enabled subnets and their corresponding gateway addresses. An exception policy is an access list that lists the traffic on which the Cisco TrustSec Layer 3 transport encapsulation must not be applied.

Specify the traffic and exception policies with the cts policy layer3 {ipv4 | ipv6} traffic access_list and the cts policy layer3 {ipv4 | ipv6} exception access_list global configuration commands. Apply the traffic and exception policies on the Cisco TrustSec Level 3 gateway interface with the cts layer3 {ipv4 | ipv6} policy interface configuration command. Enable the Cisco TrustSec Level 3 gateway interface with the cts layer3 {ipv4 | ipv6} trustsec forwarding interface configuration command.

Configure Cisco TrustSec Layer 3 SGT transport with 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.

• Traffic and exception policies can be downloaded from the authentication server (if supported by your Cisco IOS Release) or manually configured on the device with the ip access-list global configuration command. 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.

Examples

The following example shows how to configure Layer 3 SGT transport to a remote Cisco TrustSec domain:

 

Related Commands

 

Syntax Description

 

Defaults

None

 

Command History

 

Usage Guidelines

To refresh the Peer Authorization Policy on all TrustSec peers, enter cts policy refresh without specifying a peer ID.

The peer authorization policy is initially downloaded from the Cisco ACS at the end of the EAP-FAST NDAC authentication success. The Cisco ACS is configured to refresh the peer authorization policy, but the cts policy refresh command can force immediate refresh of the policy before the Cisco ACS timer expires. This command is relevant only to TrustSec devices that can impose Security Group Tags (SGTs) and enforce Security Group Access Control Lists (SGACLs).

Examples

The following example shows how to refresh the TrustSec peer authorization policy of all peers:

The following sample output displays the TrustSec peer authorization policy of all peers:

 

Related Commands

 

Syntax Description

 

Defaults

None

 

Command History

 

Usage Guidelines

SAP Pair-wise Master Key key (PMK) refresh ordinarily occurs automatically, triggered by combinations of network events and non-configurable internal timers related to dot1X authentication. The ability to manually refresh encryption keys is often part of network administration security requirements. To manually force a PMK refresh use the cts rekey command.

TrustSec supports a manual configuration mode where dot1X authentication is not required to create link-to-link encryption between switches. In this case, the PMK is manually configured on devices on both ends of the link with the sap pmk Cisco TrustSec manual interface configuration command.

Cisco TrustSec NDAC/SAP is supported only on K10 switch which has XgStub2. It is supported on both uplink (where K10 acts as supplicant) and down link with linecard that has XgStub2 (where K10 acts as authenticator).

Examples

The following example shows how to regenerate the PMK on a specified interface.

 

Related Commands

 

Syntax Description

 

Command Default

None

 

Command History

 

Usage Guidelines

The cts role-based policy trace procedure is summarized as follows:

1. Discover the network path.

Know the topology of the entire TrustSec network before executing the command. Standard network discovery methods such as IP traceroute, Cisco Discovery Protocol, or other methods can be used to obtain this information.

2. Starting from the host and continuing to the farthest node; log-in to each device in the path.

3. Execute the cts role-based policy trace command on each device.

Based on the input arguments, the command output reports the outgoing SGT value and SGACL entry/ACE. Apply the SGT value from the output as the input SGT on the next switch in the path.

If you do not provide the (optional) SGT argument in the command line, the output reports the SGT assigned to the packet along with any available binding information.

For example, a packet may be dropped because a device is blocking UDP packets, which may indicate a problem with an SGACL configuration or SGACL refresh obtained from another device, such as the Cisco Integrated Services Engine (Cisco ISE). The policy trace command would identify on which device the SGACL was enforced and which ACE was blocking.

Examples

The following example shows how to specify a source interface on the source host for an xdmcp over UDP packet.

The following example traces an HTTP over UDP packet from an IPv6 host:

 

Related Commands

 

Syntax Description

 

Defaults

None

 

Command History

 

Usage Guidelines

If you do not have a Cisco Identity Services Engine, Cisco Secure ACS, dynamic Address Resolution Protocol (ARP) inspection, Dynamic Host Control Protocol (DHCP) snooping, or Host Tracking available on your switch to automatically map SGTs to source IP addresses, you can manually map an SGT to the following with the cts role-based sgt-map command:

• A single host IPv4 or IPv6 address
• All hosts of an IPv4 or IPv6 network or subnetwork
• VRFs
• Single or multiple VLANs
• A Layer 3 physical or logical interface

Single Host Address-to-SGT Binding

The cts role-based sgt-map host command binds the specified SGT with incoming packets when the IP source address is matched by the specified host address. This IP-SGT binding has the lowest priority and is ignored in the presence of any other dynamically discovered bindings from other sources (such as, SXP or locally authenticated hosts). The binding is used locally on the switch for SGT imposition and SGACL enforcement. It is exported to SXP peers if it is the only binding known for the specified host IP address.

Network or Subnetwork Addresses-to-SGT Binding

The cts role-based sgt-map command binds the specified SGT with packets that fall within the specified network address.

SXP exports an exhaustive expansion of all possible individual IP–SGT bindings within the specified network or subnetwork. IPv6 bindings and subnet bindings are exported only to SXP listener peers of SXP version 2 or later. The expansion does not include host bindings which are known individually or are configured or learnt from SXP for any nested subnet bindings.

VRF-to-SGT Bindings

The vrf keyword specifies a virtual routing and forwarding table previously defined with the vrf definition global configuration command. The IP-SGT binding specified with the cts role-based sgt-map vrf global configuration command is entered into the IP-SGT table associated with the specified VRF and the IP protocol version which is implied by the type of IP address entered.

VLAN-to-SGT Mapping

The cts role-based sgt-map vlan-list command binds an SGT with a specified VLAN or a set of VLANs. The keyword all is equivalent to the full range of VLANs supported by the switch and is not preserved in the nonvolatile generation (NVGEN) process. The specified SGT is bound to incoming packets received in any of the specified VLANs.

The system uses discovery methods such as DHCP and/or ARP snooping (a.k.a. IP device tracking) to discover active hosts in any of the VLANs mapped by this command. Alternatively, the system could map the subnet associated with the SVI of each VLAN to the specified SGT. SXP shall export the resulting bindings as appropriate for the type of binding.

The bindings for each mapped VLAN is inserted into the IP-SGT table that is associated with the VRF, the VLAN is mapped to by either its SVI or by the cts role-based l2-vrf command.

Layer 3 Interface Mapping (L3IF)

The cts role-based sgt-map interface command binds a specified Layer 3 logical interface to a security group name or to an SGT. A security group information table that maps SGTs to security group names is downloaded from the authentication server with the TrustSec environment data. The cts role-based sgt-map interface security-group command is rejected if a security group name table is not available.

Whenever a security group table is downloaded for the first time or refreshed, all L3IF mappings are reprocessed. IP–SGT bindings are added, updated, or deleted for all network prefixes that have output paths through the specified interface.

IP-SGT binding configured through the CLI has lower priority than any other binding. The CLI binding is ignored in the presence of any other dynamically discovered binding from other sources such as SXP or locally authenticated hosts.The binding is used locally on the system for SGT imposition and SGACL enforcement and is exported to SXP peers if it is the only binding known for the given host IPv4 or IPv6 address.

IPv6 bindings and subnet bindings are exported by SXP only to SXP peers capable of handling them. SXP listeners which support SXP version 2 are capable of handling IPv6 and subnet bindings. SXP expands the IPv4 subnet bindings to all possible individual host bindings and exports them to SXP peers running version 1 of SXP protocol. The expansion shall not include host bindings which are known individually or are configured or learnt from SXP for any nested subnet bindings.

The keyword vrf when entered must be followed by a name of an already defined VRF. The binding specified by this command is entered into the IP-SGT table associated with the specified VRF and the IP protocol version entered.

The following error message is shown when the VRF name entered does not exist:

%VPN Routing/Forwarding table <VRF name> does not exist

The following error message is shown when the specified VRF name does exists but the IP protocol version implied is not enabled in the VRF:

Binding Source Priorities

TrustSec resolves conflicts among IP-SGT binding sources in the master binding database with a strict priority scheme. For example, an SGT may also be applied to an interface with the
policy { dynamic identity peer-name | static sgt tag } command (Identity Port Mapping). The current priority enforcement order, from lowest to highest, 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 Cisco TrustSec-capable link.

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.

Layer 2 VRF Assignment

For the [ no ] cts role-based l2-vrf vrf-name vlan-list { vlan-list | all } global configuration command, the vlan-list argument can be a single VLAN ID, a list of comma-separated VLAN IDs, or hyphen-separated VLAN ID ranges.

The keyword all is equivalent to the full range of VLANs supported by the network device. The keyword all is not preserved in the nonvolatile generation (NVGEN) process.

If the cts role-based l2-vrf command is issued more than once for the same VRF, each successive command entered adds the VLAN IDs to the specified VRF.

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 VRF of the SVI.

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 changed. When reactivated, the IP–SGT bindings are moved back from the FIB table associated with the VRF of the SVI to the FIB table associated with the VRF assigned by the cts role-based l2-vrf command.

Role-based Enforcement

Use the [ no ] cts role-based enforcement command to globally enable or disable SGACL enforcement for Cisco TrustSec-enabled Layer 3 interfaces in the system.

Note The terms Role-based Access Control and Role-based ACLs that appear in the Cisco TrustSec CLI command description is equivalent to Security Group Access Control List (SGACL) in Cisco TrustSec documentation.

VLAN Enforcement

Use the [ no ] cts role-based enforcement vlan-list { v lan-ids | all } command to enable or disable SGACL enforcement for Layer 2 switched packets and for Layer 3 switched packets on an SVI interface.

The vlan-ids argument can be a single VLAN ID, a list of VLAN IDs, or VLAN ID ranges.

The keyword all is equivalent to the full range of VLANs supported by the platform (For example, the Catalyst 6500 VLAN range is from 1 to 4094). SGACLs are enforced on all VLANs of all specified lists. The keyword all is not preserved in the nonvolatile generation (NVGEN) process.

Note SGACL enforcement is not enabled by default on VLANs. The cts role-based enforcement vlan-list command must be issued to enable SGACL enforcement on VLANs.

Note When a VLAN in which a role-based access control (RBAC) is enforced has an active SVI, the RBAC is enforced for both Layer 2 and Layer3 switched packets within that VLAN. Without an SVI, the RBAC is enforced only for Layer 2 switched packets, because no Layer 3 switching is possible within a VLAN without an SVI.

Defining an IPv4 RBACL

A management system (For example, the Cisco Secure ACS) is typically used to define and manage RBACLs globally within the enterprise. However, local definition of RBACLs is used primarily for testing or as a fallback policy in the absence of a dynamic downloaded policy from ACS. The following command defines an RBACL that could be applied to IPv4 traffic and enters role-based access list configuration mode:

Defining an IPv4 RBACL ACE

Following commands are used to define ACEs of an IPv4 RBACL.

• Switch(config-rb-acl)# [sequence-number | no] {permit | deny} protocol [option option-name] {[precedence precedence] [tos tos] | [dscp dscp]} [log] [fragments]
• Switch(config-rb-acl)# [sequence-number | no] [permit | deny] icmp [icmp-type [icmp-code] | icmp-message] {[precedence precedence] [tos tos] | [dscp dscp]} [log] [fragments]
• Switch(config-rb-acl)# [sequence-number | no] {permit | deny} tcp [src operator {src-port}+] [dst operator {dst-port}+] {[precedence precedence] [tos tos] | [dscp dscp]} [log] [fragments] [established | {{match-any | match-all} {{+ | -}flag-name}+]
• Switch(config-rb-acl)# [sequence-number | no] {permit | deny} udp [src operator {src-port}+] [dst operator {dst-port}+] {[precedence precedence] [tos tos] | [dscp dscp]} [log] [fragments]
• Switch(config-rb-acl)# [sequence-number | no] {permit | deny} igmp [igmp-type] {[precedence precedence] [tos tos] | [dscp dscp]} [log] [fragments]

Definin an IPv6 RBACL

The following command defines an RBACL that could be applied to IPv6 traffic and enters IPv6 role-based access list configuration mode:

Defining an IPv6 RBACL ACE

Following commands are used to define ACEs of an IPv6 RBACL.

• Switch(config-ipv6rb-acl)# [no] {permit | deny} protocol [dest-option | dest-option-type {doh-number | doh-type}] [dscp cp-value] [flow-label fl-value] [mobility | mobility-type {mh-number | mh-type}] [routing | routing-type routing-number] [fragments] [log | log-input] [sequence seqno]
• Switch(config-ipv6rb-acl)# [no] [permit | deny] icmp [icmp-type [icmp-code] | icmp-message] [dest-option | dest-option-type {doh-number | doh-type}] [dscp cp-value] [flow-label fl-value] [mobility | mobility-type {mh-number | mh-type}] [routing | routing-type routing-number] [fragments] [log | log-input] [sequence seqno]
• Switch(config-ipv6rb-acl)# [no] {permit | deny} tcp [src operator {src-port}+] [dst operator {dst-port}+] [established | [ack] [rst]] [fin] [psh] [syn] [urg] [dest-option | dest-option-type {doh-number | doh-type}] [dscp cp-value] [flow-label fl-value] [mobility | mobility-type {mh-number | mh-type}] [routing | routing-type routing-number] [fragments] [log | log-input] [sequence seqno]
• Switch(config-ipv6rb-acl)# [no] {permit | deny} udp [src operator {src-port}+] [dst operator {dst-port}+] [dest-option | dest-option-type {doh-number | doh-type}] [dscp cp-value] [flow-label fl-value] [mobility | mobility-type {mh-number | mh-type}] [routing | routing-type routing-number] [fragments] [log | log-input] [sequence seqno]

Attaching SGACL Policies

Use the [ no ] cts role-based permissions command to define, replace, or delete the list of RBACLs for a given <SGT, DGT> pair. This policy is in effect as long as there is no dynamic policy for the same DGT or SGT.

Note Static policies can be defined for individual cells in the SGT matrix. Dynamic policies from ACS, however, are defined for the entire row or column. Dynamic and static policies cannot be used together.

Assuming both row and column are downloaded, the static cell <SGT, DGT> will be overridden by the dynamic policy for SGT or DGT even if those policies do not have an explicit cell for <SGT, DGT>.

The statically configured policy defined by this command is restored after connectivity with ACS is lost and not regained before a covering policy from ACS is expired. This command is intended as a fallback policy or during testing or experimenting with RBACL enforcement.

• The from clause specifies the source SGT and the to clause specifies the destination SGT. Both a from clause and a to clause must be specified. Either clause can specify numeric value for SGT in the range from 0 to 65533 or one of the keywords unknown, or multicast-unknown.
• unknown —Selects RBACLs that are applied for unicast packets whose source SGT or destination SGT cannot be determined by the system.
• multicast-unknown —Selects RBACLs of a multicast send or multicast receive policy when the SGT of the multicast stream cannot be determined.
• rbacl name —Name of an RBACL already defined. The RBACL could be an RBACL that was defined by CLI (using ip access-list role-based name) or an RBACL that was defined by policy downloaded from ACS.
• ipv4 (optional) keyword indicates that RBACLs attached by this command are IPv4 RBACLs. This is the default and if neither IPv4 nor IPv6 are specified, the command will expect each of the given <rbacl name> to be an IPv4 RBACL.
• ipv6 keyword indicates that the RBACLs attached by this command are IPv6 RBACLs. It is mandatory to specify the keyword ipv6 when attaching IPv6 RBACLs. The command will not make an attempt to figure out on its own the IP protocol version from the attached RBACLs.

The cts role-based permissions default [ ipv4 | ipv6 ] < rbacl name >+ command defines, replaces, or deletes the list of RBACLs of the unicast default policy. This policy remains in effect as long as no dynamic unicast default policy is downloaded from ACS.

The cts role-based permissions multicast-send-default < rbacl name >+ command defines, replaces, or deletes the list of RBACLs of the multicast send default policy. This policy remains in effect as long as no dynamic multicast send default policyis downloaded from ACS.

The cts role-based permissions multicast-receive-default < rbacl name > command defines, replaces, or deletes the single RBACL of the multicast receive default policy. This policy remains in effect as long as no dynamic multicast receive default policy has been downloaded from ACS.

Flexible Net Flow

Flexible NetFlow can account for packets dropped by SGACL enforcement when SGT and DGT flow objects are configured in the flow record with the standard 5-tuple flow objects.

Use the flow record and flow exporter global configuration commands to configure a flow record, and a flow exporter, then use the flow monitor command add them to a flow monitor.

To collect only SGACL dropped packets, use the [ no ] cts role-based { ip | ipv6 } flow monitor dropped global configuration command.

For Flexible NetFlow overview and configuration information, see the following documents:

Getting Started with Configuring Cisco IOS Flexible NetFlow

http://www.cisco.com/en/US/docs/ios/fnetflow/configuration/guide/get_start_cfg_fnflow.html

Cisco IOS Flexible NetFlow Configuration Guide, Release 15.0SY

http://www.cisco.com/en/US/docs/ios-xml/ios/fnetflow/configuration/15-0sy/fnf-15-0sy-book.html

Examples

In the following example, a Catalyst 4500 series switch binds host IP address 10.1.2.1 to SGT 3 and 10.1.2.2 to SGT 4. These bindings are forwarded by SXP to an SGACL enforcement switch.

 

Related Commands

 

Syntax Description

deadtime timer_secs	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 from 1 to 864000.
load-balance method least-outstanding	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.
batch-size transactions	(Optional) The number of transactions to be assigned per batch. The default is 25. Note Batch size may impact throughput and CPU load. It is recommended that the default batch size, 25, be used because it is optimal for high throughput, without adversely impacting CPU load.
ignore-preferred-server	(Optional) Instructs the switch not to use the same server throughout a session.
key-wrap enable	Enables AES Key Wrap encryption for Trustsec RADIUS server communications.

 

Defaults

 

Command History

 

Usage Guidelines

Use the key-wrap keyword when operating the switch in FIPS mode.

Examples

The following example shows how to configure server settings and how to display the Cisco TrustSec server list:

 

Related Commands

 

Syntax Description

 

Defaults

Test is enabled for all servers.

 

Command History

 

Usage Guidelines

Because the server-liveness is enabled by default, you may receive failed authentication messages from the user CTS-Test-Server. The server-liveness probes a specified RADIUS server or all servers in the dynamic server list, and when a RADIUS server does not respond, the switch will mark it as down and sends the failed authentication message. You can disable these messages by using the no cts server test command.

To configure a password for the CTS-Test-Server user, configure the username command in global configuration mode.

Examples

The following example shows how to configure server settings and how to display the Cisco TrustSec server list:

The following example shows how to configure a password for the CTS-Test-Server user:

Switch(config)# username CTS-Test-Server password 0 Password123

 

Related Commands

 

Syntax Description

 

Defaults

No SGT number is assigned.

 

Command History

 

Usage Guidelines

In Cisco TrustSec, 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.

Examples

The following example shows how to manually configure an SGT on the network device:

 

Related Commands

 

Syntax Description

 

Defaults

 

Command History

 

Usage Guidelines

This command enables SXP, determines the SXP password, the peer speaker/listener relationship, and the reconciliation period.

When an SXP connection to a peer is configured with the cts sxp connection peer command, only the connection mode can be changed. The vrf keyword is optional. If a VRF name is not provided or a VRF name is provided with name “default,” the connection is set up in the default routing or forwarding domain.

The default setting for an SXP connection password is none. Because SXP connection is configured per IP address, a device with many peers can have many SXP connections. The cts sxp default password command sets the default SXP password to be optionally used for all SXP connections configured on the device. The SXP password can be cleartext or encrypted. The default is type 0 (cleartext). If the encryption type is 6 or 7, the encryption password argument must be a valid type 6 or type 7 ciphertext.
Use the no cts sxp default password command to delete the SXP password.

The cts sxp default source-ip command sets the default source IP address that SXP uses for all new TCP connections when a source IP address is not specified. Pre-existing TCP connections are not affected when this command is entered. If neither the default nor the peer-specific source IP address is configured, then the source-IP address will be derived from existing local IP addresses and could potentially be different for each TCP connection initiated from the device.

SXP connections are governed by three timers:

• Retry timer
• Delete Hold Down timer
• Reconciliation timer

Retry Timer

The Retry timer is triggered if at least one SXP connection that is not up. A new SXP connection is attempted when this timer expires. Use the cts sxp retry period command to configure this timer value. The default value is 120 seconds. The range is from 0 to 64000 seconds. A zero value results in no retry being attempted.

Delete Hold Down Timer

The Delete Hold Down timer value is not configurable and is set to 120 seconds. This timer is triggered when an SXP listener connection goes down. The IP-SGT mappings learned from the down connection are deleted when this timer expires. If the down connection is restored before the Delete Hold Down timer expires, the Reconciliation timer is triggered.

Reconciliation Timer

After a peer terminates an SXP connection, an internal Delete Hold-down timer starts. If the peer reconnects before the Delete Hold Down timer expires, the SXP Reconciliation 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. Use the cts sxp reconciliation period command to configure this timer.

Examples

The following example shows how to enable SXP, and configure the SXP peer connection on SwitchA, a speaker, for connection to SwitchB, a listener:

The following example shows how to configure the SXP peer connection on SwitchB, a listener, for connection to SwitchA, a speaker:

 

Related Commands

 

Syntax Description

 

Defaults

None

 

Command History

Examples

The following example deletes environment data from the cache:

Note Clearing peer authorization and SGT policies are relevant only to TrustSec devices capable of enforcing SGACLs.

 

Related Commands

 

Syntax Description

 

Defaults

None

 

Command History

 

Usage Guidelines

The c lear cts counter command clears the Cisco TrustSec counters specific to the selected interface. If no interface is specified, all of the TrustSec counters on all TrustSec interfaces are cleared.

Examples

The following example shows how to clear Cisco TrustSec statistics for GigabitEthernet interface 3/1, and then verify with the show cts interface command (a fragment of the show command output is displayed):

Switch# clear cts counter gigabitEthernet3/1

Switch# show cts interface gigabitEthernet3/1

Global Dot1x feature is Disabled

Interface GigabitEthernet3/1:

<snip>

Statistics:

authc success: 0

authc reject: 0

authc failure: 0

authc no response: 0

authc logoff: 0

authz success: 0

authz fail: 0

port auth fail: 0

<snip>

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Defaults

None

 

Command History

Examples

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Defaults

None

 

Command History

Examples

The following example shows how to clear environment data from cache:

 

Related Commands

 

Syntax Description

 

Command History

Examples

The following example shows how to clear the counters on a GigabitEthernet interface on a Catalyst 6500 series switch:

 

Related Commands

 

Syntax Description

 

Defaults

None

 

Command History

Examples

The following command clears all PACs in the keystore:

 

Related Commands

 

Syntax Description

 

Defaults

None

 

Command History

 

Usage Guidelines

To clear the peer authorization policy of all TrustSec peers, use the clear cts policy peer command without specifying a peer ID. To clear the Security Group tag of the TrustSec peer, use the clear cts policy sgt command.

Examples

The following example shows how to clear the peer authorization policy of the TrustSec peer with the peer ID peer1:

 

Related Commands

 

Syntax Description

 

Command History

 

Usage Guidelines

Use the clear cts role-based counters command to clear the Security Group ACL (SGACL) enforcement counters.

Specify the source SGT with the from keyword and the destination SGT with the to keyword. The counters for the entire permission matrix are cleared when both the from and to keywords are omitted.

The default keyword clears the statistics of the default unicast policy.

Examples

The following example shows how to clear all role-based counters:

 

Related Commands

 

Syntax Description

 

Command History

 

Usage Guidelines

This command removes a server configuration from the list of Cisco Trustsec AAA servers configured using the cts authorization list command, or the AAA server list provisioned by the Cisco TrustSec authenticator peer.

Examples

The following example removes the AAA server 10.10.10.1 from the Cisco TrustSec AAA server list.

 

Related Commands

 

Syntax Description

 

Defaults

None

 

Command History

Examples

The following example re-enables SGT propagation:

 

Related Commands

 

Syntax Description

 

Command History

 

Usage Guidelines

When any of the debug cts commands are enbled, debugging messages for the specified Cisco TrustSec service is logged. The debug condition cts command filters these debugging messages by setting match conditions for Peer ID, SGT or Security Group Name.

For SXP messages, debug conditions can be set for source and destination IP addresses. To filter by VRF, or IP-to-SGT bindings, use the conditional debug commands— debug condition ip, and debug condition vrf.

The debug conditions are not saved in the running-configuration file.

Examples

In following example, messages for debug cts ifc events and debug cts authentication details are filtered by peer-id, SGT, and SGN. Interface Controller (ifc) and Authentication debug messages are displayed only if the messages contain the peer-id=“Zoombox” or security-group tag = 7 or security-group name=“engineering”:

In the following example, SXP connection and mapping database messages are filtered by IP address and SGT. Only SXP debug messages that contain IP address 10.10.10.1, or security-group tag = 8, or security-group name = “engineering” are displayed.

 

Related Commands

 

Syntax Description

 

Command History

 

Usage Guidelines

To restore the Cisco TrustSec manual interface configuration mode parameters to default values, use the default command.

Examples

The following example shows how to restore the default dynamic policy and SGT propagation policies of a Cisco TrustSec-enabled interface:

 

Related Commands

 

Syntax Description

 

Defaults

None

 

Command History

 

Usage Guidelines

Flexible NetFlow accounts for packets dropped by SGACL enforcement when SGT and DGT flow objects are configured in the flow record with standard 5-tuple flow objects.

Use the flow record and flow exporter global configuration commands to configure a flow record, and a flow exporter, then use the flow monitor command to add them to a flow monitor.

To collect only SGACL dropped packets, use the [ no ] cts role-based { ip | ipv6 } flow monitor dropped global configuration command.

Examples

The following example configures an IPV4 Flow Record (5-tuple, direction, SGT, DGT):

 

Related Commands

 

Syntax Description

 

Defaults

Ingress or egress reflectors are not configured.

 

Command History

Examples

The following example shows how to enable the Cisco TrustSec ingress reflector on a Catalyst 6500 switch:

The following example shows how to disable the Cisco TrustSec ingress reflector on a Catalyst 6500 switch:

 

Related Commands

 

Syntax Description

 

Defaults

Policy is not configured.

 

Command History

 

Usage Guidelines

Use the policy command to apply a policy when manually configuring a TrustSec link. The default is no policy which passes all traffic without applying an SGT. The sap cts manual mode command must also be configured to bring up a TrustSec link.

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.

The authorization policy can specify the peer's SGT, peer SGT assignment trust state, RBACLs for the associated peer SGT, or an interface ACL.

• 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.

For statically configured SGTs no RBACL is applied, but traditional interface ACL can be configured separately for traffic filtering if required.

Examples

The following example shows how to apply SGT 3 to incoming traffic from the peer, except for traffic already tagged (the interface that has no communication with a Cisco Secure ACS server):

 

Related Commands

 

Syntax Description

 

Defaults

SGT derivation and CMD tagging exemption are both disabled by default.

 

Command History

 

Usage Guidelines

SGT Derivation for Switched Traffic

With Cisco TrustSec, Catalyst 4500 switches can classify packets transmitted through the switch into different user groups. Depending on the user group of a packet, specific actions can then be imposed on the packet. The SGT enables you to impose these actions.

An SGT may be a source user group tag or a destination user group tag. A source user group tag is added by a switch that is close to the source of the packet, and a destination user group tag is added by a switch in the same network, but closer to the destination of the packet.

The addition of the source user group tag for both switched and routed packets is handled by the forwarding engine of switch, with the help of the Forward Information Base (FIB). The addition of a destination user group tag for a routed packet is also handled by the forwarding engine, but the addition of a destination user group tag for a switched packet is handled by the input ACL engine, with the help of input ACL TCAM entries.

When you add a new SGT binding, the new entry is programmed into the first available free space in the TCAM block - in the order of entry. For example, if you add entries in the order shown below, the generic entry (1.0.0.0/8) is programmed in the lowest index, and not the specific entry (1.0.0.1).

TCAM search progresses from the lowest index of the block to the highest index and search stops when the first matching entry is found. When traffic ingresses the switch, the above entries mean that for a packet with destination IP address 1.0.0.1, the TCAM lookup is matched to generic entry 1.0.0.0/8 and destination user group tag 20 is assigned, even though you have made a more specific entry for packets with the destination address 1.0.0.1.

To program TCAM entries in an optimal way and to ensure that TCAM search matches specific entries (when they are available), enter the platform-cts subnet-sgt l2traffic enable command in global configuration mode.

Note Before you enable or disable [no] platform-cts subnet-sgt l2traffic enable, ensure that you have disabled Cisco TrustSec global enforcement, that is, ensure that you have configured the no cts role-based enforcement command in global configuration mode.

The [ no ] platform-cts subnet-sgt l2traffic enable command applies to IPv4 and 1Pv6 addresses.

Use the show running-config command in privileged EXEC mode to know if platform-cts subnet-sgt l2traffic enable command is enabled. For example:

Exemption of Control PDUs from CMD Tagging

Cisco TrustSec-enabled devices support the enforcement of policies on packets based on a pair of SGTs. SGTs are propagated hop-by-hop, between neighboring peers. The CMD file in a packet’s header carries the relevant SGT information.

In a typical layer 2 operation, the CMD header is inserted in the frame header before being sent out of a Cisco TrustSec-enabled interface. This is done by configuring the cts manual command in interface configuration mode, and the propagate sgt command in Cisco TrustSec manual interface configuration mode. After the packet is received by the peer switch, the CMD tag is parsed and the SGT, extracted.

Note When you configure the propagate sgt Cisco TrustSec manual interface configuration command on a link, a Catalyst 4500 switch adds the CMD header in the L2 frame header for all packets, control and data.

If a peer switch is unable to process a layer 2 frame (and drops such packets), then consider exempting CMD tagging by entering the platform-cts stub l2-control-pdu cmd-exempt command in global configuration mode. By enabling the command, you can exempt the control PDUs leaving a Catalyst 4500 switch, from CMD tagging, and also accept packets transmitted on a Cisco TrustSec-enabled link without a CMD tag.

For example, certain linecards in the Cisco Nexus 7000 Series cannot process a Layer 2 packet unless it has a 802.1Q tag. If such a line card is a peer for a Catalyst 4500 switch, you may encounter the following situation and may want to configure the command:
A trunk port on the Catalyst 4500 switch transmits selected control packets through a native VLAN. Further, the packets are transmitted with a CMD tag (because the corresponding interfaces are configured to add a CMD header), but without a 802.1Q tag (either because native VLAN tagging is not enabled or because some control packets do not support tagging), then such packets are dropped by the peer. Configure the platform-cts stub l2-control-pdu cmd-exempt command to prevent such pack drops.

Note For the CMD tagging exemption to work as expected, configure the platform-cts stub l2-control-pdu cmd-exempt command in global configuration mode first and then the cts manual command in interface configuration mode. If cts manual is already configured, then disable and reenable on the required interfaces.