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.
The Cisco TrustSec
security architecture enables you to build secure networks by establishing
clouds of trusted network devices. Each device in the cloud is authenticated by
its neighbors.
Cisco TrustSec uses the device and user identification information that is acquired during authentication to classify or tag
packets as they enter the network. These packets are tagged on ingress to the Cisco TrustSec network so that they can be 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 when a packet enters the first Cisco TrustSec-capable device on its path to the destination. Egress refers
to when a packet leaves the last Cisco TrustSec-capable device on the path.
This figure shows an
example of a Cisco TrustSec cloud.
Figure 1. Cisco TrustSec Network Cloud Example
The Cisco TrustSec
architecture consists of the following major components:
Authentication—Verifies the identity of each device before allowing it to join the Cisco TrustSec network.
Authorization—Decides the level of access to the Cisco TrustSec network
resources that is based on the authenticated identity of the device.
Access
control—Applies access policies on a per-packet basis using the source tags on
each packet.
Secure
communication—Provides encryption, integrity, and data-path replay protection
for the packets that flow over each link in the Cisco TrustSec network.
Security Group-Based Access Control
SGACLs and SGTs
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 the Cisco
NX-OS device, you 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 the 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 achieves access control
within the network. The following figure shows an example of an SGACL policy.
Figure 2. SGACL Policy
Example
This following
figure shows how the SGT assignment and the SGACL enforcement operate in a
Cisco TrustSec network.
Figure 3. SGT and SGACL in Cisco TrustSec Network
The Cisco NX-OS
device defines 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. Cisco TrustSec 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:
The number of ACEs =
(The number of sources specified) X (The number of destinations specified) X
(The number of permissions specified)
Cisco TrustSec uses
the following formula:
The number of ACEs =
The number of permissions specified
SGACL
Policies
Using security group
access control lists (SGACLs), you can control the operations that users can
perform based on the security group assignments of users and destination
resources. Policy enforcement within the Cisco TrustSec domain is represented
by a permissions matrix, with source security group numbers on one axis and
destination security group tags on the other axis. Each cell in the body of the
matrix can contain an ordered list of SGACLs which specifies the permissions
that should be applied to packets originating from the source security group
and destined for the destination security group.
The following figure
shows an example of a Cisco TrustSec permissions matrix for a simple domain
with three defined user roles and one defined destination resource. Three SGACL
policies control access to the destination server based on the role of the
user.
Figure 4. SGACL Policy
Matrix Example
By assigning users and
devices within the network to security groups and applying access control
between the security groups, Cisco TrustSec achieves role-based
topology-independent access control within the network. Because SGACLs define
access control policies based on device identities instead of IP addresses as
in traditional ACLs, network devices are free to move throughout the network
and change IP addresses. As long as the roles and the permissions remain the
same, changes to the network topology do not change the security policy. When a
user is added to the switch, you simply assign the user to an appropriate
security group and the user immediately receives the permissions of that group.
Using role-based
permissions greatly reduces the size of ACLs and simplifies their maintenance.
With Cisco TrustSec, the number of access control entries (ACEs) configured is
determined by the number of permissions specified, resulting in a much smaller
number of ACEs than in a traditional IP network.
Determining the
Source Security Group
A network device at
the ingress of the Cisco TrustSec cloud needs to determine the SGT of the
packet that enters the Cisco TrustSec cloud so that it can tag the packet with
that SGT when it forwards it into the Cisco TrustSec cloud. The egress network
device needs to determine the SGT of the packet so that it can apply the
SGACLs.
The network device
determines the SGT for a packet in the following order:
CTS tag
CLI
SXP
Interface local
Determining the
Destination Security Group
The egress network
device in a Cisco TrustSec cloud determines the destination group (DGT) for
applying the RBACL. This DGT is obtained from the tag that is configured on the
egress interface by the interface's port profile.
The network device
determines the SGT for a packet in the following order:
CLI
SXP
Interface local
SGACL
Enforcement
You configure SGACL enforcement on a port profile. If SGACL enforcement is enabled on the egress interface, the RBACL configured
for the (SGT, DGT) pair is applied to the packet. If the packet is dropped, statistics are updated on the ACE. If the SGT
is unknown (0), the (*,DGT) policy is applied.
Cisco TrustSec With
SXPv3
The Security Group Tag (SGT) Exchange Protocol (SXP) is a control protocol that propagates IP address-SGT binding information
across network devices. The Cisco TrustSec supports SXP version 3 (SXPv3) to enable transporting IPv4 subnet to the SGT bindings.
By using the
subnet-to-SGT bindings, you can minimize the forward information base (FIB)
entries needed for storing the mapping, thereby increasing the scale of
TrustSec deployments. In many scenarios, you can use subnet-SGT bindings
instead of the L3 interface-SGT.
Note
SXPv3 does not
support IPv6.
SXPv3 Subnet
Expansion
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 applies 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 the
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 4096.
You can set the expansion limit as 0 when you do not have any devices in the
network that support a lower version of SXP.
You can use the
cts sxp
mapping network-map [num_bindings] command to expand
the network limit. The
num_bindings parameter accept a value from 0 to 4096.
The value zero (0) indicates that no expansion is allowed and 4096 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 CTS. 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 4096, 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.
Cisco TrustSec
Subnet-SGT Mapping
The subnet-SGT mapping
binds an SGT to all the host addresses of a specified subnet. After this
mapping is completed, Cisco TrustSec imposes SGT on the incoming packets with
the source IP address that belongs to the specified subnet. This enables you to
enforce the CTS policy on the traffic flowing through data center hosts. You
can configure IPv4 subnet-SGT bindings under a VRF instance.
A new attribute,
net-mask, is added to the
cts role-based
sgt map command to define subnet mapping on the VSM.
In IPv4 networks,
SXPv3 and later versions can receive and parse subnet network addresses 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.
The 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.
Overview of Cisco
TrustSec with SXPv4
CTS 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/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.
Figure 5. SXPv4 Loop
Detection
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.
The commonly used SXPv4 terms are:
SXP Node ID: SXP Node ID is a 32 bit identifier that is either self-assigned by the switch or router, or can be configured by the user.
It is important for the loop detection/prevention functionality.
SXP Default Node ID: If a SXP Node ID is not configured by the user, when SXP is enabled and before establishing a connection, the switch or
router has the capability to self-assign the SXP Node ID identifier. For Nexus 1000VE, the IP address configured for mgmt0
interface is configured as the default Node ID.
SXP Peer sequence: Sequence of node IDs of the devices through which the IP-SGT binding has traversed in order to reach the listener, with
the node ID of the immediate speaker at the head of the list. The peer sequence information is necessary for the accurate
loop prevention. The listener discards bindings with its own node ID in the sequence information.
SXP Keep-alive mechanism: In-built keep-alive handshake mechanism between speaker and listener in order to allow for timely detection of connectivity
loss, deletion of connection resources and staling of the IP-SGT bindings. SXPV4 capable devices use TCP Keep-alive over V1
and V3 connections.
SXP Speaker Hold Time: The minimum acceptable hold-time that the speaker allows for a connection (directly related to the minimum interval at which
speaker will send out keep-alive messages).
SXP Listener Hold Time Range: The hold time range the listener requires for a connection (directly related to the minimum and maximum intervals at which
listener expects keep-alive messages from the speaker).
SXP Connection Negotiated Hold Time: The negotiated hold time that the speaker and listener agree upon in the open message hand-shakes prior to connection is
established.
Note
The listener expects to receive at least one update or keep-alive message within the Listener Hold Time interval on an SXPV4
connection. If the negotiation succeeds, the speaker hold time is lesser than the maximum listener hold time.
SXP Capability: The Nexus 1000VE listeners advertises the following capabilities: IPV4 and Subnet-SGT. Additionally, to support default
IP-SGT transport in a mixed network, the default IP-SGT capability is exported to allow the speaker to selectively transport
default IP-SGT mapping over SXPV4 connections.
IP-SGT (Installed) Database: The installed IP-SGT database that consists of the final IP-SGT bindings amongst all sources (CLI/SXP, Port-sgt etc) that
are selected for local installation and transport over SXP.
SXP Contributor Database: This database contains all the host/subnet SGT bindings learnt from every contributor, along with the subsidiary information
useful for loop detection and prevention, Peer Sequence:
Time-Stamp/ Counter information
Active/Contributor status
SGT and Staling Flags.
SXP Contributor Logic: If there are one or more contributors for the same binding learned at a listener, the SXPV4 listener applies the following
logic to determine the active/best SXP contributor:
Shortest Path Rule: Bindings with the shortest peer-sequence length are preferred.
Most Recently Received Rule: Bindings learnt most-recently are preferred as a tie-breaker.
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 1000VE 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 does 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.
Keepalive and
Hold-Time Negotiation with SXPv4
SXP uses a TCP-based, keepalive mechanism to determine if a connection
is live. SXPv4 adds an optional negotiated keepalive mechanism within the
protocol in order 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) being 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 and/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 via
update messages.
The hold-time for the keepalive mechanism may be negotiated during the
open/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.
Bidirectional SXP
Support Overview
The Bidirectional SXP Support feature enhances the functionality of
Cisco TrustSec with SXP version 4 by adding support for Security Group Tag
(SGT) Exchange Protocol (SXP) bindings that can be propagated in both
directions between a speaker and a listener over a single connection.
With the support for bidirectional Security Group Tag (SGT) Exchange
Protocol (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.
Figure 6. Bidirectional SXP Connection
In addition, Bi-directional 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.
Guidelines and
Limitations for SXPv4
Cisco TrustSec
SXPv4 has the following guidelines and limitations:
The
Bidirectional SXP Support feature enhances the functionality of Cisco TrustSec
with SXP version 4 by adding support for Security Group Tag (SGT) Exchange
Protocol (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 1000VE series switches over SXPV4 connections. However, the
SXPv4 peering with speakers transporting IPv6 bindings are still supported.
Cisco Nexus 1000VE series switches only expands Subnet-SGT bindings over SXPv3 connections.
After upgrading
a switch, the switch advertizes the default SXPv4 version. 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.
Prior to
modifications to 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 either speaker or listener disables the
in-built keep-alive 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 uni-directional connections to bi-directional 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.
SXP Version
Negotiation
The SXP session is
established between speaker devices and listener devices. By default, the CTS
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 CTS-supported device can establish an SXP session with
different versions, with its peer devices, depending on the SXP versions of the
peer devices.
The following table
provides information about version negotiation for interoperability in
different scenarios.
Table 1. SXP Version
Negotiation Cases
Case Number
Speaker
Listener
SXP Session
Status
SXPv1
SXPv1
SXPv1 session
is established.
SXPv1
SXPv2
SXPv1 session
is established.
SXPv1
SXPv3
SXPv1 session
is established.
SXPv1
SXPv4
SXPv1 session is established.
SXPv1
SXPv4
SXPv1
session is established.
SXPv2 (Not
N1KV)
SXPv1
SXPv1 session
is established.
SXPv2
SXPv2
Not possible because a Cisco Nexus 1000VE switch does not support SXPv2.
SXPv2 (Not
N1KV)
SXPv3
When the Cisco Nexus 1000VE (SXPv3) Listener receives an OPEN RSP from an SXPv2 speaker:
The
Listener generates a system log (syslog), records the Speaker's version, and
terminates the session.
The
connection is re-established and the Speaker's version is checked:
If the
Speaker version is SXPv2, Listener sends OPEN with SXPv1.
If the
Speaker version is not SXPv2, Listener sends OPEN with SXPv3.
On
receiving an OPEN with SXPv3 response, the Speaker (SXPv2) falls back to SXPv1
and establishes the connection.
SXPv2 (Not
N1KV)
SXPv4
When the Cisco Nexus 1000VE (SXPv4) Listener receives an OPEN RSP from an SXPv2 speaker:
The
Listener generates a system log (syslog), records the Speaker's version, and
terminates the session.
The
connection is re-established and the Speaker's version is checked:
If
the Speaker version is SXPv2, Listener sends OPEN with SXPv1.
If
the Speaker version is not SXPv2, Listener sends OPEN with SXPv4.
On
receiving an OPEN with SXPv4 response, the Speaker (SXPv2) falls back to SXPv1
and establishes the connection.
SXPv3
SXPv1
SXPv1 session
is established.
SXPv3
SXPv2
When the Cisco Nexus 1000VE (SXPv3) Listener receives an OPEN RSP from an SXPv2 speaker:
The
Listener generates a system log (syslog), records the Speaker's version, and
terminates the session.
The
connection is re-established and the Speaker's version is checked:
If
the Speaker version is SXPv2, Listener sends OPEN with SXPv1.
If
the Speaker version is not SXPv2, Listener sends OPEN with SXPv3.
On
receiving an OPEN with SXPv1 response, the Speaker (SXPv2) falls back to SXPv1
and establishes the connection.
SXPv3
SXPv3
SXPv3
session is established.
SXPv3
SXPv4
SXPv3
session is established.
SXPv4
SXPv3
SXPv3
session is established.
SXPv4
SXPv4
SXPv4
session is established.
Authorization and
Policy Acquisition
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:
Cisco TrustSec Trust
Indicates
whether the neighbor device is to be trusted for the purpose of putting the SGT
in the packets.
Peer SGT
Indicates the
security group that the peer belongs to. If the peer is not trusted, all
packets received from the peer are tagged with the SGT configured on the
ingress interface. If enforcement is enabled on this interface, the SGACLs that
are associated with the peer SGT are downloaded. If the device does not know if
the SGACLs are associated with the peer’s SGT, the device might send a
follow-up request to fetch the SGACLs.
Authorization
expiry time
Indicates the
number of seconds before the policy expires. The Cisco-proprietary
attribute-value (AV) pairs indicate the expiration time of an authorization or
policy response to a Cisco TrustSec device. A Cisco TrustSec device should
refresh its policy and authorization before it times out.
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.
Licensing
Requirements for Cisco TrustSec
The following table
shows the licensing requirements for this feature:
Feature
License Requirement
Cisco
TrustSec
This
feature requires an Advanced Services License. See the
Cisco Nexus 1000V License Configuration Guide
for more information on the licensing requirements for
Cisco Nexus 1000V.
Prerequisites for
Cisco TrustSec
You must install
the Advanced Services license.
You must enable the 802.1X feature.
You must enable
the Cisco TrustSec feature.
You must enable
the Cisco TrustSec SXP.
Guidelines and
Limitations for Cisco TrustSec
ISE policies do
not take precedence over the policies configured locally on the VSM. If you
want ISE policies to take precedence, you must remove the locally-configured
policy.
Cisco TrustSec
supports only IPv4 addressing.
To assign an SGT
to a VM, you must manually configure SGT in the port profile.
A maximum of
6000 IP-SGT mappings can be learned system-wide in the DVS. This total is for
entries learned through DHCP snooping and device tracking of individual VMs by
ARP as well as IP traffic inspection.
A maximum of 10
IP-SGT bindings can be learned from a single virtual Ethernet interface.
The IP-SGT
mappings can be communicated to up to 64 SXP peer devices.
Cisco TrustSec
does not support 802.1x or data encryption.
Cisco TrustSec does not support SXPv2 specifications.
The number of rules per policy is limited to the number of ACL policies that are supported by Cisco Nexus 1000VE.
If you override SGT mapping to a different SGT, removing the override does not revert the mapping to original SGT configuration.
CTS propage-sgt configuration does not function as expected.
The CTS interface delete-hold timer is not applicable when the port-profile is shut down. The IPSGT entry exists till the
expiry of the keep-alive default timer which runs on VSE, and then the IPSGT entry is removed from the VSM which takes more
than 80 secs.
The CTS commands that you enter under the interface mode take precedence over the port profile's commands if there is a conflict.
However, the interface retains that command irrespective of port-profile configuration.
Default
Settings
Table 2. Default Cisco
TrustSec Settings
Parameters
Default
Cisco TrustSec
Disabled
SXP
Disabled
SXP default
password
None
SXP reconcile
period
120 seconds
SXP retry
period
60 seconds
Device
tracking
Enabled
Interface
delete hold timer
60 seconds
Configuring Cisco TrustSec
Enabling the Cisco
TrustSec Feature
You must enable the
802.1X feature and the Cisco TrustSec feature on the
Cisco Nexus 1000V before you can configure Cisco
TrustSec.
Note
You cannot
disable the 802.1X feature after you enable the Cisco TrustSec feature.
Before you begin
Log in to the
CLI in EXEC mode.
Ensure that you
have installed the Advanced Services license.
Procedure
Command or Action
Purpose
Step 1
switch#
configure terminal
Enters global
configuration mode.
Step 2
feature dot1x
Example:
switch(config)# feature dot1x
Enables the
802.1X feature.
Step 3
switch(config)#
[no] feature cts
Enables (or
disables when you use the
no form) the
Cisco TrustSec feature.
Step 4
(Optional) switch(config)#
show cts
(Optional)
Displays the
Cisco TrustSec configuration.
Step 5
(Optional) switch(config)#
show feature
(Optional)
Displays the
enabled status for features.
Step 6
(Optional)
copy running-config
startup-config
(Optional)
Copies the
running configuration to the startup configuration.
Example
This example shows
how to enable the Cisco TrustSec feature:
switch# configure terminal
switch(config)# feature cts
switch(config)# show cts
CTS Global Configuration
==============================
CTS support : enabled
CTS device identity : not configured
SGT : 0
CTS caching support : disabled
Number of CTS interfaces in
DOT1X mode : 0
Manual mode : 0
switch(config)#
switch(config)# show feature
Feature Name Instance State
-------------------- -------- --------
cts 1 enabled
dhcp-snooping 1 enabled
http-server 1 enabled
lacp 1 disabled
netflow 1 disabled
network-segmentation 1 disabled
port-profile-roles 1 disabled
private-vlan 1 disabled
segmentation 1 disabled
sshServer 1 enabled
tacacs 1 disabled
telnetServer 1 enabled
vtracker 1 disabled
switch(config)#
Configuring Cisco
TrustSec Device Credentials
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 ISE. See the documentation
at the following URL:
You can configure
device tracking to enable VM IP address learning by inspecting the Address
Resolution Protocol (ARP) and IP traffic on virtual Ethernet ports.
Before you begin
Log in to the
CLI in EXEC mode.
You must enable
the Cisco TrustSec SXP.
You must enable
the Cisco TrustSec feature.
You must install
the Advanced Services license.
Procedure
Command or Action
Purpose
Step 1
switch#
configure
terminal
Enters global
configuration mode.
Step 2
switch(config)#
cts device tracking
Enables device
tracking on Cisco TrustSec.
Note
The Cisco Nexus 1000VE supports tracking of IP addresses from the ARP/IP traffic inspection on the vses and from DHCP snooping.
Cisco TrustSec device tracking tracks IP addresses using the ARP/IP traffic inspection on the vses. To enable Cisco TrustSec
device tracking to track IP addresses from DHCP snooping, you must also enable the DHCP snooping feature.
By default,
device tracking is enabled.
Step 3
(Optional) switch(config)#
show cts
device tracking
(Optional)
Displays the
Cisco TrustSec device tracking 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. The default source IPv4 address must be
set to the IPv4 address of the mgmt0 interface. No other source IPv4 address
works when configuring an SXP peer connection.
Note
There is no
effect on existing TCP connections when you configure the default SXP source
IPv4 address.
You must configure
the SXP peer connection on both the speaker and the listener devices. When you
are using password protection, make sure to use the same password on both the
devices.
Note
The SXP source
IPv4 address must be configured with the mgmt0 IPv4 address for all SXP
connections.
Source—Specifies the IPv4 address of the source.
The default source is the IPv4 address that you configured using the
cts sxp default
source-ip command.
Password—Specifies the password that SXP should
use for the connection using the following options:
Default—Uses the default SXP password that you
configured using the
cts sxp default
password command.
None—Does not use a password.
Required—Uses the password specified in the
command.
Mode—Specifies the role of the remote peer device
using the following options:
listener—The
Cisco Nexus 1000V
acts as the speaker in the connection and the peer is configured as the
listener.
speaker—The
Cisco Nexus 1000V
acts as the listener in the connection and the peer is configured as the
speaker.
The
vrf management
keywords specify that the Virtual Routing and Forwarding (VRF) to the peer is
the management (mgmt0) interface.
Step 3
(Optional) switch(config)#
show cts
sxp connection
Use the
no form
of this command to delete a node ID.
Step 3
Exit global
configuration modes:
switch(config)#
exit
Step 4
(Optional) Display the
node ID of a network device by using one of the following commands:
switch#
show cts sxp
sgt-map
switch#
show run | include
node-id
switch#
show cts sxp sgt-map
detail
Example:
Configuring the Node ID of a Network Device
The following
running configuration shows how to configure the node ID of a network device.
Replace the placeholders with relevant values for your setup.
#Node Id in Hexadecimal format
configure terminal
cts sxp node-id <0x1-0xffffffff>
exit
#Node Id in IPv4 address format
configure terminal
cts sxp node-id <172.16.1.3>
exit
The following
example shows how to configure node ID as an interface.
The valid range is 1-65534. The default hold-time for a speaker
is 120 seconds.
Step 4
Exit global configuration modes:
switch(config)#
exit
Step 5
(Optional) Display the hold-time configuration value:
switch#
show run | grep speaker
switch#
show run | grep listener
Example: Configuring the Hold-Time for the SXPv4 Protocol on a
Network Device
The following running configuration shows how to configure the
hold-time for the SXPv4 protocol on a listener device. Replace the placeholders
with relevant values for your setup.
The following running configuration shows how to configure the
hold-time for the SXPv4 protocol on a speaker device. Replace the placeholders
with relevant values for your setup.
The following example shows how to display the hold-time
configuration values.
switch(config)# show run | grep speaker
cts sxp speaker hold-time 456
switch(config)# show run | grep listener
cts sxp listener hold-time 20 30
Configuring the
Hold-Time for the SXPv4 Protocol for Each Connection
The peer connection must be configured on both devices. One device is
the speaker and the other is the listener. When using password protection, make
sure to use the same password on both ends.
Procedure
Step 1
Enter global configuration mode:
switch#
configure terminal
Step 2
Configure a minimum and maximum acceptable hold-time period in
seconds for the listener device:
A
hold-timemaximum-period value is required only when you use the
following keywords:
peer speaker and
local listener. In other instances, only a
hold-timeminimum-period value is required.
The
source keyword specifies the IPv4 address
of the source device. If no address is specified, the connection uses the
default source address, if configured, or the address of the port.
The
password keyword specifies the password
that CTS-SXP uses for the connection using the following options:
default—Use the default CTS-SXP password
you configured using the
ctssxpdefaultpassword command.
none—A password is not used.
The
mode keyword specifies the role of the
remote peer device:
both — The specified mode refers that the device is both
the speaker and the listener in the bidirectional SXP connection.
local—The specified mode refers to
the local device.
peer—The specified mode refers to the
peer device.
listener— Specifies that the peer
device is the listener.
speaker— Specifies that the peer
device is the speaker.
The
hold-time keyword allows you to specify the length of the
hold-time period for the speaker or listener device. The valid range is from
0-65534 seconds. The value 0 is the global or default hold-time. You can
disable the keep-alive mechanism by specifying the maximum hold-time value as
65535. If the
hold-time option is not specified, the global hold-time
value is used. However, if the global hold-time configuration is missing, the
default hold-time is used.
Note
A
hold-timemaximum-period value is required only when
you use the following keywords:
peer speaker and
local listener. In other instances,
only a
hold-timeminimum-period value is required.
The optional
vrf keyword specifies the VRF to the
peer. The default is the default VRF.
You cannot use the management (mgmt 0) interface for SXP.
Note
The maximum-period value must be greater than or equal to the
minimum-period value.
Step 3
Configure a minimum acceptable hold-time period in seconds for
the speaker device:
The valid range is 1-65534. The default hold-time for a speaker
is 120 seconds.
Step 4
Exit global configuration mode:
switch(config)#
exit
Step 5
(Optional) Displays CTS-SXP status and connections:
switch#
show cts sxp {connections | sgt-map}
[detail|
vrfvrf-name]
Example: Configuring the Hold-Time for the SXPv4 Protocol for Each
Connection
The following running configuration shows how to configure the
hold-time for the SXPv4 protocol for each connection. Replace the placeholders
with relevant values for your setup.
The following example shows how to display the hold-time for the
SXPv4 protocol for a connection.
switch(config)# show run cts | include connection
cts sxp connection peer 1.2.3.4 source 3.4.5.6 password none mode speaker hold-time 113 314 vrf default
switch-listener(config)# show cts sxp sgt-map detail
SXP Node ID(generated):0x14141409
IP-SGT Mappings as follows:
IPv4,SGT : <1.34.56.45/32 , 119>
Vrf :1
Peer IP :5.1.1.1
Status : Active
Seq Num : 3
Peer Seq :0b0b0b0a
IPv4,SGT : <2.3.11.0/28 , 123>
Vrf :1
Peer IP :5.1.1.1
Status : Active
Seq Num : 3
Peer Seq :0b0b0b0a,0e0e0e01
Total number of IP-SGT Mappings: 2
switch # show cts sxp connection detail
----------------------------------------------
Peer IP :3.1.1.2
VRF :default
PEER MODE :speaker
Connection State :connected
Version :4
Node ID :0x0e0e0e01
Capability :UNKNOWN
Conn Hold Time :120 seconds
The following example shows how to display the hold-time
configuration values.
switch(config)# show run | grep speaker
cts sxp speaker hold-time 456
switch(config)# show run | grep listener
cts sxp listener hold-time 20 30
The following example shows how to disable keep-alive mechanism at
listener and speaker devices by configuring maximum values for hold-time.
The
both
keyword configures the bidirectional SXP configuration.
Step 3
Exit global
configuration mode:
switch(config)#
exit
Step 4
(Optional) Displays
CTS-SXP status and connections:
switch#
show cts sxp {connections |
sgt-map} [detail|
vrfvrf-name]
Example:
Configuring Bidirectional SXP Support
The following
running configuration shows how to configure bidirectional SXP support. Replace
the placeholders with relevant values for your setup.
configure terminal
cts sxp connection peer <3.3.3.2> source <3.3.3.1> password <none> mode both vrf <vrf-name>
Warning: The peer should also be configured as both when this peer is configured as both.
The following
example shows how to display bidirectional SXP configuration details.
switch(config)# show run | include connection
cts sxp connection peer 3.3.3.2 source 3.3.3.1 password none mode both vrf management
The following
example shows the SXP learnt SGT bindings:
switch(config)# show cts sxp sgt-map detail
SXP Node ID(generated):0x00000000
IP-SGT Mappings as follows:
Total number of IP-SGT Mappings: 0
Verifying Cisco
TrustSec with SXPv4
The following table provides information about how to verify SXPv4
configuration details.
Commands
Purpose
show cts sxp sgt-map vrfvrf-name
Displays information about SXP connection.
show cts sxp connection
Displays detailed information about SXP connections.
show cts sxp connection detail
Displays SXP connection for the specified VRF.
show cts sxp connection vrfvrf-name
Displays IP address to SGT mapping.
show cts sxp sgt-map
Displays SXP learnt SGT bindings in detail.
show cts sxp sgt-map detail
Displays the SGT mapping for the specified VRF.
Configuring Static
IP-SGT Bindings
You can define a
static binding between an IP host address to a security group tag (SGT). The
static IP-SGT bindings are configured in the context of a management VRF.
Note
Any Cisco
TrustSec configuration must be done only in the management VRF.
IP-SGT binding
can be configured using the CLI or from SXP. Any SGT mapping that is configured
from the CLI displays “CLI Configured” under the SGT_CONFIGURATION column.
This example shows how to configure static subnet IP-SGT bindings:
The SXP retry period
determines how often the Cisco NX-OS software retries an SXP connection. When
an SXP connection is not successfully set up, the Cisco NX-OS software makes a
new attempt to set up the connection after the SXP retry period timer expires.
The default value is 60 seconds (1 minute). Setting the SXP retry period to 0
seconds disables the timer and retries are not attempted.
Before you begin
Log in to the
CLI in EXEC mode.
You must enable
the Cisco TrustSec SXP.
You must enable
the Cisco TrustSec feature.
You must install
the Advanced Services license.
Procedure
Command or Action
Purpose
Step 1
switch#
configure
terminal
Enters global
configuration mode.
Step 2
switch(config)#cts sxp
retry-periodseconds
Specifies the
SXP retry timer period. The default value is 60 seconds (1 minute). The range
is from 0 to 64000.
The interface
delete hold timer period determines how long the interface holds on to the
IP-SGT mapping once the interface goes to a nonparticipating state. After the
timer expires, the IP-SGT mappings are deleted from the interface and the
peers.
Specifies the
delete hold timer period for an interface. The default value is 60 seconds (1
minute). The range is from 0 to 64000.
If the timer is
set to 0, the IP-SGT mappings are deleted instantly.
The
no form of this
command does not start the timer when the interface goes to a nonparticipating
state and the IP-SGT entries are then always held on the interface.
Step 3
(Optional) switch(config)#
show cts interface
delete-hold timer
Configures a
RADIUS server host with a key and PAC. The
hostname argument is alphanumeric, case sensitive, and
has a maximum length 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
(Optional)
Displays the
RADIUS server configuration.
Step 4
aaa group server radius
group-name
Specifies the
RADIUS server group and enters RADIUS server group configuration mode.
Step 5
server {ipv4-address |
hostname}
Specifies the
RADIUS server host address.
Step 6
use-vrfvrf-name
Specifies the
management VRF instance for the AAA server group.
Note
If you use the
management VRF instance, no further configuration is necessary for the devices
in the network cloud. If you use a different VRF instance, you must configure
the devices with that VRF instance.
Step 7
exit
Exits RADIUS
server group configuration mode.
Step 8
aaa authorization cts
default groupgroup-name
Specifies the
RADIUS server groups to use for Cisco TrustSec authorization.
Step 9
exit
Exits global
configuration mode.
Step 10
(Optional)
show radius-server
groups [group-name]
(Optional)
Displays the
RADIUS server group configuration.
Step 11
(Optional)
show aaa
authorization
(Optional)
Displays the
AAA authorization configuration.
Step 12
(Optional)
show cts pacs
(Optional)
Displays the
Cisco TrustSec PAC information.
Step 13
(Optional)
copy running-config
startup-config
(Optional)
Copies the
running configuration to the startup configuration.
Example
This example shows
how to configure AAA on the Cisco TrustSec Cisco NX-OS devices:
switch# configure terminal
switch(config)# radius-server host 10.10.1.1 key L1a0K2s9 pac authentication accounting
switch(config)# aaa group server radius Rad1
switch(config-radius)# server 10.10.1.1
switch(config-radius)# use-vrf management
switch(config-radius)# exit
switch(config)# aaa authentication cts default group Rad1
switch(config)# exit
switch# copy running-config startup-config
Configuring Cisco
TrustSec Authentication in Manual Mode
You can manually
configure Cisco TrustSec on a port profile if your Cisco NX-OS device does not
have access to a Cisco Secure ACS. You must manually configure the port
profiles on both ends of the connection.
Before you begin
Ensure that you
enabled Cisco TrustSec.
Procedure
Command or Action
Purpose
Step 1
switch#
configure terminal
Enters global
configuration mode.
Step 2
switch(config)#
port-profile
name
Enters port
profile configuration mode for the named port profile. If the port profile does
not already exist, it is created.
Note
To
configure Cisco TrustSec SGTs on an interface, enter the interface
configuration mode and specify the interface.
Step 3
switch(config-port-prof)#
cts manual
Enters Cisco
TrustSec manual configuration mode.
Note
You cannot
enable Cisco TrustSec on interfaces in half-duplex mode.
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.
Note
Ensure that
you have configured the Cisco TrustSec credentials and AAA for Cisco TrustSec.
Note
The
policy dynamic and
policy static commands are mutually exclusive. Only
one can be applied at a time. To change from one to the other, you must use the
no form of the command to remove the configuration
before configuring the other command.
Configures a static authorization policy. The tag argument is a hexadecimal value in the format 0xhhhh. The 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.
Note
The policy dynamic and policy static commands are mutually exclusive. Only one can be applied at a time. To change from one to the other, you must use the no form of the command to remove the configuration before configuring the other command.
You can manually
configure SGACL policies on your Cisco NX-OS device if a Cisco Secure ICE is
not available to download the SGACL policy configuration.
Before you begin
Ensure that you have
enabled Cisco TrustSec.
Procedure
Command or Action
Purpose
Step 1
configure terminal
Example:
Enters global
configuration mode.
Step 2
cts role-based
access-listlist-name
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
(Optional)
Denies or
permits all traffic.
Step 4
(Optional) {deny |
permit}
icmp
(Optional)
Denies or
permits Internet Control Message Protocol (ICMP) traffic.
Step 5
(Optional) {deny |
permit}
igmp
(Optional)
Denies or
permits Internet Group Management Protocol (IGMP) traffic.
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.
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
Exits
role-based access-list configuration mode.
Step 10
cts role-based sgt
{sgt-value |
any
|
unknown}
dgt
{dgt-value |
any
|
unknown}
access-listlist-name
Maps the SGT values to the SGACL. The sgt-value and dgt-value argument values range from 2 to 65519.
Note
You must
create the SGACL before you can map SGTs to it.
Step 11
(Optional)
show cts role-based
access-list
(Optional)
Displays the
Cisco TrustSec SGACL configuration.
Step 12
(Optional)
copy running-config
startup-config
(Optional)
Copies the
running configuration to the startup configuration.
Example
This example shows
how to configure an SGACL policy:
After you configure
the Cisco TrustSec device credentials and AAA, you can verify the Cisco
TrustSec SGACL policies downloaded from the Cisco ISE. The Cisco NX-OS software
downloads the SGACL policies when it learns of a new SGT through authentication
and authorization on an interface.
Before you begin
Ensure that you
enabled Cisco TrustSec.
Procedure
Command or Action
Purpose
show cts
role-based access-list
Example:
switch# show cts role-based access-list
Displays Cisco
TrustSec SGACLs, both downloaded from the Cisco ICE and manually configured on
the Cisco NX-OS device.
Refreshing the
Downloaded SGACL Policies
You can refresh the
SGACL policies downloaded to the Cisco NX-OS device by the Cisco ISE.
Before you begin
Ensure that you
enabled Cisco TrustSec.
Procedure
Command or Action
Purpose
Step 1
cts refresh
role-based policy
Example:
switch# cts refresh policy
Refreshes the
Cisco TrustSec SGACL policies from the Cisco ISE.
Step 2
(Optional)
show cts
role-based policy
Example:
switch# show cts role-based policy
(Optional)
Displays the
Cisco TrustSec SGACL policies.
Clearing Cisco
TrustSec SGACL Policies
You can clear the
Cisco TrustSec SGACL policies.
Note
The way policies
are cleared depends on whether the SGT is static or dynamic. For a static SGT,
the SGT is reset to 0 after the flap occurs. For a dynamic SGT, the SGT is
downloaded again from the RADIUS server after the flap occurs.
Before you begin
Ensure that you
enabled Cisco TrustSec.
Procedure
Command or Action
Purpose
Step 1
(Optional)
show cts role-based
policy
Example:
switch# clear cts policy all
(Optional)
Displays the
Cisco TrustSec RBACL policy configuration.
You can use role-based
access control list (RBACL) logging to monitor flows that affect specific
RBACLs. The RBACLs can be configured with the optional log keyword in each of
the access control entries (ACEs). When you configure an option, statistics for
each flow that match the RBACL permit or deny conditions that you enter are
logged in the software. RBACL logging supports both IPv4 and IPv6 addresses.
You can enable logging
per rule(s) within the RBACL. An implicit deny rule is the default action for
RBACLs. To log any packets that match the implicit deny rule, you must create
an explicit deny rule and add the
log keyword.
Statistics and logging
are provided for each flow. A flow has the following fields:
Virtual Supervisor
Module (VSM) ID
Virtual Supervisor Engine (VSE) ID
Security Group Tag
(SGT)
Destination Group
Tag (DGT)
Source IP address
Source port
Destination IP
address
Destination port
Source Interface
Protocol
Hit Count
Scalability is
provided through the following functionality:
Each Cisco Nexus 1000VE switch can support up to 64 VSEs.
Each VSE can support up to 5000 permit and 5000 deny flows. The maximum number of permit/deny flows is a configurable option.
The flow reporting
interval can be from 5 to 86,400 seconds (1 day).
The configuration
flow syslog level can be from 0 to 7.
Up to three syslog servers are supported.
RBACL Flows
An RBACL flow as it
pertains to RBACL logging has the following characteristics:
It represents a
stream of IPv4/IPv6 packets with the same packet headers (SrcIP, DstIP,
Protocol, SrcPort, DstPort) for which an identical RBACL action is enforced.
Each flow entry tracks the count of packets that match the flow.
It is created only
if logging is enabled on the corresponding ingress/egress RBACL policy. Ingress
and egress flows are tracked separately.
Each VSE tracks a maximum of 10,000 ACL flows; a flow space is shared between permit/deny flows, and each has a configurable
maximum of 5000.
Each flow entry
contains the following:
Packet tuple
RBACL action
Direction
Packet count
The RBACL flow
lifecycle is as follows:
A flow is
created when the first packet of a unidirectional stream matches a Layer 3
RBACL policy. A new flow notification is sent to the syslog server.
For all
subsequent packets with a tuple that matches the flow tuple, the per-flow
packet counter is incremented.
Each flow is
tracked periodically based on the configured reporting interval. Within each
periodic report, all the active flows and the corresponding packet count seen
since the last periodic report are reported to the syslog server.
If no packets
match a flow for one full periodic interval, the flow entry is purged. This
process is the only flow-aging scheme.
A flow is not
stateful. There is no connection tracking for TCP flows.
The flow reporting
process occurs in the following manner:
For each flow
created, a new flow notification message is sent to the syslog server.
A periodic
report for each active flow comes next. A flow is active if packets that match
the flow are seen since the last periodic report.
The flow information is exported to the syslog server and contains the following: packet tuple, RBACL action, direction, VSE
UUID, VSM ID, packet count.
The periodic
time can be as low as 5 seconds with the default setting of 5 minutes. A new
user space RBACL-logging thread handles the periodic poll and report
functionality.
Syslog
messages that identify the flow space usage are sent at 75 percent, 90 percent,
and 100 percent of the threshold maximum to the syslog server once during each
interval.
Syslog
Messages
Syslog message characteristics are as follows:
Syslog messages that contain flow information are exported from each Virtual Service Engine (VSE).
The syslog client functionality is RFC-5424 compliant and
communicates to servers over a UDP port (514).
The host must be configured with a vmknic interface that can reach
the remote syslog server.
Configuring RBACL
Logging
By default, RBACL logging is enabled on all Virtual Service Engines (VSEs). In addition, the following rules apply to RBACL
logging configuration:
Any rule can be
enabled for logging by adding the log keyword.
Only packets that
have a rule with the log keyword enabled are logged.
Disabling RBACL
Logging
You can disable RBACL logging on a VSE by entering the following command:
Command
Purpose
[no] logging ip access-list cache module vse
Disables RBACL logging on the specified VSE.
Configuring a Time
Interval for Accumulating Packet Counters
You can configure
the time interval for accumulating packet counters before they are reported to
the syslog servers. You enter the time range in seconds from 5 to 86,400
seconds (1 day). The default is 300 seconds (5 minutes).
You can configure
the amount of time to accumulate packet counters by entering one of the
following commands:
Command
Purpose
logging ip access-list cache
interval
secs
Sets the
time interval in seconds to accumulate packet counters before they are reported
to the syslog servers, where
secs
is the number of seconds.
[no]
logging ip access-list cache interval
secs
Reverts
the configuration to the default time interval configuration 300 seconds (5
minutes), where
secs
is the number of seconds.
This example shows
the time interval syslog message format that is sent periodically when the time
interval expires:
You can configure the number of deny and permit flows per VSE. The range is from 0 to 5000 flows; the default is 3000. A syslog
message is sent when the flow is near the maximum threshold. The first message is sent when the number of flows has reached
75 percent of the maximum threshold and the next message is sent when the number of flows has reached 90 percent of the maximum
threshold. The last message is sent when the number of flows reaches the maximum threshold of 100 percent.
Configuring Permit
Flows
You can configure
permit flows by entering one of the following commands:
Command
Purpose
logging ip access-list cache max-permit-flows
num
Sets the
number of permit flows, where
num
is the number of flows.
[no]
logging ip access-list cache max-permit-flows
Reverts
the configuration to the default permit flow value of 3000.
- Oct 6 04:17:22 sfish-231-157.cisco.com 1 2011-08-28T11:14:24 - n1k-acllog -
ACLLOG-MAX-PERMIT-FLOW-REACHED The number of ACL log permit-flows has reached 75 percent
limit (3969)
- Oct 6 04:17:26 sfish-231-157.cisco.com 1 2011-08-28T11:14:26 - n1k-acllog -
ACLLOG-MAX-PERMIT-FLOW-REACHED The number of ACL log permit-flows has reached 90 percent
limit (4969)
- Oct 6 04:17:27 sfish-231-157.cisco.com 1 2011-08-28T11:14:31 - n1k-acllog -
ACLLOG-MAX-PERMIT-FLOW-REACHED The number of ACL log permit-flows has reached 100 percent
limit (5000)
Configuring Deny
Flows
You can configure
deny flows by entering one of the following commands:
Command
Purpose
logging ip access-list cache max-deny-flows
num
Sets the
number of deny flows, where
num
is the number of flows.
[no]
logging ip access-list cache max-deny-flows
Reverts
the configuration to the default deny flow value 3000.
- Oct 6 04:17:27 sfish-231-157.cisco.com 1 2011-08-28T11:14:31 - n1k-acllog -
ACLLOG-MAX-DENY-FLOW-REACHED The number of ACL log deny-flows has reached 75 percent limit
(4330)
- Oct 6 04:18:27 sfish-231-157.cisco.com 1 2011-08-28T11:15:31 - n1k-acllog -
ACLLOG-MAX-DENY-FLOW-REACHED The number of ACL log deny-flows has reached 90 percent limit
(4630)
- Oct 6 04:20:17 sfish-231-157.cisco.com 1 2011-08-28T11:17:20 - n1k-acllog -
ACLLOG-MAX-PERMIT-FLOW-REACHED The number of ACL log permit-flows has reached 100 percent
limit (5000)
Configuring Syslog
Server Severity Levels
You can set the severity
level of a syslog message and up to three remote servers to which you want the
message to be sent using the following commands:
Command
Purpose
[no]
acllog match-log-level
level
Sets the
severity level at which syslog messages are sent, where
level is the severity code from 0 to 7. The no acllog
match-log-level level command reverts the RBACL log level to the default
severity level 6.
[no]
logging ip access-list cache max-deny-flowsnumber
Sets the
maximum number of deny flows to
number per module. The
no logging ip access-list
cache max-deny-flowsnumber sets the maximum number of deny-flows to
the default value of 3000.
[
no]
logging ip access-list cache max-permit-flows
number
Set the
max-permit-flows to a specified number per module. The no logging ip access-list cache max-permit-flowsnumber sets the maximum number of permit-flows to
the default value of 3000.
logging server
A.B.C.D 0-7
Specifies
the syslog server on which you want to set a severity level, where
A.B.C.D is the
syslog server IP address and 0 to 7 are the severity levels you can choose.
Note
For ACL logging to
work, the RBACL Logging level should be less than or equal to the Syslog level.
The severity level
range is from 0 to 7 (default is 6):
Severity
Code
Severity
Level
Description
0
Emergency
System is
unusable
1
Alert
Action
must be taken immediately
2
Critical
Critical
conditions
3
Error
Error
conditions
4
Warning
Warning
conditions
5
Notice
Normal
but significant condition
6 (Default)
Informational
Informational messages
7
Debug
Debug-level messages
Verifying the Cisco
TrustSec Configuration
Use the following
commands to verify the configuration:
Command
Purpose
show aaa authentication
Displays
the AAA authentication configuration on the
Cisco Nexus 1000V.
show aaa authorization
Displays
the AAA authorization configuration on the
Cisco Nexus 1000V.
show cts
Displays
the global Cisco TrustSec configuration on the
Cisco Nexus 1000V.
show cts sxp
Displays
the Cisco TrustSec SXP configuration.
show cts device tracking
Displays
the Cisco TrustSec device tracking configuration.
show cts sxp connection
Displays
Cisco TrustSec SXP connections.
show cts role-based sgt-map
Displays
all the mapping between IP address/Subnet and SGT for Cisco TrustSec.
show cts ipsgt entries
Displays
all the IP address/Subnet to SGT mappings.
show cts interface delete-hold timer
Displays
the Cisco TrustSec interface delete hold timer period.
show cts environment-data
Displays
Cisco TrustSec environmental data.
show cts
interface
Displays
the Cisco TrustSec configuration for all interfaces.
show cts interface
ethernetslot/port
Displays
the Cisco TrustSec configuration for the specified Ethernet interface.
show cts interface vethernetnumber
Displays
the Cisco TrustSec configuration for the specified virtual Ethernet interface.
show cts role-based access-list
Displays
Cisco TrustSec SGACL information.
show cts role-based counters
Displays
the configuration status of RBACL statistics and lists statistics for all RBACL
policies.
show cts role-based
policy
Displays
Cisco TrustSec SGACL policy information.
show running-configuration cts
Displays
the running configuration information for Cisco TrustSec.