trustsec sga confguide

Cisco TrustSec Configuration Guide

© 2010 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. of 106

Cisco TrustSec Security Group Access Solution Configuration Guide

Version 1.5

Cisco Systems, Inc.



Contents

Introduction.................................................................................................................................................... 4 Cisco TrustSec Security Group Access Solution Overview .......................................................................... 4

Component Details...................................................................................................................... 4 Other Components ...................................................................................................................... 5 Topology and SGA Features....................................................................................................... 6

Configuration of the SGA Solution ................................................................................................................ 7 Configuration Scenarios.............................................................................................................. 7 Notes on Setting Up Test Scenarios............................................................................................ 7 Checklist ..................................................................................................................................... 8 Cisco TrustSec SGA Configuration Flow................................................................................... 9

Cisco TrustSec SGA Use Cases................................................................................................................. 10 Creating the Cisco Secure ACS5.1 Base Configuration ............................................................................. 12

Installing Cisco Secure ACS 5.1............................................................................................... 13 Performing the Initial Setup of Cisco Secure ACS 5.1............................................................. 13 Accessing Cisco Secure ACS 5.1 ............................................................................................. 14 Configuring Microsoft Active Directory for the User Identity Data Store............................... 17 Obtaining the Server Certificate and CA Certificate ................................................................ 19 Changing the Global Setting for EAP-FAST............................................................................ 25

Configuring the Cisco Nexus 7000 Series with Cisco NX-OS..................................................................... 25 Seed and Non-Seed Devices and IEEE 802.1X Roles.............................................................. 25 Obtaining and Upgrading the Cisco Nexus 7000 Series with Appropriate Cisco NX-OS Version...................................................................................................................................... 26 Obtaining and Installing Cisco TrustSec License for Cisco Nexus 7000 Series Switch .......... 27 Enabling Cisco TrustSec on Cisco NX-OS .............................................................................. 29 Configuring Cisco TrustSec Credentials .................................................................................. 29 Configuring Authentication, Authorization, and Accounting and RADIUS on the Cisco Nexus 7000 Series to Communicate with Cisco Secure ACS ............................................................. 30 Creating the Device SGT and Assigning It to the Cisco Nexus 7000 Series Seed Device ...... 33 Verifying Cisco Nexus 7000 Series NDAC for the Seed Device ............................................. 35

Configuring Private VLAN for Data Center Access ..................................................................................... 37 Enforcing Access Policy for Servers Using SGACL.................................................................................... 41

Assigning SGTs for Network Entities ...................................................................................... 42 Configuring Static IP-to-SGT Mapping on the Cisco Catalyst 4948 and SXP Connection to the Cisco Nexus 7000 Series .......................................................................................................... 49

Adding a Non-Seed Device to the Cisco TrustSec Domain ........................................................................ 52 Configuring NDAC for the Non-Seed Device.......................................................................... 53 Configuring the Non-Seed Device Cisco Nexus 7000 Series Switch....................................... 56 Enabling Hop-by-Hop Layer 2 Encryption with IEEE 802.1AE.............................................. 56

Adding Hardware That Does Not Support Cisco TrustSec (Cisco Catalyst 6500 Series) to the Cisco TrustSec Domain ........................................................................................................................................ 58

Configuring NDAC on the Cisco Catalyst 6500 Series Switch................................................ 59 Adding the Cisco Catalyst 6500 Series Switch as an AAA Client ........................................... 60 Configuring the Non-Seed Device Cisco Catalyst 6500 Series Switch.................................... 61 Configuring the Authenticator (Cisco Nexus 7000 Series) and Supplicant (Cisco Catalyst 6500 Series) for SXP Connection ...................................................................................................... 65 Configuring SXP on the Cisco Nexus 7000 Series with Cisco NX-OS ................................... 65 Configuring SXP on the Cisco Catalyst 6500 Series with Cisco IOS Software....................... 66



Verifying the SXP Connection on Both Devices...................................................................... 66 Assigning SGT Using IEEE 802.1X User Authentication ............................................................................ 67

Configuring the Cisco Catalyst 6500 Series with Cisco IOS Software for IEEE 802.1X User Authentication........................................................................................................................... 68 Configuring the Cisco Secure ACS Server for IEEE 802.1X User Authentication ................. 69 Testing IEEE 802.1X User Authentication on the Client ......................................................... 73

Enforcing Policy with SGACLs .................................................................................................................... 80 Appendix ..................................................................................................................................................... 86

How TrustSec Features Work with Existing Cisco Identity Features on Catalyst Switches.... 86 SGT and Other Authorization Methods.................................................................................... 86 SGT and Host Mode ................................................................................................................. 86 SGT and Locally Assigned VLAN ........................................................................................... 88 SGT and Open Mode ................................................................................................................ 88 Configuring Back-to-Back NDAC and IEEE 802.1AE Encryption between Multiple VDCs in a Single Cisco Nexus 7000 Series Switch ................................................................................ 88 Sample Configuration ............................................................................................................... 91



Introduction

The goal of this guide is to provide the details necessary to configure the Cisco® TrustSec™ Security Group Access

solution. This guide provides configuration details for all components of the Cisco TrustSec Security Group Access

solution, including the Cisco Nexus® 7000 Series Switches running Cisco NX-OS Software; Cisco Secure Access

Control System (ACS) 5.1; and Cisco Catalyst® 6500, 4500, 3750, and 3560 Series Switches running Cisco IOS®

Software. The guide presents step-by-step configuration information using two common use cases supported in this

release of solution: a use case involving data center server segmentation, and a use case involving access policy

enforcement between the campus and data center.

Cisco TrustSec Security Group Access Solution Overv iew

The Cisco TrustSec Security Group Access (SGA) architecture builds secure networks by establishing a domain of

trusted network devices. Every device in the SGA domain is authenticated by its peer device. Communication on the

links between devices in the SGA domain is secured with a combination of encryption, message integrity checks,

and data-path replay protection mechanisms. SGA also uses the device and user identity information acquired

during authentication to classify the packets as they enter the network. This packet classification is maintained by

tagging packets on ingress to the SGA-based 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.

For additional information about the Cisco TrustSec solution, see http://www.cisco.com/go/trustsec.

Component Details

Tables 1 and 2 list supported components for this release of the SGA solution. Access switches can be Cisco

Catalyst 6500, 4500, 3750, or 3560 Series switches.

Table 1. Switch Platform Support

Platform (Supervisor) Cisco TrustSec SGA Feature OS Version Requirement

Cisco Nexus 7000 Series Security group access control list (SGACL), IEEE 802.1AE (media access control security [MACsec]), network device admission control (NDAC) policy, and SGT Exchange Protocol (SXP)

Cisco NX-OS5.0.2a. Advanced Service Package license for Cisco TrustSec required

Mandatory as enforcement point

Cisco Catalyst 6500E Switch with Supervisor Engine 32 or720or Virtual Switching System (VSS) 720

NDAC, SXP, and Endpoint Admission Control (EAC)

Cisco IOS Software 12.2 (33) SXI3 or later Optional as an access switch

Cisco Catalyst 4900 Series Switch

SXP and EAC Cisco IOS Software 12.2 (50) SG7 or later Optional as an access switch

Cisco Catalyst 4500E Switch with Supervisor 6L-E or 6-E

SXP and EAC Cisco IOS Software 12.2 (50) SG7 or later Optional as an access switch

Cisco Catalyst 3750-X or 3560-X Series Switches

SXP and EAC Cisco IOS Software 12.2 (53) SE1 or later Optional as an access switch

Cisco Catalyst 3750 or 3560 Series Switches


Cisco Catalyst Blade Switch 3000 or 3100Series


Note: K9 image is required for all IOS and ACS images.

http://www.cisco.com/go/trustsec



Table 2. Cisco Secure ACS Requirement

Platform Version Specific Requirement Requirement

Cisco Secure ACS 5.1 Cisco Secure ACS 5.1 runs on Cisco 1121 Secure Access Control System Appliance or VMware image for ESX Server 3.5 or 4.0. Advanced Access License is required to enable Cisco TrustSec features.

Mandatory as policy server

For additional information about components used in this guide, please refer to the product configuration guides

listed here:

● Cisco Nexus 7000Series with Cisco NX-OS 5.x:

http://www.cisco.com/en/US/products/ps9402/products_installation_and_configuration_guides_list.html

● Cisco Catalyst 6500 Series withCisco IOS Software 12.2 (33) SX:

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/book.html

● Cisco Catalyst 4500 Series with Cisco IOS Software 12.2 (53) SG:

http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/53SG/configuration/config.html

● Cisco Catalyst 3750-Xand 3560-XSeries with Cisco IOS Software 12.2 (53) SE2:

http://www.cisco.com/en/US/docs/switches/lan/catalyst3750x_3560x/software/release/12.2_53_se/configurati

on/guide/3750xscg.html

● Cisco Secure ACS5.1:

http://cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_system/5.1/user/guide/acsuserguide.ht

ml

Other Components

Other components are required for identity-based user access control using the IEEE 802.1X protocol. These

include Microsoft Windows 2003 or 2008 Server running Microsoft Active Directory, Certificate Authority (CA) server,

Domain Name System (DNS) server, and Dynamic Host Configuration Protocol (DHCP) server. An end host running

the Microsoft Windows operating system can also be a part of this environment. Table 3 lists the other components

that may be required in your Cisco TrustSec environment.

Table 3. Other Components

Type Function

Microsoft Active Directory Server or equivalent directory service

This guide uses Microsoft Windows Server 2008 Active Directory service as the user identity repository. Although you can still use the Cisco Secure ACS internal user database, an external database is recommended for identity authentication. Cisco Secure ACS Supports connections to Microsoft Active Directory and Lightweight Directory Access Protocol (LDAP) service.

DHCP service This guide uses Microsoft Windows Server 2008 DHCP server to provide DHCP service. If any existing service provides equivalent service, you can use that service as well.

DNS service This guide uses Microsoft Windows Server 2008 DNS server to provide DNS service. If any existing service provides equivalent service, you can use that service as well.

Certificate authority server This guide uses Microsoft Windows Server 2008 CA server to provide standalone Certificate Authority service. If any existing provides equivalent service, you can use that service as well.

Target servers This guide uses two target servers to test the SGACL. Those servers are running typical Internet services such as HTTP, FTP, Secure Shell (SSH), or even file sharing.

Endpoint PC This guide uses a Microsoft Windows XP endpoint running Cisco Secure Services Client for the IEEE 802.1X supplicant. SGA is a supplicant-agnostic solution: that is, it does not require any specific agent or IEEE 802.1X supplicant running on the endpoint machine. You can use the Cisco Secure Services Client supplicant, Microsoft Windows or another OS embedded supplicant, or another third-party supplicant.


http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/book.html

http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/53SG/configuration/config.html

http://www.cisco.com/en/US/docs/switches/lan/catalyst3750x_3560x/software/release/12.2_53_se/configuration/guide/3750xscg.html

http://www.cisco.com/en/US/docs/switches/lan/catalyst3750x_3560x/software/release/12.2_53_se/configuration/guide/3750xscg.html

http://cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_system/5.1/user/guide/acsuserguide.html




Topology and SGA Features

The SGA architecture is based on several main features, described in Table 4.

Table 4. SGA Main Features

Feature Description

Security Group Tag (SGT) The Security Group Tag (SGA) is a 16-bit single label indicating the classification of a source in the SGA domain, appended to an Ethernet frame or IP packet. There are several ways to assign SGTs to network entities, such as in an authorization process of successful IEEE 802.1X authentication or MAC authentication bypass (MAB). An SGT can be assigned statically to a particular IP address or to a switch interface.

Security Group Access Control List (SGACL)

Security Group-based Access Control List (SGACL) is the enforcement method for the SGA solution. Based on policy, an SGACL can be applied to traffic from the source security group to the destination security group. Because SGACL does not require any IP address in its access control entries (ACEs), administrators can easily manage a large number of access control lists (ACLs). In contrast to a traditional IP access list, SGACL is applied to the egress port to the destination endpoint. An egress ACL reduces the number of access control entries per source endpoint; therefore the administrator can support a more scalable access control system.

Endpoint Admission Control (EAC) Endpoint Admission Control (EAC) is an authentication process for an endpoint user or a device connecting to the SGA domain. Usually EAC takes place at the access-level switch. Successful authentication and authorization in the EAC process results in SGT assignment for the user or device. Currently, EAC can be archived by IEEE 802.1X user or device authentication or by MAC authentication bypass.

Network Device Admission Control (NDAC)

Network Device Admission Control (NDAC) is an authentication process in which each network device (for instance, Ethernet switches) in the SGA domain is verified by its peer device for its credentials and trustworthiness. NDAC uses an authentication framework based on IEEE 802.1X port-based authentication and uses Extensible Authentication Protocol–Flexible Authentication Through Secure Tunneling (EAP-FAST) as its EAP method. Successful authentication and authorization in the NDAC process results in SAP negotiation for IEEE802.1AE encryption.

Security Association Protocol (SAP) Security Association Protocol (SAP) is key management and negotiation mechanism for IEEE 802.1AE–based link encryption. With SAP, authenticating devices use EAPoL-key exchange to negotiate a cipher suite, exchange security parameter indexes (SPIs), and manage keys. Successful completion of all three tasks results in the establishment of a security association (SA).

SGT Exchange Protocol (SXP) SGT Exchange Protocol (SXP) is a protocol developed for SGA to propagate the IP-to-SGT binding table across network devices that do not have SGT-capable hardware support to hardware that supports SGT/SGACL.

The configuration in this guide uses the following components (Figure 1):

● Cisco Nexus 7010 Switch running Cisco NX-OS (CTS7K-DC)

● Cisco Nexus 7010 Switch running Cisco NX-OS (CTS7K-CORE)

● Cisco Catalyst 4948 Switch running Cisco IOS Software (CTS4K-DCAS)

● Cisco Catalyst 6500 Switch running Cisco IOS Software (CTS6K-AS)

● Cisco Secure ACS) 5.1

● Microsoft Server 2008 running Microsoft Active Directory, DHCP, DNS, and CA service

● Microsoft Server 2003 running web, FTP, SSH, and terminal servers (human resources[HR] server)

● Microsoft Server 2003 running web, FTP, SSH, and terminal servers (IT server)

● Microsoft Windows XP (Cisco Secure Services Client supplicant)



Figure 1. Sample Topology and SGA Solution Features

Configuration of the SGA Solution

This section discusses the overall requirements for the SGA solution configuration.

Configuration Scenarios

This guide provides step-by-step instructions to configure SGA features such as NDAC, SAP, SGT assignment

(EAC), SXP, and SGACL (shown in Figure 1). The following SGA configuration scenarios are discussed:

● How to configure Cisco Secure ACS5.1 to enable SGT/SGACL

● How to configure a seed device (CTS7K-DC) to provision initial policy

● How to configure data center switches (CTS7K-DC and CTS4K-DCAS) to separate traffic using private VLAN

features

● How to configure SGACL on the Cisco Nexus 7000 Series Switches (CTS7K-DC)

● How to configure NDAC

● How to enable IEEE802.1AE link encryption between two Cisco Nexus 7000 Series Switches (Adding a non-

seed device to the SGA domain)

● How to configure SXP connection between Cisco Nexus 7000 Series Switches and Cisco Catalyst 6500

Series Switches (Adding Non-Cisco SGT capable device to SGA domain)

● How to configure IEEE 802.1X authentication and assign SGT

Notes on Setting Up Test Scenarios

Note the following in setting up the test scenarios:

● In these scenarios, a minimum of one Cisco Nexus 7000 Series Switch with Cisco NX-OS5.0.2a is required

for SGACL enforcement and IEEE 802.1AE encryption. To enable SGT/SGACL features, you need to have

the Advance Service license purchased and installed on your Cisco Nexus 7000 Series system.



● In this guide, a Cisco Nexus 7000 Series feature called the virtual device context (VDC) is used to create a

second Cisco Nexus 7000 Series Switch (CTS7K-CORE). The appendix describes how to virtually allocate

interfaces to the secondary VDC to perform IEEE 802.1AE encrypted linking in a back-to-back connection.

For more information about VDC, see the following URL:

http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-

os/virtual_device_context/configuration/guide/vdc_nx-os_cfg.html.

● Cisco Secure ACS 5.1 runs on the Cisco Secure ACS1121 Series Appliance or on a virtual machine running

on a VMware ESX server. Cisco TrustSec features can be enabled with the Cisco TrustSec Access Control

license, and this license needs to be obtained and installed on the Cisco Secure ACS system prior to testing.

● For the endpoint client, you can use a Microsoft Windows–based operating system to perform IEEE 802.1X

authentication. Cisco TrustSec SGA does not require any special agent on the endpoint client. Cisco

TrustSec SGA solution is supplicant agnostic; therefore, you can use the OS built-in supplicant of your choice

(Microsoft Windows XP with SP3, Windows Vista with SP2, or Windows 7 are highly recommended). In this

guide, Cisco Secure Services Client 5.1 on Microsoft Windows XP SP3 is used. For more information about

Cisco Secure Services Client, please visit the following URL:

http://www.cisco.com/en/US/products/ps7034/index.html.

● Use a Microsoft Windows–based server OS for Microsoft Active Directory, DHCP server, DNS server, and CA

server functions (Microsoft Windows Server 2003 or 2008 is preferred).

● There are two servers prepared for this test scenario. Both servers are running Microsoft Windows Server

2003, and various server services are running (including HTTP server, FTP server, SSH server, terminal

server, and file sharing server).

Checklist

Use the checklist in Table 5 to verify your readiness for your test or deployment. If you are missing any component in

the checklist, please consult with your Cisco representative to discuss an alternative plan.

Table 5. Deployment Readiness Checklist

Platform Requirement Use Notes

Cisco Nexus 7010 ● N7K-M148GT-11 (48-port 10/100/1000 Megabit Ethernet module)

● Advanced LAN license is required for Cisco TrustSec and VDC

● Cisco NX-OS5.0.2a or later

Data center distribution and core switch

Cisco Catalyst 6500 Series

● Supervisor Engine 32 or 720 or VSS720

● Any 10/100/1000 Gigabit Ethernet module

● Cisco IOS Software 12.2(33)SXI3 or later

Wiring closet and data center access switch

● Recommend Supervisor Engine 720 or VSS720 for data center use (end of row [EoR])

● Recommend Supervisor Engine 32 with 6148A 10/100/1000 power over Ethernet (PoE) line card for wiring closet

Cisco Catalyst 4500 or 4900 Series

● Supervisor

● Cisco IOS Software12.2 (50) SG7 or later

Data center access switch (Cisco Catalyst 4948) and wiring closet (Cisco Catalyst 4500 Series)

Alternative platform is Cisco Catalyst 6500 Series

Cisco Catalyst 3560-X or 3750-X Series

Cisco IOS Software 12.2 (53) SE2 or later Wiring closet Alternative platforms are Cisco Catalyst 6500 and 4500 Series

Cisco Catalyst 3560-E or 3750-E Series

Cisco IOS Software 12.2 (53) SE1 or later Wiring closet Alternative platforms are Cisco Catalyst 6500 and 4500 Series

Cisco Catalyst Blade Switch 3000 or 3100 Series

Cisco IOS Software12.2 (53) SE1 or later Data center server access switch Alternative platform is Cisco Catalyst 4948

Cisco EtherSwitch Service Module for Cisco Integrated Services

Cisco IOS Software12.2 (53) SE1 or later Branch office integrated access switch

http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/virtual_device_context/configuration/guide/vdc_nx-os_cfg.html

http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/virtual_device_context/configuration/guide/vdc_nx-os_cfg.html

http://www.cisco.com/en/US/products/ps7034/index.html



Platform Requirement Use Notes

Routers (ISRs)

Cisco Secure ACS5.1 ● Cisco Secure ACS1121 or 1120 is required for installation

● VMware ESX 3.5 or 4.0 is supported for virtual machine deployment

● Cisco TrustSec Access Control license is required to enable Cisco TrustSec features

Policy server for Cisco TrustSec solution

Directory Server Microsoft Active Directory or generic LDAP server (depends on EAP type and Inner method used)

User and machine identity store

DHCP Server DHCP server running on Microsoft Windows Server system or any alternative server platform

DHCP

DNS Server DNS server running on Microsoft Windows Server system or any alternative server platform

DNS

CA Server CA server running on Microsoft Windows Server system or any third-party CA service

CA server to generate Cisco Secure ACS server certificate, root CA certificate, or certificate to be used for certificate-based user authentication

● Used to request signed server certificate for Cisco Secure ACS

● This CA server can be used to issue certificate for user or machine when certificate-based authentication method is used (for example, EAP-TSL)

Network Time Protocol (NTP) Server

NTP server application running on Microsoft Windows Server or any other alternative server platform

NTP ● Cisco Secure ACS needs to synchronize its time and time zone with that on Microsoft Active Directory to communicate for user authentication

● NTP server must be set up so that both Microsoft Active Directory and Cisco Secure ACS can access it

Generic Service Servers ● Service server for HTTP, FTP, SSH, terminal service, or file sharing service

● Two servers should be prepared for this configuration to verify the SGACL access control

Cisco TrustSec SGA Configuration Flow

This guide does not cover configuration of the basic network topology and assumes that end-to-end network

connectivity is in place. All network devices and required protocols should already be configured for end-to-end IP

connectivity before SGA is configured. In addition, all network access devices (NADs) should have network

connectivity to Cisco Secure ACS5.1. Figure 2 provides a high-level overview of the configuration steps.



Figure 2. SGA Configuration Flow

The SGA configuration in this guide proceeds in the following order:

1. Configure basic functions for SGT/SGACL in Cisco Secure ACS5.1.

2. Configure SGT/SGACL on the Cisco Nexus 7000 Series Switch (seed device, CTS7K-DC).

3. Configure private VLAN on both the Cisco Nexus 7000 Series Switch (CTS7K-DC) and Cisco Catalyst 4948

(CTS4K-DCAS) for traffic path isolation.

4. Assign SGT for servers manually on the Cisco Nexus 7000 Series Switch (CTS7K-DC).

5. Assign SGT for servers manually on the Cisco Catalyst 4948 (CTS4K-DCAS) and exchange IP-to-SGT binding

with the Cisco Nexus 7000 Series Switch (CTS7K-DC) using SXP.

6. Configure the Cisco Nexus 7000 Series Switch (NX7K-DC) to apply the SGACL and verify the access control.

7. Add the core switch (NX7K-CORE) to the SGA domain using NDAC.

8. Configure SAP after the NDAC to derive the key used for encryption between two sets of Cisco Nexus 7000

Series Switches (CTS7K-CORE and CTS7K-DC),

9. Add the access layer switch to perform NDAC between a Cisco Catalyst 6500 Series Switch (CTS6K-AS) and

Cisco Nexus 7000 Series Switch (CTS7K-CORE).

10. Configure the SXP connection between the Cisco Catalyst 6500 Series Switch (CTS6K-AS) and Cisco Nexus

7000 Series Switch (CTS7K-CORE) to exchange the IP-to-SGT binding table.

11. Configure the Cisco Catalyst 6500 Series Switch (CTS6K-AS) to perform IEEE 802.1x authentication and SGT

assignment and verify the access control.

Cisco TrustSec SGA Use Cases

The configurations in this guide focus on two use cases. The first use case is configuration of SGA enforcement in

the data center (Figure 3). Specifically, the configuration builds an environment in which multiple servers are

connected to third-party access switches in the data center. Those servers are placed on the same segment (VLAN).

SGT is used to group each server, and SGACL is used to enforce traffic between the servers. To isolate the path in



the same segment, private VLAN capabilities are used so that servers on the Isolated VLAN can communicate only

with the promiscuous port (primary VLAN).SGA allows you to dynamically control server-to-server communication

without defining a static access list on the switch.

Figure 3. Configuration of SGA Enforcement in the Data Center

The second use case expands the scope of SGA to include an enterprise campus network. Cisco’s SGA technology

is used to classify traffic from a specific user role dynamically assigned through user authentication by tagging. Then

the tagged traffic is be filtered at the egress port of the switch in the data center. The configuration uses existing

authentication mechanisms such as IEEE 802.1X authentication, MAC Authentication Bypass, and web

authentication bypass to identify users or network entities on the network and assign specific SGTs. Figure 4 shows

the campus network and data center communication use case. After the IT staff authenticates to the network, IT

should be accessing only the IT server. The SGACL dynamically assigns the SGT to the IT staff role to prevent IT

staff from accessing the confidential human resources department database.



Figure 4. Configuration of SGA Enforcement in the Data Center and Campus Network

Creating the Cisco Secure ACS5.1 Base Configuration

The SGA configuration starts with Cisco Secure ACS to establish the base functions to develop policies for the

solution (Figure 5). You need to prepare your Cisco Secure ACS 5.1 appliance server or Cisco Secure ACS 5.1

running on VMware ESX server. You also need to have your Cisco Secure ACS5.1 Base license and Cisco TrustSec

Access Control license installed before starting this section.



Figure 5. Cisco Secure ACS 5.1 Base Configuration

Installing Cisco Secure ACS 5.1

This guide does not provide steps for installing Cisco Secure ACS 5.1.

● The installation steps are documented at the following URL:

http://cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_system/5.1/installation/guide/acs5_1_i

nstall_guide.html.

● For the complete Cisco Secure ACS5.1configuration guide, visit the following URL:

http://cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_system/5.1/user/guide/acsuserguide.ht

ml.

Performing the Initial Setup of Cisco Secure ACS 5. 1

After you install the Cisco Secure ACS, your console should display the text-based wizard shown here to setup the

initial configuration. Change the values to match your environment.

localhost login: setup

Enter hostname[]: cts-acs1

Enter IP address[]: 10.1.100.3

Enter IP default netmask[]: 255.255.255.0

Enter IP default gateway[]: 10.1.100.1

Enter default DNS domain[]: cts.local

Enter Primary nameserver[]: 10.1.100.100

Add/Edit another nameserver? Y/N : n

Enter username [admin]: admin

Enter password:<password entered>

http://cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_system/5.1/installation/guide/acs5_1_install_guide.html

http://cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_system/5.1/installation/guide/acs5_1_install_guide.html





Enter password again:<password reentered>

Bringing up network interface...

Pinging the gateway...

Pinging the primary nameserver...

Do not use `Ctrl-C' from this point on...

Appliance is configured

Installing applications...

Installing acs...

Generating configuration...

Rebooting...

After Cisco Secure ACS server is installed, the system reboots automatically. After the reboot, you can now log in to

Cisco Secure ACS using the command-line interface (CLI) username and password you configured in previous step.

Other information such as the clock and NTP server IP address that is not a part of the initial setup wizard needs to

be configured using CLI commands. Follow the next steps to configure the time zone and NTP server address. First

configure the time zone. The timezone string can be found as an output of show timezones .

cts-acs-svr1/admin# config t

Enter configuration commands, one per line. End with CNTL/Z.

cts-acs-svr1/admin(config)# clock timezone US/Pacific

Now configure the NTP server if there is one. In the lab environment, you should have the NTP server running so

that all network devices are synchronized with the correct date and time.

cts-acs-svr1/admin(config)# ntp server 10.1.100.100

When you change your date or clock or time zone information, Cisco Secure ACS asks you to restart Cisco Secure

ACS services. Make sure you restart your Cisco Secure ACS service to make the configuration change effective. If

an NTP server is not available, use the clock set command to configure the Cisco Secure ACS appliance clock and

date manually. Again, it is very important to synchronize the clock to authenticate the user and device against

Microsoft Active Directory. If the clock for the Cisco Secure ACS appliance and Microsoft Active Directory differ by

more than 5 minutes, authentication will fail.

cts-acs-svr1/admin# clock set <MONTH><DAY><Hour:Minute:Second><YEAR>

Accessing Cisco Secure ACS 5.1

When you finish configuring the preceding information, you can configure and administer Cisco Secure ACS through

the Cisco Secure ACS web interface. Note that the current version of Cisco Secure ACS 5.1 supports only HTTPS-

enabled Microsoft Internet Explorer Versions 6 and 7 and Mozilla Firefox Version 3.0; Internet Explorer 8 is not

supported with current version of Cisco Secure ACS. You should use a supported browser to configure the Cisco

Secure ACS appliance correctly. In your browser, enter the Cisco Secure ACS URL: for example,

https://<acs_server_address> , where <acs_server_address> is either the IP address or DNS host name of the

Cisco Secure ACS server.

In the topology in this guide, the Cisco Secure ACS server IP address is 10.1.100.3. Therefore, the web interface

can be reached with https://10.1.100.3 . Remember that you must use HTTPS to connect to Cisco Secure ACS; an

HTTP request to the Cisco Secure ACS web interface is not redirected automatically.

When your browser displays an alert of a distrusted self-signed digital certificate, add an exception to open the logon

prompt page.



Login to the Cisco Secure ACS web interface using the initial default credential shown in Table 6.

Table 6. Logon Credential for Cisco Secure ACS Web Console

Username Password

acsadmin default

When you type the initial default credential, Cisco Secure ACS asks you to change the default password. Change

the default password to your own password for the web interface.

On the next page, you are asked to install the Base license for Cisco Secure ACS5.1. Place the Base license file

(.lic) on your local system and then click the Browse button to select the file. After you select the file, click Install to

install the actual license file.



The license installation page allows you to install the Base license for Cisco Secure ACS5.1. Any additional feature

licenses, including the Cisco TrustSec Access Control license, are installed from the System Administration

>Configuration > Licensing > Feature Options page. You must install the Cisco TrustSec Access Control license

to enable any SGT/SGACL functions on the Cisco Secure ACS web interface. Note that without a valid Cisco

TrustSec license, no Cisco TrustSec user interface will be displayed. On this page, you can also add any other

licenses you may have purchased.

After the license installation, logout and then login again to refresh the navigation items. After you log in again, you

will see that the Cisco TrustSec SGA features now appear in the menu. Notably, three menu items are added for

SGA functions: Security Groups is added under Policy Elements > Authorization and Permissions > N etwork

Access , Security Group ACLs is added under Policy Elements > Authorization and Permissions > N amed

Permission Objects , and TrustSec Access Control is added under Access Policies > TrustSec Access Control .

These menu items are available only after you have installed appropriate license. Before moving to the next steps,

verify that these Cisco TrustSec user interface items are available.

Next you will create the base Cisco Secure ACS configuration, by configuring Microsoft Active Directory for the user

identity data store, obtaining and installing both the Cisco Secure ACS server certificate and the CA certificate, and

changing the global setting for EAP-FAST.

Configuring Microsoft Active Directory for the User Identity Data Store

This guide uses Microsoft Active Directory as the user identity data store. The Cisco Secure ACS server looks up the

user account information stored in Microsoft Active Directory and performs IEEE 802.1X authentication. Although the

local database in the internal identity store can be used for authentication, this guide focuses on the configuration

with Microsoft Active Directory integration. This guide assumes that the test topology includes Microsoft Windows

Server 2003 or 2008 running the Microsoft Active Directory service. Cisco Secure ACS supports the Microsoft Active

Directory domain running on Microsoft Windows Server 200, 2003, and 2008.

In the Microsoft Active Directory running on Microsoft Windows Server 2008, the users and security groups listed in

Table 7 are created in advance for user authentication. Both users are assigned to specific security groups.

Table 7. Microsoft Active DirectoryUser Accounts and Security Groups

Username Security Group

hradmin HR Admin Group

itadmin IT Admin Group



Microsoft Active Directory can be added and configured on the Users and Identity Stores > External Identity

Stores > Active Directory page. As shown in the following screen, some information is required to set up

communication with Microsoft Active Directory. Use the information in Table 8 to add Cisco Secure ACS to your

Microsoft Active Directory for authentication.

Table 8. Microsoft Active Directory and Domain Information

Field Value Description

Active Directory Domain Name cts.local Enter the name of the Microsoft Active Directory domain to which you want to join Cisco Secure ACS.

Username administrator Enter a Microsoft Active Directory user with Create Computer Objects permission to add devices to the Microsoft Active Directory domain. This username does not have to be an administrator account. Contact your network administrator for more information.

Password 5k063hE Enter the configured password of the administrator user.

You can leave the rest of checkboxes at their default settings. You can click the Test Connection button to verify

communication with Microsoft Active Directory. If communication can be established, you will see a message

indicating successful communication establishment. Also upon successful communication path establishment, the

connectivity status changes from DISCONNECTED to CONNECTED.

You should check the communication between Cisco Secure ACS and Microsoft Active Directory first, using ping.

Also, remember that Cisco Secure ACS and Microsoft Active Directory must be time-synchronized to within five

minutes. Time in Cisco Secure ACS is set according to the NTP server. If the time difference is greater than five

minutes, communication with Microsoft Active Directory fails with error message.



● Information about Microsoft Active Directory integration is available at the following URL:

http://cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_system/5.1/user/guide/users_id_stores

.html - wp1053213.

● Configuration details are available at the following URL:

http://cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_system/5.1/user/guide/users_id_stores

.html - wp1140906.

After a successful connectivity test, the next step is to select the Microsoft Active Directory group. Click the Directory

Groups tab. Click the Select button to choose the Microsoft Active Directory group used in Cisco Secure ACS

authentication. In this guide, four groups are selected, listed in Table 9.

Table 9. Microsoft Active Directory and Domain Information

Group Name Description

Domain Computers Domain member computer group: This group is selected for IEEE 802.1X–based machine authentication. This group is optional If your policy does not require any machine authentication.

Domain User Domain member user group: This group is selected for IEEE 802.1X–based user authentication. Use this group when authenticating domain users. You can also use a different security group that is mapped to the user account.

HR Admin Group Human resources administrators security group: This group is added for the purposes of this guide. This group includes a user account called hradmin.

IT Admin Group IT administrators security group This group is added for the purposes of this guide. This group includes a user account called itadmin.

Obtaining the Server Certificate and CA Certificate

Create a digital certificate for Cisco Secure ACS from your trusted public or enterprise certificate authority.

Note: Use of a self-signed certificate is not recommended. Obtaining a digital certificate for Cisco Secure ACS

signed by a trusted third-party or enterprise CA is highly recommended.

In Cisco Secure ACS, choose System Administration > Configuration > Local Serve r Certificates > Local

Certificates and select Add .

http://cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_system/5.1/user/guide/users_id_stores.html - wp1053213






Select Generate Certificate Signing Request and click Next to provide the information needed to generate the

certificate signing request (CSR).

Enter the fully qualified domain name (FQDN) of the Cisco Secure ACS server, CN=cts-acs1.cts.local , and select

2048 for the key length; then click Finish . Depending on the key length, it may take a minute to generate the

certificate request and have it appear under Outstanding Signing Request . Choose an appropriate key length

based on your security policy. The use of FQDN as the common name is recommended because the server name

without a domain name is already used in the Cisco Secure ACS self-signed certificate.

Now the CSR needs to be exported. Choose System Administration > Configuration > Local Serve r Certificates

> Outstanding Signing Requests and select the CSR you created. Click Export to save it as a Privacy Enhanced

Mail (PEM) file on the local system.

Submit the CSR to your enterprise CA or public CA for creating your digital certificate for Cisco Secure ACS server.

This guide uses the enterprise CA server running on Microsoft Windows Server 2003 Enterprise edition. In your

browser, access the CA server web enrollment interface.



Navigate to select a task by choosing Request a certificate > Submit an advanced certific ate request > Submit a

certificate request by using a base-64-encoded CMC or PKCS #10 file , or submit a renewal request by using a

base-64-encoded PKCS#7 file.

Open your CSR PEM file using any text editor. Copy the entire request string and paste it in the Saved Request text

box. Choose Web Server for Certificate Template . Click Submit to request the certificate. When you copy the

signing request, make sure that you include all the lines. The following screen shows a sample CSR.

Note: WordPad on Microsoft Windows systems can be used to open the CSR PEM file (file with the .pem

extension) generated with Cisco Secure ACS to avoid insertion of extra characters when the request is copied to the

web certificate enrollment console.



After a certificate is issued, you can download the certificate to the local system. The Microsoft Windows Server

2008 CA allows you to save your certificate in two formats. Save the certificate to the local system with Distinguished

Encoding Rules (DER) format (default).

Note: For importing certificates, Cisco Secure ACS supports both DER and PEM formats.

Before you exit your CA web enrollment console, you need to obtain the root CA server certificate. Click on Home in

the upper-right corner of the screen to go to the initial web enrollment page. Select Download a CA certificate,

certificate chain, or CRL . On this page, you can select a CA certificate and download it to the local system. Even

though Cisco Secure ACS supports both DER and PEM (Base-64) encoding, download the certificate to the local

system in DER format.



Now the server certificate and the CA certificate should both be available on your local system. These certificates

need to be installed in Cisco Secure ACS. To install your new server certificate, choose System Administration >

Configuration > Local Server Certificates > Local C ertificate and select Add . Choose the Bind CA Signed

Certificate option and click on Next .

Click Browse to locate your saved server certificate. Make sure you select both checkboxes in the Protocol section.



Now you can see that the newly generated server certificate signed by the CA server is installed.

Finally, install the trusted CA server certificate on the Cisco Secure ACS Server. In the previous step, the CA server

certificate was generated and downloaded to the local system. You are going to use this certificate and install it on

Cisco Secure ACS Server.

Choose Users and Identity Stores > Certificate Authorities and click the Add button.

In the Certificate File To Import section, click the Browse button and locate the previously downloaded CA

certificate. Select the Trust for client with EAP-TLS checkbox and click the Submit button. Note that because you

selected the Trust for client with EAP-TLS checkbox, Cisco Secure ACS uses the certificate trust list for EAP-TLS

authentication when mutual authentication is required. Now you can find the CA certificate in the list.



Changing the Global Setting for EAP-FAST

EAP-FAST is a protocol used in the Cisco TrustSec SGA architecture to authenticate network devices as well as

convey SGT and other information. The next step is to change one of the runtime characteristics of the EAP-FAST

protocol. Choose System Administration > Configuration > Global Syst em Options > EAP-FAST > Setting to

optimize the EAP-FAST settings.

In the General section, change Authority Identity Info Description to your Cisco Secure ACS server name. This

description is a user-friendly string that describes the Cisco Secure ACS server that sends credentials to a client.

The client in Cisco TrustSec SGA architecture can be either the endpoint running EAP-FAST as its EAP method for

IEEE 802.1X authentication or the supplicant network device performing NDAC. The client can discover this string in

the protected access credentials (PAC) type-length-value (TLV) information. The default value is CTS ACS. You

should change the value so that the Cisco Secure ACSPAC information can be uniquely identified on network

devices upon NDAC authentication. After the value is changed, click Submit .

Configuring the Cisco Nexus 7000 Series with Cisco NX-OS

This section describes how to configure the first Cisco Nexus 7000 Series Switch.

Seed and Non-Seed Devices and IEEE 802.1X Roles

In IEEE 802.1X, the authenticator must have IP connectivity to the authentication server (Cisco Secure ACS)

because it has to relay the authentication exchange between the supplicant and the authenticator using the RADIUS

protocol. When an endpoint device, such as a PC, connects to a network, it is obvious that this PC functions as a

supplicant: an agent that requests network access. However, in the case of an SGA connection between two

network devices, the IEEE 802.1X role of each network device may not be immediately apparent to the other

network devices.

Cisco TrustSec SGA architecture allows network devices to run a role-selection algorithm to automatically determine

which device acts as the authenticator and which device acts as the supplicant. The role-selection algorithm assigns

the authenticator role to the device that has IP connectivity to a RADIUS server and receives the first RADIUS

response back from this RADIUS server. Both devices start both the authenticator and supplicant states when



connected. When a device detects that its peer has access to a RADIUS server, it terminates its own authenticator

state and assumes the role of the supplicant. If both devices receive a response from the RADIUS sever at the same

time, the algorithm compares the MAC addresses used as the source for sending Extensible Authentication Protocol

over LAN (EAPoL) packets. The device with the higher MAC address value takes precedence for the authenticator

role, and other device becomes the supplicant. If a device that supports SGA is directly connected to RADIUS

server, or is indirectly connected but receives the initial policy from the RADIUS server, this device is called the seed

device. Other network devices that support SGA are called non-seed devices.

In the topology, a Cisco Nexus 7000 Series device is indirectly connected to the Cisco Secure ACS server. This is

the first Cisco Nexus 7000 Series device that communicates to Cisco Secure ACS server; therefore, in this case, this

device (CTS7K-DC) is the seed device. This section discusses how to configure the Cisco Nexus 7000 Series to

enable SGT/SGACL (Figure 6).

Figure 6. Sample Topology Showing Seed and Non-Seed Nexus 7000 Series Switches

Obtaining and Upgrading the Cisco Nexus 7000 Series with Appropriate Cisco NX-OS Version

The first step in the Cisco Nexus 7000 Series configuration is to upgrade Cisco NX-OS to a version that supports

SGT/SGACL. This section discusses the commands needed to upgrade Cisco NX-OS. It assumes that you have

already obtained a version of Cisco NX-OS that supports SGT/SGACL.

The latest Cisco NX-OS device configuration guide can be found at the following URL:

http://www.cisco.com/en/US/products/ps9402/products_installation_and_configuration_guides_list.html.

Obtain the appropriate files from Cisco.com and place those images on a local FTP server that Cisco NX-OS can

access. In this case, three files are required for the upgrade: the Cisco NX-OS kickstart file, Cisco NX-OS System

Software image, and Cisco NX-OS electronic programmable logical device (EPLD) updates file.

Make sure that your Cisco Nexus 7000 Series has IP connectivity to your FTP server and that FTP service is

running.




Copy the file to the local bootflash directory for the Cisco Nexus 7000 Series.

CTS7K-DC# copy ftp://10.1.100.100/n7000-s1-kickstart.5.0.2a.bin bootflash:///

Enter vrf (If no input, current vrf 'default' is considered): <enter>

Enter username: anonymous

Enter password:

-------------

CTS7K-DC# copy ftp://10.1.100.100/n7000-s1-dk9.5.0.2a.bin bootflash:///



Enter password:

-------------

CTS7K-DC# copy ftp://10.1.100.100/n7000-s1-epld.5.0.2.img bootflash:///



Enter password:

After you have downloaded images, make sure they are in the bootflash directory.

CTS7K-DC# dir | inc 5.0.2

107369112 May 27 15:46:45 2010 n7000-s1-dk9.5.0.2a.bin

13947936 May 27 16:24:50 2010 n7000-s1-epld.5.0.2.img

23613440 May 27 16:24:11 2010 n7000-s1-kickstart.5.0.2a.bin

Define the boot command for both the kickstart file and the boot image. Make sure you define this command for both

supervisors (1 and 2).

CTS7K-DCAS(config)# boot kickstart bootflash:/n7000-s1-kickstart.5.0.2a.bin sup-1

CTS7K-DCAS(config)# boot system bootflash:/n7000-s1-dk9.5.0.2a.bin sup-1

CTS7K-DCAS(config)# boot kickstart bootflash:/n7000-s1-kickstart.5.0.2a.bin sup-2

CTS7K-DCAS(config)# boot system bootflash:/n7000-s1-dk9.5.0.2a.bin sup-2

Save the configuration with the copy running-config startup-config command.

CTS7K-DCAS# copy running-config startup-config

[########################################] 100%

CTS7K-DCAS#

Reload your Cisco Nexus 7000 Series Switch and enter show version to verify your Cisco NX-OS version.

After you install Cisco Secure ACS, your console should show the text-based wizard to setup the initial configuration.

Change the values to match your environment.

Note: The EPLD file is used to upgrade several programmable logical devices (PLDs) that provide hardware

functions in all modules. When upgrading the system software, you should also upgrade the PLD to the same

version as the system software, using the EPLD image. This guide does not cover this upgrade procedure. Read the

following installation guide to upgrade the EPLD file on the Cisco Nexus 7000 Series Switch:

http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/epld/epld_rn.html.

Obtaining and Installing Cisco TrustSec License for Cisco Nexus 7000 Series Switch

Cisco TrustSec SGA requires an additional feature license. If you do not have Cisco TrustSec license installed on

Cisco NX-OS, you cannot enable Cisco TrustSec on a switch, as shown here.

http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/epld/epld_rn.html



CTS7K-DC# config t


CTS7K-DC(config)# feature dot1x

CTS7K-DC(config)# feature cts

CTS enable error: Feature does not have an installed license

You need to purchase the Advanced Service license to enable Cisco TrustSec.

● For more information about the Cisco TrustSec license, see the following URL:

http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-

os/security/configuration/guide/Cisco_Nexus_7000_NX-

OS_Security_Configuration_Guide__Release_5.x_chapter12.html - con_1188935.

● For more information about the Cisco Nexus 7000 Series license, see the following URL:

http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/license_copyright/nx-os_sw_lisns.pdf.

To obtain the license file, you need to present the host ID along with your product authorization key (PAK).The host

ID can be obtained at the Cisco NX-OS CLI, by entering the show license host-id command as shown here.

CTS7K-DC# show license host-id

After you obtain the license file (which has a .lic extension), you can use this file to activate Cisco TrustSec on Cisco

NX-OS. You need to copy your license file to the Cisco NX-OS bootflash directory using TFTP or FTP. Make sure

that your license file does not contain any extra characters inserted by your local system. A sample license file is

shown here.

Enterprise.lic:

SERVER this_host ANY

VENDOR cisco

INCREMENT LAN_ENTERPRISE_SERVICES_PKG cisco 1.0 permanent uncounted \

VENDOR_STRING=<LIC_SOURCE>MDS_SWIFT</LIC_SOURCE><SKU>N7K-LAN1K9=</SKU> \

HOSTID=VDH=TBC10412106 \

NOTICE="<LicFileID>20071025133322456</LicFileID><LicLineID>1</LicLineID>\

<PAK></PAK>" SIGN=0CC6E2245FBE

Use the command shown here to activate your Cisco TrustSec features using the license file.

CTS7K-DC# install license bootflash:your_license_file.lic

If the license file is corrupted, you will see the error message shown here when you try to install the license file.

CTS7K-DC# install license bootflash:Enterprise.lic

\Installing license failed: SERVER line in license should have "this_host ANY"

After a successful installation, you can check your new license file by entering the command shown here at the CLI.

CTS7K-DC# show license usage

Feature Ins Lic Status Expiry Date Comments

Count

--------------------------------------------------------------------------------

LAN_ADVANCED_SERVICES_PKG Yes - In use Never -

LAN_ENTERPRISE_SERVICES_PKG No - In use Grace 119D 22H

--------------------------------------------------------------------------------

http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/security/configuration/guide/Cisco_Nexus_7000_NX-OS_Security_Configuration_Guide__Release_5.x_chapter12.html - con_1188935



http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/license_copyright/nx-os_sw_lisns.pdf



Enabling Cisco TrustSec on Cisco NX-OS

You must enable both the IEEE 802.1X and Cisco TrustSec SGA features on the Cisco NX-OS device before you

can configure SGA. Use the CLI commands shown here to enable both IEEE 802.1X and Cisco TrustSec.

CTS7K-DC# config t


CTS7K-DC(config)# feature dot1x

CTS7K-DC(config)# feature cts

CTS7K-DC(config)# exit

To verify that Cisco TrustSec is enabled, you can enter the command shown here.

CTS7K-DC# show dot1x

Sysauthcontrol Enabled

Dot1x Protocol Version 2

CTS7K-DC# show cts

CTS Global Configuration

==============================

CTS support : enabled

CTS device identity : not configured

CTS caching support : disabled

Number of CTS interfaces in

DOT1X mode : 0

Manual mode : 0

You can also enter the show feature command to display the currently available features and a list of enabled and

disabled features.

Configuring Cisco TrustSec Credentials

On a device enabled for Cisco TrustSec, you have to configure Cisco TrustSec credentials to identify the device

uniquely. Cisco TrustSec uses the password in the credentials for device authentication, a process called network

device admission control, or NDAC. This guide uses CTS7K-DC as the device ID and trustsec123 as the password.

CTS7K-DC# config t


CTS7K-DC(config)# cts device-id CTS7K-DC password trustsec123


Verify the device ID using the command shown here.

CTS7K-DC# show cts

CTS Global Configuration

==============================

CTS support : enabled

CTS device identity : CTS7K-DC

CTS caching support : disabled



Number of CTS interfaces in

DOT1X mode : 0

Manual mode : 0

Configuring Authentication, Authorization, and Acco unting and RADIUS on the Cisco Nexus 7000 Series to

Communicate with Cisco Secure ACS

Now the Cisco Nexus 7000 Series needs to communicate with the Cisco Secure ACS server. Cisco Secure ACS is

connected to the Cisco Catalyst 4948 data center access switch, and the Cisco Catalyst 4948 is connected to the

Cisco Nexus 7000 Series through a trunk link. This Cisco Nexus 7000 Series first communicates with Cisco Secure

ACS; therefore, this switch is a seed device. The Cisco Secure ACS server is connected to VLAN 100 port on the

Cisco Catalyst 4948, and VLAN 100 is trunked to the Cisco Nexus 7000 Series (the trunk port is Ethernet 3/2). Detail

information about the environment is shown here.

interface Ethernet3/2

switchport

switchport mode trunk

switchport trunk native vlan 2

switchport trunk allowed vlan 2,100,200,999

no shutdown

Also, the VLAN 100 interface is enabled on CTS7K-DC.

CTS7K-DC# show feature | inc vlan

interface-vlan 1 enabled

CTS7K-DCAS# show run interface VLAN 100

interface Vlan100

no shutdown

ip address 10.1.100.1/24

Cisco Secure ACS connectivity can also be verified through the Cisco Discovery Protocol if Cisco Discovery Protocol

is enabled on interface.

CTS4K-DCAS#show cdp neighbors

Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge

S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,

D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID Local Intrfce Holdtme Capability Platform Port ID

0015177f74c8 Gig 1/20 155 H CSACS-112 eth0

To connect to Cisco Secure ACS and perform NDAC authentication and policy acquisition through authorization,

enter the commands shown here. First define the RADIUS server with the radius-server host command. The pac

keyword is required to receive a protected access credential file for NDAC.

CTS7K-DC# config t


CTS7K-DC(config)# radius-server host 10.1.100.3 key cisco123 pac


Second, specify the RADIUS server group and specify the RADIUS server host address in the server group

configuration mode. In the same configuration mode, specify the virtual route forwarding (VRF) name for the



authentication, authorization, and accounting (AAA) server group. If the Cisco Secure ACS server is directly

connected to the management interface (mgmt0), then use the VRF name management . In this guide, the Cisco

Secure ACS server is connected through the switched virtual interface (SVI; VLAN 100), so the VRF default name

cts-radius is the group name used here.

Note: You must configure use-vrf default in the CLI under aaa group server radius <radius group name> . You

can verify the CLI command by entering show running-configuration all .

CTS7K-DC# config t


CTS7K-DC(config)# aaa group server radius cts-radius

CTS7K-DC(config-radius)# server 10.1.100.3

CTS7K-DC(config-radius)# use-vrf default

CTS7K-DC(config-radius)# exit

Finally, you need to map the authentication service to the RADIUS group. The commands shown here do that for the

IEEE 802.1X and Cisco TrustSec authentication and authorization services. The RADIUS server host defined in the

RADIUS server group, called cts-radius , is used. (You can use a different name for the server group.)

CTS7K-DC# config t


CTS7K-DC(config)# aaa authentication dot1x default group cts-radius

CTS7K-DC(config)# aaa authorization cts default group cts-radius


Now the Cisco Nexus 7000 Series seed device is ready for the seed device NDAC process. Before the NDAC

process starts, you need to go back to the Cisco Secure ACS web console and configure this Cisco Nexus 7000

Series Switch as a Cisco TrustSec AAA client. Logon to the Cisco Secure ACS web console and choose Network

Resources > Network Devices and AAA Clients . Click the Create button to define a new network device. In the

Name field, enter CTS7K-DCAS . In the Network Device Groups section, leave the Location field at the default.

Click the Select button for Device Type to open the Network Device Groups window. Click Create to configure the

device group for the device capable of supporting Cisco TrustSec SGA. In the Name field, enter CTS Network

Device and click Submit .

Now in the IP Address section, select Single IP Address and enter your device IP address. In the Authentication

Options section, select RADIUS and then type your RADIUS shared secret, which was configured earlier. Select the

checkbox for TrustSec and select Use Device ID for TrustSec identification to use the device name as the Cisco

TrustSec device ID. If you need to change your device ID to something other than the device name, then deselect

this option and enter the appropriate device ID. In the Password field, enter the device password, which was also

configured earlier. Finally, in the TrustSec Advanced Settings section, make sure that the Other TrustSec

devices to trust this device (CTS trusted) option is selected. This option will make the network device the trusted



device for sending SGT traffic. If a device receives SGT tagged traffic from a distrusted device, the device will not

honor the SGT traffic. That traffic will be tagged with a special SGT of Unknown (SGT value = zero).

Table 10 summarizes the complete configuration and describes each option.

Table 10. Summary Information for Network Device and AAA Client Configuration

Configuration Value Description

Name CTS7K-DC This is the name of the network device. If you are duplicating a network device, you must enter a unique name as a minimum configuration; all other fields are optional.

Location All Locations Leave this section at the default.

Device Type All Device Type: CTS Network Device

Choose CTS Network Device as the device type.

IP Single IP Address

10.1.100.1

This setting specifies the IP addresses and subnet masks associated with the network device. Select to enter a single IP address or to define a range. This address should be the routable source IP address of the network device with which Cisco Secure ACS can communicate.

RADIUS Checked Check to use the RADIUS protocol to authenticate communication to and from the network device.

Shared Secret cisco123 Enter the shared secret of the network device if you have enabled the RADIUS protocol. This shared secret is exactly the same string that is defined with the key keyword in the radius-host command found in Cisco NX-OS or Cisco IOS Software.

TrustSec Checked This option appears only when you enable the Cisco TrustSec feature. Check to use Cisco TrustSec on the network device. If the network device is the seed device (the first device in the Cisco TrustSec network), you must also check the RADIUS check box.

Use Device ID for TrustSec identification

Checked This is the name that will be used for Cisco TrustSec identification of this device. By default, the configured device name is used. If you want to use another name, clear the Use device name for Cisco TrustSec identificati on check box and enter the name in the Identification field.

Device ID CTS7K-DC (dimmed) This is the name that will automatically be populated as the device name if Use Device ID for TrustSec identification is checked. Make sure that this device ID matches the device ID configured in the Cisco NX-OS cts device-id command. The device ID is case sensitive.

Password trustsec123 The Cisco TrustSec authentication password. This credential also needs to match to credential configured on Cisco NX-OS cts device-id command password keyword.



Configuration Value Description

Other TrustSec devices to trust this device (CTS trusted)

Checked This option specifies whether all the device’s peer devices trust this device. By default, this option is checked, which means that the peer devices trust this device and do not change the SGT on packets arriving from this device. If you uncheck the check box, the peer devices reclassify packets from this device with the related peer SGT.

Download peer authorization policy every: Days Hours Minutes Seconds

1 Day (default) This option specifies the expiry time for the peer authorization policy. Cisco Secure ACS returns this information to the device in response to a peer policy request. The default is 1 day.

Download SGACL lists every: Days Hours Minutes Seconds

1 Day (default) This option specifies the expiry time for SGACL lists. Cisco Secure ACS returns this information to the device in response to a request for SGACL lists. The default is 1 day.

Download environmental data every: Days Hours Minutes Seconds

1 Day (default) This option specifies the expiry time for environment data. Cisco Secure ACS returns this information to the device in response to a request for environment data. The default is 1 day.

Reauthentication every: Days Hours Minutes Seconds

1 Day (default) This option specifies the dot1x (.1x) reauthentication period. Cisco Secure ACS configures this for the supplicant and returns this information to the authenticator. The default is 1 day.

Creating the Device SGT and Assigning It to the Cis co Nexus 7000 Series Seed Device

As noted previously, Cisco TrustSec SGA also uses the device and user identification information acquired during

authentication to classify 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, or SGT, allows the

network to enforce the access control policy by enabling the endpoint device to act on the SGT to filter traffic. As part

of policy acquisition phase (authorization), a device that supports Cisco TrustSec receives an SGT called the device

SGT. This device SGT represents the security group to which the device itself belongs and is exchanged with

neighbor devices as a token of a trusted device. This device SGT is configured on Cisco Secure ACS prior to the

seed device NDAC process.

A device SGT can be uniquely assigned to every device that supports SGA. You should use a single SGT value for

all devices that support Cisco TrustSec unless there is a specific need to separate security groups for a certain set of

devices. This guide uses a single device SGT for all devices that support SGA.

On the Cisco Secure ACS web console, choose Policy Elements > Authorization and Permissions > N etwork

Access > Security Groups . Note that this configuration option is available only after you install the Cisco TrustSec

Access Control license. Click the Create button and enter your seed device name in the Name field. You can add a

description as needed. After you enter the device name, click Submit .

After submitting the configuration, the Cisco Secure ACS server will automatically generate the SGT for this device.

You will not be able to select the SGT value. In this example, CTS-Device-SGT2/0002 (Dec / Hex) is generated for

all the Cisco TrustSec network devices.



Creation of the SGT does not automatically assign the device SGT to the Cisco TrustSec device upon successful

NDAC. The device SGT needs to be mapped to the actual Cisco TrustSec device before NDAC authentication takes

place. To perform Cisco Secure ACS device SGT–to–device mapping, choose Access Policies > TrustSec Access

Control > Network Device Access > Authorization Pol icy . On this page, choose Rule based result selection .

(The default is Single result selection .)The Rule based result selection option allows you to create conditions to

assign an SGT to a set of Cisco TrustSec devices.

In the right corner, click the Customize button to enable multiple conditions. From the list on the left, select

TrustSec Device ID , NDG: Device Type , NDG: Location , and Time And Date . Then, use the > button to move

those items to the right side box. When you are done, click OK.

Finally, click the Create button to map the device SGT to the actual device. In the Name field, enter Device SGT .

Make sure that Status is set to Enabled . In the Conditions section, select NDG: Device Type . For the operant,

choose in from the pull-down menu. Click the Select button and choose All Device Types: CTS Network Device

Group from the list. In the Result section, click Select and choose the device SGT CTS-Device-SGT , which was

created earlier. Then click OK. This completes the device SGT–to–network device mapping.



Click OK to move back to the Authorization Policy page. Click Save Changes to save the configuration.

Verifying Cisco Nexus 7000 Series NDAC for the Seed Device

After both Cisco NX-OS and Cisco Secure ACS are configured, Cisco NX-OS should communicate with Cisco

Secure ACS and start the NDAC process. After the NDAC process is complete, you can verify the seed device

NDAC result on both the Cisco Secure ACS and Cisco NX-OS CLI consoles.

First, enter the commands shown here to verify the RADIUS server status.

CTS7K-DC# show radius-server

retransmission count:1

timeout value:5

deadtime value:0

source interface:any available

total number of servers:1

following RADIUS servers are configured:

10.1.100.3:

available for authentication on port:1812

available for accounting on port:1813

RADIUS shared secret:********

Secure Radius: Enabled

Authority Identity (AID)is :517822aea6bb11de8000d4ef073797ea



CTS7K-DC# show radius-server groups cts-radius

group cts-radius:

server: 10.1.100.3 on auth-port 1812, acct-port 1813

deadtime is 0

vrf is default

After the Cisco Nexus 7000 Series Switch is authenticated as a seed device, a set of data called protected

authorization credentials, or PAC, is provisioned on Cisco NX-OS. After the PAC is provisioned, your Cisco Nexus

7000 Series NDAC is complete. Use the show cts pac command to check whether the PAC is provisioned for Cisco

NX-OS. Notice that A-ID (Authority-ID) information is included in the command output. Now you can verify the unique

Cisco Secure ACS A-ID configured in the Cisco Secure ACS EAP-FAST global setting.

CTS7K-DC# show cts pacs

PAC Info :

==============================

PAC Type : Trustsec

AID : 517822aea6bb11de8000d4ef073797ea

I-ID : CTS7K-DC

AID Info : CTS ACS 1

Credential Lifetime : Tue Sep 29 11:36:56 2009

PAC Opaque : 000200b00003000100040010517822aea6bb11de8000d4ef073797ea

0006009400030100fe7d86450ed2d67fe040e4eb855518a8000000014ab8533700093a80bfa75e69

ca42cd2571cc4ae5a59cb1fdff4bc43168f0d0e825142d7dd7b90b8828fea52f57e44a41ae3b47c0

b1a66f023ee6121b24b87c11db29ca3257e18222df28478eea3ec259ed4fa25dced89db9363db44a

4b832f4074194412140cfe006a7d59a6fb9ddfaf48e3c9a2af9e292805c51c8c

Upon successful NDAC, devices that support Cisco TrustSec receive environment data. The environment data is a

collection of information or policies that help a device function as a Cisco TrustSec node. The device acquires the

environment data from the authentication server when the device first joins a Cisco TrustSec cloud, although you

can also manually configure some of the data on a device. The device must refresh the Cisco TrustSec environment

data before it expires. By default, environment data is refreshed every day. This value is configurable from the

Network Devices and AAA Client settings on the Cisco Secure ACS web console. The device uses RADIUS to

acquire the environment data from the authentication server listed in Table 11.

Table 11. Environment Data

Data Description

Server list List of servers that the client can use for future RADIUS requests (for both authentication and authorization)

Device SGT Security group to which the device itself belongs

Expiry timeout Interval that controls how often the Cisco TrustSec device should refresh its environment data

You can check the environment data from the Cisco NX-OS CLI. The device SGT created earlier on the Cisco

Secure ACS is downloaded to the Cisco Nexus 7000 Series upon completion of the Cisco TrustSec NDAC process.

Use the show cts environment-data CLI command to acquire this information. The example here shows the

environment data output to the seed device. As previously configured, the Local Device SGT value is shown as

0x0002 in hexadecimal format (2 in decimal format). Server List shows available Cisco Secure ACSA-ID, IP

address, and port number values.



CTS7K-DC# show cts environment-data

CTS Environment Data

==============================

Current State : CTS_ENV_DNLD_ST_ENV_DOWNLOAD_DONE

Last Status : CTS_ENV_SUCCESS

Local Device SGT : 0x0002

Transport Type : CTS_ENV_TRANSPORT_DIRECT

Data loaded from cache : FALSE

Env Data Lifetime : 86400 seconds after last update

Last Update Time : Tue Sep 22 11:44:16 2009

Server List : ACSServerList1

AID:517822aea6bb11de8000d4ef073797ea IP:10.1.100.3 Port:1812

Now take a look at the Cisco Secure ACS log for this NDAC. You can find the Cisco Secure ACS RADIUS

authentication log by choosing Monitoring and Report > Launch Monitoring & Report Viewer . Another window

then opens and displays the Monitoring and Reports tool. In the right panel, choose Dashboard > General

tab>My Favorite Reports >Authentication – RADIUS – Today . In the log, you will notice that there is a one

Access-Reject log and one Access-Accept log for the Cisco TrustSec seed device. The first access-reject log is

expected as EAP-FAST authentication needs to be failed for Phase 0 PAC provisioning purposes. After the PAC is

provisioned, another authentication succeeds with appropriate policy acquisition (authorization).

When the Cisco Nexus 7000 Series or any device that supports Cisco TrustSec cannot communicate with the Cisco

Secure ACS server, there is a chance that the device will fail to download the environment data. When a device that

supports Cisco TrustSec cannot download environment data, it also cannot download any policy from Cisco Secure

ACS. Following is an example of a show cts environment-data command upon communication failure.

CTS7K-DC# show cts environment-data


==============================

Current State : CTS_ENV_DNLD_ST_ENV_DOWNLOAD_FAILED

Last Status : CTS_ENV_DATA_DL_FAILURE





Last Update Time : Wed Jul 8 06:35:26 2009


AID:5c660cf656d611de8000a69d3695bca6 IP:172.16.100.50 Port:1812

If you do not see any PAC data after entering show cts pacs , or if you receive a failure status after entering show

cts environment-data , you should check the IP connectivity to your Cisco Secure ACS server.

Configuring Private VLAN for Data Center Access

This section discusses how to configure the Cisco Catalyst 4948 data center access switch to connect two servers

(Figure 7).



Figure 7. Sample Topology for Data Center Access

With Cisco IOS Software12.2(52)SG, the Cisco Catalyst 4948 currently supports the Cisco TrustSec features listed

in Table 12.

Table 12. Cisco TrustSec Features Supported by the Cisco Catalyst 4948 Switch

Feature Description

Dynamic SGT assignment with RADIUS

SGT is assigned to the endpoint through RADIUS upon authorization for IEEE 802.1X, MAC authentication bypass or web authentication bypass (EAC).

IP-to-SGT manual binding The endpoint IP address and SGT can be manually mapped locally on a switch that supports Cisco TrustSec.

SXP The IP-to-SGT binding table is sent from a device that does not support Cisco TrustSec to a device that does support Cisco TrustSec for hardware-based tagging.

Although the Cisco Catalyst 4948 does not support SGACL enforcement at the access layer, you can enforce policy

using SGACL with the Cisco Nexus 7000 Series Switch, which is usually placed at the data center core or

distribution layer. Then you use private VLAN on both the Cisco Catalyst 4948 and Cisco Nexus 7010 Switches so

that two servers are allowed to communicate through the SVI configured in the Cisco Nexus 7010, where you can

apply SGACL to enforce policy. This technique is useful when the data center access switch or top-of-rack (ToR)

switch does not natively support SGACL enforcement. This method also can be used when you want to separate

server traffic in the same segment, as shown in Figure 8. Again, if the switch directly connected to the server (for

example, the server access switch) supports SGACL, then there is no need to configure private VLAN.

Use the steps that follow to configure a private VLAN between the Cisco Catalyst 4948 and Cisco Nexus 7010

Switches.



To understand how private VLAN works, review the configuration page for the private VLAN feature for the Cisco

Catalyst 4948 by visiting the following URL:

http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/52sg/configuration/guide/pvlans.html. Also review

the definitions for private VLAN technology in Table 13.

Table 13. Private VLAN Terminology

Term Definition

Private VLAN Private VLANs are sets of VLAN pairs that share a common identifier and provide a mechanism for achieving Layer 2 separation between ports while sharing a single Layer 3 router port and IP subnet.

Primary VLAN A private VLAN has only one primary VLAN. Every port in a private VLAN s a member of the primary VLAN. The primary VLAN carries unidirectional traffic downstream from the promiscuous ports to the (isolated and community) host ports and to other promiscuous ports.

Secondary VLAN A secondary VLAN is a type of VLAN used to implement private VLANs. Secondary VLANs are associated with a primary VLAN and are used to carry traffic from hosts to other allowed hosts or to routers.

Promiscuous port A promiscuous port belongs to the primary VLAN and can communicate with all interfaces, including the community and isolated host ports and private VLAN trunk ports that belong to the secondary VLANs associated with the primary VLAN.

Isolated port An isolated port is a host port that belongs to an isolated secondary VLAN. It has complete Layer 2 separation from other ports within the same private VLAN, except for the promiscuous ports. Private VLANs block all traffic to isolated ports except traffic from promiscuous ports. Traffic received from an isolated port is forwarded only to promiscuous ports.

In this guide, VLAN 200 is used as the primary VLAN, and VLAN 999 is used as the secondary VLAN for private

VLAN. To isolate traffic within a broadcast domain, an isolated port is configured to the ports connected to the target

servers.

First, make sure that you enable VLAN Trunk Protocol (VTP) in transparent mode in VTP Versions 1 and 2. You

cannot change the VTP mode to client or server for private VLAN. This configuration uses the VLANs shown here.

CTS4K-DCAS#config t


CTS4K-DCAS(config)# vtp domain cts

CTS4K-DCAS(config)# vtp mode transparent

Now configure the primary and secondary VLANs for the private VLAN feature.

CTS4K-DCAS#config t


CTS4K-DCAS(config)# vlan 200

CTS4K-DCAS(config-vlan)# name PVLAN-PRI

CTS4K-DCAS(config-vlan)# private-vlan primary

CTS4K-DCAS(config-vlan)# private-vlan association 999

CTS4K-DCAS(config-vlan)#exit

CTS4K-DCAS(config)# vlan 999

CTS4K-DCAS(config-vlan)# name PVLAN-SEC

CTS4K-DCAS(config-vlan)# private-vlan isolated

CTS4K-DCAS(config-vlan)# end

CTS4K-DCAS#

Next, configure the interface to support private VLAN.

CTS4K-DCAS#config t


CTS4K-DCAS(config)# interface GigabitEthernet 1/1

CTS4K-DCAS(config-if)# private-vlan primary

http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/52sg/configuration/guide/pvlans.html



CTS4K-DCAS(config-if)# switchport private-vlan host-association 200 999

CTS4K-DCAS(config-if)# switchport mode private-vlan host

CTS4K-DCAS(config-if)# spanning-tree portfast

CTS4K-DCAS(config-if)#exit

Gigabit Ethernet 1/1 is now configured. Configure Gigabit Ethernet 1/2 with the same interface. The uplink interface

to the Cisco Nexus 7010 is configured as the IEEE 802.1q trunk port. The uplink configuration is shown here for

reference.

interface GigabitEthernet1/47

switchport trunk encapsulation dot1q




media-type rj45

end

On the Cisco Nexus 7000 Series Switch side, you also need to enable private VLAN and configure the primary and

secondary VLANs for private VLAN. Refer to the following URL for more information about the Cisco Nexus 7000

Series private VLAN feature: http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-

os/layer2/configuration/guide/Cisco_Nexus_7000_Series_NX-

OS_Layer_2_Switching_Configuration_Guide_Release_5.x_chapter4.html.

Now access your Cisco Nexus 7000 Series Switch console. Use the command shown here to enable the private

VLAN and VTP features.

CTS7K-DC# config t


CTS7K-DC(config)# feature private-vlan

CTS7K-DC(config)# feature vtp


Configure the VTP mode as transparent and set the VTP domain name to cts .

CTS7K-DC# config t


CTS7K-DC(config)# vtp mode transparent

CTS7K-DC(config)# vtp domain cts


Configure VLAN 99 as the secondary private VLAN (Isolated) and VLAN 200 as the primary private VLAN.

CTS7K-DC# config t


CTS7K-DC(config)# vlan 999

CTS7K-DC(config-vlan)# name PVLAN-SEC

CTS7K-DC(config-vlan)# private-vlan isolated

CTS7K-DC(config-vlan)# exit


CTS7K-DC(config-vlan)# name PVLAN-PRI

CTS7K-DC(config-vlan)# private-vlan primary

CTS7K-DC(config-vlan)# private-vlan association 999

http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/layer2/configuration/guide/Cisco_Nexus_7000_Series_NX-OS_Layer_2_Switching_Configuration_Guide_Release_5.x_chapter4.html






Finally, configure the SVI for VLAN 200.

CTS7K-DC# config t


CTS7K-DC(config)# int vlan 200

CTS7K-DC(config-if)# private-vlan mapping 999

CTS7K-DC(config-if)# ip local-proxy-arp

CTS7K-DC(config-if)# exit

The CLI ip local-proxy-arp command must be present for router to respond to the Address Resolution Protocol

(ARP) request for IP addresses in a subnet in which normally no routing is required.

Make sure that your Cisco Catalyst 4948 switch uplink is configured as a trunk port.

The configuration of an IEEE 802.1q trunk interface to the Cisco Catalyst 4948 is shown here for reference.


switchport




no shutdown

Private VLAN between the Cisco Catalyst 4948 and Cisco Nexus 7010 Switches has now been configured. You can

easily test the private VLAN capability by sending an Internet Control Message Protocol (ICMP) packet between the

two servers connected to the Cisco Catalyst 4948. Now access the HR server as well as the IT server and perform

continuous ICMP from both sides (choose Start > Run and enter cmd ; then enter ping –t 172.16.200.x0 ).

Make sure that you can ping the other server first. With private VLAN, traffic from an isolated VLAN is sent to the

promiscuous port. Therefore, two servers need to communicate through the SVI of VLAN 200 on the Cisco Nexus

7000 Series Switch. After you verify successful pinging between the two servers, go back to the Cisco Nexus 7000

Series Switch and shutdown Interface VLAN 200.If the ping command stops responding, then you can be assured

that the two servers are communicating with each other through the promiscuous port and SVI on the Cisco Nexus

7000 Series Switch, even though those servers are in the same subnet and connected to the Cisco Catalyst 4948

Switch.

Enforcing Access Policy for Servers Using SGACL

This section discusses how to set policy in Cisco Secure ACS to enforce traffic between two servers using the

SGACL feature on the Cisco Nexus 7000 Series. This section demonstrates SGT assignment by defining IP-to-SGP

mapping manually on the Cisco TrustSec device (Figure 8).



Figure 8. Server Traffic Segmentation Use Case Topology

The first step is to set up the SGT for servers and associated SGACL to control the traffic path.

Assigning SGTs for Network Entities

Cisco TrustSec SGA solution assigns a unique 16-bit tag, the SGT, to a security group. As discussed, SGT is

assigned to each network device in the SGA domain to tag data sourced from the device itself. To assign SGTs to

traffic coming from other network entities such as endpoint devices (for instance, a client PC) or servers, the SGT

assignment process needs to take place for these entities as well. Essentially all the entities attached to SGA

domain should have SGTs assigned. Following is a list of methods for assigning SGTs to such network entities:

● SGT assignment through IEEE 802.1X authentication

● SGT assignment through MAC Authentication Bypass

● SGT assignment through web authentication bypass

● SGT assignment through identity lookup on the Cisco Secure ACS server

● Static (manual) SGT assignment to the endpoint IP address

● Static (manual) SGT assignment on the switch interface

In the data center scenario, two server entities are attached to the Cisco TrustSec domain. To control traffic between

those two servers, you need to assign SGTs to those servers. Because it is not practical to perform IEEE 802.1X–

based authentication, MAC authentication bypass, or even web authentication on those servers, you must map SGT

to those server IP addresses statically.

First you generate SGTs for servers connected to the Cisco Catalyst 4948.



Access your Cisco Secure ACS web console and choose Policy Elements > Authorization and Permissions >

Network Access > Security Groups . Click the Create button to generate SGTs for the two server groups as shown

here. Again, Cisco Secure ACS automatically generates the SGT values.

The values of your SGTs may differ from those shown in Table 14.

Table 14. SGT Values for Servers

SGT Name SGT Value (Decimal and Hexadecimal) Description

HR Server 3/0003 HR server group SGT

IT Server 4/0004 IT server group SGT

Now using those unique tags, you can control the traffic that the server can transmit using security group access

control lists, or SGACLs. SGACLs are also known as role-based ACLs. SGACLs can be based on role membership

instead of IP addresses or subnets to accommodate today’s access control requirements.

Table 15 presents a matrix that shows the relationship between the SGT and the SGACL. The SGT assigned to the

source of the traffic is referred to the source group tag. The SGT assigned to the destination of the traffic is referred

to as the destination group tag. In this matrix, the columns represent the source group tag, and the rows represent

the destination group tags. The policies of this matrix indicate that if a server is a member of the HR server, this

server has no access to services running on IT servers. Also, if a server is in the IT server group, no web access to

the HR server is allowed. The IT server group has access to services running on the HR server for maintenance

purposes only. Those services can be terminal services, SSH, or FTP. You can also define binary access control

(permit all or deny all) in addition to transport service.

Table 15. SGACL Policies for Servers

Source/Destination HR Server IT Server

HR Server – No access

IT Server Only maintenance service (terminal service, SSH, etc.) allowed

–

You configure the actual matrix at the Cisco Secure ACS web console in a similar way. First configure the content of

the SGACL. Choose Policy Elements > Authorization and Permissions > N amed Permission Objects >

Security Group ACLs and click the Create button. A screen is displayed where you can name and configure the

SGACL content.



The SGACL name cannot include spaces, hyphens (-), question marks (?), or exclamation points (!).

After you create the SGACL, its generation ID appears. The generation ID is used to track changes in the name or

contents of the SGACL. When you modify the name or contents of an SGACL, Cisco Secure ACS updates the

generation ID. When the generation ID of an SGACL changes, the relevant Cisco TrustSec network devices reload

the content of the SGACL.

Use the syntax shown here to create the content of the SGACL.

deny all

deny icmp

deny igmp

deny ip

deny tcp [{dest|src} {{eq | gt | lt | neq}port-number | range port-number1 portnumber 2}]

denyudp [{dest|src} {{eq | gt | lt | neq}port-number | range port-number1 portnumber 2}]

permitall

permit icmp

permit igmp

permit ip

permit tcp [{dest|src} {{eq | gt | lt | neq}port-number | range port-number1 portnumber 2}]

permit udp [{dest|src} {{eq | gt | lt | neq}port-number | range port-number1 portnumber 2}]

Create two SGACLs as shown in Table 16.

Table 16. SGACL Contents for Server to Server Access

Name SGACL Content

Permit_IT_Services permit tcp dst eq 22

permit tcp dst eq 445


permit icmp

deny ip

Deny_All permit tcp src eq 22

permit tcp src eq 445


permit icmp

deny ip



A matrix similar to the one shown earlier can also be found in the Cisco Secure ACS configuration. Choose Access

Policies > TrustSec Access Control > Egress Policy .

The rows and columns consist of the SGTs that were generated and are already available on Cisco Secure ACS. All

SGT values that you have created should be available as source group tags or destination group tags. Using this

matrix, you can build the same matrix that was discussed earlier.

First, configure the rules for HR servers. Choose the cell in which the source is HR Servers and the destination is IT

Server . Double-click the cell to open a window where you can choose pre-populated a SGACL and closing ACL.

This example uses a SGACL named Deny_All .

Note: The closing ACL (Permit IP or Deny IP) can be used to set the default filter for any unmatched traffic at the

end of the ACL. Cisco NX-OS 4.2.1 for the Cisco Nexus 7000 Series does not support the download of multiple

SGACLs in a single authorization message. Although the Cisco Secure ACS interface allows this closing ACL, note

that this closing ACL needs to be included in the SGACL itself. Use DenyIP as the closing ACL; otherwise, all traffic

will be permitted by default.

Repeat the preceding steps to apply the SGACL to traffic from IT Server to HR Servers . Use the

Permit_IT_Services SGACL for this entry. You should have a matrix similar to the one shown here.



The preceding configuration is all that is needed to setup access policy for servers in the data center use case. Now

configure the Cisco Nexus 7000 Series Switch to statically assign IP addresses of servers to SGTs, so that the Cisco

Nexus 7000 Series Switch can download associated policies (the ones you just created in the previous steps) and

apply those policies.

Access your Cisco Nexus 7000 Series console. Use this CLI syntax to assign a unique IP address to a specific SGT

value manually:

cts role-based sgt-map <A.B.C.D><SGT-Value-in-Decimal>

where A.B.C.D is the IP address of the host.

Use the entries shown here to assign a specific SGT (the same SGT as assigned on the Cisco Secure ACS

interface) to each server’s IP address.

CTS7K-DC# config t


CTS7K-DC(config)# cts role-based sgt-map 10.1.200.100 3

CTS7K-DC(config)# cts role-based sgt-map 10.1.200.200 4


After you statically map a server IP address to a specific SGT, you can review the configuration with a show

command.

CTS7K-DC# show cts role-based sgt-map

IP ADDRESS SGT VRF/VLAN SGT CONFIGURATION

10.1.200.100 3 vrf:1 CLI Configured

10.1.200.200 4 vrf:1 CLI Configured

Finally, turn on SGACL enforcement for the default VRF.

CTS7K-DC# config t


CTS7K-DC(config)# cts role-based enforcement


Now verify the policy provisioning from the Cisco Secure ACS to Cisco Nexus 7000 Series. Use a show command to

see if SGACL enforcement is enabled on the VLAN or VRF.



CTS7K-DC# show cts role-based enable

vrf:1

The output shows that SGACL enforcement is enabled on vrf:1 (the default VRF).

You can now check the contents of the SGACL downloaded to the Cisco Nexus 7000 Series. Use a show command

to verify the SGACL contents.

CTS7K-DC# show cts role-based access-list

rbacl:Deny IP

deny ip

rbacl:Deny_All




permit icmp

deny ip

rbacl:IT_Admin_Only






permit icmp

deny ip

You can now verify that exactly the same SGACL contents are downloaded from the Cisco Secure ACS to the Cisco

Nexus 7000 Series. Use a show command to verify the SGACL matrix that you have created in Cisco Secure ACS

as well. If you do not see the contents or matrix of SGACL, enter cts refresh role-based-policy to request the latest

policy from the Cisco Secure ACS server.

CTS7K-DC# show cts role-based policy

sgt:3

dgt:4 rbacl:Deny_All




permit icmp

deny ip

sgt:4

dgt:3 rbacl:Permit_IT_Services




permit icmp

deny ip



sgt:any

dgt:any rbacl:Permit IP

permit ip

Because SGACL content is manually typed in the Cisco Secure ACS user interface, it is very easy to have typing

errors, which may result in SGACL syntax errors. If any illegal SGACL syntax is downloaded to the Cisco Nexus

7000 Series, a syslog will be generated to indicate that the system failed to parse the SGACL content. When this

parser error occurs, the invalid SGACL content will not be downloaded. A sample syslog message is shown here.

CTS7K-DC# 2009 Jul 6 14:18:57 CTS7K-DC %$ VDC-2 %$ %CTS-2-RBACL_UNABLE_PARSE_ACE: Unable to parse RBACL ACE substring: permit dst dst eq 20

You can now logon to both the IT server and HR server to test the traffic enforcement. If those servers are running

terminal service, SSH service, or Microsoft Windows file sharing, you can test the connectivity from each server.

You can enter show system internal access-list output statistics module <module#> to show actual traffic hits

for each SGACL entry in ternary content addressable memory (TCAM). Currently, this is the way to verify that

SGACL is applied to the traffic.

CTS7K-DC# show system internal access-list output statistics module 3

VLAN 2 :

=========

no acl related hardware resources found

VLAN 200 :

=========


VDC-2 Ethernet1/2 :

====================


VDC-2 Ethernet1/4 :

====================


VDC-2 Ethernet1/6 :

====================


VDC-2 VRF table 1 :

====================

Tcam 0 resource usage:

----------------------

Label_a = 0x800

Bank 0

------

IPv4 Class

Policies: Rbacl() [Merged]

Entries:

[Index] Entry [Stats]

---------------------

[0000] permit icmp 0.0.0.4/32 0.0.0.3/32 [0]

[0001] permit tcp 0.0.0.4/32 eq 443 0.0.0.3/32 [0]

[0002] permit tcp 0.0.0.4/32 eq 80 0.0.0.3/32 [0]

[0003] permit tcp 0.0.0.4/32 0.0.0.3/32 eq 3389 [58]



[0004] permit tcp 0.0.0.4/32 0.0.0.3/32 eq 445 [80]

[0005] permit tcp 0.0.0.4/32 0.0.0.3/32 eq 22 [0]

[0006] permit tcp 0.0.0.4/32 0.0.0.3/32 fragment [0]

[0007] permit icmp 0.0.0.3/32 0.0.0.4/32 [0]

[0008] permit tcp 0.0.0.3/32 eq 3389 0.0.0.4/32 [71]

[0009] permit tcp 0.0.0.3/32 eq 445 0.0.0.4/32 [78]

[0010] permit tcp 0.0.0.3/32 eq 22 0.0.0.4/32 [0]

[0011] permit tcp 0.0.0.3/32 0.0.0.4/32 fragment [0]

[0012] deny ip 0.0.0.4/32 0.0.0.3/32 [4]

[0013] deny ip 0.0.0.3/32 0.0.0.4/32 [3]

[0014] permit ip 0.0.0.0/0 0.0.0.0/0 [237]

Configuring Static IP-to-SGT Mapping on the Cisco C atalyst 4948 and SXP Connection to the Cisco Nexus

7000 Series

Previously, you defined server IP-to-SGT binding on the Cisco Nexus 7000 Series Switch. You can configure this

static mapping on the Cisco Catalyst 4948 at the data center access. However, the current Cisco Catalyst 4948

hardware is not capable of tagging an SGT to a frame and sending it to the Cisco Nexus 7000 Series Switch.

Hardware such as the Cisco Nexus 7000 Series with Cisco NX-OS supports Cisco TrustSec. Without hardware that

supports Cisco TrustSec, the Cisco TrustSec software cannot tag the packet with SGT. In such a case you can use

SXP to propagate the IP-to-SGT binding table across network devices that do not have hardware support for Cisco

TrustSec.

SXP can be established between an access-layer device and a distribution-layer switch. A SXP peer that sends IP-

to-SGT binding information to other peer is called SXP Speaker. Any device that receives the binding table and

applies it to the ingress port for tagging is called SXP listener. An access switch also sends the IP-to-SGT binding

table to the core switch using SXP.

This section discusses how to configure static IP-to-SGT mapping on the Cisco Catalyst 4948 and then send the

binding table to the Cisco Nexus 7000 Series Switch (Figure 9).



Figure 9. SXP Connection Example between Data Center Access Switch and Distribution Switch

To begin the configuration, remove the IP-to-SGT mapping CLI command on the Cisco Nexus 7000 Series. Use CLI

command shown here to remove IP-to-SGT static entries for servers.

CTS7K-DC# config t


CTS7K-DC(config)# no cts role-based sgt-map 10.1.200.100

CTS7K-DC(config)# no cts role-based sgt-map 10.1.200.200


After you remove the IP-to-SGT mapping, configure SXP on the Cisco Nexus 7000 Series. To configure SXP, you

need some information for peer establishment: the source IP address, peer IP address, SXP credential for peer

establishment, and role information. Use the entries shown here to configure the Cisco Nexus 7000 Series SXP

connection. This guide uses sxp12345 as the credential.

CTS7K-DC# config t


CTS7K-DC(config)# cts sxp enable

CTS7K-DC(config)# cts sxp connection peer 10.1.2.3 source 10.1.2.1 password required sxp12345 mode speaker


Access your Cisco Catalyst 4948 console and configure the same IP-to-SGT mapping entries.

CTS4K-DCAS#config t


CTS4K-DCAS(config)# cts role-based sgt-map host 10.1.200.100 sgt 3



CTS4K-DCAS(config)# cts role-based sgt-map host 10.1.200.200 sgt 4

CTS4K-DCAS(config)#exit

Verify your static mapping with a show command.

CTS4K-DCAS#show cts role-based sgt-map all

Active IP-SGT Bindings Information

IP Address SGT Source

============================================

10.1.200.100 3 CLI

10.1.200.200 4 CLI

IP-SGT Active Bindings Summary

============================================

Total number of CLI bindings = 2

Total number of active bindings = 2

Now you can configure SXP on the Cisco Catalyst 4948 as well. Use the entries shown here to complete the

speaker-side configuration on the Cisco Catalyst 4948.

CTS4K-DCAS#config t


CTS4K-DCAS(config)# cts sxp enable

CTS4K-DCAS(config)# cts sxp default password sxp12345

CTS4K-DCAS(config)# cts sxp connection peer 10.1.2.1 source 10.1.2.3 password default mode peer listener

CTS4K-DCAS(config)#exit

Verify your SXP connection using a show command.

CTS4K-DCAS#show cts sxp connections

SXP : Enabled

Default Password : Set

Default Source IP: Not Set

Connection retry open period: 120 secs

Reconcile period: 120 secs

Retry open timer is running

----------------------------------------------

Peer IP : 10.1.2.1

Source IP : 10.1.2.3

Conn status : On

Local mode : SXP Speaker

Connection inst# : 1

TCP conn fd : 1

TCP conn password: default SXP password

Duration since last state change: 0:00:01:10 (dd:hr:mm:sec)

Total num of SXP Connections = 1



You can also verify the connection from the Cisco Nexus 7000 Series side.

CTS7K-DC# show cts sxp connection

PEER_IP_ADDR VRF PEER_SXP_MODE SELF_SXP_MODE CONNECTION STATE

10.1.2.3 default speaker listener connected

Verify that the IP-to-SGT binding table is sent from the Cisco Catalyst 4948 to the Cisco Nexus 7000 Series Switch

and that the Cisco Nexus Series Switch learns about the binding information for policy enforcement. Use a show

command to verify the current IP-to-SGT mapping.

CTS7K-DC# show cts role-based sgt-map


10.1.50.2 2 vrf:1 Learned on interface:Ethernet3/3

10.1.200.100 3 vrf:1 Learned from SXP peer:10.1.2.3


After you configure SXP between the Cisco Catalyst 4948 and Cisco Nexus 7000 Series and verify that the

enforcement point (the Cisco Nexus 7000 Series Switch) learns the IP-to-SGT mapping through SXP, you can test

the SGACL in the same way as in previous sections. You can logon to two servers and test the communication

between the two servers with several services.

This completes the use case of Cisco TrustSec policy enforcement for the data center. It is important to complete

this section because the next section uses the same servers. The next section discusses the use case of traffic

enforcement between the campus network and data center.

Adding a Non-Seed Device to the Cisco TrustSec Doma in

This section discusses how to configure the second Cisco Nexus 7000 Series Switch which is not directly connected

to the Cisco Secure ACS Server (Figure 10). This section includes the configuration of the following Cisco TrustSec

architecture features:

● Authentication and connection of Cisco Nexus 7000 Series non-seed device using NDAC

● SAP configuration between two devices that support Cisco TrustSec

● IEEE 802.1AE encryption using a key derived from SAP



Figure 10. Connection between Seed Device and Non-Seed Device

Configuring NDAC for the Non-Seed Device

In this section, you configure NDAC for the non-seed Cisco Nexus 7000 Series device. Make sure that you have the

appropriate Cisco NX-OS version installed on the Cisco Nexus 7000 Series Switch. Also be sure that the second

Cisco Nexus 7000 Series Switches have the appropriate Advanced Services license for Cisco TrustSec installed.

Before you configure the second Cisco Nexus 7000 Series Switches, you need to configure the downlink port on the

seed device to perform IEEE 802.1X–based NDAC authentication. On the Cisco Nexus 7000 Series seed device

(CTS7K-DC) console, configure Cisco TrustSec on the downlink interface to the second Cisco Nexus 7000 Series

Switch.

CTS7K-DC# configure terminal


CTS7K-DC(config)# interface ethernet 3/3

CTS7K-DC(config-if)# cts dot1x

CTS7K-DC(config-if-cts-dot1x)# ?

no Negate a command or set its defaults

propagate-sgt Enable SGT propagation from this port(the default; use the no

form to disable)

replay-protection Enable replay-protection (the default; use the no form to

disable)

sap Specify preferred SAP negotiation parameters

end Go to exec mode



exit Exit from command interpreter

pop Pop mode from stack or restore from name

push Push current mode to stack or save it under name

where Shows the cli context you are in

You are now in the Cisco TrustSec IEEE 802.1X mode where various behaviors of the Cisco TrustSec link can be

configured. For this section, leave everything at the default settings. By default, the features listed in Table 17 are

enabled. This completes the NDAC interface configuration for the non-seed device.

Table 17. Options for cts dot1x Mode

Feature Description

propagate-sgt Enables SGT propagation on the Layer 2 Cisco TrustSec interface. 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. After using this command, you must enable and disable the interface using the shutdown and no shutdown command sequence for the configuration to take effect. By default, this feature is enabled.

Replay-protection Enables the data-path replay protection feature for Cisco TrustSec authentication on an interface. After using this command, you must enable and disable the interface using the shutdown and no shutdown command sequence for the configuration to take effect. By default, this feature is enabled.

sap modelist Configures the Cisco TrustSec SAP operation mode. The following operation modes are available:

● gcm-encrypt Galois/Counter Mode (GCM) encryption and authentication mode (default)

● gmac GCM authentication mode

● no-encap No encapsulation and no SGT insertion

● null Encapsulation without authenticator or encryption

Cisco Secure ACS also needs to be configured to receive the NDAC request from the second Cisco Nexus 7000

Series Switches. Configure the items here in the same way that you configured the Cisco TrustSec seed device

(CTS7K-DC).

Add a second Cisco Nexus 7000 Series Switches as AAA clients. Make sure that All Device Types:CTS Network

Device is selected for Network Device Group. By assigning device to same network device group called CTS

Network Device , same device SGT (Device SGT) is assigned to this device as well.



Table 18 shows the values used in this AAA client configuration for CTS7K-CORE.

Table 18. Summary of Information for AAA Client CTS7K-CORE

Configuration Value

Name CTS7K-Core

Location All Locations

Device Type CTS Network Device Group


10.1.50.2

RADIUS Checked

Shared Secret cisco123

TrustSec Checked

Use Device ID for TrustSec identification Checked

Device ID CTS7K-CORE (dimmed)

Password trustsec123

Other TrustSec Device to trust this device (CTS tru sted) Checked

Download peer authorization policy every: Days Hours Minutes Seconds 1 Day (default)

Download SGACL lists every: Days Hours Minutes Seco nds 1 Day (default)

Download environmental data every: Days Hours Minut es Seconds 1 Day (default)

Reauthentication every: Days Hours Minutes Seconds 1 Day (default)



Configuring the Non-Seed Device Cisco Nexus 7000 Se ries Switch

On the non-seed device Cisco Nexus 7000 Series console, enable Cisco TrustSec and IEEE 802.1X.

CTS7K-CORE# config t


CTS7K-CORE(config)# feature dot1x

CTS7K-CORE(config)# feature cts

CTS7K-CORE(config)# end

Next, configure the Cisco TrustSec device ID and its credential.



CTS7K-CORE(config)# cts device-id CTS7K-CORE password trustsec123

CTS7K-CORE(config)# exit

Optionally, configure the AAA group command shown here. Note that on a non-seed device, no other AAA

commands or RADIUS commands are configured. Configure use-vrf <VRF-name> only if a different VRF is used for

the AAA server group.

CTS7K-CORE(config)# aaa group server radius aaa-private-sg

CTS7K-CORE(config-radius)# use-vrf default

CTS7K-CORE(config-radius)# exit

Enabling Hop-by-Hop Layer 2 Encryption with IEEE 80 2.1AE

After successful NDAC authentication and authorization using the EAP-FAST protocol, a supplicant device and

authenticator device use EAPoL key exchange to negotiate a cipher suite, exchange security parameter indexes

(SPIs), and manage keys. In this section, you configure hop-by-hop Layer 2 encryption using technology based on

the IEEE802.1AE standard. This feature is one of the main elements of the Cisco TrustSec solution. When the user

is authenticated and authorized to access to network, Cisco TrustSec allows you to transmit the user information

confidentially. Rather than attempting to encrypt individual applications, Cisco TrustSec offers line-rate encryption

and decryption for both Gigabit Ethernet and 10 Gigabit Ethernet interfaces. Encryption is based on the IEEE

802.1AE frame format and algorithm (128-bit AES-GCM). Cisco TrustSec also uses the SAP key management and

negotiation mechanism. With SAP, authenticating devices use EAPoL key exchange to negotiate a cipher suite,

exchange SPIs, and manage keys. Successful completion of all three tasks results in the establishment of a security

association.

SAP negotiation can use any of the following modes of operation:

● GCM encryption: Both encryption and authentication are enabled. SGT insertion is enabled as well (default).

● GCM authentication: Only GCM authentication is enabled. SGT insertion is enabled as well. No encryption

is enabled.

● No encapsulation (clear text): No encapsulation is enabled. SGT insertion is disabled.

● Null: Encapsulation with no encryption or authentication is enabled. SGT insertion is enabled.

IEEE 802.1AE encryption can be established either manually or with NDAC using the EAP-FAST protocol. For the

SAP mode, make sure that both ends of the NDAC link have the same operation mode. By default, GCM encryption

mode is enabled. If the operation modes do not match, then SAP negotiation fails, and link goes down. If one end of

the link does not support SAP negotiation, the other end of the link should be configured in no encapsulation mode.



Now configure the interface to perform NDAC and IEEE802.1AE encryption for the seed Cisco Nexus 7000 Series

device.

CTS7K-DC# config t


CTS7K-DC(config)# interface Ethernet 3/15

CTS7K-DC(config-if)# cts dot1x

CTS7K-DC(config-if-cts-dot1x)# exit

You can verify the NDAC result with the command shown here.

CTS7K-CORE# show cts interface ethernet 3/15

CTS Information for Interface Ethernet3/15:

CTS is enabled, mode: CTS_MODE_DOT1X

IFC state: CTS_IFC_ST_CTS_OPEN_STATE

Authentication Status: CTS_AUTHC_SUCCESS

Peer Identity: CTS7K-DC

Peer is: CTS Capable

802.1X role: CTS_ROLE_SUP

Last Re-Authentication:

Authorization Status: CTS_AUTHZ_SUCCESS

PEER SGT: 2

Peer SGT assignment: Trusted

SAP Status: CTS_SAP_SUCCESS

Configured pairwise ciphers: GCM_ENCRYPT

Replay protection: Enabled

Replay protection mode: Strict

Selected cipher: GCM_ENCRYPT

Current receive SPI: sci:18bad853520000 an:0

Current transmit SPI: sci:18bad853460000 an:3

You can also verify the NDAC result on the seed device.

CTS7K-DC# show cts interface ethernet 3/3





Peer Identity: CTS7K-CORE


802.1X role: CTS_ROLE_AUTH



PEER SGT: 2











On CTS7K-DC (the non-seed device), make sure that your environmental data is downloaded successfully after

NDAC.

CTS7K-CORE# show cts environment-data


==============================







Last Update Time : Mon Sep 28 11:01:53 2009



On CTS7K-DC (the non-seed device), you may also want to check the status of IEEE 802.1X authentication.

CTS7K-CORE# show dot1x interface ethernet 3/15 details

Dot1x Info for Ethernet3/15

-----------------------------------

PAE = SUPPLICANT

StartPeriod = 30

AuthPeriod = 30

HeldPeriod = 60

MaxStart = 3

Dot1x Supplicant Client List

-------------------------------

Authenticator = 00:18:BA:D8:53:46

Supp SM State = AUTHENTICATED

Supp Bend SM State = IDLE

Port Status = AUTHORIZED

Adding Hardware That Does Not Support Cisco TrustSe c (Cisco Catalyst 6500 Series) to the Cisco TrustSec Domain

This section discusses how to configure the network access device in this guide, the Cisco Catalyst 6500 Series

Switch. The Cisco Catalyst 6500 Series Switch demonstrates two features in the architecture: NDAC using Cisco

IOS Software, and SXP. The Cisco Catalyst 6500 Series binds the IP address of endpoint and its SGT to build

binding table. Then the switch passes this table to the Cisco Nexus 7000 Series Switch—where the packet is tagged

with SGT in the hardware (Figure 11).



Figure 11. Topology Showing Catalyst 6500 Connecting to CTS Capable Device

Configuring NDAC on the Cisco Catalyst 6500 Series Switch

In this section, you configure the NDAC for the non-seed Cisco Catalyst 6500 Series device. Make sure that you

have the appropriate Cisco IOS Software release (Release 12.2 (33)SXI or higher is recommended) installed on the

Cisco Catalyst 6500 Series Switch with Supervisor Engine 720 or 32 or VSS 720.

Before proceeding to the Cisco Catalyst 6500 Series configuration for Cisco TrustSec, you need to configure the

downlink port on the authenticator device, the Cisco Nexus 7000 Series Switch, to perform IEEE 802.1X

authentication for Cisco TrustSec. On the Cisco Nexus 7000 Series non-seed device (CTS7K-CORE) console,

configure Cisco TrustSec on the downlink interface to the Cisco Catalyst 6500 Series Switch. In the cts

dot1xconfiguration mode, set the SAP mode to no encapsulation using sap modelist no-encap , because currently

the Cisco Catalyst 6500 Series does not support IEEE 802.1AE encryption, SGT tagging (Cisco metadata insertion),

or SAP negotiation.



CTS7K-CORE(config)# interface Ethernet 3/13

CTS7K-CORE(config-if)# cts dot1x

CTS7K-CORE(config-if-cts-dot1x)# sap modelist no-encap

CTS7K-CORE(config-if-cts-dot1x)# no propagate-sgt

CTS7K-CORE(config-if-cts-dot1x)# exit

Note that since the Cisco Catalyst 6500 Series currently does not support hardware encryption, SAP operation mode

needs to be configured as no-encap , so that it performs encapsulation without authentication or encryption. Also



make sure that the non-seed Cisco Nexus 7000 Series device has downloaded environmental data successfully.

Use show cts environment-data to verify.

CTS7K-CORE# show run interface ethernet 3/13


cts dot1x

no propagate-sgt

sap modelist no-encap

switchport



switchport trunk allowed vlan 3,10,99

no shutdown

CTS7K-CORE# show cts environment-data


==============================







Last Update Time : Tue Sep 29 11:01:52 2009



Adding the Cisco Catalyst 6500 Series Switch as an AAA Client

Cisco Secure ACS also needs to be configured to receive NDAC requests from the Cisco Catalyst 6500 Series

device. Configure the AAA client in the same way that you configured the other non-seed device (CTS7K-DC) except

this time enable the RADIUS authentication option. This option is needed because the Cisco Catalyst 6500 Series is

used to authenticate the connecting endpoint device, and the RADIUS authentication option is required to

authenticate the endpoint IEEE 802.1X supplicant. Make sure that CTS6K-AS is assigned to the All Device Types:

CTS Network Device device type as shown here.



Table 19 shows all the settings.

Table 19. Summary Information of AAA Client Configuration for CTS6K-AS

Configuration Value

Name CTS6K-AS

Location All Locations

Device Type CTS Network Device Group


10.1.3.2

RADIUS Checked

Shared Secrets cisco123

TrustSec Checked

Use Device ID for TrustSec identification Unchecked

Device ID CAT6K-AS (dimmed)

Password trustsec123

Other TrustSec Device to trust this device (CTS tru sted) Checked

Download peer authorization policy every: Days Hours Minutes Seconds 1 Day (default)

Download SGACL lists every: Days Hours Minutes Seco nds 1 Day (default)

Download environmental data every: Days Hours Minut es Seconds 1 Day (default)

Reauthentication every: Days Hours Minutes Seconds 1 Day (default)

Configuring the Non-Seed Device Cisco Catalyst 6500 Series Switch

First configure the device ID for this Cisco Catalyst 6500 Series Switch. Note that the device ID is configured in

privileged mode, not in configuration mode.



CTS6K-AS#cts credentials id CTS6K-AS password trustsec123

CTS device ID and password have been inserted in the local keystore. Please make sure that the same ID and password are configured in the server database.

Next configure AAA on the Cisco Catalyst 6500 Series Switch. As described before, this Cisco Catalyst 6500 Series

Switch is connected to the endpoint device to authenticate the endpoint using the IEEE 802.1X protocol. Unlike for

the other non-seed device, here you configure AAA, RADIUS, and IEEE 802.1X as you configure normal IEEE

802.1X authentication.

Use the commands shown here to enable AAA for IEEE 802.1X authentication on the Cisco Catalyst 6500 Series.

CTS6K-AS#config t


CTS6K-AS(config)# aaa new-model

CTS6K-AS(config)# aaa authentication dot1x default group radius

CTS6K-AS(config)# aaa authorization network default group radius

CTS6K-AS(config)# aaa accounting dot1x default start-stop group radius

CTS6K-AS(config)# exit

Use the commands shown here to define the RADIUS server and vendor-specific attribute (VSA) characteristics. The

radius-server vsa send authentication command enables the switch to recognize and use VSA as defined by

RADIUS ITEM attribute 26.

CTS6K-AS#config t


CTS6K-AS(config)# radius-server host 10.1.100.3 auth-port 1812 acct-port 1813 pac key cisco123

CTS6K-AS(config)# radius-server vsa send authentication


Use the commands shown here to enable IEEE 802.1X authentication globally.

CTS6K-AS#config t


CTS6K-AS(config)# dot1x system-auth-control


Finally, configure the uplink interface to the Cisco Nexus 7000 Series to perform NDAC authentication.

CTS6K-AS#config t


CTS6K-AS(config)# int gigabitEthernet 1/2

CTS6K-AS(config-if)#

CTS6K-AS(config-if)# cts dot1x

You can verify the general Cisco TrustSec function status and statistics using a show command.

CTS6K-AS#show cts

Global Dot1x feature: Enabled

CTS device identity: "CTS6K-AS"

CTS caching support: disabled

Number of CTS interfaces in DOT1X mode: 1



Number of CTS interfaces in corresponding IFC state

INIT state: 0

AUTHENTICATING state: 0

AUTHORIZING state: 0

SAP_NEGOTIATING state: 0

OPEN state: 1

HELD state: 0

DISCONNECTING state: 0

CTS events statistics:

authentication success: 15

authentication reject : 8

authentication failure: 9

authentication logoff : 0

authentication no resp: 0

authorization success : 18

authorization failure : 0

sap success : 0

sap failure : 0

port auth failure : 0

You can use show cts pac to verify whether PAC information is provisioned to the Cisco Catalyst 6500 Series. I-ID-

Info contains the unique Cisco Secure ACS server name defined on the Cisco Secure ACS web console.

CTS6K-AS#show cts pacs

AID: 517822AEA6BB11DE8000D4EF073797EA

PAC-Info:

PAC-type = Cisco Trustsec

AID: 517822AEA6BB11DE8000D4EF073797EA

I-ID: CTS6K-AS

A-ID-Info: CTS ACS 1

Credential Lifetime: 15:34:45 PDT Oct 6 2009

PAC-Opaque: 000200B00003000100040010517822AEA6BB11DE8000D4EF073797EA000600940003010014175EBA01FA76CE7FB23C4A3EFD73A1000000014AC18DB700093A809CF7CA19D8BDBF0F14495B98FCF1B3D4F7B9E24D220C7B508983042708783B67AE1379F727ABD9066DD49312BEE9D77A763118263168B2B511C950678AC2D9F5751B072A5F5E5BE2F2228EB08BAA72ED06E0F469E71FC6655AC6FB9855C0F5A326EE524311D1F248A729AC386BD0796A36D0EFCF

Refresh timer is set for 5d23h

Use the show cts interface command to see the Cisco TrustSec link status on the connection to the Cisco Nexus

7000 Series Switch.

CTS6K-AS#show cts interface gigabitEthernet 1/2

Global Dot1x feature is Enabled

Interface GigabitEthernet1/2:

CTS is enabled, mode: DOT1X

IFC state: OPEN

Authentication Status: SUCCEEDED

Peer identity: "CTS7K-CORE"

Peer's advertised capabilities: "sap"



802.1X role: Supplicant

Reauth period applied to link: Not applicable to Supplicant role

Authorization Status: SUCCEEDED

Peer SGT: 2


Cache Info:

Expiration : 15:35:52 PDT Sep 30 2009

Cache applied to link : NONE

Statistics:

authc success: 1

authc reject: 1

authc failure: 0

authc no response: 0

authc logoff: 0

authz success: 1

authz fail: 0

port auth fail: 0

Dot1x Info for GigabitEthernet1/2

-----------------------------------

PAE = SUPPLICANT

StartPeriod = 30

AuthPeriod = 30

HeldPeriod = 60

MaxStart = 3

Credentials profile = CTS-ID-profile

EAP profile = CTS-EAP-profile

Make sure that your environment data is downloaded to the Cisco Catalyst 6500 Series Switch as a result of NDAC.

Note: Cisco TrustSec environment data is downloaded upon NDAC completion. Although authentication and

authorization brings up the linkstate, the nonseed device still needs to have a route to the Cisco Secure ACS server.

When the output of show cts environment-data shows that your download failed, check your IP connectivity from

this device to the Cisco Secure ACS server.

The show dot1x interface command is useful for determining the authentication status. Notice that the credential and

EAP profiles are now Cisco TrustSec profiles.

CTS6K-AS#show dot1x interface gigabitEthernet 1/2 details

Dot1x Info for GigabitEthernet1/2

-----------------------------------

PAE = SUPPLICANT

StartPeriod = 30

AuthPeriod = 30

HeldPeriod = 60

MaxStart = 3

Credentials profile = CTS-ID-profile

EAP profile = CTS-EAP-profile

Dot1x Supplicant Client List



-------------------------------

Authenticator = 0018.bad8.5350

Supp SM State = AUTHENTICATED

Supp Bend SM State = IDLE


Here are the results of the show cts interface command on the authenticator role device (CTS7K-DC).

CTS7K-CORE# show cts interface ethernet 3/15





Peer Identity: CTS7K-DC


802.1X role: CTS_ROLE_SUP



PEER SGT: 2









Configuring the Authenticator (Cisco Nexus 7000 Ser ies) and Supplicant (Cisco Catalyst 6500 Series) fo r

SXP Connection

This section describes how to configure SXP between the authenticator (Cisco Nexus 7000 Series downlink) and

supplicant (Cisco Catalyst 6500 Series uplink). The configuration steps are exactly same as those in the previous

section for the Cisco Catalyst 4948 and Cisco Nexus 7000 Series.

Configuring SXP on the Cisco Nexus 7000 Series with Cisco NX-OS

Enter the CLI commands shown here on the Cisco Nexus 7000 Series (CTS7K-CORE) to set up the SXP

connection.

First enable the SXP feature.



CTS7K-CORE(config)# cts sxp enable

SXP requires connection to the other network peer. To establish connectivity in the control plane, each device needs

to authenticate others using a password. Use the command shown here to define the other end of the peer for SXP.



CTS7K-CORE(config)# cts sxp connection peer 10.1.3.2 source 10.1.3.1 password required 7 vtt12345 mode speaker



CTS7K-CORE(config)# exit

Configuring SXP on the Cisco Catalyst 6500 Series w ith Cisco IOS Software

Enter the CLI commands shown here on the Cisco Catalyst 6500 Series (CTS6K-AS) to setup the SXP connection

and enable the SXP feature.

CTS6K-AS# config t


CTS6K-AS(config)# cts sxp enable

CTS6K-AS(config)# cts sxp default password sxp12345

CTS6K-AS(config)# cts sxp connection peer 10.1.3.1 source 10.1.3.2 password default mode peer listener

Verifying the SXP Connection on Both Devices

Use the CLI commands shown here to verify SXP connection establishment on both the Cisco Catalyst 6500 Series

and Cisco Nexus 7000 Series.

CTS6K-AS#show cts sxp connections

SXP : Enabled

Default Password : Set

Default Source IP: Not Set

Connection retry open period: 120 secs

Reconcile period: 120 secs

Retry open timer is not running

----------------------------------------------

Peer IP : 10.1.3.1

Source IP : 10.1.3.2

Conn status : On

Local mode : SXP Speaker

Connection inst# : 1

TCP conn fd : 1

TCP conn password: default SXP password

Duration since last state change: 5:03:23:49 (dd:hr:mm:sec)

Total num of SXP Connections = 1

CTS7K-CORE# show cts sxp connection

PEER_IP_ADDR VRF PEER_SXP_MODE SELF_SXP_MODE CONNECTION STATE

10.1.3.2 default speaker listener connected

To learn the endpoint IP address for a user authentication or MAC authentication bypass session, configure the IP

device tracking feature and DHCP snooping (optional). Use the commands shown here to enable IP device tracking

and DHCP snooping on the VLAN connected to the endpoint device. In this example, VLAN 10 is a port VLAN to

which the endpoint device will be connecting for IEEE 802.1X authentication.

CTS6K-AS# config t


CTS6K-AS(config)# ip device tracking

CTS6K-AS(config)# ip dhcp snooping



CTS6K-AS(config)# ip dhcp snooping vlan 10,99

CTS6K-AS(config)# interface GigabitEthernet 1/2

CTS6K-AS(config-if)# ip dhcp snooping trust

Now you are ready to perform IEEE 802.1X authentication to actually assign a SGT value to a particular role.

Assigning SGT Using IEEE 802.1X User Authentication

A previous section discussed SGT assignment for network entities such as application servers in the data center.

This section discusses how to assign SGT to traffic coming from endpoints such as PCs. As discussed, there are

three ways of assigning SGTs dynamically to the endpoint device; the SGT can be assigned through authorization in

IEEE 802.1X authentication, MAC authentication bypass, and web authentication bypass. The following diagram

shows how SGT value is assigned to endpoint upon successful authorization.

Figure 12. Flow and Process of SGT Assignment to Endpoint

In this guide, a Cisco Catalyst 6500 Series Switch is used as the access layer switch, which provides IEEE 802.1X

authentication service to the end user. Cisco TrustSec is an infrastructure-based security technology and has no

dependency on the type of supplicant agent running on an endpoint device. This guide uses a Cisco Secure

Services Client (supplicant) on Microsoft Windows XP to perform IEEE 802.1X authentication.

Note: Although Cisco Secure Services Client is used in this guide, you can use your choice of supplicant,

including a Microsoft Windows native supplicant such as Wireless Zero Configuration in Microsoft Windows XP.



Table 20 lists usernames and the associated groups. Microsoft Active Directory is also used as an external user data

store that Cisco Secure ACS queries.

Table 20. User Credential and Group Information in Active Directory

Username Password Group

tradmin cisco123 HR Admin Group

Itadmin cisco123 IT Admin Group

Configuring the Cisco Catalyst 6500 Series with Cis co IOS Software for IEEE 802.1X User Authentication

In this section, you configure the Cisco Catalyst 6500 Series with Cisco IOS Software to perform IEEE 802.1X port-

based user authentication. First, you configure AAA for IEEE 802.1X authentication. Configure the Cisco Catalyst

6500 Series as shown here.

CTS6K-AS#config t


CTS6K-AS(config)# aaa authentication dot1x default group radius

CTS6K-AS(config)# aaa authorization network default group radius

CTS6K-AS(config)# aaa accounting dot1x default start-stop group radius

You configured RADIUS server in a previous section. Make sure that you have command shown here configured.

CTS6K-AS#show run | inc radius-server

radius-server host 10.1.100.3 auth-port 1812 acct-port 1813 key cisco123

radius-server vsa send authentication

You also enabled IEEE 802.1X globally on the system in a previous section. Make sure that you have command

shown here configured.

CTS6K-AS#show run | inc system-auth-control

dot1x system-auth-control

Now configure the interface to which the endpoint is going to connect. First enter the command shown here to verify

that the current interface commands have been configured in advance. You should have your VLAN set to VLAN 10

and your port mode set to mode access .

CTS6K-AS#show run int fastEthernet 2/1

Building configuration...

Current configuration : 365 bytes

!

interface FastEthernet2/1

switchport

switchport access vlan 10

switchport mode access

spanning-tree portfast edge

end

Enable the authentication control on the port Fast Ethernet 2/1 using the authentication port-control auto

command.

CTS6K-AS(config-if)# authentication port-control auto



Enable IEEE 802.1X authentication on a port.

CTS6K-AS(config-if)# dot1x pae authenticator

Enable reauthentication for IEEE 802.1X if needed.

CTS6K-AS(config-if)# authentication periodic

Optionally, configure authentication control to overwrite the reauthentication timer value if it is sent from the AAA

server.

CTS6K-AS(config-if)# authentication timer reauthenticate server

Finally, you need to enable the multiauthentication feature to authenticate multiple MAC addresses coming into the

IEEE 802.1X-enabled port. This feature may not be required in other lab environments, but it is needed here

because the Microsoft Windows XP client is running in the VMware ESX server environment and the virtual interface

of the Microsoft Windows XP image needs to be bridged to the physical network interface card. In this case, there

are two MAC addresses: one for the guest virtual machine image, and other for the actual physical network interface

card.

CTS6K-AS(config-if)# authentication host-mode multi-auth

This completes the configuration on the Cisco Catalyst 6500 Series Switch. Next you configure the Cisco Secure

ACS server for IEEE 802.1X user authentication.

Configuring the Cisco Secure ACS Server for IEEE 80 2.1X User Authentication

You configure the Cisco Secure ACS server to perform IEEE 802.1X authentication as well as SGT assignment upon

successful user authentication. First create unique SGTs for the HR Administrator and IT Administrator roles.

Choose Policy Elements > Authorization and Permissions > N etwork Access > Security Group and then create

two SGTs named HR Administrator and IT Administrator .



Next, create the access service for IEEE 802.1X user authentication. Choose Access Policies > Access Services

and then click the Create button. In the Name field, enter IEEE 802.1X for this access service.

Under Access Service Policy Structure , select Based on service template and then click the Select button.

Choose Network Access – Simple and then click OK.

Click Next to move to the Allowed Protocols page. Leave everything at the default settings and click the Finish

button to finish creating the access service. After you click Finish , you will probably see the message shown here.

Click No and close this window for now.

Note: By default, the Network Access – Simple template enables Protectect EAP (PEAP) (MSCHAPv2 or EAP-

GTC) or EAP-FAST (MSCHAPv2). If you are using a different EAP method, choose the appropriate method. You can

always come back to this menu in your access service and change the EAP type and inner authentication method.

Now configure the remaining policy rules for this access service. Choose Access Policies > Access Service . In the

main window, you will see the entry IEEE 802.1X or (your access service). Click the Identity link to configure the

identity source for this access service. Select Single result selection . For the Identity Source field, click the Select

button and choose AD1, your Microsoft Active Directory server. Click the Save Changes button to finish identity

source selection.



On Menu: Access Policies > Access Service > IEEE802.1X , click the Authorization link. On the Authorization

page, click the Customize button. In the Customize Conditions section, click the << button to move currently

selected items to the Available list on the left. Select AD1:External Groups and click the >> button to move the

item to the Selected box. In the Customize Results section, click the > button to move Security Group in the

Available box to the Selected box. Click OK to continue.

Now you are back to the Authorization page of the Access Service section again. Click the Create button to create

your condition statement to map a role to a specific SGT. Examples of the conditions creation pages for both user

roles, HR Administrator and IT Administrator, are shown here, with the settings summarized in Tables 21 and 22.



Table 21. Value of Authorization Policy for HR Admin Group

Configuration Value

Name HR Admin Group

Status Enabled

Conditions AD1:ExternalGroups

Operant contains any

Value cts.local/Users/HR Admin Group

Authorization Profiles Permit Access

Security Group HR Administrator

Table 22. Value of Authorization Policy for IT Admin Group

Configuration Value

Name IT Admin Group

Status Enabled

Conditions AD1:ExternalGroups

Operant contains any

Value cts.local/Users/IT Admin Group

Authorization Profiles Permit Access

Security Group IT Administrator

Following is a sample authorization page for an access service.

After configuring authorization for the access service, select this access service on the Service Selection page.

Choose Access Policies > Service Selection . Select Single result selection and choose IEEE 802.1X or your

access service from the pull-down menu. After selecting this service, click Save Changes and complete the

configuration.



Testing IEEE 802.1X User Authentication on the Clie nt

After configuring Cisco Secure ACS to assign the SGTs, you need to verify whether this SGT assignment is working

properly. You can easily test this by performing IEEE 802.1X user authentication on the client side with multiple user

credentials.

First logon to the Microsoft Windows XP machine using the domain administrator credential (the username is

hradmin and the password is cisco123 , or whatever password you configured on Microsoft Active Directory). After

you are logged onto the desktop, double-click the Ethernet icon in the system tray. This brings up the Cisco Secure

Services Client interface.

First use the HR Admin credential (username hradmin and password cisco123 ) to access to the network. After you

enter the correct credentials, IEEE 802.1X user authentication starts and succeeds with the message shown here on

the Cisco Catalyst 6500 Series Switch.

.Sep 30 16:50:17.687: %DOT1X-5-SUCCESS: Authentication successful for client (0014.5e42.9ec3) on Interface Fa2/1

.Sep 30 16:50:17.687: %AUTHMGR-7-RESULT: Authentication result 'success' from 'dot1x' for client (0014.5e42.9ec3) on Interface Fa2/1

.Sep 30 16:50:18.187: %AUTHMGR-5-SUCCESS: Authorization succeeded for client (0014.5e42.9ec3) on Interface Fa2/1



You can see the IEEE 802.1X authentication and authorization status using a show command.

CTS6K-AS#show authentication int FastEthernet 2/1

Client list:

Interface MAC Address Method Domain Status Session ID

Fa2/1 0014.5e42.9ec3 dot1x DATA Authz Success 0A010A01000019AD7DF9F334

Available methods list:

Handle Priority Name

3 0 dot1x

Runnable methods list:

Handle Priority Name

3 0 dot1x

Use the show dot1x interface command to see more details about IEEE 802.1X port status and settings.

CTS6K-AS#show dot1x interface FastEthernet 2/1 details

Dot1x Info for FastEthernet2/1

-----------------------------------

PAE = AUTHENTICATOR

PortControl = AUTO

ControlDirection = Both

HostMode = SINGLE_HOST

QuietPeriod = 60

ServerTimeout = 0

SuppTimeout = 30

ReAuthMax = 2

MaxReq = 2

TxPeriod = 12

Dot1x Authenticator Client List

-------------------------------

Supplicant = 0014.5e42.9ec3

Session ID = 0A010A01000019AD7DF9F334

Auth SM State = AUTHENTICATED

Auth BEND SM State = IDLE


In this guide, Cisco Secure ACS was configured to assign a specific SGT named HR Administrator (6/0006) for

successful authorization of the HR Administrator role. You can verify the value of SGT that is assigned to the

particular role after IEEE 802.1X authentication. Use the command shown here to verify the SGT value.

CTS6K-AS#show cts role-based sgt-map all



============================================

10.1.3.2 2 INTERNAL

10.1.10.100 6 LOCAL




============================================

Total number of LOCAL bindings = 1

Total number of INTERNAL bindings = 2


Now go back to your Cisco Secure Services Client interface in Microsoft Windows XP and repeat the authentication

with the IT Administrator credentials (username itadmin and password cisco123 ). You can reinitiate the

authentication by highlighting the connection name 802.1X Access and then clicking the Connect button in the

Cisco Secure Services Client interface. After authentication succeeds, verify the SGT value for IT Administrator by

entering the same show command as before. IT Administrator should be assigned to SGT 5 (5/0005).




============================================

10.1.3.2 2 INTERNAL

10.1.10.100 5 LOCAL

172.19.124.155 2 INTERNAL


============================================


Total number of INTERNAL bindings = 2


It is always good idea to verify that the SGT values are correctly bound and sent to other peers of the SXP

connection. A device that supports Cisco TrustSec such as the Cisco Nexus 7000 Series tags SGTs based on the

information sent over the SXP connection. Logon to your Cisco Nexus 7000 Series console and enter the show

command shown here to verify that the IP-to-SGT binding table has been correctly sent over SXP.

CTS7K-CORE# show cts role-based sgt-map


10.1.3.2 2 vlan:3 Learned on interface:Ethernet3/13






10.1.50.1 2 vrf:1 Learned on interface:Ethernet3/15

As you can see, the endpoint IP 10.1.10.100 and SGT 5 binding is correctly inserted in the SGT mapping table on

the Cisco Nexus 7000 Series Switch through the SXP peer 10.1.3.2, which is the Cisco Catalyst 6500 Series Switch.

You have used some show commands to verify successful IEEE 802.1X authentication and IP-to-SGT mapping on

both the Cisco Nexus 7000 Series and Cisco Catalyst 6500 Series Switches. You can also check whether the

authentication process is successful in the Cisco Secure ACS log. To do so, you return to your Cisco Secure ACS

web console and check the log of your last authentication session.



Logon to your Cisco Secure ACS console again and choose Monitoring and Reports > Launch Monitoring and

Report Viewer . Another browser window appears. This new screen, called Monitoring and Reports , provides

report and troubleshooting functions. Look at all the logs generated by Cisco Secure ACS in this console. In this new

screen, choose Dashboard and click the Troubleshooting tab. You should see the Live Authentications logs in

the left pane. The Live Authentications log shown here shows all the RADIUS transactions in real time (with a 10-

second refresh delay). This live log should help you to observe what is happening in your network in real time.

The Dashboard Live Authentications log gives you a lot of information without clicking any field. Just hover your

mouse cursor over an item for your session. For instance, in the sample log, the information shown here appears if

you move your mouse cursor over the failure reason for an hradmin failed authentication session.

The screen displays a full description of the failure reason. It also provides a possible resolution for this failure.

Now move your mouse cursor over the NAD IP address 10.1.3.2. More detail information about this network access

device is displayed. With this information, you now know where HR administrator is located (based on the NAS IP

address) and the port to which the HR administrator connects (based on the NAS port ID). This message also allows

the administrator to obtain more port information by querying the network access device using the Simple Network

Management Protocol (SNMP).



As soon as you click the SNMP Query to NAD link, you go to the Network Device > Session Status Summary

page. This page provides detailed information about the network access device, including platform information,

running software, location of the device (if available), and a contact for this device (if available).

In addition, this page provides detailed information about the authentication session. From the information shown in

the sample screen, you can see the following:

● There is a client with MAC address 00:14:5e:42:9e:c3.

● Username hradmin authenticated successfully with session ID0A010A01000019DD8F459254.

● The port to which this user is connected is configured to perform flexible authentication with an authorization

order of dot1x, mab, and webauth.

● This port is configured as single host mode for IEEE 802.1X.

You can obtain this type of data without physically accessing the network access device.

Now go back to the Live Authentications log and click the MAC address of the device. You will see an historical

report for the past 30 days for the particular host with a MAC address of 00-14-5E-42-9E-C3. Most Recent

Authentication shows the log of the last access of the endpoint with this particular MAC address. You’ll see that

username hradmin has been using this endpoint.

If you click Authentication By Username , you’ll see the last n number of usernames that used this endpoint. This

powerful log can reveal any misuse of the endpoint by some other person. If you click any username from this page,

Cisco Secure ACS generates the same report page based on the username.



This page also has a link called Active Sessions . This link brings you to the RADIUS Active Sessions report page,

which tells you if there is any active user session for a particular username.

Now, again return to the Live Authentications log. Find the authentication session for any failed authentication.

Click the Details ( ) icon for this session, and another report window appears. The RADIUS Authentication

Detail page for this failed session provides additional detailed information.

Toward the bottom of the screen are collapsed menus for Authentication Details and Steps . Authentication

Details shows all the detailed information about this RADIUS transaction, including all the RADIUS attributes passed

between the network access device and the Cisco Secure ACS server. Steps shows the step-by-step RADIUS



transaction process, including the authorization decision result. Any error or failure log is colored red for easy

troubleshooting of the authentication. The following screen shows a sample Steps display.

Enforcing Policy with SGACLs

This guide has provided configurations to assign unique SGTs to all network entities, including network devices,

application servers, and endpoint devices (user role). On the basis of these unique tags, you now can control traffic

from the user endpoint to the server in the data center. Just as you tested the data center scenario, you will now

create an SGACL for each user role and control traffic between the user and server using those SGACLs (Figure

13).



Figure 13. Traffic Flow and SGACL Enforcement in Campus to Data Center Use Case

So far, you have configured the network entities and assigned unique SGTs as shown in Table 23.

Table 23. User Role and SGT Values

Entities SGT (Decimal and Hexadecimal)

IT Administrator role 5/0005

HR Administrator role 6/0006

IT Server role 4/0004

HR Server role 3/0003

You will now configure the SGACLs for IT Admin and HR Admin. Return to your Cisco Secure ACS Web console.

First configure the content of the SGACL. Choose Policy Elements > Authorization and Permissions > N amed

Permission Objects > Security Group ACLs . On this page, simply click the Create button. Create the SGACL

content as shown here. Again, the name of the SGACL cannot include spaces, hyphens (-), question marks (?), or

exclamation marks (!).



After the SGACL is created, its generation ID appears. This generation ID is used to track changes in the name or

contents of the SGACL. When you modify the name or contents of an SGACL, Cisco Secure ACS updates its

generation ID. When the generation ID of an SGACL changes, the relevant Cisco TrustSec network devices reload

the content of the SGACL (Table 24).

Table 24. SGACL Policies for User Roles

Name Security Group ACL Content

IT_Admin_Only permit tcp dst eq 20





permit icmp

deny ip

Permit_Web_Only permit tcp dst eq 80


permit icmp

deny ip



The following access control entry syntax is supported by the Cisco Nexus 7000 Series with Cisco NX-OS 4.2.

deny all

deny icmp

deny igmp

deny ip

deny tcp [{dest|src} {{eq | gt | lt | neq} port-number | range port-number1 portnumber 2}]

deny udp [{dest|src} {{eq | gt | lt | neq} port-number | range port-number1 portnumber 2}]

permit all

permit icmp

permit igmp

permit ip

permit tcp [{dest|src} {{eq | gt | lt | neq} port-number | range port-number1 portnumber 2}]

permit udp [{dest|src} {{eq | gt | lt | neq} port-number | range port-number1 portnumber 2}]

Now choose Access Policies >TrustSec Access Control >Egress Po licy . You configured policy earlier for the

data center use case; now you are going to configure the policy matrix for user roles and server connection.

The HR Administrator role should have access to the HR Servers for web service. Choose the Permit_Web_Only

SGACL for the cell with HR Administrator as the source and HR Servers as the destination. Deny all the packets

from HR Administrator to IT Servers.

The IT Administrator role should have access to HR Servers for maintenance purposes only. Choose the

IT_Admin_Only SGACL for the cell with IT Administrator as the source and HR Servers as the destination. Permit

all the traffic from IT Administrator to IT Servers.

Now return to the seed Cisco Nexus 7000 Series Switch (CTS7K-DC), where the SGACL is enforced. First, you will

enable SGACL (RBACL) enforcement on the seed Cisco Nexus 7000 Series Switch. Entering cts role-based

enforcement at the CLI enables enforcement on the switch. You can enable enforcement for a specific VRF and

VLAN. You should enable both the VRF and VLAN if the traffic is routed through a Layer 3 interface (SVI) and is

going to an individual VLAN.



CTS7K-DC# config t


CTS7K-DC(config)# cts role-based enforcement


CTS7K-DC(config-vlan)# cts role-based enforcement



CTS7K-DC(config-vlan)# cts role-based enforcement

You can verify which VRF and VLAN are enabled for enforcement by entering the show command shown here.

CTS7K-DC# show cts role-based enable

vlan:200

vlan:999

vrf:1

Now SGACLs configured on Cisco Secure ACS will not be downloaded automatically upon enforcement. Instead,

they are downloaded either manually after a refresh command, or upon policy timer expiration. In this guide, you will

download the policy manually. Enter the command shown here to download the currently available SGACL on the

Cisco Secure ACS.

CTS7K-DC# cts refresh role-based-policy

Verify that the SGACL access control entry downloaded to the local system by entering the command shown here.

CTS7K-DC# show cts role-based access-list

rbacl:Deny IP

deny ip

rbacl:Deny_All




permit icmp

deny ip

rbacl:IT_Admin_Only






permit icmp

deny ip

rbacl:Permit IP

permit ip

rbacl:Permit_IT_Services




permit icmp

deny ip

rbacl:Permit_Web_Only





permit icmp

deny ip

Finally, verify the SGT-to-SGACL mapping, using the show cts role-based policy command. The output of this

command should be exactly what is configured in the egress policy matrix on the Cisco Secure ACS server.

CTS7K-DC# show cts role-based policy

sgt:3

dgt:4 rbacl:Deny_All




permit icmp

deny ip

sgt:4

dgt:3 rbacl:Permit_IT_Services




permit icmp

deny ip

sgt:5

dgt:3 rbacl:IT_Admin_Only






permit icmp

deny ip

sgt:5

dgt:4 rbacl:Permit IP

permit ip

sgt:6

dgt:3 rbacl:Permit_Web_Only



permit icmp

deny ip

sgt:6

dgt:4 rbacl:Deny IP

deny ip



sgt:any

dgt:any rbacl:Permit IP

permit ip

You are now ready to test the SGACL access control from the client machine to both HR Servers and IT Server. To

verify the access control enforcement, use the command show system internal access-list output statistics

module <MOD#> as discussed in the data center use case.

This completes the Cisco TrustSec configuration. Your Cisco TrustSec environment does not have to be exactly the

same as the one discussed in this guide, and a different implementation in your environment is expected. It is highly

recommended that you use the predefined test cases according to your network environment.



Appendix

This appendix presents some additional configuration information related to Cisco TrustSec:

● How TrustSec features co-exist with basic identity features on Catalyst Switches

● How to configure NDAC and IEEE 802.1AE encryption using a single Cisco Nexus 7000 Series Switch with

multiple VDCs

● Sample configuration

How TrustSec Features Work with Existing Cisco Iden tity Features on Catalyst Switches

As discussed throughout this guide, every endpoint is authenticated to have SGT assigned. The authentication is

based on 802.1X Authentication, MAC Address Authentication Bypass (MAB), or Web Authentication. In this section,

we are going to discuss how SGT assignment process (as known as Endpoint Admission Control) works with

existing 802.1X and associated features.

First it is very important to note that SGT is dynamically assigned via RADIUS VSA (using Cisco VSA) in 802.1X,

MAB, Web-Auth authorization process unless SGT is mapped to IP addresses statically. When an endpoint is

successfully authenticated, SGT value is returned to switch in RADIUS access-accept packet. Switch first binds SGT

value to endpoint MAC address. ARP snooping functionality found in IP Device Tracking feature then determines

assigned IP Address to a MAC address. Switch now has a binding table for SGT value, MAC Address, and IP

Address.

SGT and Other Authorization Methods

SGT assignment process can be coupled with other authorization methods such as dynamic VLAN assignment or

downloadable ACL. For instance, we can download a set of ACE to a particular endpoint and assign SGT at same

time. In this case, ingress switch does enforcement using downloaded ACL and egress switch can still perform

SGACL based on SGT value assigned in EAC process.

SGT and Host Mode

For 802.1X authentication, SGT assignment is supported on most of the host modes. For instance, if multiple

endpoints are connected to single interface and also multi-auth host mode is enabled, we can assign different SGT

value per MAC address authenticated on that port. Same concept applies to MAC Authentication Bypass or Web

Authentication method.

Following is a sample example of multi-auth host mode.

interface GigabitEthernet1/0/2



switchport voice vlan 99

authentication host-mode multi-auth

authentication port-control auto

authentication periodic

authentication timer reauthenticate server

mab

dot1x pae authenticator

dot1x timeout tx-period 12

spanning-tree portfast

end



In order to verify multiple endpoints are authenticated using multi-auth host mode, use show authenticate interface

<interface_name>.

CTS3K-AS#show auth int gi1/0/2

Client list:

Interface MAC Address Method Domain Status Session ID

Gi1/0/2 0050.56b2.5968 dot1x DATA Authz Success 0A0131020000001502F894EE

Gi1/0/2 000c.2953.7108 dot1x DATA Authz Success 0A0131020000001702F89A2C

Gi1/0/2 0050.56b2.3392 dot1x DATA Authz Success 0A0131020000001802F89A2C

Gi1/0/2 0000.0000.2efa mab DATA Authz Success 0A0131020000001902F9FA1A

Gi1/0/2 0050.56b2.2efa dot1x DATA Authz Success 0A0131020000001B02FA5321

Now ARP snooping binding table shows IP address and MAC address bindings. Use show ip device tracking

interface <interface_name>.

CTS3K-AS#show ip device tracking interface GigabitEthernet1/0/2

IP Device Tracking = Enabled

IP Device Tracking Probe Count = 3

IP Device Tracking Probe Interval = 30

---------------------------------------------------------------------

IP Address MAC Address Vlan Interface STATE

---------------------------------------------------------------------

10.1.10.103 0050.56b2.3392 10 GigabitEthernet1/0/2 ACTIVE

10.1.10.105 0050.56b2.2efa 10 GigabitEthernet1/0/2 ACTIVE

10.1.10.104 0050.56b2.5968 10 GigabitEthernet1/0/2 ACTIVE

10.1.10.106 000c.2953.7108 10 GigabitEthernet1/0/2 ACTIVE

Finally you can determine SGT value and IP address bindings using show cts role-based sgt-map all.




============================================

10.1.10.102 15 LOCAL

10.1.10.103 7 LOCAL

10.1.10.104 5 LOCAL

10.1.10.105 15 LOCAL

10.1.10.106 5 LOCAL

10.1.10.110 14 LOCAL


============================================





As long as authentication is performed for endpoint, SGT can be assigned via RADIUS VSA. If there is no

authentication is involved, then no SGT is assigned. For instance, multi-host mode authenticates the first endpoint

connecting to an interface. Once this endpoint is authenticated, other endpoints connecting to same interface can

access to network without any authentication process. In this case, the first endpoint will receive SGT value.

However other endpoints connecting to same interface are not authenticated. Therefore those endpoints are not

assigned to SGT value. When no SGT value is assigned to endpoint, the traffic coming from this type of host is

considered as “unknown”. Any policy for Unknown source SGT is applied at egress enforcement point.

In case interface is configured with Multi-domain host mode, SGT can be assigned to each endpoint in both Voice

and Data domain.

SGT and Locally Assigned VLAN

There are features to assign locally defined VLAN to provide least network access. Guest VLAN, Authentication

Failed VLAN, and Inaccessible Authentication Bypass are examples of this type of local authorization method. Those

features assign VLAN upon specific condition and never involves RADIUS server for authorization. Because there is

no RADIUS based authorization, SGT cannot be assigned to endpoints authorized by those methods. Again, if there

is no SGT assignment, traffic coming from those endpoints is considered as “Unknown”.

SGT and Open Mode

Open mode can be extremely useful when deploying 802.1X based technology to network for the first time. Open

mode basically opens up logical controlled port in 802.1X protocol regardless the authentication result. Because

there is not enforcement performed, user traffic will not be blocked at interface but authentication log can be

recorded on RADIUS server. SGT can be still used to tag traffic from a particular user who passes authentication

successfully. Any user who fails authentication will not receive any SGT, therefore the traffic should be considered

as “unknown”. In the egress policy (discussed in configuration guide) for SGACL where you define policy between a

source security group to a destination security group, the policy for unknown source security group should be

permitted for a particular destination security group to make sure there is no enforcement introduced with open

mode. Alternatively you can change the default policy for egress policy in matrix, so that any traffic without any

specific policy can be permitted along with open mode.

Configuring Back-to-Back NDAC and IEEE 802.1AE Encr yption between Multiple VDCs in a Single Cisco

Nexus 7000 Series Switch

This appendix section discusses network device admission control, or NDAC, and IEEE 802.1AE encryption

between two virtual device contexts, or VDCs, using a single Cisco Nexus 7000 Series chassis.

The Cisco NX-OS Software for the Cisco Nexus Family switch platform supports VDCs, which partition a single

physical device into multiple logical devices to provide fault isolation, management isolation, address allocation

isolation, service differentiation domains, and adaptive resource management. You can manage a VDC instance

independently within a physical device. Each VDC appears as a unique device to the connected users.

This concept and technology can be applied to Cisco TrustSec. Using multiple VDC instances on a single physical

device, you can verify NDAC and IEEE 802.1AE encryption for any proof-of-concept and feature verification and

testing as if there are separate Cisco Nexus 7000 Series devices (Figure 14). This guide does not discuss VDC in

details. For more information about VDC technology on the Cisco Nexus 7000 Series Switch platform, please refer to

the following URL: http://www.cisco.com/en/US/docs/switches/datacenter/sw/4_1/nx-

os/virtual_device_context/configuration/guide/vdc_nx-os_cfg.html.

http://www.cisco.com/en/US/docs/switches/datacenter/sw/4_1/nx-os/virtual_device_context/configuration/guide/vdc_nx-os_cfg.html

http://www.cisco.com/en/US/docs/switches/datacenter/sw/4_1/nx-os/virtual_device_context/configuration/guide/vdc_nx-os_cfg.html



Figure 14. How to Create Logical Nexus 7000 Switches to Perform 802.1AE Encryption with Back-to-Back Link

For instance, assume that you have a Cisco Nexus 7000 Series Switch named CTS-V1-DCAS that is connected to

Cisco Secure ACS5.1. To separate this single device into two logical VDCs, you first need to figure out how those

two VDCs are connected in a logical topology.

Create another VDC instance called CTS-V1-DC as shown in Figure 14. Initially, all the interfaces belong to CTS-V1-

DCAS, so now you have to allocate some of those interfaces to newly created VDC, CTS-V1-DC. After you allocate

interfaces for the VDC, you can configure Cisco TrustSec on both devices. Following is output of a show module

command on CTS-V1-DCAS to determine the type of module installed on CTS-V1-DCAS.

CTS7K-V1-DCAS# show module

Mod Ports Module-Type Model Status

--- ----- -------------------------------- ------------------ ------------

1 32 10 Gbps Ethernet Module N7K-M132XP-12 ok

2 48 10/100/1000 Mbps Ethernet Module N7K-M148GT-11 ok

5 0 Supervisor module-1X N7K-SUP1 active *

CTS-V1-DCAS has a 32-port 10 Gigabit Ethernet module (N7K-M132XP-12) and a 48-port 10/100/1000-Mbps

Ethernet Module (N7K-M148-GT-11). Here, you will use the 10 Gigabit Ethernet Module to connect each VDC. Ports

for this type of module must be allocated in a certain way. You can allocate interfaces on your physical device in any

combination, except for the interfaces on the Cisco Nexus 7000 Series 32-port 10 Gigabit Ethernet module (N7K-

M132XP-12). This module has eight port groups that consist of four interfaces each. You must you assign all four

interfaces in a port group to the same VDC. Table 25 shows the allocation groups for the N7K-M132XP-12.

Table 25. Port Allocation Groups for the Cisco Nexus 7000 Series 32-Port 10 Gigabit Ethernet Module (N7K-M132XP-12)

Port Group Port Number

Group 1 1, 3, 5, 7

Group 2 2, 4, 6, 8

Group 3 9, 11, 13, 15



Port Group Port Number

Group 4 10, 12, 14, 16

Group 5 17, 19, 21, 23

Group 6 18, 20, 22, 24

Group 7 25, 27, 29, 31

Group 8 26, 28, 30, 32

Use CLI command shown here to create a VDC instance named CTS7K-V1-DC.

CTS7K-V1-DCAS(config)# vdc CTS7K-V1-DC

After you create a VDC, you have to allocate interfaces to it.

CTS7K-V1-DCAS(config-vdc)# allocate interface Ethernet1/1,Ethernet1/3,Ethernet1/5,Ethernet1/7

Moving ports will cause all config associated to them in source vdc to be removed. Are you sure you want to move the ports (y/n)? [yes]

CTS7K-V1-DCAS(config-vdc)# exit

CTS7K-V1-DCAS(config)# exit

CTS7K-V1-DCAS#

After you allocate interfaces, logon to the newly created VDC using the CLI command shown here. You may notice

that your prompt has changed.

CTS7K-V1-DCAS# switchto vdc CTS7K-V1-DC

Cisco Nexus Operating System (NX-OS) Software

TAC support: http://www.cisco.com/tac

Copyright (c) 2002-2009, Cisco Systems, Inc. All rights reserved.

The copyrights to certain works contained in this software are

owned by other third parties and used and distributed under

license. Certain components of this software are licensed under

the GNU General Public License (GPL) version 2.0 or the GNU

Lesser General Public License (LGPL) Version 2.1. A copy of each

such license is available at

http://www.opensource.org/licenses/gpl-2.0.php and

http://www.opensource.org/licenses/lgpl-2.1.php

CTS7K-V1-DCAS-CTS7K-V1-DC#

You can verify the allocated interfaces by entering the CLI command shown here.

CTS7K-V1-DCAS-CTS7K-V1-DC# show interface brief

--------------------------------------------------------------------------------

Ethernet VLAN Type Mode Status Reason Speed Port

Interface Ch #

--------------------------------------------------------------------------------

Eth1/1 -- eth routed up none 10G(S) --

Eth1/3 -- eth routed up none 10G(S) --

Eth1/5 -- eth routed down Administratively down auto(S) --

Eth1/7 -- eth routed down SFP not inserted auto(S) --

CTS7K-V1-DCAS-CTS7K-V1-DC#



Now you have two different logical Cisco Nexus 7000 Series VDC instances, and they are ready for configuration for

NDAC and IEEE 802.1AE encryption. Use the NDAC and SAP configurations described in the previous sections to

configure those two VDCs just as you configure two different Cisco Nexus 7000 Series Switches physically.

Sample Configuration

CTS4K-DCAS

no service pad

service timestamps debug datetime msec localtime

service timestamps log datetime msec localtime

no service password-encryption

service compress-config

!

hostname CTS4K-DCAS

!

boot-start-marker

boot-end-marker

!

aaa new-model

!

!

!

!

!

aaa session-id common

clock timezone PST -8

clock summer-time PDT recurring

ip subnet-zero

no ip routing

ip domain-name cts.local

ip name-server 10.1.100.100

!

ip vrf mgmtVrf

!

ip device tracking

vtp domain cts

vtp mode transparent

!

cts role-based sgt-map 10.1.200.100 sgt 3

cts role-based sgt-map 10.1.200.200 sgt 4

cts sxp enable

cts sxp default password sxp12345

cts sxp connection peer 10.1.2.1 source 10.1.2.3 password default mode peer listener

!

!

power redundancy-mode redundant

!



!

!

!

!

spanning-tree mode pvst

spanning-tree extend system-id

!

vlan internal allocation policy ascending

!

vlan 2

name mgmt

!

vlan 100

name Service-Server-Group

!

vlan 200

name Test-Server-Group

private-vlan primary

private-vlan association 999

!

vlan 999

name PriVLAN-Secondary

private-vlan isolated

!

!

!

interface FastEthernet1

ip vrf forwarding mgmtVrf

no ip address

no ip route-cache

shutdown

speed auto

duplex auto

!


switchport private-vlan host-association 200 999

switchport mode private-vlan host


!


switchport private-vlan host-association 200 999

switchport mode private-vlan host


!


!


!




!


!


!


!


!


!


!


!


!


!


!


!





!





!





!





!


!


!


!




!


!


!


!


!


!


!


!


!


!


!


!


!


!


!


!


!


!


!


!


!


!


!








media-type rj45

!






media-type rj45

!

interface Vlan1

no ip address

no ip route-cache

shutdown

!

interface Vlan2

ip address 10.1.2.3 255.255.255.0

no ip route-cache

!

ip default-gateway 10.1.2.1

ip http server

no ip http secure-server

!

!

control-plane

!

!

line con 0

stopbits 1

line vty 0 4

!

ntp master

end

CTS7K-DC

feature eigrp

feature private-vlan

feature interface-vlan

feature dot1x

feature dhcp

feature cts

cts device-id CTS7K-DC password trustsec123

cts role-based sgt-map 10.1.200.222 10

cts sxp enable



cts sxp connection peer 10.1.2.3 source 10.1.2.1 password required sxp12345 mode speaker

cts role-based enforcement

feature vtp

ip domain-lookup



ip host CTS7K-DC

radius-server host 10.1.100.3 key cisco123 pac authentication accounting

aaa group server radius aaa-private-sg

aaa group server radius cts-radius

server 10.1.100.3

hostname CTS7K-DC

!~ Omit default ACLs ~

aaa authentication dot1x default group cts-radius

aaa accounting dot1x default group cts-radius

aaa authorization cts default group cts-radius

vrf context management

vlan 1

vlan 2

name mgmt

vlan 100

name Service-Server-Group

vlan 200


name Test-Server-Group

private-vlan primary

private-vlan association 999

vlan 999


name PriVLAN-Secondary

private-vlan isolated

vdc CTS7K-DC id 1

limit-resource vlan minimum 16 maximum 4094

limit-resource monitor-session minimum 0 maximum 2

limit-resource vrf minimum 16 maximum 8192

limit-resource port-channel minimum 0 maximum 768

limit-resource u4route-mem minimum 32 maximum 32


limit-resource m4route-mem minimum 48 maximum 48


vdc CTS7K-CORE id 2

allocate interface Ethernet3/13-24

boot-order 1

limit-resource vlan minimum 16 maximum 4094



limit-resource monitor-session minimum 0 maximum 2

limit-resource vrf minimum 16 maximum 8192

limit-resource port-channel minimum 0 maximum 768





interface Vlan1

delay 10

interface Vlan2

no shutdown

delay 10

ip address 10.1.2.1/24

ip router eigrp lab

interface Vlan100

no shutdown

delay 10

ip address 10.1.100.1/24

ip router eigrp lab

ip dhcp relay address 10.1.100.100

interface Vlan200

no shutdown

delay 10

private-vlan mapping 999

ip address 10.1.200.1/24

ip local-proxy-arp

ip router eigrp lab

interface Vlan999

delay 10


ip router eigrp lab


switchport




no shutdown


cts dot1x

ip address 10.1.50.1/24



ip router eigrp lab

no shutdown


































no shutdown



interface mgmt0

vrf member management

clock timezone PDT -8 0

clock summer-time PDT 1 Monday March 02:00 1 Monday November 12:00 1

line console

boot kickstart bootflash:/n7000-s1-kickstart.4.2.1.bin sup-1

boot system bootflash:/n7000-s1-dk9.4.2.1.bin sup-1

boot kickstart bootflash:/n7000-s1-kickstart.4.2.1.bin sup-2

boot system bootflash:/n7000-s1-dk9.4.2.1.bin sup-2

router eigrp lab

autonomous-system 1

address-family ipv4 unicast

service dhcp

ip dhcp relay


vtp domain cts

CTS7K-CORE

feature telnet

feature eigrp

feature interface-vlan

feature dot1x

feature dhcp



feature cts

cts device-id CTS7K-CORE password trustsec123

cts sxp enable

cts sxp connection peer 10.1.3.2 source 10.1.3.1 password required sxp12345 mode speaker


feature vtp

ip domain-lookup

ip host CTS7K-CORE

aaa group server radius aaa-private-sg

hostname CTS7K-CORE

vrf context management

vlan 1

vlan 3

name Access_Mgmt

vlan 10

name Access-VLAN

vlan 99

name voice

interface Vlan1

interface Vlan3

no shutdown

ip address 10.1.3.1/24

ip router eigrp lab

interface Vlan10

no shutdown

ip address 10.1.10.1/24

ip router eigrp lab


interface Vlan99

no shutdown

ip address 10.1.99.1/24

ip router eigrp lab



cts dot1x

no propagate-sgt

sap modelist no-encap

switchport






no shutdown



cts dot1x

ip address 10.1.50.2/24

ip router eigrp lab

no shutdown










interface mgmt0

router eigrp lab

autonomous-system 1

address-family ipv4 unicast

service dhcp

ip dhcp relay


vtp domain cts

CTS6K-AS

service timestamps debug datetime msec localtime

service timestamps log datetime msec localtime

no service password-encryption

service counters max age 5

!

hostname CTS6K-AS



!

aaa new-model

!

!

aaa authentication dot1x default group radius

aaa authorization network default group radius

aaa accounting dot1x default start-stop group radius

!

!

!

aaa session-id common

clock timezone PST -8

clock summer-time PDT recurring

ip subnet-zero

!

!

!

ip dhcp snooping vlan 10,99

ip dhcp snooping



ip device tracking

vtp domain cts


no mls acl tcam share-global

mls netflow interface

mls rate-limit capture 100 10

mls cef error action freeze

cts sxp enable

cts sxp default password sxp12345

cts sxp connection peer 10.1.3.1 source 10.1.3.2 password default mode peer listener

!

!

spanning-tree mode pvst

spanning-tree extend system-id

dot1x system-auth-control

diagnostic bootup level minimal

port-channel per-module load-balance

!

redundancy

main-cpu

auto-sync running-config

mode sso

!

vlan internal allocation policy ascending

vlan access-log ratelimit 2000

!

vlan 3



name Access_Mgmt

!

vlan 10

name Access-VLAN

!

vlan 99

name voice

!

!

!

!

!


no ip address

shutdown

!


switchport





media-type rj45

cts dot1x

ip dhcp snooping trust

!


switchport



authentication event fail action next-method




snmp trap mac-notification change added

snmp trap mac-notification change removed


dot1x timeout tx-period 12


!


switchport



switchport voice vlan 99

authentication host-mode multi-domain

authentication order dot1x mab






mab

snmp trap mac-notification change added

snmp trap mac-notification change removed



!


no ip address

shutdown

!


no ip address

shutdown

!


no ip address

shutdown

!


no ip address

shutdown

!


no ip address

shutdown

!


no ip address

shutdown

!


no ip address

shutdown

!


no ip address

shutdown

! ~ Interface omitted ~

!


ip address 172.19.124.155 255.255.255.128

!

!

interface Vlan1

no ip address



shutdown

!

interface Vlan3

ip address 10.1.3.2 255.255.255.0

!

router eigrp 1

network 10.1.0.0 0.0.255.255

no auto-summary

!

ip classless

!

no ip http server

no ip http secure-server

!

ip access-list extended test

!

snmp-server engineID local 8000000903000015C7244940

snmp-server community public RO

snmp-server community private RW

snmp-server enable traps MAC-Notification move change

snmp-server host 10.1.100.30 version 2c cisco123

!

radius-server attribute 8 include-in-access-req

radius-server host 10.1.100.3 auth-port 1812 acct-port 1813 key cisco123

radius-server vsa send accounting

radius-server vsa send authentication

!

control-plane

!

!

dial-peer cor custom

!

!

!

!

line con 0

login authentication console

line vty 5 15

!

!

end



Printed in USA C07-608226-00 07/10

trustsec sga confguide

Documents