The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This chapter describes how to configure Cisco TrustSec on Cisco NX-OS devices.
This chapter includes the following sections:
Your software release might not support all the features documented in this module. For the latest caveats and feature information, see the Bug Search Tool at https://tools.cisco.com/bugsearch/ and the release notes for your software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "New and Changed Information"chapter or the Feature History table in this chapter.
This section provides information about Cisco TrustSec.
The Cisco TrustSec security architecture builds secure networks by establishing clouds of trusted network devices. Each device in a cloud is authenticated by its neighbors. Communication on the links between devices in the cloud is secured with a combination of encryption, message integrity checks, and data-path replay protection mechanisms. Cisco TrustSec uses the device and user identification information acquired during authentication for classifying, or coloring, the packets 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, also 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.
 Note |
Ingress refers to entering the first Cisco TrustSec-capable device encountered by a packet on its path to the destination, and egress refers to leaving the last Cisco TrustSec-capable device on the path. |
The Cisco TrustSec architecture consists of the following major components:
A Cisco TrustSec network has the following entities:
When the link between the supplicant and the AT comes up, the following sequence of events might occur:
The ports stay in the unauthorized state (blocking state) until the SA protocol negotiation is complete.
SA protocol negotiation can use any of the following modes of operation:
Galois/Counter Mode (GCM) encryption
GCM authentication (GMAC)
No encapsulation (clear text)
Encapsulation with no encryption or authentication
Based on the IEEE 802.1AE standard, Cisco TrustSec uses ESP-128 GCM and GMAC.
Cisco TrustSec authenticates a device before allowing it to join the network. Cisco TrustSec uses 802.1X authentication with Extensible Authentication Protocol Flexible Authentication through Secure Tunnel (EAP-FAST) as the Extensible Authentication Protocol (EAP) method to perform the authentication.
Cisco TrustSec uses EAP-FAST for authentication. EAP-FAST conversations allow other EAP method exchanges inside the EAP-FAST tunnel using chains, which allows administrators to 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.
The implementation of EAP-FAST for Cisco TrustSec has the following enhancements:
In 802.1X, the AT must have IP connectivity with the authentication server because it has to relay the authentication exchange between the supplicant and the AT using RADIUS over UDP/IP. When an endpoint device, such as a PC, connects to a network, it is obvious that it should act 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 AT and supplicant roles for the Cisco NX-OS devices, Cisco TrustSec runs a role-selection algorithm to automatically determine which Cisco NX-OS device acts as the AT and which device acts as the supplicant. The role-selection algorithm assigns the AT role to the device that has IP reachability to a RADIUS server. Both devices start both the AT and supplicant state machines. When a Cisco NX-OS device detects that its peer has access to a RADIUS server, it terminates its own AT state machine and assumes the role of the supplicant. If both Cisco NX-OS devices have access to a RADIUS server, the algorithm compares the MAC addresses used as the source for sending the EAP over LAN (EAPOL) packets. The Cisco NX-OS device that has the MAC address with the higher value becomes the AT and the other Cisco NX-OS device becomes the supplicant.
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 AT
Authenticated the user if the supplicant is an endpoint device
At the end of the Cisco TrustSec authentication process, the AT and the supplicant have the following information:
Device ID of the peer
Cisco TrustSec capability information of the peer
Key used for the SA protocol
Cisco TrustSec does not use IP addresses or MAC addresses as device identities. Instead, assign a name (device ID) to each Cisco TrustSec-capable Cisco NX-OS device to identify it uniquely in the Cisco TrustSec network. This device ID is used for the following:
Looking up authorization policy
Looking up passwords in the databases during authentication
Cisco TrustSec supports password-based credentials. The authentication servers may use self-signed certificates instead. Cisco TrustSec authenticates the supplicants through passwords and uses MSCHAPv2 to provide mutual authentication even if the authentication server certificate is not verifiable.
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.
The authentication server uses a temporarily configured password to authenticate the supplicant when the supplicant first joins the Cisco TrustSec network. When the supplicant first joins the Cisco TrustSec network, the authentication server authenticates the supplicant using a manufacturing certificate and then generates a strong password and pushes it to the supplicant with the PAC. The authentication server also keeps the new password in its database. The authentication server and the supplicant use this password for mutual authentication in all future EAP-FAST phase 0 exchanges.
Cisco TrustSec does not require a specific type of user credentials for endpoint devices. You can choose any type of authentication method for the user (for example, MSCHAPv2, LEAP, generic token card (GTC), or OTP) and use the corresponding credentials. Cisco TrustSec performs user authentication inside the EAP-FAST tunnel as part of the EAP-FAST phase 2 exchange.
MACSec is supported over FabricPath through native VLAN tagging on trunk and FabricPath ports feature. Native VLAN tagging can be configured either globally or on an interface for control packets and data packets. Use the following commands to enable native VLAN tagging globally:
vlan dot1q tag native exclude control
vlan dot1q tag native fabricpath
vlan dot1q tag native fabricpath exclude control
Use the following commands to enable native VLAN tagging on FabricPath ports:
switchport trunk native vlan tag exclude control
switchport fabricpath native vlan tag
switchport fabricpath native vlan tag exclude control
Native VLAN tagging provides support for tagged and untagged modes when sending or receiving packets. The following table explains the mode for a packet on a global configuration or port configuration for the above commands.
|
Tagging Configuration |
TX-Control |
TX-Data (Native VLAN) |
RX-Control |
RX-Data |
|---|---|---|---|---|
|
Global trunk port tagging |
Untagged |
Tagged |
Untagged and tagged |
Tagged |
|
Global FabricPath tagging |
Untagged |
Untagged |
Untagged and tagged |
Untagged and tagged |
|
Global FabricPath tagging for data packets |
Untagged |
Tagged |
Untagged and tagged |
Tagged |
|
Port-level trunk port tagging |
Untagged |
Tagged |
Untagged and tagged |
Tagged |
|
Port-level Fabricpath tagging |
Untagged |
Untagged |
Untagged and tagged |
Untagged and tagged |
|
Port-level FabricPath tagging for data packets |
Untagged |
Tagged |
Untagged and tagged |
Tagged |
In security group access lists (SGACLs), you can control the operations that users can perform based on assigned security groups. The grouping of permissions into a role simplifies the management of the security policy. As you add users to a Cisco NX-OS device, you simply assign one or more security groups and they immediately receive the appropriate permissions. You can modify security groups to introduce new privileges or restrict current permissions.
Cisco TrustSec assigns a unique 16-bit tag, called the security group tag (SGT), to a security group. The number of SGTs in a Cisco NX-OS device is limited to the number of authenticated network entities. The SGT is a single label that indicates the privileges of the source within the entire enterprise. Its scope is global within a Cisco TrustSec network.
The management server derives the SGTs based on the security policy configuration. You do not have to configure them manually.
Once authenticated, Cisco TrustSec tags any packet that originates from a device with the SGT that represents the security group to which the device is assigned. The packet carries this SGT throughout the network within the Cisco TrustSec header. Because this tag represents the group of the source, the tag is referred to as the source SGT. At the egress edge of the network, Cisco TrustSec determines the group that is assigned to the packet destination device and applies the access control policy.
Cisco TrustSec defines access control policies between the security groups. By assigning devices within the network to security groups and applying access control between and within the security groups, Cisco TrustSec essentially achieves access control within the network.
The Cisco NX-OS device defines the Cisco TrustSec access control policy for a group of devices as opposed to IP addresses in traditional ACLs. With such a decoupling, the network devices are free to move throughout the network and change IP addresses. Entire network topologies can change. As long as the roles and the permissions remain the same, changes to the network do not change the security policy. This feature greatly reduces the size of ACLs and simplifies their maintenance.
In traditional IP networks, the number of access control entries (ACEs) configured is determined as follows:
Number of ACEs = (number of sources specified) X (number of destinations specified) X (number of permissions specified)
Cisco TrustSec uses the following formula:
Number of ACEs = number of permissions specified
For information about SGACL policy enforcement with SGT caching, see SGACL Policy Enforcement With Cisco TrustSec SGT Caching.
A network device at the ingress of the Cisco TrustSec network cloud needs to determine the SGT of the packet entering the Cisco TrustSec network cloud so that it can tag the packet with that SGT when it forwards it into the Cisco TrustSec network cloud. The egress network device needs to determine the SGT of the packet so that it can apply the SGACLs.
The network device can determine the SGT for a packet using one of the following methods:
Obtain the source SGT during policy acquisition—After the Cisco TrustSec authentication phase, a network device acquires a policy from an authentication server. The authentication server indicates whether the peer device is trusted or not. If a peer device is not trusted, the authentication server can also provide an SGT to apply to all packets coming from the peer device.
Obtain the source SGT field from the Cisco TrustSec header—If a packet comes from a trusted peer device, the Cisco TrustSec header carries the correct SGT field if the network device is not the first network device in the Cisco TrustSec network cloud for the packet.
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 the source IP address. The SGT Exchange Protocol (SXP) can also populate the IP-address-to-SGT mapping table.
The egress network device in a Cisco TrustSec network cloud determines the destination group for applying the SGACL. In some cases, ingress devices or other nonegress devices might have destination group information available. In those cases, SGACLs might be applied in these devices rather than in egress devices.
Cisco TrustSec determines the destination group for the packet in the following ways:
Destination SGT of the egress port obtained during the policy acquisition
Destination SGT lookup based on the destination IP address
cts role-based access-list acl-on-fex-egress
deny udp
deny ip
cts role-based sgt 9 dst 0 access-list acl-on-fex-egressFrom Cisco NX-OS Release 7.3(0)D1(1), you can use the SGACL detailed logging feature to observe the effects of SGACL policies after their enforcement at the egress point. You can check the following:
Whether a flow is permitted or denied
Whether a flow is monitored or enforced by the SGACL
By default, the SGACL detailed logging feature is disabled.
Note |
SGACL monitoring mode requires SGACL detailed logging to be enabled. To disable SGACL detailed logging, make sure that SGACL monitoring mode is disabled. |
From Cisco NX-OS Release 7.3(1)D1(1), the SGACL detailed logging feature is supported on the Cisco Nexus M2 and M3 series modules. However, the SGACL detailed logging information for traffic arriving on interfaces of the Cisco M2 series modules is supported when the following conditions are met:
The source SGT for traffic is derived locally on the enforcement device.
The interfaces of the Cisco M2 series modules do not have any port-SGT configuration.
Note |
The SGACL detailed logging feature is not supported on the Cisco Nexus M1 series modules. |
During the predeployment phase of Cisco TrustSec, an administrator will use the monitor mode to test the security policies without enforcing them to make sure that the policies are what were originally intended. If there is something wrong with the security policy, the monitor mode provides a convenient mechanism for identifying the same, along with an opportunity to correct the policy before enabling SGACL enforcement. This enables administrators to have an increased visibility to the outcome of the policy actions before they enforce it, and confirm that the subject policy meets the security requirements (access is denied to resources if users are not authorized).
The monitoring capability is provided at the SGT-DGT pair level. By default, the SGACL monitoring mode is disabled. When you enable the SGACL monitoring mode feature, the deny action is implemented as an ACL permit on the line cards. This allows the SGACL counters and logging to display how connections are handled by the SGACL policy. Since all the monitored traffic is now permitted, there is no disruption of service due to SGACLs while in the SGACL monitor mode.
From Cisco NX-OS Release 7.3(1)D1(1), the SGACL monitor mode feature is supported on the Cisco Nexus M2 and M3 series modules. However, the SGACL monitor mode feature is not supported on the Cisco Nexus M1 series modules.
Note |
The SGACL monitor mode feature is supported on the Cisco Nexus M2 series modules for all scenarios, and flows are allowed or denied based on the SGACL monitor mode configuration and policy actions. However, the support for SGACL detailed logging information is limited. For more information, see SGACL Detailed Logging. |
In releases earlier than Cisco NX-OS Release 8.0 (1), SGACLs from only one source was valid. Consider the following scenarios:
SGACL is configured using CLI followed by SGACL downloaded from Integrated Services Engine (ISE). In this case, the SGACL downloaded from ISE is ignored.
SGACL is downloaded from ISE followed by SGACL configured using CLI. In this case, the SGACL downloaded from ISE is overwritten.
From Cisco NX-OS Release 8.0 (1), the SGACLs downloaded using ISE and SGACLs configured using CLI can coexist. You can prioritize whether to use SGACLs downloaded from ISE or SGACLs configured by using CLI. Use the [no] cts role-based priority-static command to choose the install priority between the SGACLs configured by using CLI or SGACLs downloaded by ISE. By default, the SGACLs configured by using CLI have higher priority in Cisco NX-OS.
This section discusses about the special cases that needs to be considered when you enable SGT Caching feature with Cisco TrustSec SGACL policy enforcement. Specifically, the SGT Caching mode for sgt=any,dgt=any, and sgt=0,dgt=0.
The SGT Caching feature mandates the installation of two main SGACL policies, that is, <sgt = any, dgt = any> and <sgt = 0, dgt = 0> in the hardware. If these SGACL policies are not configured by using CLI, then CTS manager creates and installs the reserved SGACL policies: <sgt = any, dgt= any, permit all log> and <sgt = 0, dgt = 0, permit all>.
Prior to Cisco NX-OS Release 8.0(1), if the SGT Caching feature is enabled with Cisco TrustSec SGACL policy enforcement, the following changes are observed:
The reserved SGACL created by SGT caching is considered as SGACL configured by CLI. The SGACL policy with values <sgt =any, dgt = any, ise_user_rbacl> downloaded from ISE is ignored, because SGACLs configured by using CLI are given higher priority. Therefore, the reserved SGACL with values <sgt=any dgt=any, permit all log> is installed in hardware, when SGACL with <sgt =any, dgt = any> is not configured by the user by using CLI and only available in ISE.
SGACL traffic counters are not supported for the reserved SGACLs. Therefore, the SGACL traffic counters are not supported for the default Any-Any policy, when SGT-caching with enforcement is enabled and there is no SGACL with <sgt=any , dgt=any> configured by using CLI.
If you configure an SGACL with values <sgt=any,dgt=any,user_rbacl by using CLI, the permit all log is appended with the user_rbacl ACE and installed in hardware. SGACL traffic counters are supported as usual for this user installed with Any-Any policy by using CLI.
Starting from Cisco NX-OS Release 8.0(1), the rules that apply to CLI installed Any-Any SGACLs with SGT-caching feature in prior releases, are also applicable to the ISE downloaded SGACLs. In case of coexistence of the Any-Any SGACL from both CLI and ISE, the policy that needs to be used is decided based on the priority selection. SGACL traffic counters for the default policy are supported as long as the Any-Any policy from either CLI or ISE is available.
The following table provides information about how SGACLs from different sources (CLI or ISE) are selected and installed based on the "install priority" and "monitor mode" configuration.
|
Priority Configured |
Monitor Mode Status |
CLI SGACL Only |
CLI Monitored SGACL Only |
ISE SGACL Only |
ISE Monitored SGACL Only |
CLI SGACL and ISE SGACL |
CLI and ISE Monitored SGACL |
CLI Monitored SGACL and ISE SGACL |
CLI Monitored SGACL and ISE Monitored SGACL |
|---|---|---|---|---|---|---|---|---|---|
|
no cts role-based priority-static |
Disabled |
Install CLI SGACL |
Install CLI SGACL |
Install ISE SGACL |
No Install |
Install ISE SGACL |
Install CLI SGACL |
Install ISE SGACL |
No Install |
|
cts role-based priority-static |
Disabled |
Install CLI SGACL |
Install CLI SGACL |
Install ISE SGACL |
No Install |
Install CLI SGACL |
Install CLI SGACL |
Install CLI SGACL |
Install CLI SGACL |
|
no cts role-based priority-static |
Enabled |
Install CLI SGACL |
Install CLI Monitored SGACL |
Install ISE SGACL |
Install CLI Monitored SGACL |
Install ISE SGACL |
Install ISE Monitored SGACL |
Install ISE SGACL |
Install ISE Monitored SGACL |
|
cts role-based priority-static |
Enabled |
Install CLI SGACL |
Install CLI Monitored SGACL |
Install ISE SGACL |
Install CLI Monitored SGACL |
Install CLI SGACL |
Install CLI SGACL |
Install CLI Monitored SGACL |
Install CLI Monitored SGACL |
From Cisco NX-OS Release 8.0(1), you can enable or disable SGACL policy enforcement on Layer 3 (L3) physical interfaces and port-channels.
Consider the following scenario with two Cisco Nexus 7000 series switches. This scenario provides an overview about using the SGACL policy enforcement per interface.
The following table provides information about the SGACL policies.
|
SGT Information |
SGT10 |
SGT20 |
SGT Unknown |
|
SGT10 |
Permit |
Deny |
Deny |
|
SGT20 |
Deny |
Permit |
Deny |
When SGACLs are applied on this setup, hosts with SGT10 cannot communicate with SGT20 and Unknown SGT hosts, because SGACL policy drops the packets. However, when you disable the SGACL policy enforcement on the port E4/1:
The host H1 cannot communicate with the host H2 because this network traffic is subjected to the SGT 10 DGT 20 Deny policy.
The host H1 can communicate with host H3 even if this network traffic is subjected to the SGT 10 DGT unknown Deny policy. This communication is possible because the packet is exiting through the port E4/1 on which the SGACL policy enforcement is disabled.

The following figure shows the packet routes between different hosts after the SGACL policy enforcement is disabled on the port E4/1.
The Cisco NX-OS device hardware in the access layer supports Cisco TrustSec. Without the Cisco TrustSec hardware, the Cisco TrustSec software cannot tag the packets with SGTs. You can use SXP to propagate the SGTs across network devices that do not have hardware support for Cisco TrustSec.
SXP operates between access layer devices and distribution layer devices. The access layer devices use SXP to pass the IP addresses of the Cisco TrustSec-authenticated devices with their SGTs to the distribution switches. Distribution devices with both Cisco TrustSec-enabled software and hardware can use this information to tag packets appropriately and enforce SGACL policies.
Tagging packets with SGTs requires hardware support. You might have devices in your network that cannot tag packets with SGTs. To allow these devices to send IP address-to-SGT mappings to a device that has Cisco TrustSec-capable hardware, you must manually set up the SXP connections. Manually setting up an SXP connection requires the following:
If you require SXP data integrity and authentication, you must configure the same SXP password on both of the peer devices. You can configure the SXP password either explicitly for each peer connection or globally for the device. The SXP password is not required.
You must configure each peer on the SXP connection as either an SXP speaker or an SXP listener. The speaker device distributes the SXP 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.
The Security Group Tag (SGT) Exchange Protocol (SXP) is a control protocol, which propagates IP address-SGT binding information across network devices. From Cisco NX-OS Release 7.3(0)D1(1), the SXP version 3 (SXPv3) feature provides support to transport the IPv4 subnet to the SGT bindings.
By using the subnet for SGT bindings, you can minimize the forward information base (FIB) entries needed for storing the mapping, which allows users to increase the scale of the TrustSec deployments. In many scenarios, you can use subnet-SGT bindings instead of the L3 interface-SGT.
Note |
|
The SXPv3 protocol allows you to configure the expansion limit for a subnet binding. SXP expands a subnet binding to host address bindings when a connection is set up with a peer with a version earlier than Version 3. SXP binding expansion is applicable only to IPv4 subnet binding.
The characteristics of subnet expansion are as follows:
When expanding the bindings for overlapping IP addresses with different SGT values, the mapping is obtained from the IP address with the longest prefix length.
If the subnet expansion reaches the configured limit, a system log is generated for the subnet that cannot be expanded.
Binding expansion does not expand broadcast IP addresses in a subnet. Also, note that SXP does not summarize host IP addresses to subnet bindings. In the SXP propagation path, if there is a node that does not understand subnet binding, the bindings are expanded and propagated through the rest of the propagation path as host IP binding even though there is a node that understands subnet binding.
The default expansion limit is zero (0) and the maximum allowed expansion limit is 65535. You can set the expansion limit as 0 when you do not have any devices supporting a lower version of SXP, in the network.
You can use the cts sxp mapping network-map [num_bindings] command to expand the network limit. The num_bindings parameter can accept value from 0 to 65535. The value zero (0) indicates that no expansion is allowed and 65535 is the maximum expansion limit allowed. The default value is zero (0).
Consider an example when the expansion limit is set to 67 and the subnet is /24. Cisco NX-OS expands the first 67 IP addresses for the first subnet SGT known to Cisco TrustSec. Since subnet /24 contains more hosts, it will never be fully expanded, and a syslog is generated.
Note |
When you set the maximum expansion limit as 65535, Cisco NX-OS supports the mapping of every IP in a /16 subnet. However, you must consider the hardware or software impact of setting the expansion limit to the maximum limit. |
The SXP session is established between speaker devices and listener devices. By default, the Cisco TrustSec device advertises the highest supported SXP version. The negotiation is made based on the highest common version supported by the speaker and listener devices. A standalone Cisco TrustSec-supported device can establish SXP session with different versions, with its peer devices, depending on the SXP versions of the peer devices.
Note |
Configure the SXP default source IP address on an SXP device only when all its peer SXP devices are configured to connect to this configured default source IP address. If the default source IP address configuration is not used on an SXP device, configure the source IP address that the SXP device should use with the cts sxp connection peer command. |
The following table provides information about version negotiation for interoperability in different scenarios.
|
Case Number |
Speaker |
Listener |
SXP Session Status |
|---|---|---|---|
|
1 |
SXPv1 |
SXPv1 |
SXPv1 session is established. |
|
2 |
SXPv1 |
SXPv2 |
SXPv1 session is established. |
|
3 |
SXPv1 |
SXPv3 |
SXPv1 session is established. |
|
4 |
SXPv2 |
SXPv1 |
SXPv1 session is established. |
|
5 |
SXPv2 |
SXPv2 |
Not possible because a Cisco Nexus 7000 device does not support SXPv2. |
|
6 |
SXPv2 |
SXPv3 |
If a Cisco Nexus 7000 device with SXPv3 is interoperating with another Cisco SXP device having SXPv2, the Cisco Nexus 7000 device ensures that the connection is established as SXPv1. |
|
7 |
SXPv3 |
SXPv1 |
SXP session is established. |
|
8 |
SXPv3 |
SXPv2 |
If a Cisco Nexus 7000 device with SXPv3 is interoperating with another Cisco SXP device having SXPv2, the Cisco Nexus 7000 device ensures that the connection is established as SXPv1. |
|
9 |
SXPv3 |
SXPv3 |
SXPv3 session is established. |
|
10 |
SXPv1 |
SXPv4 |
SXPv1 session is established. |
|
11 |
SXPv2 |
SXPv4 |
If a Cisco Nexus 7000 device with SXPv4 is interoperating with another Cisco SXP device having SXPv2, the Cisco Nexus 7000 device ensures that the connection is established as SXPv1. |
|
12 |
SXPv3 |
SXPv4 |
SXPv3 session is established. |
|
13 |
SXPv4 |
SXPv1 |
SXPv1 session is established. |
|
14 |
SXPv4 |
SXPv2 |
If a Cisco Nexus 7000 device with SXPv4 is interoperating with another Cisco SXP device having SXPv2, the Cisco Nexus 7000 device ensures that the connection is established as SXPv1. |
|
15 |
SXPv4 |
SXPv3 |
SXPv3 session is established. |
|
16 |
SXPv4 |
SXPv4 |
SXPv4 session is established. |
You can provide the default route for SGT bindings, when IP-SGT for the source IP address or destination IP address is not configured. In this scenario, SGT is derived from the default route entry. Note that you can use the default route only for the listener device with SXPv3. By default, the transport of SGT bindings through the default route by using SXP, is disabled. You can enable the transport of SGT bindings through the default route by using the cts sxp allow default-route-sgt command. Use the no form of this command to disable the default route of the SGT bindings.
Cisco TrustSec SXP version 4 (SXPv4) enhances the functionality of SXP by adding a loop detection mechanism to prevent stale binding in the network. SXP connections can be enabled such that the binding forwarded by one switch for an SXP connection can be received from another SXP connection, resulting in SXP connection loops. SXP loop topology might, however, result in stale binding in the network. SXPv4' s built-in loop detection and prevention mechanism addresses the stale binding issue whenever there is a loop between SXP nodes.
Loop prevention is achieved by adding SXP propagation path information when propagating (adding or deleting) bindings. Propagation path information keeps track of the network devices (via their node IDs) that the binding travels in an ordered manner. All nodes that participate in the network with looped SXP connections must run SXPv4 to function correctly. Loop detection is a mandatory capability in SXPv4.
In the figure above there are three network devices: SW1, SW2, and SW3. There are also three SXP connections: SXP1, SXP2, and SXP3, together which create an SXP connection loop. A binding (10.1.10.1, 100) is learned at SW1 through local authentication. The binding is exported by SW1 to SW2 together with the path information (that is, SW1, from where the binding is forwarded).
Upon receiving the binding, SW2 exports it to SW3, again prepending the path information (SW2, SW1). Similarly, SW3 forwards the binding to SW1 with path information SW3, SW2, SW1. When SW1 receives the binding, the path information is checked. If its own path attribute is in the binding update received, then a propagation loop is detected. This binding is dropped and not stored in the SXP binding database.
If the binding is removed from SW1, (for example, if a user logs off), a binding deletion event is sent. The deletion event goes through the same path as above. When it reaches SW1, no action will be taken as no such binding exists in the SW1 binding database.
Loop detection is done when a binding is received by an SXP but before it is added to the binding database.
An SXP node ID is used to identify the individual devices within the network. The node ID is a four-octet integer that can be configured by the user. If it is not configured by the user, Cisco TrustSec assigns the router ID on the default VRF as the node ID, in the same manner that EIGRP generates its router ID, which is the first IP address on Cisco Nexus 7000 series switches.
The SXP loop detection mechanism drops binding propagation packets based on finding its own node ID in the peer sequence attribute. Changing a node ID in a loop detection-running SXP network could break SXP loop detection functionality and therefore needs to be handled carefully.
The bindings that are associated with the original node ID have to be deleted in all SXP nodes before the new node ID is configured. This can be done by disabling the SXP feature on the network device where you desire to change the node ID. Before you change the node ID, wait until the SXP bindings that are propagated with the particular node ID in the path attribute are deleted.
The node ID configuration is blocked or restricted when SXP is in the enabled state. Router-ID changes in the switch do not affect the SXP node ID, while SXP is enabled. A syslog is generated to indicate that the router ID of the system has changed and this may affect SXP loop detection functionality.
Note |
Disabling the SXP feature brings down all SXP connections on the device. |
SXP uses a TCP-based, keepalive mechanism to determine if a connection is live. SXPv4 adds an optional negotiated keepalive mechanism within the protocol to provide more predictable and timely detection of connection loss.
SXP connections are asymmetric with almost all of the protocol messages (except for open/open_resp and error messages) sent from an SXP speaker to an SXP listener. The SXP listener can keep a potentially large volume of state per connection, which includes all the binding information learned on a connection. Therefore, it is only meaningful to have a keepalive mechanism that allows a listener to detect the loss of connection with a speaker.
The mechanism is based on two timers:
Hold timer—Used by a listener for detection of elapsing time without successive keepalive or update messages from a speaker
Keepalive timer—Used by a speaker to trigger the dispatch of keepalive messages during intervals when no other information is exported through update messages
The hold-time for the keepalive mechanism may be negotiated during the open or open_resp exchange at connection setup. The following information is important during the negotiation:
A listener may have desirable range for the hold-time period locally configured or have a default of 90 to 180 seconds. A value of 0xFFFF..0xFFFF indicates that the keepalive mechanism is not used.
A speaker may have a minimum acceptable hold-time period locally configured or have a default of 120 seconds. This is the shortest period of time a speaker is willing to send keepalive messages for keeping the connection alive. Any shorter hold-time period would require a faster keepalive rate than the rate the speaker is ready to support.
A value of 0xFFFF implies that the keepalive mechanism is not used.
The negotiation succeeds when the speaker’s minimum acceptable hold-time falls below or within the desirable hold-time range of the listener. If one end turns off the keepalive mechanism, the other end should also turn it off to make the negotiation successful.
The negotiation fails when the speaker’s minimum acceptable hold-time is greater than the upper bound of the listener’s hold-time range.
The selected hold-time period of a successful negotiation is the maximum of the speaker’s minimum acceptable hold-time and the lower bound of the listener’s hold-time range.
The speaker calculates the keepalive time to one-third of the selected hold-time by default unless a different keepalive time is locally configured.
Larger Minimum listener hold-time values are recommended on systems with large number of bindings or connections. Also, these values are recommended if there is a requirement to hold the bindings on the listener during network maintenance events.
For more information about the hold-time negotiation process, see the Cisco TrustSec Configuration Guide, Cisco IOS Release 15M&T.
The Bidirectional SXP Support feature enhances the functionality of Cisco TrustSec with SXP version 4 by adding support for SXP bindings that can be propagated in both directions between a speaker and a listener over a single connection.
With the support for bidirectional SXP configuration, a peer can act as both a speaker and a listener and propagate SXP bindings in both directions using a single connection.
The bidirectional SXP configuration is managed with one pair of IP addresses, thereby reducing operational complexity. On either end, only the listener initiates the SXP connection and the speaker accepts the incoming connection.
In addition, bidirectional SXP uses the underlying loop-detection benefits of SXPv4 to avoid replay of updates back and forth across the same connection.
Note |
The peers at each end of the connection must be configured as a bidirectional connection using the both keyword. It is an incorrect configuration to have one end configured as a bidirectional connection using the both keyword and the other end configured as a speaker or listener (unidirectional connection). The system will not be able to detect the mismatch in configuration leading to unpredictable SXP connectivity. |
Cisco TrustSec SXPv4 has the following guidelines and limitations:
The Bidirectional SXP Support feature enhances the functionality of Cisco TrustSec with SXPv4 by adding support for SXP bindings that can be propagated in both directions between a speaker and a listener over a single connection.
IPV6 bindings are not learned or transported by the Cisco Nexus 7000 series switches over SXPv4 connections. However, the SXPv4 peering with speakers transporting IPv6 bindings are still supported.
Cisco Nexus 7000 series switches only expand Subnet-SGT bindings over SXPv3 connections.
After upgrading to the Cisco Nexus Release 8.0(1), the default version SXPv4 is advertised by a switch. The appropriate connection versions are re-negotiated with the peers.
Ensure that there are no overlapping node IDs configured in the network or the node IDs that are configured in the network do not overlap with IP addresses used elsewhere in the network.
Ensure that there are no overlapping IP addresses to avoid unintentional reuse of default node IDs in the network.
Before modifying IP addresses in the switch or a router, ensure that the old and the new IP addresses have not been used as default node IDs locally or remotely in the network.
Ensure that the speaker and listener hold-time values per connection or global or default for each speaker-listener pair are compatible.
Note that using the hold-time value as 65535 on speaker or listener disables the in-built keepalive mechanism and avoids the staling of bindings upon connectivity loss on SXPv4 devices. Administrative connection resets are required to clear these bindings.
When migrating existing unidirectional connections to bidirectional connections, ensure that the global hold times are compatible and the bindings learnt in both directions are within the supported scale limits. Also, ensure that the global or default hold-time values on speaker and listener are compatible, since you cannot configure hold-time values for these connections on a per-connection basis.
Subnet-SGT mapping binds an SGT to all the host addresses of a specified subnet. After this mapping is implemented, Cisco TrustSec imposes SGT on incoming packets having a source IP address that belongs to the specified subnet. This enables you to enforce the Cisco TrustSec policy on the traffic flowing through data center hosts. You can configure IPv4 subnet-SGT bindings under a VRF instance.
In IPv4 networks, SXPv3 and later versions can receive and parse subnet network address or prefix strings from SXPv3 peers.
For example, the IPv4 subnet 198.1.1.0/29 is expanded as follows (only three bits for host addresses):
Host addresses 198.1.1.1 to 198.1.1.7 are tagged and propagated to the SXP peer.
Network and broadcast addresses 198.1.1.0 and 198.1.1.8 are not tagged and not propagated.
Note |
Use the cts sxp mapping network-map global configuration command to limit the number of subnet binding expansions exported to an SXPv1 peer. |
Subnet bindings are static, which means that active hosts are not learned. They can be used locally for SGT imposition and SGACL enforcement. Packets tagged by subnet-SGT mapping can be propagated on Layer 2 or Layer 3 TrustSec links. Additionally, you can use the cts sxp allow default-route-sgt command to enable the transport of SGT bindings through the default route, that is, unknown IP address 0.0.0.0.
The Layer 2 (L2) control plane protocols are responsible for creating and maintaining operational states between devices connected through the Cisco TrustSec-enabled links. SGT tagging is enabled by default on Cisco TrustSec-enabled links. A Cisco TrustSec-enabled device applies SGT tags for almost all the L2 packets egressing an interface. The L2 peers on the ingress interfaces process the SGT packets. However, some peers cannot process the SGT-tagged control packets tagged due to limitations. For example, Cisco F3 Series modules do not accept the packets with an SGT tag in the port ingress when the IEEE 802.1Q tag is missing in front of the SGT tag. This causes a peer to drop the L2 control packets such as Cisco Discovery Protocol, Link Level Discovery Protocol (LLDP), Link Aggregation Control Protocol (LACP), or bridge protocol data units (BPDU) with SGT.
From Cisco NX-OS Release 8.1(1), Cisco TrustSec provides the following enhancements to exempt SGT tagging for the L2 control packets:
By default, Cisco NX-OS assigns null SGT for the L2 control packets even if the device SGT is non-zero.
Cisco Nexus line card modules perform the following action after receiving null SGT and L2 packet from the Supervisor module:
Cisco Nexus F Series modules do not tag null SGT for the L2 control packets.
Cisco Nexus M Series modules tag null SGT for the L2 control packets. In this case, you can prevent the Cisco Nexus M series modules from tagging null SGT by using the no propagate-sgt l2-control command. This exemption ensures that the L2 control protocols are transmitted without any SGT tags from the Cisco TrustSec-enabled ports.
Use the no propagate-sgt l2-control command to exempt the SGT tagging of the L2 control plane protocols for an interface. By default, the SGT tagging is not exempted for the L2 control plane protocols. For example, if the Cisco M3 series module has to interoperate with the Cisco F3 series module by using the Cisco TrustSec enabled link, then enable the no propagate-sgt l2-control command for the M3 series module. This ensures that the control packets are accepted by the Cisco F3 series module.
You can also enable or disable the SGT tagging of the L2 control plane protocols under a port profile or a port channel.
Note |
|
After authentication ends, the supplicant and AT obtain the security policy from the authentication server. The supplicant and AT enforce the policy against each other. Both the supplicant and AT provide the peer device ID that each receives after authentication. If the peer device ID is not available, Cisco TrustSec can use a manually configured peer device ID.
The authentication server returns the following policy attributes:
 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 uses the RADIUS Change of Authorization feature to automatically download policies from Cisco Identity Services Engine (ISE) server to a switch, after an administrator updates the AAA profile on the server.
Note |
The feature works with Cisco ISE only and not with Cisco Secure Access Control Server (ACS). |
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 network cloud, 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.
Note |
If you have manually configured the Cisco TrustSec device ID, but not using the AAA server for a Cisco TrustSec deployment, you should remove the Cisco TrustSec device ID by using the no cts device-id command. Otherwise, the following false syslog error is generated: The no cts device-id command is supported from Cisco NX-OS Release 7.2. If you are using Cisco NX-OS Release 6.2.6 or a later release, you can disable only by disabling Cisco TrustSec and reapplying Cisco TrustSec configurations without the cts device-id configuration. |
The device must refresh the Cisco TrustSec environment data before it expires. The device can also cache the 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:
The Cisco NX-OS device that plays the role of the Cisco TrustSec AT in the 802.1X authentication process has IP connectivity to the authentication server, which allows it 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 AT to act as a RADIUS relay for the supplicant.
The supplicant sends a special EAP over LAN (EAPOL) message to the Cisco TrustSec AT that contains the RADIUS server IP address and UDP port and the complete RADIUS request. The Cisco TrustSec AT 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 Cisco TrustSec AT forwards the message back to the supplicant, encapsulated in an EAPOL frame.
Effective with Cisco NX-OS Release 7.2(0)D1(1), Cisco TrustSec is supported on over Virtual Port Channel (vPC) and vPC+. The following Cisco TrustSec configurations on both vPC or vPC+ peers must be consistent:
Port-SGT configuration on all interfaces of a vPC (SGT and trust mode)
IP-SGT configuration
VLAN-SGT configuration
SXP peer connections configuration
SGT caching configuration
AAA/RADIUS configuration
SGACL policy configuration
Enforcing SGACL on VLAN and VRF configuration
Note |
|
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} Cisco TrustSec Manual interface mode command (Identity Port Mapping). The current priority enforcement order, from lowest (1) to highest (7), is as follows:
Cisco Fabric Services—Cisco TrustSec IP-SGT bindings learned on vPC peer. This is applicable only to vPC peer devices.
VLAN-SGT—Bindings learned from snooped ARP or DHCP packets on a VLAN that is configured with a VLAN-SGT mapping.
SGT-caching—IP-SGT bindings learned on a VLAN or VRF, where SGT-caching is configured.
SXP—Bindings learned from SXP peers.
Learned on interface—Bindings of authenticated hosts, which are learned through EPM and device tracking. This type of binding also includes individual hosts that are learned through ARP snooping on L2 [I]PM configured ports.
CLI—Address bindings configured using the IP-SGT form of the cts role-based sgt-map global configuration command.
Port ASIC—SGT bindings derived inline or directly from the port, based on CTS trusted or untrusted configuration.
Cisco TrustSec configuration and operation are local to the virtual device context (VDC). For more information on VDCs, see the Cisco Nexus 7000 Series NX-OS Virtual Device Context Configuration Guide.
Cisco TrustSec has the following prerequisites:
You must enable the 802.1X feature before you enable the Cisco TrustSec feature. Although none of the 802.1X interface level features are available, 802.1X is required for the device to authenticate with RADIUS.
Cisco TrustSec has the following guidelines and limitations:
Traffic generated from any supervisor is tagged with device-SGT provided that a non-zero value is configured or downloaded and SGT propagation is enabled on the egress interface. However, even if the SGACL enforcement is enabled on the corresponding VRF or VLAN, this traffic would not be subject to SGACL enforcement, if the destination for this traffic is the next hop device.
Cisco TrustSec stops tagging traffic when Netflow is configured on the same interface which is used for tagging. Do not configure Netflow on the same interface if the matrix does not specify that the Netflow is supported with SGT. The workaround for this issue is to remove Netflow from the interface which is used for tagging and use a different interface to send the Netflow (with no relation to the Cisco TrustSec).
The Cisco Nexus 7000 series switch does not support multiple SGACLs for the same source and destination pair. It is recommended that the multi line single SGACL is used.
Cisco TrustSec MACSec—The following set of requirements must be used when deploying MACSec over SP-provided pseudowire connections. These requirements help to ensure the right service, quality, or characteristics are ordered from the SP.
The Cisco Nexus 7000 series switch supports MACSec over Point-to-Point links, including those using DWDM, as well as non-PtP links such as EoMPLS where the following conditions are met:
There is no re-ordering or buffering of packets on the MACSec link.
No additional frames can be injected to the MACSec link.
There must be end-to-end link event notification—if the edge device or any intermediate device loses a link then there must be notifications sent so that the user is aware of the link failure as the service will be interrupted.
For MACsec links that have a bandwidth that is greater than or equal to 40G, multiple security associations (SCI/AN pairs) are established with each SA protocol exchange.
Cisco TrustSec SGT supports IPv4 addressing only.
Cisco TrustSec SGT in-line tagging is not supported over OTV, VXLAN, FCoE, or Programmable Fabric.
SXP cannot use the management (mgmt 0) interface.
You cannot enable Cisco TrustSec on interfaces in half-duplex mode.
If SGACL is applied to the packets being routed through SVI, SGACL has to be enabled on all the VLANs and the VRF instance involved.
You cannot configure both Cisco TrustSec and 802.1X on an interface; you can configure only one or the other. However, you must enable the 802.1X feature for Cisco TrustSec to use EAP-FAST authentication.
AAA authentication and authorization for Cisco TrustSec is only supported by the Cisco Secure ACS and Cisco ISE.
To download sgname tables or refresh the environment data, you must use the Cisco ISE Release 1.0 or a later release. The Cisco Secure ACS does not support these features.
Cisco TrustSec supports 200,000 IP-SGT maps. This is subject to the FIB TCAM space availability on each of the modules. Note that the CLI rollback is not supported when more than 100,000 IP-SGT mappings are manually configured. For more information, see Cisco Nexus 7000 Series NX-OS Verified Scalability Guide.
The CISCO-TRUSTSEC-SXP-MIB does not provide an instance number. The object ctsxSxpConnInstance does not provide the instance number of the Cisco TrustSec SXP connection. Currently this number is not maintained and cannot be displayed.
CTS-2-RBACL_ENFORCEMENT_FAILED:Failed to disable RBACL enf on vdc reloadThe Cisco TrustSec configuration commands are not available. The no cts dev-id pswd dev-pswd command is currently not supported in NX-OS software. When the cts dev-id pass command is configured, the command configuration can be replaced using the same command, but it cannot be deleted.
When you change the Cisco TrustSec MACSec port mode from Cache Engine (CE) mode to FabricPath mode, CRC errors are displayed in the Cisco TrustSec MACsec link until native VLAN tagging is disabled on the FabricPath core port. Such configuration changes that occur on a Cisco TrustSec port should be flapped. However, this could cause possible traffic disruptions. In such circumstances, to avoid the display of CRC errors and traffic disruptions, perform the following steps:
Disable the cache engine port while having the Cisco TrustSec MACsec enabled.
Change the port mode to FabricPath mode.
Disable the native VLAN tagging on the FabricPath core port.
Enable the port.
The subnet-to-SGT bindings are not expanded by default. To enable expansion, the cts sxp mapping network-mapcommand must be set to a non-zero value.
An SGT that is associated with a longer prefix is always selected even if a corresponding SGT binding exists. For example, consider the hosts 12.1.0.0/16 with the subnet-SGT binding 10 and 12.1.1.1 with IP-SGT binding 20. SGT 20 is selected for the host 12.1.1.1 even though the parent prefix SGT is 10. Similarly, if VLAN 121 is designated to the subnet 12.1.0.0/16 and configured with a VLAN-SGT binding of 30, host 12.1.1.1 will continue to have the SGT value of 20 and the host 12.1.1.2 will have an SGT value of 10, because the subnet-SGT binding is considered a longer match than a VLAN-SGT mapping.
To enable the monitoring mode, enable the cts role-based detailed-logging command. You can enable or disable logging at the ACE level, as being done currently.
Monitoring at a per-RBACL or per-ACE level is not supported.
The monitor mode counter statistics and logging output might not match because the logging output count is rate limited, while counter statistics are directly obtained from the hardware.
When you enable monitor all by using CLI, ISE, or both, the monitoring for all SGT-DGT pairs is turned on, independent of per-pair configuration.
When you disable the monitor mode feature, the switch reverts to the default behavior. The monitored SGACLs from ISE will not be installed. All the CLI-installed SGACLS will begin to enforce or deny the policies as configured.
The traffic hitting SGACL Access Control Entry (ACE) with the log option set is punted to the supervisor, causing network congestion in the supervisor and the packets originated from supervisor such as ping, OSPF hello, and SXP may fail leading to control plane disruption. Therefore, we recommend that you enable log option only for troubleshooting or validation purposes.
The following guidelines and limitations are applicable for the SGACL Egress Policy Overwrite feature:
If overlapping RBACL exists from both the sources (CLI and ISE) for an sgt-dgt pair, the respective RBACL is programmed in to the hardware based on the configured priority. The RBACL is programmed as conventional or monitored based on the monitor mode property.
If RBACL exists only from a single source, irrespective of configured priority, the RBACL is programmed as conventional or monitored based on the monitor mode property.
Irrespective of the configured priority, RBACL always get updated into the PSS. However, hardware programming is based on the priority and monitor mode property.
SGACLs are monitored when you enable monitor mode globally and set monitor all. However, based on the install priority set by using the cts role-based priority-static command, either the SGACLs downloaded from ISE or the SGACLs configured by using CLI are monitored.
When SGACL exists only from a single source, that is, either from ISE or CLI, the existing SGACL is used irrespective of the configured install priority of SGACLs.
When you set monitor all by using CLI, ISE, or both, the monitoring for all SGT-DGT pairs is turned on, independent of per-pair configuration.
Based on the set priority, the monitoring is enabled for the SGACL configured by using CLI or SGACL downloaded from ISE.
When you disable the monitor mode feature, the switch reverts to the default behavior. The monitored SGACLs from ISE will not be installed. All the CLI-installed SGACLS will begin to enforce or deny the policies as configured.
The following guidelines and limitations are applicable for the SGACL Egress Policy Overwrite feature:
Irrespective of whether SGT and DGT are known or unknown for a given network traffic, or an SGACL policy exists for a given SGT and DGT, SGACL policy enforcement disablement on an interface does bypass all SGACLs.
Per Interface SGACL Bypass feature is configured on an L3 physical interface as well as an L3 port-channel. However, port-channel member ports cannot be configured for this feature.
SGACL policy enforcement feature is removed from an interface when the IP address is removed.
When an L3 interface is converted to an L2 interface, the IP configuration is erased. Thereby, the SGACL policy enforcement feature is also erased for the L2 interface.
When you change a VRF, all L3 configurations are erased on an L3 interface. Thereby, the SGACL policy enforcement feature is also erased for the L3 interface.
When you enable or disable the Cisco TrustSec SGT Caching feature, by default, Cisco TrustSec reprograms all the RBACLs to add or remove the log option for all the ACEs. Due to this reprogramming, the previously known statistics are deleted for a RBACL and they are not displayed in the show cts role-based counters command output.
The following guidelines and limitations are applicable to SGT tagging exemption for L2 protocols feature:
You can exempt SGT tagging only on the following control packets by using the no propagate-sgt l2-control command:
Spanning Tree Protocol (STP), Rapid Spanning Tree Protocol (RSTP), and Multiple Spanning Tree Protocol (MSTP)
IEEE Standard 802.3 Slow Protocols such as Link Aggregation Control Protocol (LACP), Operation, Administration, and Maintenance (OAM), and Link Level Discovery Protocol (LLDP)
IEEE 802.1X Extensible Authentication Protocol over LAN (EAPOL)
Cisco Discovery Protocol, Virtual Terminal Protocol (VTP), Dynamic Trunking Protocol (DTP), Port Aggregation Protocol (PAgP), or Unidirectional Link Detection (UDLD)
Per VLAN Spanning Tree Plus (PVST+)
IEEE 802.3 Full Duplex PAUSE Frame
If the Cisco M3 Series module has to interoperate with the Cisco F3 Series module by using the Cisco TrustSec enabled link, then enable the no propagate-sgt l2-control command for the Cisco M3 Series module. This ensures that the control packets are accepted by the Cisco F3 Series module.
By default, Cisco NX-OS exempts SGT tagging for any L2 control packets for the Cisco F2e series module and Cisco F3 series module because packets are not tagged with null SGT. Therefore, Cisco F2e Series modules interoperating with Cisco F3 Series modules or Cisco F3 Series modules interoperating with another Cisco F3 Series modules work without enabling the no propagate-sgt l2-control command on the Cisco TrustSec enabled links.
Currently, Cisco Nexus F3 Series modules do not support SGT tagging with regard to the following Cisco products unless these products support the SGT tagging exemption feature for Layer 2 protocols.
Cisco Catalyst 3000 Series Switches
Cisco Catalyst 4500 Series Switches
Cisco Catalyst 6500 Series Switches
Cisco 4000 Series Integrated Services Routers
Cisco ASR 1000 Series Routers
Cisco Integrated Services Router Generation 2
This table provides information about the support for port interoperability for the Cisco TrustSec-enabled links between the Cisco Nexus modules:
|
Cisco Nexus Modules |
Port Interoperability for Cisco TrustSec Enabled Link With SGT Propagation and Without MACSec |
Port Interoperability for Cisco TrustSec Enabled Link Without SGT Propagation and Without MACSec |
Port Interoperability for Cisco TrustSec Enabled Link With SGT Propagation and With MACSec |
Port Interoperability for Cisco TrustSec Enabled Link Without SGT Propagation and With MACSec |
|---|---|---|---|---|
|
Cisco M3 Series and Cisco F3 Series modules |
Enable SGT tagging exemption on the Cisco M3 Series module port. |
Interoperate by default. |
Not interoperable. |
Interoperate by default. |
|
Cisco M2 Series and Cisco F3 Series modules |
Not interoperable because SGT tagging exemption is not supported on Cisco M2 Series modules. |
Interoperate by default. |
Not interoperable. |
Interoperate by default. |
|
Cisco F3 Series and Cisco F2e Series modules |
Interoperate by default. |
Interoperate by default. |
Interoperate by default. |
Interoperate by default. |
|
Cisco M3 Series and Cisco F2e Series modules |
Interoperate by default. |
Interoperate by default. |
Interoperate by default. |
Interoperate by default. |
|
Cisco M2 Series and Cisco F2e Series modules |
Interoperate by default. |
Interoperate by default. |
Interoperate by default. |
Interoperate by default. |
|
Cisco M3 Series and Cisco M2 Series modules |
Interoperate by default. |
Interoperate by default. |
Interoperate by default. |
Interoperate by default. |
This table lists the default settings for Cisco TrustSec parameters.
|
Parameter |
Default |
|---|---|
|
Cisco TrustSec |
Disabled |
|
SXP |
Disabled |
|
SXP default password |
None |
|
SXP reconcile period |
120 seconds (2 minutes) |
|
SXP retry period |
60 seconds (1 minute) |
|
Caching |
Disabled |
This section provides information about the configuration tasks for Cisco TrustSec.
You must enable both the 802.1X feature and the Cisco TrustSec feature on the Cisco NX-OS device before you can configure Cisco TrustSec.
Note |
You cannot disable the 802.1X feature after you enable the Cisco TrustSec feature. |
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
configure terminal Example: |
Enters global configuration mode. |
|
Step 2 |
feature dot1x Example: |
Enables the 802.1X feature. |
|
Step 3 |
feature cts Example: |
Enables the Cisco TrustSec feature. |
|
Step 4 |
exit Example: |
Exits global configuration mode. |
|
Step 5 |
(Optional) show cts Example: |
(Optional)
Displays the Cisco TrustSec configuration. |
|
Step 6 |
(Optional) show feature Example: |
(Optional)
Displays the enabled status for features. |
|
Step 7 |
(Optional) copy running-config startup-config Example: |
(Optional)
Copies the running configuration to the startup configuration. |
You must configure unique Cisco TrustSec credentials on each Cisco TrustSec-enabled Cisco NX-OS device in your network. Cisco TrustSec uses the password in the credentials for device authentication.
Note |
You must also configure the Cisco TrustSec credentials for the Cisco NX-OS device on the Cisco Secure ACS. See the documentation at: http://www.cisco.com/c/en/us/support/security/secure-access-control-system/products-installation-and-configuration-guides-list.html |
Ensure that you have enabled Cisco TrustSec.
| Command or Action | Purpose | |||
|---|---|---|---|---|
|
Step 1 |
configure terminal Example: |
Enters global configuration mode. |
||
|
Step 2 |
cts device-id name password password Example: |
Configures a unique device ID and password. The name argument has a maximum length of 32 characters and is case sensitive.
|
||
|
Step 3 |
exit Example: |
Exits global configuration mode. |
||
|
Step 4 |
(Optional) show cts Example: |
(Optional)
Displays the Cisco TrustSec configuration. |
||
|
Step 5 |
(Optional) show cts environment Example: |
(Optional)
Displays the Cisco TrustSec environment data. |
||
|
Step 6 |
(Optional) copy running-config startup-config Example: |
(Optional)
Copies the running configuration to the startup configuration. |
Configuring Native VLAN Tagging
Perform this task to configure native VLAN tagging globally.
Ensure that you enabled Cisco TrustSec.
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
configure terminal Example: |
Enters global configuration mode. |
|
Step 2 |
vlan dot1q tag native {fabricpath} exclude control Example: |
Tags control and data packets as appropriate.
|
Perform this task to configure native VLAN tagging globally.
Ensure that you enabled Cisco TrustSec.
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
configure terminal Example: |
Enters global configuration mode. |
|
Step 2 |
interface type slot/port Example: |
Specifies the interface that you want to add to a channel group, and enters the interface configuration mode. |
|
Step 3 |
vlan dot1q tag native {fabricpath} exclude control Example: |
Tags control and data packets as appropriate.
|
You can use Cisco Secure ACS for Cisco TrustSec authentication. You must configure RADIUS server groups and specify the default AAA authentication and authorization methods on one of the Cisco TrustSec-enabled Cisco NX-OS devices in your network cloud. Because Cisco TrustSec supports RADIUS relay, you need to configure AAA only on a seed Cisco NX-OS device that is directly connected to a Cisco Secure ACS. For all the other Cisco TrustSec-enabled Cisco NX-OS devices, Cisco TrustSec automatically provides a private AAA server group, aaa-private-sg. The seed Cisco NX-OS devices uses the management virtual routing and forwarding (VRF) instance to communicate with the Cisco Secure ACS.
Note |
Only the Cisco Secure ACS supports Cisco TrustSec. |
This section describes how to configure AAA on the seed Cisco NX-OS device in your Cisco TrustSec network cloud.
Note |
When you configure the AAA RADIUS server group for the seed Cisco NX-OS device, you must specify a VRF instance. If you use the management VRF instance, no further configuration is necessary for the nonseed devices in the network cloud. If you use a different VRF instance, you must configure the nonseed devices with that VRF instance. |
Obtain the IPv4 or IPv6 address or hostname for the Cisco Secure ACS.
Ensure that you enabled Cisco TrustSec.
| Command or Action | Purpose | |||
|---|---|---|---|---|
|
Step 1 |
configure terminal Example: |
Enters global configuration mode. |
||
|
Step 2 |
radius-server host {ipv4-address | ipv6-address | hostname} key [0 | 7] key pac Example: |
Configures a RADIUS server host with a key and PAC. The hostname argument is alphanumeric, case sensitive, and has a maximum of 256 characters. The key argument is alphanumeric, case sensitive, and has a maximum length of 63 characters. The 0 option indicates that the key is in clear text. The 7 option indicates that the key is encrypted. The default is clear text. |
||
|
Step 3 |
(Optional) show radius-server Example: |
(Optional)
Displays the RADIUS server configuration. |
||
|
Step 4 |
aaa group server radius group-name Example: |
Specifies the RADIUS server group and enters RADIUS server group configuration mode. |
||
|
Step 5 |
server {ipv4-address | ipv6-address | hostname} Example: |
Specifies the RADIUS server host address. |
||
|
Step 6 |
use-vrf vrf-name Example: |
Specifies the management VRF instance for the AAA server group.
|
||
|
Step 7 |
exit Example: |
Exits RADIUS server group configuration mode. |
||
|
Step 8 |
aaa authentication dot1x default group group-name Example: |
Specifies the RADIUS server groups to use for 802.1X authentication. |
||
|
Step 9 |
aaa authorization cts default group group-name Example: |
Specifies the RADIUS server groups to use for Cisco TrustSec authorization. |
||
|
Step 10 |
exit Example: |
Exits global configuration mode. |
||
|
Step 11 |
(Optional) show radius-server groups [group-name] Example: |
(Optional)
Displays the RADIUS server group configuration. |
||
|
Step 12 |
(Optional) show aaa authentication Example: |
(Optional)
Displays the AAA authentication configuration. |
||
|
Step 13 |
(Optional) show aaa authorization Example: |
(Optional)
Displays the AAA authorization configuration. |
||
|
Step 14 |
(Optional) show cts pacs Example: |
(Optional)
Displays the Cisco TrustSec PAC information. |
||
|
Step 15 |
(Optional) copy running-config startup-config Example: |
(Optional)
Copies the running configuration to the startup configuration. |
Cisco TrustSec configures an AAA server group named aaa-private-sg on the nonseed Cisco NX-OS devices in the network cloud. By default, the aaa-private-sg server group uses the management VRF instance to communicate with the Cisco Secure ACS and no further configuration is required on the nonseed Cisco NX-OS devices. However, if you choose to use a different VRF instance, you must change the aaa-private-sg on the nonseed Cisco NX-OS device to use the correct VRF instance.
Ensure that you enabled Cisco TrustSec.
Ensure that you have configured a seed Cisco NX-OS device in your network.
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
configure terminal Example: |
Enters global configuration mode. |
|
Step 2 |
aaa group server radius aaa-private-sg Example: |
Specifies the RADIUS server group aaa-private-sg and enters RADIUS server group configuration mode. |
|
Step 3 |
use-vrf vrf-name Example: |
Specifies the management VRF instance for the AAA server group. |
|
Step 4 |
exit Example: |
Exits RADIUS server group configuration mode. |
|
Step 5 |
(Optional) show radius-server groups aaa-private-sg Example: |
(Optional)
Displays the RADIUS server group configuration for the default server group. |
|
Step 6 |
(Optional) copy running-config startup-config Example: |
(Optional)
Copies the running configuration to the startup configuration. |
This section provides information about the configuration tasks for Cisco TrustSec authentication, authorization, and data path security.
Follow these steps to configure Cisco TrustSec authentication and authorization:
|
Step 1 |
Enable the Cisco TrustSec feature. See Enabling the Cisco TrustSec SGT Feature. |
|
Step 2 |
Enable Cisco TrustSec authentication. See Enabling Cisco TrustSec Authentication. |
|
Step 3 |
Enable 802.1X authentication for Cisco TrustSec on the interfaces. |
You must enable Cisco TrustSec authentication on the interfaces. By default, the data path replay protection feature is enabled and the SA protocol operating mode is GCM-encrypt.
 Caution |
For the Cisco TrustSec authentication configuration to take effect, you must enable and disable the interface, which disrupts traffic on the interface. |
Note |
Enabling 802.1X mode for Cisco TrustSec automatically enables authorization and SA protocol on the interface. |
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
configure terminal Example: |
Enters global configuration mode. |
|
Step 2 |
interface ethernet slot/port [- port2] Example: |
Specifies a single port or a range of ports and enters interface configuration mode. |
|
Step 3 |
cts dot1x Example: |
Enables 802.1X authentication for Cisco TrustSec and enters Cisco TrustSec 802.1X configuration mode. |
|
Step 4 |
(Optional) no replay-protection Example: |
(Optional)
Disables replay protection. The default is enabled. |
|
Step 5 |
(Optional) sap modelist {gcm-encrypt | gcm-encrypt-256 | gmac | no-encap | null} Example: |
(Optional)
Configures the SAP operation mode on the interface. Use the gcm-encrypt keyword for GCM encryption. This option is the default. Use the gcm-encrypt-256 keyword for 256-bit GCM encryption. Use the gmac keyword for GCM authentication only. Use the no-encap keyword for no encapsulation for SA protocol and no SGT insertion. Use the null keyword for encapsulation without authentication or encryption. |
|
Step 6 |
exit Example: |
Exits Cisco TrustSec 802.1X configuration mode. |
|
Step 7 |
shutdown Example: |
Disables the interface. |
|
Step 8 |
no shutdown Example: |
Enables the interface and enables Cisco TrustSec authentication on the interface. |
|
Step 9 |
exit Example: |
Exits interface configuration mode. |
|
Step 10 |
(Optional) show cts interface {all | brief | ethernet slot/port} Example: |
(Optional)
Displays the Cisco TrustSec configuration on the interfaces. |
|
Step 11 |
(Optional) copy running-config startup-config Example: |
(Optional)
Copies the running configuration to the startup configuration. |
By default, the Cisco NX-OS software enables the data-path reply protection feature. You can disable the data-path replay protection feature on the interfaces for Layer 2 Cisco TrustSec if the connecting device does not support SA protocol.
When this task is configured on a port profile, any port profile that joins the group inherits the configuration.
Caution |
For the data-path replay protection configuration to take effect, you must enable and disable the interface, which disrupts traffic on the interface. |
Ensure that you enabled Cisco TrustSec authentication on the interface.
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
configure terminal Example: |
Enters global configuration mode. |
|
Step 2 |
interface ethernet slot/port [- port2] Example: |
Specifies a single port or a range of ports and enters interface configuration mode. |
|
Step 3 |
cts dot1x Example: |
Enables 802.1X authentication for Cisco TrustSec and enters Cisco TrustSec 802.1X configuration mode. |
|
Step 4 |
no replay-protection Example: |
Disables data-path replay protection. The default is enabled. Use the replay-protection command to enable data-path replay protection on the interface. |
|
Step 5 |
exit Example: |
Exits Cisco TrustSec 802.1X configuration mode. |
|
Step 6 |
shutdown Example: |
Disables the interface. |
|
Step 7 |
no shutdown Example: |
Enables the interface and disables the data-path reply protection feature on the interface. |
|
Step 8 |
exit Example: |
Exits interface configuration mode. |
|
Step 9 |
(Optional) show cts interface {all | brief | ethernet slot/port} Example: |
(Optional)
Displays the Cisco TrustSec configuration on the interface. |
|
Step 10 |
(Optional) copy running-config startup-config Example: |
(Optional)
Copies the running configuration to the startup configuration. |
You can configure the SA protocol operation mode on the interfaces for Layer 2 Cisco TrustSec. The default SA protocol operation mode is GCM-encrypt.
When this task is configured on a port profile, any port profile that joins the group inherits the configuration.
Caution |
For the SA protocol operation mode configuration to take effect, you must enable and disable the interface, which disrupts traffic on the interface. |
Ensure that you enabled Cisco TrustSec authentication on the interface.
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
configure terminal Example: |
Enters global configuration mode. |
|
Step 2 |
interface ethernet slot/port [- port2] Example: |
Specifies a single interface or a range of interfaces and enters interface configuration mode. |
|
Step 3 |
cts dot1x Example: |
Enables 802.1X authentication for Cisco TrustSec and enters Cisco TrustSec 802.1X configuration mode. |
|
Step 4 |
sap modelist [gcm-encrypt | gcm-encrypt-256 | gmac | no-encap | null] Example: |
Configures the SA protocol authentication mode on the interface. Use the gcm-encrypt keyword for GCM encryption. This option is the default. Use the gcm-encrypt-256 keyword for 256-bit GCM encryption. Use the gmac keyword for GCM authentication only. Use the no-encap keyword for no encapsulation for SA protocol on the interface and no SGT insertion. Use the null keyword for encapsulation without authentication or encryption for SA protocol on the interface. Only the SGT is encapsulated. |
|
Step 5 |
exit Example: |
Exits Cisco TrustSec 802.1X configuration mode. |
|
Step 6 |
shutdown Example: |
Disables the interface. |
|
Step 7 |
no shutdown Example: |
Enables the interface and SA protocol operation mode on the interface. |
|
Step 8 |
exit Example: |
Exits interface configuration mode. |
|
Step 9 |
(Optional) show cts interface {all | brief | ethernet slot/port} Example: |
(Optional)
Displays the Cisco TrustSec configuration on the interface. |
|
Step 10 |
(Optional) copy running-config startup-config Example: |
(Optional)
Copies the running configuration to the startup configuration. |
The SGT propagation feature on the Layer 2 interface is enabled by default. You can disable the SGT propagation feature on an interface if the peer device connected to the interface cannot handle Cisco TrustSec packets tagged with an SGT.
When this task is configured on a port profile, any port profile that joins the group inherits the configuration.
Caution |
For the SGT propagation configuration to take effect, you must enable and disable the interface, which disrupts traffic on the interface. |
Ensure that you enabled Cisco TrustSec authentication on the interface.
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
configure terminal Example: |
Enters global configuration mode. |
|
Step 2 |
interface ethernet slot/port [- port2] Example: |
Specifies a single port or a range of ports and enters interface configuration mode. |
|
Step 3 |
cts dot1x Example: |
Enables 802.1X authentication for Cisco TrustSec and enters Cisco TrustSec 802.1X configuration mode. |
|
Step 4 |
no propagate-sgt Example: |
Disables SGT propagation. The default is enabled. Use the propagate-sgt command to enable SGT propagation on the interface. |
|
Step 5 |
exit Example: |
Exits Cisco TrustSec 802.1X configuration mode. |
|
Step 6 |
shutdown Example: |
Disables the interface. |
|
Step 7 |
no shutdown Example: |
Enables the interface and disables the data-path reply protection feature on the interface. |
|
Step 8 |
exit Example: |
Exits interface configuration mode. |
|
Step 9 |
(Optional) show cts interface {all | brief | ethernet slot/port} Example: |
(Optional)
Displays the Cisco TrustSec configuration on the interface. |
|
Step 10 |
(Optional) copy running-config startup-config Example: |
(Optional)
Copies the running configuration to the startup configuration. |
You can trigger an SA protocol exchange to generate a new set of keys and protect the data traffic flowing on an interface.
Ensure that you enabled Cisco TrustSec.
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
cts rekey ethernet slot/port Example: |
Generates the SA protocol keys for an interface. |
|
Step 2 |
(Optional) show cts interface {all | brief | ethernet slot/port} Example: |
(Optional)
Displays the Cisco TrustSec configuration on the interfaces. |
You can manually configure Cisco TrustSec on an interface if your Cisco NX-OS device does not have access to a Cisco Secure ACS or authentication is not needed because you have the MAC address authentication bypass feature enabled. You must manually configure the interfaces on both ends of the connection.
Note |
You cannot enable Cisco TrustSec on interfaces in half-duplex mode. Use the show interface command to determine if an interface is configured for half-duplex mode. |
Caution |
For the Cisco TrustSec manual mode configuration to take effect, you must enable and disable the interface, which disrupts traffic on the interface. |
Ensure that you enabled Cisco TrustSec.
| Command or Action | Purpose | |||||
|---|---|---|---|---|---|---|
|
Step 1 |
configure terminal Example: |
Enters global configuration mode. |
||||
|
Step 2 |
interface interface slot/port Example: |
Specifies an interface and enters interface configuration mode. |
||||
|
Step 3 |
cts manual Example: |
Enters Cisco TrustSec manual configuration mode.
|
||||
|
Step 4 |
sap pmk {key [left-zero-padded] [display encrypt] | encrypted encrypted_pmk | use-dot1x} [modelist {gcm-encrypt |gcm-encrypt-256 | gmac | no-encap | null}] Example: |
Configures the SA protocol pairwise master key (PMK) and operation mode. SA protocol is disabled by default in Cisco TrustSec manual mode. The key argument is a hexadecimal value with an even number of characters and a maximum length of 32 characters. Use the left-zero-padded keyword to pad zeros to the left of the entered string if the PMK length is less than 32 bytes. Use the display encrypt keyword to specify that the configured PMK be displayed in AES-encrypted format in the running configuration. Use the encrypted encrypted_pmk keyword to specify an encrypted PMK string of 64 bytes (128 hexadecimal characters). Use the use-dot1x keyword when the peer device does not support Cisco TrustSec 802.1X authentication or authorization but does support SA protocol data path encryption and authentication. The mode list configures the cipher mode for the data path encryption and authentication as follows: Use the gcm-encrypt keyword for GCM encryption. This option is the default. Use the gcm-encrypt-256 keyword for GCM encryption. Use the gmac keyword for GCM authentication. Use the no-encap keyword for no encapsulation and no SGT insertion. Use the null keyword for encapsulation of the SGT without authentication or encryption. |
||||
|
Step 5 |
(Optional) policy dynamic identity peer-name Example: |
(Optional)
Configures a dynamic authorization policy download. The peer-name argument is the Cisco TrustSec device ID for the peer device. The peer name is case sensitive.
|
||||
|
Step 6 |
(Optional) policy static sgt tag [trusted] Example: |
(Optional)
Configures a static authorization policy. The tag argument is a decimal value or a hexadecimal value in the format 0xhhhh . The decimal range is from 2 to 65519, and the hexadecimal range is from 0x2 to 0xffef. The trusted keyword indicates that traffic coming on the interface with this SGT should not have its tag overridden.
|
||||
|
Step 7 |
exit Example: |
Exits Cisco TrustSec manual configuration mode. |
||||
|
Step 8 |
shutdown Example: |
Disables the interface. |
||||
|
Step 9 |
no shutdown Example: |
Enables the interface and enables Cisco TrustSec authentication on the interface. |
||||
|
Step 10 |
exit Example: |
Exits interface configuration mode. |
||||
|
Step 11 |
(Optional) show cts interface {all | brief | ethernet slot/port} Example: |
(Optional)
Displays the Cisco TrustSec configuration for the interfaces. |
||||
|
Step 12 |
(Optional) show cts sap pmk {all | interface ethernet slot/port} Example: |
(Optional)
Displays the hexadecimal value of the configured PMK for all interfaces or a specific Ethernet interface. |
||||
|
Step 13 |
(Optional) copy running-config startup-config Example: |
(Optional)
Copies the running configuration to the startup configuration. |
This section provides information about the configuration tasks for SGACL policies.
Follow these steps to configure Cisco TrustSec SGACL policies:
|
Step 1 |
To improve performance, globally enable SGACL batch programming. |
|
Step 2 |
For Layer 2 interfaces, enable SGACL policy enforcement for the VLANs with Cisco TrustSec-enabled interfaces. |
|
Step 3 |
For Layer 3 interfaces, enable SGACL policy enforcement for the VRF instances with Cisco TrustSec-enabled interfaces. |
|
Step 4 |
If you are not using AAA on a Cisco Secure ACS to download the SGACL policy configuration, manually configure the SGACL mapping and policies. |
Perform the following task to enable batching of Security Group Access Control List (SGACL) programming.
Ensure that you enabled Cisco TrustSec.
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
configure terminal |
Enters global configuration mode. |
|
Step 2 |
[no] cts role-based policy batched-programming enable |
Enables batching of SGACL programming-related tasks. To disable SGACL batch programming after you have explicitly enabled the feature, use the no form of this command. |
If you use SGACLs, you must enable SGACL policy enforcement in the VLANs that have Cisco TrustSec-enabled Layer 2 interfaces.
Note |
This operation cannot be performed on FCoE VLANs. |
Ensure that you enabled Cisco TrustSec.
Ensure that you enabled SGACL batch programming.
| Command or Action | Purpose | |||
|---|---|---|---|---|
|
Step 1 |
configure terminal Example: |
Enters global configuration mode. |
||
|
Step 2 |
vlan vlan-id Example: |
Specifies a VLAN and enters VLAN configuration mode. |
||
|
Step 3 |
cts role-based enforcement Example: |
Enables Cisco TrustSec SGACL policy enforcement on the VLAN.
|
||
|
Step 4 |
exit Example: |
Saves the VLAN configuration and exits VLAN configuration mode. |
||
|
Step 5 |
(Optional) show cts role-based enable Example: |
(Optional)
Displays the Cisco TrustSec SGACL enforcement configuration. |
||
|
Step 6 |
(Optional) copy running-config startup-config Example: |
(Optional)
Copies the running configuration to the startup configuration. |
If you use SGACLs, you must enable SGACL policy enforcement in the VRF instances that have Cisco TrustSec-enabled Layer 3 interfaces.
Note |
You cannot enable SGACL policy enforcement on the management VRF instance. |
Ensure that you enabled Cisco TrustSec.
Ensure that you enabled SGACL batch programming.
Ensure that you enabled dynamic Address Resolution Protocol (ARP) inspection or Dynamic Host Configuration Protocol (DHCP) snooping.
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
configure terminal Example: |
Enters global configuration mode. |
|
Step 2 |
vrf context vrf-name Example: |
Specifies a VRF instance and enters VRF configuration mode. |
|
Step 3 |
cts role-based enforcement Example: |
Enables Cisco TrustSec SGACL policy enforcement on the VRF instance. |
|
Step 4 |
exit Example: |
Exits VRF configuration mode. |
|
Step 5 |
(Optional) show cts role-based enable Example: |
(Optional)
Displays the Cisco TrustSec SGACL enforcement configuration. |
|
Step 6 |
(Optional) copy running-config startup-config Example: |
(Optional)
Copies the running configuration to the startup configuration. |
Ensure that you have enabled Cisco TrustSec.
|
Step 1 |
Enter global configuration mode: switch# configure terminal |
|
Step 2 |
Enable detailed logging for SGACLs: switch(config)# cts role-based detailed-logging |
|
Step 3 |
Enable detailed logging for the IP access list: switch(config)# [no] logging ip access-list detailed |
|
Step 4 |
(Optional) Change the default value of the logging level such that the ACLLOG SYSLOGs appear using the terminal monitor: switch(config)# logging level acllog 6 |
|
Step 5 |
(Optional) Clear the cache every 15 seconds to limit the cache output to only recent connections: switch(config)# logging ip access-list cache interval 15 |
|
Step 6 |
Exit global configuration mode: switch(config)# exit |
|
Step 7 |
Display information about the detailed logging IP access list and ACE actions: switch# show logging ip access-list cache detail |
|
Step 8 |
(Optional) Display the running configuration for Cisco TrustSec: switch# show run cts |
This example shows a running configuration, followed by verification commands that display the detailed logging IP access list. The status of the monitor mode and ACE action are highlighted in the output. Replace the placeholders with relevant values for your setup.
configure terminal
cts role-based detailed-logging
logging ip access-list detailed
logging level acllog 6
logging ip access-list cache interval 15
.
.
.
switch(config)# sh logging ip access-list cache detail
SGT Src IP Dst IP S-Port D-Port Src Intf Protocol Monitor ACL-Name ACE-Number ACE-Action ACL-Direction ACL-Filter-Type ACL Applied Intf Hits
---------------------------------------------------------------------------------------------------------------------------------------------
40 4.1.1.2 3.1.1.1 0 0 Ethernet4/11 (1)ICMP (1 )ON ---- ----- Deny ----- ----- ----- 0 --------------------------------------------------------------------------------
10 1.1.1.1 2.1.1.2 0 0 Ethernet4/46 (1)ICMP (1 )ON ---- ----- Permit ----- ----- ----- 8
--------------------------------------------------------------------------------
20 2.1.1.2 1.1.1.1 0 0 Ethernet4/34 (1)ICMP (0 )OFF ---- ----- Deny ----- ----- ----- 3
--------------------------------------------------------------------------------
30 3.1.1.1 4.1.1.2 0 0 Ethernet8/48 (1)ICMP (0 )OFF ---- ----- Permit ----- ----- ----- 0
--------------------------------------------------------------------------------
Number of cache entries: 4
--------------------------------------------------------------------------------------------------------------------------------------
The following example displays detailed logging when monitor all is enabled:
switch(config)# show logging ip access-list cache detail
SGT Src IP Dst IP S-Port D-Port Src Intf Protocol Monitor ACL-Name ACE-Number ACE-Action ACL-Direction ACL-Filter-Type ACL Applied Intf Hits
---------------------------------------------------------------------------------------------------------------------------------------------
26 172.16.2.6 10.1.1.1 0 0 Ethernet6/14 (1)ICMP (1 )ON ---- ----- Deny ----- ----- ----- 20
--------------------------------------------------------------------------------
Number of cache entries: 1
--------------------------------------------------------------------------------------------------------------------------------------Note |
In this output, the logs show Deny, but traffic is not denied when Monitor (1 ) ON is displayed. |
The following example displays system log:
2016 Jan 22 10:48:47 xbow-vdc4 %$ VDC-4 %$ %ACLLOG-6-ACLLOG_FLOW_INTERVAL: Src IP: 172.16.2.6, Dst IP: 10.1.1.1, Src Port: 0, Dst Port: 0, Src Intf: Ethernet6/14, Protocol: "ICMP"(1), Monitor: (1)"ON" , ACL Name: ---, ACE Action: Deny, Appl Intf: ---, Hit-count: 20
The following example displays the Cisco TrustSec policy:
switch# show cts role-based policy
sgt:26
dgt:101 rbacl:test(monitored)
deny ip log
switch# show running-config cts
!Command: show running-config cts
!Time: Fri Jan 22 11:01:54 2016
version 7.3(0)D1(1)
feature cts
cts role-based counters enable
cts role-based detailed-logging
cts role-based monitor enable
cts role-based monitor all
cts role-based sgt-map 10.1.1.1 101
cts role-based sgt-map 172.16.2.6 26
cts role-based access-list permit
permit ip log
cts role-based access-list test
deny ip log
cts role-based sgt 26 dgt 101 access-list test
cts role-based enforcement
logging level cts 6
switch(config)# show cts role-based counters
RBACL policy counters enabled
Counters last cleared: 01/22/2016 at 10:58:27 AM
sgt:26 dgt:101 [20]
rbacl:test(monitored)
deny ip log [20]
switch(config)# show system internal access-list output entries detail module 6
Flags: F - Fragment entry E - Port Expansion
D - DSCP Expansion M - ACL Expansion
T - Cross Feature Merge Expansion
VDC-4 VRF table 1 :
====================
INSTANCE 0x0
---------------
Tcam 0 resource usage:
----------------------
Label_a = 0x200
Bank 0
------
IPv4 Class
Policies: Rbacl()
Netflow profile: 0
Netflow deny profile: 0
Entries:
[Index] Entry [Stats]
---------------------
[0014:000a:000a] prec 3 permit ip 0.0.0.26/32 0.0.0.101/32 log [0]
[0015:000b:000b] prec 3 permit ip 0.0.0.0/0 0.0.0.0/0 log [0]
[0016:000c:000c] prec 3 permit ip 0.0.0.0/0 0.0.0.0/0 [0]
L4 protocol cam entries usage: none
No mac protocol cam entries are in use
INSTANCE 0x1
---------------
Tcam 0 resource usage:
----------------------
Label_a = 0x200
Bank 0
------
IPv4 Class
Policies: Rbacl()
Netflow profile: 0
Netflow deny profile: 0
Entries:
[Index] Entry [Stats]
---------------------
[0014:000a:000a] prec 3 permit ip 0.0.0.26/32 0.0.0.101/32 log [20]
[0015:000b:000b] prec 3 permit ip 0.0.0.0/0 0.0.0.0/0 log [0]
[0016:000c:000c] prec 3 permit ip 0.0.0.0/0 0.0.0.0/0 [0]
Ensure that you have enabled Cisco TrustSec.
Ensure that you have enabled counters.
|
Step 1 |
Enter global configuration mode: switch# configure terminal |
||
|
Step 2 |
Enable detailed logging for SGACLs: switch(config)# cts role-based detailed-logging |
||
|
Step 3 |
Depending on the requirements, perform one of the following actions:
|
||
|
Step 4 |
Display the Cisco TrustSec SGACL policies and details about the monitor mode feature for each pair: switch(config)# show cts role-based policy |
||
|
Step 5 |
Display the monitoring status of RBACL statistics and lists statistics for all RBACL policies: switch(config)# show cts role-based counters
|
||
|
Step 6 |
(Optional) Display the running configuration for Cisco TrustSec: switch(config)# show run cts |
This example shows a running configuration to configure the SGACL monitor mode for SGT 20 to DGT 30. Replace the placeholders with relevant values for your setup.
configure terminal
cts role-based detailed-logging
cts role-based monitor permissions from <20> to <30>
exit
The following example displays the Cisco TrustSec SGACL policies and details about the monitor mode feature for each SGT-DGT pair:
switch(config)# sh cts role-based policy
sgt:unknown
dgt:unknown rbacl:rbacl1
permit ip log
sgt:10
dgt:20 rbacl:rbacl1(monitored)
permit ip log
sgt:20
dgt:10 rbacl:rbacl2
deny ip log
sgt:30
dgt:40 rbacl:rbacl1
permit ip
sgt:40
dgt:30 rbacl:rbacl2(monitored)
deny ip
sgt:any
dgt:any rbacl:rbacl1
permit ip log
The following example displays the monitoring status of RBACL statistics and lists the statistics for all the RBACL policies:
switch(config)# sh cts role-based counters
RBACL policy counters enabled
Counters last cleared: 12/23/2015 at 01:41:46 AM
sgt:unknown dgt:unknown [0]
rbacl:rbacl1
permit ip log [0]
sgt:10 dgt:20 [5]
rbacl:rbacl1(monitored)
permit ip log [5]
sgt:20 dgt:10 [5]
rbacl:rbacl2
deny ip log [5]
sgt:30 dgt:40 [0]
rbacl:rbacl1
permit ip [0]
sgt:40 dgt:30 [0]
rbacl:rbacl2(monitored)
deny ip [0]
sgt:any dgt:any [0]
rbacl:rbacl1
permit ip log [0]
The following example displays a running configuration for Cisco TrustSec:
switch(config)# show run cts
!Command: show running-config cts
!Time: Wed Dec 23 02:01:43 2015
version 7.3(0)D1(1)
feature cts
cts role-based counters enable
cts role-based detailed-logging
cts role-based monitor enable
cts role-based sgt-map 1.1.1.1 10
cts role-based sgt-map 2.1.1.2 20
cts role-based sgt-map 3.1.1.1 30
cts role-based sgt-map 4.1.1.2 40
cts role-based access-list rbacl1
permit ip log
cts role-based access-list rbacl2
deny ip log
cts role-based sgt 0 dgt 0 access-list rbacl1
cts role-based sgt 10 dgt 20 access-list rbacl1
cts role-based sgt 20 dgt 10 access-list rbacl2
cts role-based sgt 30 dgt 40 access-list rbacl1
cts role-based sgt 40 dgt 30 access-list rbacl2
cts role-based sgt any dgt any access-list rbacl1
cts role-based monitor permissions from 10 to 20
cts role-based monitor permissions from 40 to 30
cts role-based enforcement
The following example displays the running configuration for Cisco TrustSec, that does not include the SGACL logging:
switch(config)# show run cts
!Command: show running-config cts
!Time: Wed Dec 23 02:01:43 2015
version 7.3(0)D1(1)
feature cts
cts role-based counters enable
cts role-based detailed-logging
cts role-based monitor enable
cts role-based sgt-map 1.1.1.1 10
cts role-based sgt-map 2.1.1.2 20
cts role-based sgt-map 3.1.1.1 30
cts role-based sgt-map 4.1.1.2 40
cts role-based access-list rbacl1
permit ip log
cts role-based access-list rbacl2
deny ip log
cts role-based access-list rbacl1_no_log
permit ip
cts role-based access-list rbacl2_no_log
deny ip
cts role-based sgt 0 dgt 0 access-list rbacl1
cts role-based sgt 10 dgt 20 access-list rbacl1
cts role-based sgt 20 dgt 10 access-list rbacl2
cts role-based sgt 30 dgt 40 access-list rbacl1_no_log
cts role-based sgt 40 dgt 30 access-list rbacl2_no_log
cts role-based sgt any dgt any access-list rbacl1
cts role-based monitor permissions from 10 to 20
cts role-based monitor permissions from 40 to 30
cts role-based enforcement
You can manually configure unique Cisco TrustSec security group tags (SGTs) for the packets originating from this device.
Ensure that you have enabled Cisco TrustSec.
|
Step 1 |
Enter global configuration mode: switch# configure terminal |
||
|
Step 2 |
Configure the SGT for packets sent from the device: switch(config)# cts sgt tag
|
||
|
Step 3 |
Exit global configuration mode: switch(config)# exit |
||
|
Step 4 |
(Optional) Display the Cisco TrustSec environment data information: switch# show cts environment-data |
||
|
Step 5 |
(Optional) Copy the running configuration to the startup configuration: switch# copy running-config startup-config |
You can manually configure an IPv4 address to SGACL SGT mapping on a VLAN if you do not have Cisco Secure ACS, dynamic ARP inspection, or DHCP snooping available on your Cisco NX-OS device.
Ensure that you enabled Cisco TrustSec.
Ensure that you enabled SGACL policy enforcement on the VLAN.
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
configure terminal Example: |
Enters global configuration mode. |
|
Step 2 |
vlan vlan-id Example: |
Specifies a VLAN and enters VLAN configuration mode. |
|
Step 3 |
cts role-based sgt-map ipv4-address tag Example: |
Configures SGT mapping for the SGACL policies for the VLAN. |
|
Step 4 |
exit Example: |
Saves the VLAN configuration and exits VLAN configuration mode. |
|
Step 5 |
(Optional) show cts role-based sgt-map [summary | sxp peer peer-ipv4-addr | vlan vlan-id | vrf vrf-name] Example: |
(Optional)
Displays the Cisco TrustSec SGACL SGT mapping configuration. |
|
Step 6 |
(Optional) copy running-config startup-config Example: |
(Optional)
Copies the running configuration to the startup configuration. |
You can manually configure IPv4-address-to-SGACL SGT mapping on a VRF instance if a Cisco Secure ACS is not available to download the SGACL policy configuration. You can use this feature if you do not have Cisco Secure ACS, dynamic ARP inspection, or DHCP snooping available on your Cisco NX-OS device.
Ensure that you enabled Cisco TrustSec.
Ensure that you enabled SGACL policy enforcement on the VRF instance.
Ensure that the Layer-3 module is enabled.
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
configure terminal Example: |
Enters global configuration mode. |
|
Step 2 |
vrf context vrf-name Example: |
Specifies a VRF instance and enters VRF configuration mode. |
|
Step 3 |
cts role-based sgt-map ipv4-address tag Example: |
Configures SGT mapping for the SGACL policies for the VLAN. |
|
Step 4 |
exit Example: |
Exits VRF configuration mode. |
|
Step 5 |
(Optional) show cts role-based sgt-map [summary | sxp peer peer-ipv4-addr | vlan vlan-id | vrf vrf-name] Example: |
(Optional)
Displays the Cisco TrustSec SGACL SGT mapping configuration. |
|
Step 6 |
(Optional) copy running-config startup-config Example: |
(Optional)
Copies the running configuration to the startup configuration. |
You can map VLANs to SGTs. This procedure is useful for deploying Cisco TrustSec for devices that are VLAN capable but not SGT capable. A host or server can be assigned an SGT based on the assigned VLAN, and any traffic from the VLAN would be marked with the given SGT.
Ensure that you enabled Cisco TrustSec.
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
configure terminal Example: |
Enters global configuration mode. |
|
Step 2 |
vlan vlan-id Example: |
Specifies a VLAN and enters VLAN configuration mode. |
|
Step 3 |
cts role-based sgt sgt-value Example: |
Maps the VLAN to an SGT. The sgt-value argument range is from 1 to 65519. |
|
Step 4 |
exit Example: |
Saves the VLAN configuration and exits VLAN configuration mode. |
|
Step 5 |
(Optional) show cts role-based sgt vlan {all | vlan-id} Example: |
(Optional)
Displays the configured SGT for the specified VLAN. |
|
Step 6 |
(Optional) show cts role-based sgt-map [summary | sxp peer peer-ipv4-addr | vlan vlan-id | vrf vrf-name] Example: |
(Optional)
Displays the SGT mappings. |
|
Step 7 |
(Optional) copy running-config startup-config Example: |
(Optional)
Copies the running configuration to the startup configuration. |
You can manually configure SGACL policies on your Cisco NX-OS device if a Cisco Secure ACS is not available to download the SGACL policy configuration.
Ensure that you have enabled Cisco TrustSec.
For Cisco TrustSec logging to function, you must enable Cisco TrustSec counters or statistics.
Ensure that you have enabled SGACL policy enforcement on the VLAN and VRF instance.
| Command or Action | Purpose | |||
|---|---|---|---|---|
|
Step 1 |
configure terminal Example: |
Enters global configuration mode. |
||
|
Step 2 |
cts role-based access-list list-name Example: |
Specifies an SGACL and enters role-based access list configuration mode. The list-name argument value is alphanumeric, case sensitive, and has a maximum length of 32 characters. |
||
|
Step 3 |
(Optional) {deny | permit} all Example: |
(Optional)
Denies or permits all traffic. |
||
|
Step 4 |
(Optional) {deny | permit} icmp Example: |
(Optional)
Denies or permits Internet Control Message Protocol (ICMP) traffic. |
||
|
Step 5 |
(Optional) {deny | permit} igmp Example: |
(Optional)
Denies or permits Internet Group Management Protocol (IGMP) traffic. |
||
|
Step 6 |
(Optional) {deny | permit} ip Example: |
(Optional)
Denies or permits IP traffic. |
||
|
Step 7 |
(Optional) {deny | permit} tcp [{dst | src} {{eq | gt | lt | neq} port-number | range port-number1 port-number2}] Example: |
(Optional)
Denies or permits TCP traffic. The default permits all TCP traffic. The range for the port-number, port-number1, and port-number2 arguments is from 0 to 65535. |
||
|
Step 8 |
{deny | permit} udp [{dst | src} {{eq | gt | lt | neq} port-number | range port-number1 port-number2}] Example: |
Denies or permits UDP traffic. The default permits all UDP traffic. The range for the port-number, port-number1, and port-number2 arguments is from 0 to 65535. |
||
|
Step 9 |
exit Example: |
Exits role-based access-list configuration mode. |
||
|
Step 10 |
cts role-based sgt {sgt-value | any | unknown} dgt {dgt-value | any | unknown} access-list list-name Example: |
Maps the SGT values to the SGACL. The sgt-value and dgt-value argument values range from 0 to 65520.
|
||
|
Step 11 |
(Optional) show cts role-based access-list Example: |
(Optional)
Displays the Cisco TrustSec SGACL configuration. |
||
|
Step 12 |
(Optional) copy running-config startup-config Example: |
(Optional)
Copies the running configuration to the startup configuration. |
After you configure the Cisco TrustSec device credentials and AAA, you can verify the Cisco TrustSec SGACL policies downloaded from the Cisco Secure ACS. The Cisco NX-OS software downloads the SGACL policies when it learns of a new SGT through authentication and authorization on an interface, from SXP, or from manual IPv4 address to SGACL SGT mapping.
Ensure that you enabled Cisco TrustSec.
| Command or Action | Purpose |
|---|---|
|
show cts role-based access-list Example: |
Displays Cisco TrustSec SGACLs, both downloaded from the Cisco Secure ACS and manually configured on the Cisco NX-OS device. |
You can refresh the SGACL policies downloaded to the Cisco NX-OS device by the Cisco Secure ACS.
Ensure that you enabled Cisco TrustSec.
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
cts refresh role-based-policy sgt {sgt-value | any | unknown} Example:Example: |
Refreshes the Cisco TrustSec SGACL policies from the Cisco Secure ACS.
|
|
Step 2 |
(Optional) show cts role-based policy Example: |
(Optional)
Displays the Cisco TrustSec SGACL policies. |
You can refresh the environment data download from the AAA server.
Ensure that you enabled Cisco TrustSec.
Ensure that you are using the Cisco Identity Services Engine (ISE) Release 1.0 or later releases.
| Command or Action | Purpose | |||
|---|---|---|---|---|
|
Step 1 |
cts refresh environment-data Example: |
Refreshes the environment data from the AAA server. |
||
|
Step 2 |
show cts environment-data Example: |
Displays the downloaded environment data pertaining to the local device.
|
You can clear the Cisco TrustSec SGACL policies.
Ensure that you enabled Cisco TrustSec.
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
(Optional) show cts role-based policy Example: |
(Optional)
Displays the Cisco TrustSec RBACL policy configuration. |
|
Step 2 |
clear cts policy {all | peer device-name | sgt sgt-value} Example: |
Clears the policies for Cisco TrustSec connection information. |
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 Cisco NX-OS devices in your network.
Follow these steps to manually configure Cisco TrustSec SXP:
|
Step 1 |
Enable the Cisco TrustSec feature. |
||
|
Step 2 |
Enable SGACL policy enforcement on the VRF instance. |
||
|
Step 3 |
Enable Cisco TrustSec SXP. |
||
|
Step 4 |
Configure SXP peer connections.
|
You must enable Cisco TrustSec SXP before you can configure peer connections.
Ensure that you enabled Cisco TrustSec.
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
configure terminal Example: |
Enters global configuration mode. |
|
Step 2 |
cts sxp enable Example: |
Enables SXP for Cisco TrustSec. |
|
Step 3 |
exit Example: |
Exits global configuration mode. |
|
Step 4 |
(Optional) show cts sxp Example: |
(Optional)
Displays the SXP configuration. |
|
Step 5 |
(Optional) copy running-config startup-config Example: |
(Optional)
Copies the running configuration to the startup configuration. |
You must configure the SXP peer connection on both the speaker and listener devices. When using password protection, make sure to use the same password on both ends.
Note |
If the default SXP source IP address is not configured and you do not specify the SXP source address in the connection, the Cisco NX-OS software derives the SXP source IP address from existing local IP addresses. The SXP source address could be different for each TCP connection initiated from the Cisco NX-OS device. |
Ensure that you enabled Cisco TrustSec.
Ensure that you enabled SXP.
Ensure that you enabled RBACL policy enforcement in the VRF instance.
| Command or Action | Purpose | |||
|---|---|---|---|---|
|
Step 1 |
configure terminal Example: |
Enters global configuration mode. |
||
|
Step 2 |
cts sxp connection peer peer-ipv4-addr [source src-ipv4-addr] password {default | none | required password} mode {speaker | listener | local | peer | speaker} } [vrf vrf-name] Example: |
Configures the SXP address connection. The source keyword specifies the IPv4 address of the source device. The default source is IPv4 address you configured using the cts sxp default source-ip command. The password keyword specifies the password that SXP should use for the connection using the following options:
The speaker and listener keywords specify the role of the remote peer device. The vrf keyword specifies the VRF instance to the peer. The default is the default VRF instance.
|
||
|
Step 3 |
exit Example: |
Exits global configuration mode. |
||
|
Step 4 |
(Optional) show cts sxp connections Example: |
(Optional)
Displays the SXP connections and their status. |
||
|
Step 5 |
(Optional) copy running-config startup-config Example: |
(Optional)
Copies the running configuration to the startup configuration. |
By default, SXP uses no password when setting up connections. You can configure a default SXP password for the Cisco NX-OS device.
Ensure that you enabled Cisco TrustSec.
Ensure that you enabled SXP.
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
configure terminal Example: |
Enters global configuration mode. |
|
Step 2 |
cts sxp default password password Example: |
Configures the SXP default password. |
|
Step 3 |
exit Example: |
Exits global configuration mode. |
|
Step 4 |
(Optional) show cts sxp Example: |
(Optional)
Displays the SXP configuration. |
|
Step 5 |
(Optional) show running-config cts Example: |
(Optional)
Displays the SXP configuration in the running configuration. |
|
Step 6 |
(Optional) copy running-config startup-config Example: |
(Optional)
Copies the running configuration to the startup configuration. |
The Cisco NX-OS software uses the default source IPv4 address in all new TCP connections where a source IPv4 address is not specified. When you change the default source IP address, the existing SXP connections are reset and the IP-SGT bindings learned over SXP are cleared. The SXP connections, for which a source IP address has been configured, will continue to use the same IP address, while coming back up.
The SXP connections, for which a source IP address has not been configured, uses the default IP address as the source IP address. Note that for such connections, correct destination IP address configuration on the peer and the reachability to the default source IP address are the required conditions before such connections can become operational. It is recommended to ensure that these conditions are met for existing operational connections, before configuring default source IP address on a device.
Ensure that you enabled Cisco TrustSec.
Ensure that you enabled SXP.
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
configure terminal Example: |
Enters global configuration mode. |
|
Step 2 |
cts sxp default source-ip src-ip-addr Example: |
Configures the SXP default source IPv4 address. |
|
Step 3 |
exit Example: |
Exits global configuration mode. |
|
Step 4 |
(Optional) show cts sxp Example: |
(Optional)
Displays the SXP configuration. |
|
Step 5 |
(Optional) copy running-config startup-config Example: |
(Optional)
Copies the running configuration to the startup configuration. |
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 reconcile period timer starts. While the SXP reconcile period timer is active, the Cisco NX-OS 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 reconcile period to 0 seconds disables the timer and causes all entries from the previous connection to be remo