security configuration guide, cisco dcnm for lan, release 5 · security configuration guide, cisco...

Security Configuration Guide, Cisco DCNM for LAN, Release 5.xFirst Published: March 19, 2010

Last Modified: July 11, 2011

Americas HeadquartersCisco Systems, Inc.170 West Tasman DriveSan Jose, CA 95134-1706USAhttp://www.cisco.comTel: 408 526-4000 800 553-NETS (6387)Fax: 408 527-0883

Text Part Number: OL-20638-03

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS,INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND,EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITEDWARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITHTHE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY,CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain versionof the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.

NOTWITHSTANDINGANYOTHERWARRANTYHEREIN, ALL DOCUMENT FILES AND SOFTWAREOF THESE SUPPLIERS ARE PROVIDED “AS IS"WITHALL FAULTS.CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OFMERCHANTABILITY, FITNESS FORA PARTICULAR PURPOSEANDNONINFRINGEMENTORARISING FROMACOURSEOFDEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUTLIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERSHAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at http://cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Ciscoand any other company. (1101R)

Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shownfor illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.

© 2011 Cisco Systems, Inc. All rights reserved.

http://cisco.com/go/trademarks

http://cisco.com/go/trademarks

C O N T E N T S

Preface xvii

Audience xvii

Document Organization xvii

Document Conventions xviii

Related Documentation xviii

Cisco DCNM Documentation xix

Cisco Nexus 1000V Series Switch Documentation xix

Cisco Nexus 2000 Series Fabric Extender Documentation xix

Cisco Nexus 3000 Series Switch Documentation xix



Cisco Nexus 7000 Series Switch Documentation xx

Obtaining Documentation and Submitting a Service Request xx

New and Changed Information 1

New and Changed Information 1

Overview 3

Authentication, Authorization, and Accounting 3

RADIUS and TACACS+ Security Protocols 4

User Accounts and Roles 5

802.1X 5

IP ACLs 5

MAC ACLs 5

VACLs 6

Port Security 6

DHCP Snooping 6

Dynamic ARP Inspection 6

IP Source Guard 7

Keychain Management 7

Security Configuration Guide, Cisco DCNM for LAN, Release 5.x OL-20638-03 iii

Traffic Storm Control 7

Using the Layer 2 Security Audit Wizard 9

Information About the Security Audit Wizard 9

Licensing Requirements for the Security Audit Wizard 9

Prerequisites for the Security Audit Wizard 10

Platform Support for the Security Audit Wizard 10

Configuring Layer 2 Security Using the Security Audit Wizard 10

Field Descriptions for the Security Audit Wizard 18

Security Audit Wizard: Select Interfaces 18

Security Audit Wizard: Select VLANs 19

Security Audit Wizard: Apply Traffic Storm Control Configurations 19

Security Audit Wizard: Apply Trust Definitions and IP Source Guard 19

Security Audit Wizard: Port Security 20

Security Audit Wizard: DHCP Snooping and DAI 20

Additional References for the Security Audit Wizard 20

Feature History for the Security Audit Wizard 21

Configuring AAA 23

Information About AAA 23

AAA Security Services 23

Benefits of Using AAA 24

Remote AAA Services 24

AAA Server Groups 25

AAA Service Configuration Options 25

Authentication and Authorization Process for User Login 26

Prerequisites for AAA 27

Licensing Requirements for AAA 27

Platform Support for AAA 27

Configuring AAA 28

Changing an AAA Authentication Rule Method 28

Adding an AAA Authentication Rule Method 28

Rearranging an AAA Authentication Rule Method 29

Deleting an AAA Authentication Rule Method 30

Enabling or Disabling the Default User Role for AAA Authentication 31

Enabling or Disabling Login Authentication Failure Messages 31

Enabling or Disabling AAA Authentication 32

Security Configuration Guide, Cisco DCNM for LAN, Release 5.xiv OL-20638-03

Contents

Changing an AAA Accounting Rule Method 33

Adding an AAA Accounting Rule Method 34

Rearranging an AAA Accounting Rule Method 35

Deleting an AAA Accounting Rule Method 35

Using AAA Server VSAs with Cisco NX-OS Devices 36

About VSAs 36

VSA Format 36

Specifying Cisco NX-OS User Roles and SMNPv3 Parameters on AAA Servers 37

Field Descriptions for AAA 37

Security: AAA: Rules: Summary Pane 37

Security: AAA: Rules: device: Authentication Rules: Rule: Authentication Rules Tab 38

Security: AAA: Rules: device: Accounting Rules: Rule: Accounting Rules Tab 38

Security: AAA: Server Groups: device: Settings Tab 39

Additional References for AAA 39

Feature History for AAA 40

Configuring RADIUS 41

Information About RADIUS 41

RADIUS Network Environments 41

RADIUS Operation 42

RADIUS Server Monitoring 42

Vendor-Specific Attributes 43

Licensing Requirements for RADIUS 44

Prerequisites for RADIUS 45

Platform Support for RADIUS 45

Configuring RADIUS Servers 45

RADIUS Server Configuration Process 45

Adding a RADIUS Server Host 46

Copying a RADIUS Server Host 47

Deleting a RADIUS Server Host 47

Configuring a Global RADIUS Key 48

Configuring a Key for a Specific RADIUS Server 49

Adding a RADIUS Server Group 49

Adding a RADIUS Server Host to a RADIUS Server Group 50

Deleting a RADIUS Server Host from a RADIUS Server Group 51

Deleting a RADIUS Server Group 51

Security Configuration Guide, Cisco DCNM for LAN, Release 5.x OL-20638-03 v

Contents

Configuring the Global Source Interface for RADIUS Server Groups 51

Configuring a Source Interface for a Specific RADIUS Server Group 52

Allowing Users to Specify a RADIUS Server at Login 53

Configuring the Global RADIUS Transmission Retry Count and Timeout Interval 53

Configuring the RADIUS Transmission Retry Count and Timeout Interval for a Server 54

Configuring Accounting and Authentication Attributes for RADIUS Servers 55

Configuring Periodic RADIUS Server Monitoring 55

Configuring the RADIUS Dead-Time Interval 56

Displaying RADIUS Server Statistics 57

Where to Go Next 57

Field Descriptions for RADIUS Server Groups and Servers 57

Security: AAA: Server Groups: Summary Pane 58

Security: AAA: Server Groups: device: Default RADIUS Server Group: Global Settings

Tab 58

Security: AAA: Server Groups: device: Default RADIUS Server Group: server: Server

Details Tab 59

Security: AAA: Server Groups: device: server group: Details Tab 60

Additional References for RADIUS 60

Feature History for RADIUS 61

Configuring TACACS+ 63

Information About TACACS+ 63

TACACS+ Advantages 64

TACACS+ Operation for User Login 64

Default TACACS+ Server Encryption Type and Secret Key 65

TACACS+ Server Monitoring 65

TACACS+ Configuration Distribution 66

Vendor-Specific Attributes for TACACS+ 66

Cisco VSA Format for TACACS+ 67

Licensing Requirements for TACACS+ 67

Prerequisites for TACACS+ 68

Platform Support for TACACS+ 68

Configuring TACACS+ 68

TACACS+ Server Configuration Process 69

Enabling TACACS+ 69

Adding a TACACS+ Server Host 69

Security Configuration Guide, Cisco DCNM for LAN, Release 5.xvi OL-20638-03

Contents

Copying a TACACS+ Server Host 70

Deleting a TACACS+ Server Host 71

Configuring a Global TACACS+ Key 72

Configuring a Key for a Specific TACACS+ Server 72

Adding a TACACS+ Server Group 73

Adding a TACACS+ Server Host to a TACACS+ Server Group 74

Deleting a TACACS+ Server Host from a TACACS+ Server Group 74

Deleting a TACACS+ Server Group 75

Configuring the Global Source Interface for TACACS+ Server Groups 75

Configuring a Source Interface for a Specific TACACS+ Server Group 76

Allowing Users to Specify a TACACS+ Server at Login 76

Configuring the Global TACACS+ Timeout Interval 77

Configuring the Timeout Interval for a TACACS+ Server 77

Configuring TCP Ports 78

Configuring Periodic TACACS+ Server Monitoring 79

Configuring the TACACS+ Dead-Time Interval 79

Disabling TACACS+ 80

Displaying TACACS+ Statistics 80

Where to Go Next 81

Field Descriptions for TACACS+ Server Groups and Servers 81

Security: AAA: Server Groups: Summary Pane 81

Security: AAA: Server Groups: device: Default TACACS Server Group: Global Settings

Tab 82

Security: AAA: Server Groups: device: Default TACACS Server Group: server: Server Details

Tab 82

Security: AAA: Server Groups: device: server group: Details Tab 83

Additional References for TACACS+ 84

Feature History for TACACS+ 84

Configuring User Accounts and RBAC 87

Information About User Accounts and RBAC 87

About User Accounts 87

Characteristics of Strong Passwords 88

About User Roles 88

About User Role Rules 89

Licensing Requirements for User Accounts and RBAC 89

Security Configuration Guide, Cisco DCNM for LAN, Release 5.x OL-20638-03 vii

Contents

Platform Support for User Accounts and RBAC 90

Configuring User Accounts 90

Creating a User Account 90

Copying a User Account 93

Changing a User Account Password 93

Changing a User Account Expiry Date 94

Adding a User Account Role 95

Deleting a User Account Role 96

Deleting a User Account 97

Configuring Roles 98

Creating a User Role 98

Copying a User Role 99

Adding a Rule to a User Role 99

Changing a Rule in a User Role 100

Rearranging a Rule in a User Role 101

Deleting a Rule from a User Role 102

Changing a User Role Interface Policy 103

Changing a User Role VLAN Policy 104

Changing a User Role VRF Policy 105

Field Descriptions for RBAC 106

Security: RBAC: Roles: Summary Pane 107

Security: RBAC: Roles: device: role: Details Tab: General Area 107

Security: RBAC: Roles: device: role: Details Tab: Command Authorization Rules Area 107

Security: RBAC: Users: Summary Pane 108

Additional References for User Accounts and RBAC 108

Feature History for User Accounts and RBAC 109

Configuring 802.1X 111

Information About 802.1X 111

Device Roles 111

Authentication Initiation and Message Exchange 113

Ports in Authorized and Unauthorized States 114

MAC Authentication Bypass 115

802.1X and Port Security 116

Single Host and Multiple Hosts Support 117

Supported Topologies 117

Security Configuration Guide, Cisco DCNM for LAN, Release 5.xviii OL-20638-03

Contents

Licensing Requirements for 802.1X 118

Prerequisites for 802.1X 118

Platform Support for 802.1X 119

Configuring 802.1X 119

Process for Configuring 802.1X 119

Enabling the 802.1X Service 119

Enabling the 802.1X Feature on an Interface 120

Controlling 802.1X Authentication on an Interface 120

Enabling Global Periodic Reauthentication 121

Enabling Periodic Reauthentication for an Interface 121

Changing Global 802.1X Authentication Timers 122

Changing 802.1X Authentication Timers for an Interface 123

Enabling Single Host or Multiple Hosts Mode 124

Enabling MAC Address Authentication Bypass 125

Disabling 802.1X Authentication on the Device 125

Disabling the 802.1X Feature 126

Setting Global Maximum Authenticator-to-Supplicant Frame Retransmission Retry Count 127

Configuring the Maximum Authenticator-to-Supplicant Frame Retransmission Retry Count

for an Interface 127

Enabling RADIUS Accounting for 802.1X Authentication 128

Configuring AAA Accounting Methods for 802.1X 128

Setting the Maximum Reauthentication Retry Count on an Interface 129

Displaying 802.1X Statistics 130

Field Descriptions for 802.1X 130

Security: Dot1X: Summary Pane 130

Security: Dot1X: device: Global Settings Tab: General 131

Security: Dot1X: device: Global Settings Tab: Timers 131

Security: Dot1X: device: slot: interface: Interface Settings Tab: General 132

Security: Dot1X: device: slot: interface: Interface Settings Tab: Timers 133

Additional References for 802.1X 133

Feature History for 802.1X 134

Configuring IP ACLs 135

Information About ACLs 135

ACL Types and Applications 136

Order of ACL Application 137

Security Configuration Guide, Cisco DCNM for LAN, Release 5.x OL-20638-03 ix

Contents

About Rules 138

Protocols 138

Source and Destination 139

Implicit Rules 139

Additional Filtering Options 139

Logical Operators and Logical Operation Units 141

Logging 141

Time Ranges 141

Statistics and ACLs 143

Atomic ACL Updates 143

Licensing Requirements for IP ACLs 143

Platform Support for IP ACLs 144

Configuring IP ACLs 145

Creating an IP ACL 145

Changing an IP ACL 145

Changing Sequence Numbers in an IP ACL 146

Removing an IP ACL 146

Applying an IP ACL to a Physical Port 147

Applying an IP ACL to a Virtual Ethernet Interface 148

Applying an IP ACL to a Port Channel 148

Applying an IP ACL as a VACL 149

Displaying IP ACL Statistics 149

Field Descriptions for IPv4 ACLs 150

IPv4 ACL: Details Tab 150

IPv4 Access Rule: Details Tab 150

IPv4 Access Rule: Details: Source and Destination Section 150

IPv4 Access Rule: Details: Protocol and Others Section 152

IPv4 Access Rule: Details: Advanced Section 154

IPv4 ACL Remark: Remark Details Tab 155

Field Descriptions for IPv6 ACLs 155

IPv6 ACL: Details Tab 155

IPv6 Access Rule: Details Tab 156

IPv6 Access Rule: Details: Source and Destination Section 156

IPv6 Access Rule: Details: Protocol and Others Section 158

IPv6 Access Rule: Details: Advanced Section 160

Security Configuration Guide, Cisco DCNM for LAN, Release 5.xx OL-20638-03

Contents

IPv6 ACL Remark: Remark Details Tab 161

Configuring Object Groups 162

Creating an Address Object Group 162

Creating a Port Object Group 162

Changing an Object Group 163

Changing Sequence Numbers in an Object Group 163

Configuring Time Ranges 164

Creating a Time Range 165

Changing a Time Range 165

Removing a Time Range 166

Field Descriptions for Time Ranges 167

Additional References for IP ACLs 168

Feature History for IP ACLs 168

Configuring MAC ACLs 169

Information About MAC ACLs 169

Licensing Requirements for MAC ACLs 169

Platform Support for MAC ACLs 170

Configuring MAC ACLs 170

Creating a MAC ACL 170

Changing a MAC ACL 171

Changing Sequence Numbers in a MAC ACL 172

Removing a MAC ACL 172

Applying a MAC ACL to a Physical Port 172

Applying a MAC ACL to a Virtual Ethernet Interface 173

Applying a MAC ACL to a Port Channel 174

Applying a MAC ACL as a VACL 175

Monitoring and Clearing MAC ACL Statistics 175

Field Descriptions for MAC ACLs 175

MAC ACL: ACL Details Tab 175

MAC Access Rule: Details: General Section 175

MAC Access Rule: Details: Source and Destination Section 176

MAC ACL Remark: Remark Details Tab 178

Additional References for MAC ACLs 178

Feature History for MAC ACLs 178

Configuring VLAN ACLs 179

Security Configuration Guide, Cisco DCNM for LAN, Release 5.x OL-20638-03 xi

Contents

Information About VLAN ACLs 179

VLAN Access Maps and Entries 179

VACLs and Actions 180

VACL Statistics 180

Licensing Requirements for VACLs 180

Platform Support for VACLs 180

Configuring VACLs 181

Adding a VACL 181

Changing a VACL 181

Removing a VACL or VLAN Access-Map Entry 182

Applying a VACL to a VLAN 183

Field Descriptions for VACLs 184

VLAN Access Map Entry: Details Tab 184

VLAN Access Map Entry: Details: Match Condition And Action Section 184

Additional References for VACLs 185

Feature History for VLAN ACLs 185

Configuring Port Security 187

Information About Port Security 187

Secure MAC Address Learning 188

Static Method 188

Dynamic Method 188

Sticky Method 189

Dynamic Address Aging 189

Secure MAC Address Maximums 189

Security Violations and Actions 190

Port Security and Port Types 191

Port Security and Port-Channel Interfaces 192

Port Type Changes 193

802.1X and Port Security 194

Licensing Requirements for Port Security 194

Prerequisites for Port Security 195

Platform Support for Port Security 195

Configuring Port Security 195

Enabling or Disabling Port Security Globally 195

Enabling or Disabling Port Security on a Layer 2 Interface 196

Security Configuration Guide, Cisco DCNM for LAN, Release 5.xxii OL-20638-03

Contents

Enabling or Disabling Sticky MAC Address Learning 197

Adding a Static Secure MAC Address on an Interface 198

Removing a Static Secure MAC Address on an Interface 199

Removing a Dynamic or Sticky Secure MAC Address 200

Configuring a Maximum Number of MAC Addresses 200

Configuring an Address Aging Type and Time 202

Configuring a Security Violation Action 202

Displaying Secure MAC Addresses 203

Field Descriptions for Port Security 204

Device: Global Settings Tab 204

Interface: Secure Interface Details: Secure Interface Configuration Section 204

Interface: Secure Interface Details: Secure Address Configuration Section 206

Interface: Dynamic MAC Addresses Tab 207

Additional References for Port Security 208

Feature History for Port Security 208

Configuring DHCP 209

Information About DHCP Snooping 209

Trusted and Untrusted Sources 210

DHCP Snooping Binding Database 210

DHCP Relay Agent 211

Packet Validation 211

DHCP Snooping Option 82 Data Insertion 211

Licensing Requirements for DHCP 213

Prerequisites for DHCP 213

Platform Support for DHCP 214

Configuring DHCP 214

Minimum DHCP Configuration 214

Enabling or Disabling the DHCP Snooping Feature 215

Enabling or Disabling DHCP Snooping Globally 215

Enabling or Disabling DHCP Snooping on a VLAN 216

Enabling or Disabling DHCP Snooping MAC Address Verification 217

Enabling or Disabling Option 82 Data Insertion and Removal 217

Configuring a Layer 2 Interface as Trusted or Untrusted 218

Enabling or Disabling the DHCP Relay Agent 219

Enabling or Disabling Option 82 for the DHCP Relay Agent 219

Security Configuration Guide, Cisco DCNM for LAN, Release 5.x OL-20638-03 xiii

Contents

Configuring a DHCP Server Address on a Layer 3 Ethernet Interface 220

Configuring a DHCP Server Address on a Port Channel 221

Configuring a DHCP Server Address on a VLAN Interface 221

Displaying DHCP Bindings 222

Field Descriptions for DHCP Snooping 223

Device: Configuration Tab 223

Device: Configuration: Global Settings Section 223

Device: Configuration: DHCP Trust State Section 224

Device: Dynamic Binding Tab 224

VLAN: DHCP VLAN Details Tab 224

Additional References for DHCP 225

Feature History for DHCP 225

Configuring Dynamic ARP Inspection 227

Information About DAI 228

Understanding ARP 228

Understanding ARP Spoofing Attacks 228

Understanding DAI and ARP Spoofing Attacks 229

Interface Trust States and Network Security 229

Prioritizing ARP ACLs and DHCP Snooping Entries 231

Logging DAI Packets 231

Licensing Requirements for DAI 231

Prerequisites for DAI 232

Platform Support for DAI and ARP ACLs 232

Configuring DAI 232

Enabling or Disabling DAI on VLANs 232

Configuring the DAI Trust State of a Layer 2 Interface 233

Applying ARP ACLs to VLANs for DAI Filtering 234

Enabling or Disabling Additional Validation 235

Configuring the DAI Logging Buffer Size 235

Configuring the DAI System Logging Rate 236

Configuring DAI Log Filtering 236

Monitoring and Clearing DAI Statistics 237

Field Descriptions for DAI 237

Device: Details: Global Settings Section 237

Device: Details: ARP Trust State Section 238

Security Configuration Guide, Cisco DCNM for LAN, Release 5.xxiv OL-20638-03

Contents

VLAN: DAI VLAN Details Tab 238

Configuring ARP ACLs 239

Creating an ARP ACL 239

Changing an ARP ACL 240

Removing an ARP ACL 241

Field Descriptions for ARP ACLs 241

ARP ACL: ACL Details Tab 241

ARP Access Rule: ACE Details Tab 242

ARP Access Rule: ACE Details: Source and Destination Section 242

ARP ACL Remark: Remark Details Tab 245

Additional References for DAI 245

Feature History for DAI 245

Configuring IP Source Guard 247

Information About IP Source Guard 247

Licensing Requirements for IP Source Guard 248

Prerequisites for IP Source Guard 248

Platform Support for IP Source Guard 249

Configuring IP Source Guard 249

Enabling or Disabling IP Source Guard on a Layer 2 Interface 249

Adding or Removing a Static IP Source Entry 250

Displaying IP Source Guard Bindings 250

Field Descriptions for IP Source Guard 251

Device: Static Binding Tab 251

Interface: Interface Configuration Tab 251

Additional References for IP Source Guard 252

Feature History for IP Source Guard 252

Configuring Keychain Management 253

Information About Keychain Management 253

Keychains and Keychain Management 253

Lifetime of a Key 254

Licensing Requirements for Keychain Management 254

Platform Support for Keychain Management 255

Configuring Keychain Management 255

Creating a Keychain 255

Removing a Keychain 255

Security Configuration Guide, Cisco DCNM for LAN, Release 5.x OL-20638-03 xv

Contents

Configuring a Key 256

Configuring Text for a Key 257

Configuring Accept and Send Lifetimes for a Key 257

Where to Go Next 258

Field Descriptions for Keychain Management 259

Keychain Object 259

Keychain Entry Object 259

Related Fields 260

Additional References for Keychain Management 260

Feature History for Keychain Management 260

Configuring Traffic Storm Control 263

Information About Traffic Storm Control 263

Licensing Requirements for Traffic Storm Control 265

Platform Support for Traffic Storm Control 265

Configuring Traffic Storm Control 265

Displaying Traffic Storm Control Statistics 266

Field Descriptions for Traffic Storm Control 266

Switching: Traffic Storm Control: Summary Pane 267

Switching: Traffic Storm Control: device: interface type: interface: Interface Configuration

Tab 267

Additional References for Traffic Storm Control 268

Feature History for Traffic Storm Control 268

Security Configuration Guide, Cisco DCNM for LAN, Release 5.xxvi OL-20638-03

Contents

Preface

This preface describes the audience, organization, and conventions of the . It also provides information onhow to obtain related documentation.

• Audience, page xvii

• Document Organization, page xvii

• Document Conventions, page xviii

• Related Documentation, page xviii

• Obtaining Documentation and Submitting a Service Request, page xx

AudienceThis publication is for experienced network administrators who configure and maintain Cisco NX-OS devices.

Document OrganizationThis document is organized into the following chapters:

DescriptionChapter

Describes the new and changed information for the new Cisco DCNMsoftware releases.

"New and Changed Information"

Describes the security features supported by Cisco DCNM."Overview"

Describes how to use the Security Audit Wizard to configure Layer 2security.

"Using the Layer 2 Security AuditWizard"

Describes how to configure authentication, authorization, and accounting(AAA) features.

"Configuring AAA"

Describes how to configure the RADIUS security protocol."Configuring RADIUS"

Security Configuration Guide, Cisco DCNM for LAN, Release 5.x OL-20638-03 xvii

DescriptionChapter

Describes how to configure the TACACS+ security protocol."Configuring TACACS+"

Describes how to configure user accounts and role-based access control(RBAC).

"Configuring User Accounts andRBAC"

Describes how to configure 802.1X authentication."Configuring 802.1X"

Describes how to configure IP access control lists (ACLs)."Configuring IP ACLs"

Describes how to configure MAC ACLs."Configuring MAC ACLs"

Describes how to configure VLAN ACLs."Configuring VLAN ACLs"

Describes how to configure port security."Configuring Port Security"

Describes how to configure Dynamic Host Configuration Protocol(DHCP) snooping.

"Configuring DHCP"

Describes how to configure Address Resolution Protocol (ARP)inspection.

"Configuirng Dynamic ARPInspection"

Describes how to configure IP Source Guard."Configuring IP Source Guard"

Describes how to configure keychain management."Configuring KeychainManagement"

Describes how to configure traffic storm control."Configuring Traffic StormControl"

Document ConventionsThis document uses the following conventions:

Means reader take note. Notes contain helpful suggestions or references to material not covered in themanual.

Note

Means reader be careful. In this situation, you might do something that could result in equipment damageor loss of data.

Caution

Related DocumentationThis section contains information about the documentation available for Cisco DCNM and for the platformsthat Cisco DCNM manages.

Security Configuration Guide, Cisco DCNM for LAN, Release 5.xxviii OL-20638-03

PrefaceDocument Conventions

Cisco DCNM DocumentationCisco DCNM documentation is available at the following URL:

http://www.cisco.com/en/US/products/ps9369/tsd_products_support_series_home.html

The documentation set for Cisco DCNM includes the following documents:

Release Notes

Cisco DCNM Release Notes, Release 5.x

Installation and Licensing

Cisco DCNM Installation and Licensing Guide, Release 5.x

Cisco DCNM FabricPath Configuration Guide, Release 5.x

Cisco Nexus 1000V Series Switch DocumentationThe Cisco Nexus 1000V Series Switch documentation is available at the following URL:


Cisco Nexus 2000 Series Fabric Extender DocumentationThe Cisco Nexus 2000 Series Fabric Extender documentation is available at the following URL:


Cisco Nexus 3000 Series Switch DocumentationThe Cisco Nexus 3000 Series Switch documentation is available at the following URL:






Security Configuration Guide, Cisco DCNM for LAN, Release 5.x OL-20638-03 xix

PrefaceCisco DCNM Documentation









Obtaining Documentation and Submitting a Service RequestFor information on obtaining documentation, submitting a service request, and gathering additional information,see the monthlyWhat's New in Cisco Product Documentation, which also lists all new and revised Ciscotechnical documentation, at:

http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html

Subscribe to theWhat's New in Cisco Product Documentation as a Really Simple Syndication (RSS) feedand set content to be delivered directly to your desktop using a reader application. The RSS feeds are a freeservice and Cisco currently supports RSS version 2.0.

Security Configuration Guide, Cisco DCNM for LAN, Release 5.xxx OL-20638-03

PrefaceCisco Nexus 7000 Series Switch Documentation


http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html

C H A P T E R 1New and Changed Information

This chapter provides release-specific information for each new and changed feature in the . The latest versionof this document is available at the following Cisco website:

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

• New and Changed Information, page 1

New and Changed InformationTo check for additional information about Cisco DCNM, see the Cisco DCNM Release Notes, Release 5.xavailable at the following Cisco website:

http://www.cisco.com/en/US/products/ps9369/prod_release_notes_list.html

This table summarizes the new and changed features for the , and tells you where they are documented.

Table 1: New and Changed Security Features for Cisco DCNM Release 5.x

Where DocumentedChanged inRelease

DescriptionFeature

Configuring AAA, page 235.2(1)Added support for the CiscoNexus 3000 Series Switches.

AAA

Configuring DHCP, page 2095.2(1)Added support for the CiscoNexus 1000V Series Switches,

DHCP snooping

Cisco Nexus 3000 SeriesSwitches, and Cisco Nexus5000 Series Switches.

Configuring IP Source Guard,page 247

5.2(1)Added support for the CiscoNexus 3000 Series Switches.

IP Source Guard

Configuring IP ACLs, page135


IPv4 ACLs

Security Configuration Guide, Cisco DCNM for LAN, Release 5.x OL-20638-03 1

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

http://www.cisco.com/en/US/products/ps9369/prod_release_notes_list.html

Where DocumentedChanged inRelease

DescriptionFeature

Configuring RADIUS, page41


RADIUS

Configuring TACACS+, page63


TACACS+

Configuring Traffic StormControl, page 263


Traffic storm control

Configuring User Accountsand RBAC, page 87


User accounts andRBAC

Configuring VLAN ACLs,page 179


VLAN ACLs

Configuring AAA, page 235.0(2)Added the ability to enable ordisable AAA authentication foruser logins.

AAA authentication

Configuring AAA, page 235.0(2)Added support for remote usersto log in to a Cisco NX-OS

AAA authentication

device through a RADIUS orTACACS+ remoteauthentication server using adefault user role.

Configuring IP ACLs, page135

5.0(2)Added support for objectgroups.

IP ACLs

Configuring AAA, page 235.0(2)Added the ability to enable ordisable login authenticationfailure messages.

Login authentication


5.0(2)Added support for configuringthe global source interface forall RADIUS server groups.

RADIUS servergroups


5.0(2)Added support for configuringa source interface for a specificRADIUS server group.

RADIUS servergroups


5.0(2)Added support for configuringthe global source interface forall TACACS+ server groups.

TACACS+ servergroups


5.0(2)Added support for configuringa source interface for a specificTACACS+ server group.

TACACS+ servergroups

Security Configuration Guide, Cisco DCNM for LAN, Release 5.x2 OL-20638-03

New and Changed InformationNew and Changed Information

C H A P T E R 2Overview

The Cisco NX-OS software supports security features that can protect your network against degradation orfailure and also against data loss or compromise resulting from intentional attacks and from unintended butdamaging mistakes by well-meaning network users.

This chapter includes the following sections:

• Authentication, Authorization, and Accounting, page 3

• RADIUS and TACACS+ Security Protocols, page 4

• User Accounts and Roles, page 5

• 802.1X, page 5

• IP ACLs, page 5

• MAC ACLs, page 5

• VACLs, page 6

• Port Security, page 6

• DHCP Snooping, page 6

• Dynamic ARP Inspection, page 6

• IP Source Guard, page 7

• Keychain Management, page 7

• Traffic Storm Control, page 7

Authentication, Authorization, and AccountingAuthentication, authorization, and accounting (AAA) is an architectural framework for configuring a set ofthree independent security functions in a consistent, modular manner.

Provides the method of identifying users, including login and password dialog, challengeand response, messaging support, and, depending on the security protocol that you select,

Authentication

encryption. Authentication is the way a user is identified prior to being allowed access to


the network and network services. You configure AAA authentication by defining a namedlist of authentication methods and then applying that list to various interfaces.

Provides the method for remote access control, including one-time authorization orauthorization for each service, per-user account list and profile, user group support, andsupport of IP, IPX, ARA, and Telnet.Remote security servers, such as RADIUS and TACACS+, authorize users for specific rightsby associating attribute-value (AV) pairs, which define those rights, with the appropriate

Authorization

user. AAA authorization works by assembling a set of attributes that describe what the useris authorized to perform. These attributes are compared with the information contained ina database for a given user, and the result is returned to AAA to determine the user’s actualcapabilities and restrictions.

Provides the method for collecting and sending security server information used for billing,auditing, and reporting, such as user identities, start and stop times, executed commands

Accounting

(such as PPP), number of packets, and number of bytes. Accounting enables you to trackthe services that users are accessing, as well as the amount of network resources that theyare consuming.

You can configure authentication outside of AAA. However, you must configure AAA if you want to useRADIUS or TACACS+, or if you want to configure a backup authentication method.

Note

Related Topics

• Configuring AAA, page 23

RADIUS and TACACS+ Security ProtocolsAAA uses security protocols to administer its security functions. If your router or access server is acting asa network access server, AAA is the means through which you establish communication between your networkaccess server and your RADIUS or TACACS+ security server.

The chapters in this guide describe how to configure the following security server protocols:

A distributed client/server system implemented through AAA that secures networks againstunauthorized access. In the Cisco implementation, RADIUS clients run on Cisco routers and

RADIUS

send authentication requests to a central RADIUS server that contains all user authenticationand network service access information.

A security application implemented through AAA that provides a centralized validation ofusers who are attempting to gain access to a router or network access server. TACACS+

TACACS+

services are maintained in a database on a TACACS+ daemon running, typically, on a UNIXor Windows NT workstation. TACACS+ provides for separate and modular authentication,authorization, and accounting facilities.

Related Topics

• Configuring RADIUS, page 41• Configuring TACACS+, page 63


OverviewRADIUS and TACACS+ Security Protocols

User Accounts and RolesYou can create and manage user accounts and assign roles that limit access to operations on the Cisco NX-OSdevice. Role-based access control (RBAC) allows you to define the rules for an assign role that restrict theauthorization that the user has to access management operations.

Related Topics

• Configuring User Accounts and RBAC, page 87

802.1X802.1X defines a client-server-based access control and authentication protocol that restricts unauthorizedclients from connecting to a LAN through publicly accessible ports. The authentication server authenticateseach client connected to an Cisco NX-OS device port.

Until the client is authenticated, 802.1X access control allows only Extensible Authentication Protocol overLAN (EAPOL) traffic through the port to which the client is connected. After authentication is successful,normal traffic can pass through the port.

Related Topics

• Configuring 802.1X, page 111

IP ACLsIP ACLs are ordered sets of rules that you can use to filter traffic based on IPv4 information in the Layer 3header of packets. Each rule specifies a set of conditions that a packet must satisfy to match the rule. Whenthe Cisco NX-OS software determines that an IP ACL applies to a packet, it tests the packet against theconditions of all rules. The first match determines whether a packet is permitted or denied, or if there is nomatch, the Cisco NX-OS software applies the applicable default rule. The Cisco NX-OS software continuesprocessing packets that are permitted and drops packets that are denied.

Related Topics

• Configuring IP ACLs, page 135

MAC ACLsMAC ACLs are ACLs that filter traffic using the information in the Layer 2 header of each packet. Each rulespecifies a set of conditions that a packet must satisfy to match the rule. When the Cisco NX-OS softwaredetermines that a MAC ACL applies to a packet, it tests the packet against the conditions of all rules. Thefirst match determines whether a packet is permitted or denied, or if there is no match, the NX-OS softwareapplies the applicable default rule. The Cisco NX-OS software continues processing packets that are permittedand drops packets that are denied.

Related Topics

• Configuring MAC ACLs, page 169


OverviewUser Accounts and Roles

VACLsA VLAN ACL (VACL) is one application of an IP ACL or MAC ACL. You can configure VACLs to applyto all packets that are routed into or out of a VLAN or are bridged within a VLAN. VACLs are strictly forsecurity packet filtering and for redirecting traffic to specific physical interfaces. VACLs are not defined bydirection (ingress or egress).

Related Topics

• Configuring VLAN ACLs, page 179

Port SecurityPort security allows you to configure Layer 2 interfaces that allow inbound traffic from only a restricted setof MAC addresses. The MAC addresses in the restricted set are called secure MAC addresses. In addition,the device does not allow traffic from these MAC addresses on another interface within the same VLAN. Thenumber of MAC addresses that the device can secure is configurable per interface.

Related Topics

• Configuring Port Security, page 187

DHCP SnoopingDHCP snooping acts like a firewall between untrusted hosts and trusted DHCP servers. DHCP snoopingperforms the following activities:

• Validates DHCP messages received from untrusted sources and filters out invalid messages.

• Builds and maintains the DHCP snooping binding database, which contains information about untrustedhosts with leased IP addresses.

• Uses the DHCP snooping binding database to validate subsequent requests from untrusted hosts.

Dynamic ARP inspection (DAI) and IP Source Guard also use information stored in the DHCP snoopingbinding database.

Related Topics

• Configuring DHCP, page 209

Dynamic ARP InspectionDynamic ARP inspection (DAI) ensures that only valid ARP requests and responses are relayed. When DAIis enabled and properly configured, a Cisco NX-OS device performs these activities:

• Intercepts all ARP requests and responses on untrusted ports.

• Verifies that each of these intercepted packets has a valid IP-to-MAC address binding before updatingthe local ARP cache or before forwarding the packet to the appropriate destination.

• Drops invalid ARP packets.


OverviewVACLs

DAI can determine the validity of an ARP packet based on valid IP-to-MAC address bindings stored in aDHCP snooping binding database. This database is built by DHCP snooping if DHCP snooping is enabledon the VLANs and on the device. If the ARP packet is received on a trusted interface, the device forwardsthe packet without any checks. On untrusted interfaces, the device forwards the packet only if it is valid.

Related Topics

• Configuring Dynamic ARP Inspection, page 227

IP Source GuardIP Source Guard is a per-interface traffic filter that permits IP traffic only when the IP address and MACaddress of each packet matches one of two sources of IP and MAC address bindings:

• Entries in the DHCP snooping binding table.

• Static IP source entries that you configure.

Filtering on trusted IP and MAC address bindings helps prevent attacks that rely on spoofing the IP addressof a valid host. To circumvent IP Source Guard, an attacker would have to spoof both the IP address and theMAC address of a valid host.

Related Topics

• Configuring IP Source Guard, page 247

Keychain ManagementKeychain management allows you to create and maintain keychains, which are sequences of keys (sometimescalled shared secrets). You can use keychains with features that secure communications with other devicesby using key-based authentication. The device allows you to configure multiple keychains.

Some routing protocols that support key-based authentication can use a keychain to implement a hitless keyrollover for authentication.

Related Topics

• Configuring Keychain Management, page 253

Traffic Storm ControlTraffic storm control (also called traffic suppression) allows you to monitor the levels of the incoming trafficover a 1-second interval. During this interval, the traffic level, which is a percentage of the total availablebandwidth of the port, is compared with the traffic storm control level that you configured. When the ingresstraffic reaches the traffic storm control level that is configured on the port, traffic storm control drops thetraffic until the interval ends.

Related Topics

• Configuring Traffic Storm Control, page 263


OverviewIP Source Guard


OverviewTraffic Storm Control

C H A P T E R 3Using the Layer 2 Security Audit Wizard

This chapter describes how to use the Layer 2 Security Audit Wizard.


• Information About the Security Audit Wizard, page 9

• Licensing Requirements for the Security Audit Wizard, page 9

• Prerequisites for the Security Audit Wizard, page 10

• Platform Support for the Security Audit Wizard, page 10

• Configuring Layer 2 Security Using the Security Audit Wizard, page 10

• Field Descriptions for the Security Audit Wizard, page 18

• Additional References for the Security Audit Wizard, page 20

• Feature History for the Security Audit Wizard, page 21

Information About the Security Audit WizardThe Security Audit Wizard allows you to examine the existing Layer 2 security features, such as port security,dynamic ARP inspection (DAI), DHCP snooping, IP Source Guard, and traffic storm control, configured ondifferent devices. It also allows you to apply the configurations that are missing on the device.

Licensing Requirements for the Security Audit WizardThe following table shows the licensing requirements for this feature:

License RequirementProduct

The Security AuditWizard requires a LANEnterpriselicense. For a complete explanation of the Cisco

Cisco DCNM

DCNM licensing scheme and how to obtain and applylicenses, see the Cisco DCNM Installation andLicensing Guide, Release 5.x.



The Security Audit Wizard is not available in CiscoNX-OS. For a complete explanation of the Cisco

Cisco NX-OS

NX-OS licensing scheme for your platform, see theCisco NX-OS Licensing Guide.

Prerequisites for the Security Audit WizardThe Security Audit Wizard has the following prerequisites:

You should be familiar with the following features before you use the Security Audit Wizard to change thesecurity configuration:

• Address Resolution Protocol (ARP)

• DHCP snooping

• Port security

• IP Source Guard

• Traffic storm control

You must enable the following features on the device that you want to perform the audit on:

• DHCP snooping

• Port security

Platform Support for the Security Audit WizardThe following platform supports this feature. For platform-specific information, including guidelines andlimitations, system defaults, and configuration limits, see the corresponding documentation.

DocumentationPlatform

Cisco Nexus 7000 Series Switches DocumentationCisco Nexus 7000 Series Switches

Configuring Layer 2 Security Using the Security Audit WizardYou can use the Security Audit Wizard to configure Layer 2 security features such as port security, dynamicARP inspection, DHCP snooping, IP Source Guard, and traffic storm control.

Procedure

Step 1

From the toolbar, choose the icon.


Using the Layer 2 Security Audit WizardPrerequisites for the Security Audit Wizard


The Layer 2 Security Audit dialog box displays the welcome message with a list of steps to be performed.

This figure shows the Security Audit dialog box.

Figure 1: Security Audit Welcome Message

Step 2 Click Next.The Layer 2 Security Audit dialog box displays a list of available interfaces in the network that you can chooseto audit.


Using the Layer 2 Security Audit WizardConfiguring Layer 2 Security Using the Security Audit Wizard

This figure shows a list of available interfaces.

Figure 2: Layer 2 Security Audit Wizard: Select Interfaces

Step 3 From the Interfaces Available in Network area, choose the interfaces that you want to perform a security auditon and then click Add.

Step 4 (Optional) Click Save to save your selection.Step 5 Click Next.

The Layer 2 Security Audit dialog box displays a list of available VLANs in the network that you can chooseto audit.



This figure shows a list of available VLANs.

Figure 3: Layer 2 Security Audit Wizard: Select VLANs

Step 6 From the VLANs Available in Network area, choose the VLANs that you want to perform a security auditon and then click Add.

Step 7 Click Next.The Layer 2 Security Audit dialog box displays a list of traffic storm control configuration issues that arereported during the audit.



This figure shows a list of traffic storm control configuration issues reported by the wizard.

Figure 4: Layer 2 Security Audit Wizard: List of Traffic Storm Control Configuration Issues

Step 8 Click Next.The Layer 2 Security Audit dialog box displays a list of trust definition and IP Source Guard issues that arereported during the audit.



This figure shows a list of trust definition and IP Source Guard issues.

Figure 5: Layer 2 Security Audit Wizard: List of Trust Definition and IP Source Guard Issues

Step 9 (Optional) Click Fix all to fix all the reported issues.Step 10 Click Next.

The Layer 2 Security Audit dialog box displays a list of port security issues that are reported during the audit.



This figure shows a list of port security issues.

Figure 6: Layer 2 Security Audit Wizard: List of Port Security Issues

Step 11 (Optional) Click Fix all to fix all the issues that are reported.Step 12 Click Next.

The Layer 2 Security Audit dialog box displays a list of DHCP snooping and DAI issues that are reportedduring the audit.



This figure shows a list of DHCP snooping and DAI issues.

Figure 7: Layer 2 Security Audit Wizard: List of DHCP Snooping and DAI Issues

Step 13 (Optional) Click Fix all to fix all the issues that are reported.Step 14 Click Next.

The Layer 2 Security Audit dialog box displays the summary of the configurations to be applied on the device.



This figure shows a summary of the configurations.

Figure 8: Layer 2 Security Audit Wizard: Configuration Summary

Step 15 Click Finish to apply all the configuration settings to the device.

Field Descriptions for the Security Audit WizardThis section describes the fields for the Security Audit Wizard:

Security Audit Wizard: Select InterfacesTable 2: Security Audit Wizard: Select Interfaces

DescriptionField

Interface ID.Interface

Interface description.Description

Type of interface.Type


Using the Layer 2 Security Audit WizardField Descriptions for the Security Audit Wizard

Security Audit Wizard: Select VLANsTable 3: Security Audit Wizard: Select VLANs

DescriptionField

VLAN ID.VLAN ID

Name of the VLAN.VLAN Name

Security Audit Wizard: Apply Traffic Storm Control ConfigurationsTable 4: Security Audit Wizard: Apply Traffic Storm Control Configurations

DescriptionField


Value assigned for unicast traffic control.Unicast

Value assigned for multicast traffic control.Multicast

Value assigned for broadcast traffic control.Broadcast

Security Audit Wizard: Apply Trust Definitions and IP Source GuardTable 5: Security Audit Wizard: Apply Trust Definitions and IP Source Guard

DescriptionField


Trust state of the interface. Trusted interfaces areconfigured to receive traffic fromwithin the network.

DHCP Trust State

This field indicates whether DHCP Trust State isenabled.

Trust state of the interface. Trusted interfaces areconfigured to receive traffic fromwithin the network.

ARP Trust State

This field indicates whether ARP Trust State isenabled.

Whether IP Source Guard is enabled.IP Source Guard


Using the Layer 2 Security Audit WizardSecurity Audit Wizard: Select VLANs

Security Audit Wizard: Port SecurityTable 6: Security Audit Wizard: Port Security

DescriptionField


Whether the interface type is Access or Trunk.Port Type

Global port type for the device.Port Security

Maximum number of addresses that can be bound toa port.

Maximum Number of Secure Addresses

Whether stickiness is enabled for the host address.Stickiness

Violation action configured in the portsecurity-enabled interface. Valid values are protect,

Violation Action

restrict, and shutdown. The default violation actionis shutdown.

Whether the port can be configured for port security.Port Security Capable

Security Audit Wizard: DHCP Snooping and DAITable 7: Security Audit Wizard: DHCP Snooping and DAI

DescriptionField

VLAN ID.VLAN ID

Name of the VLAN.VLAN Name

Whether DHCP snooping is enabled for the VLAN.By default, this checkbox is unchecked.

DHCP Snooping

Whether DAI is enabled for the VLAN. By default,this checkbox is unchecked.

DAI

Additional References for the Security Audit WizardThis section includes additional information related to using the Security Audit Wizard.


Using the Layer 2 Security Audit WizardSecurity Audit Wizard: Port Security

Related Documents

Document TitleRelated Topic

Cisco NX-OS Licensing GuideCisco NX-OS Licensing

Cisco DCNM Installation and Licensing Guide,Release 5.x

Cisco DCNM Licensing

Feature History for the Security Audit WizardThis table lists the release history for this feature.

Table 8: Feature History for the Security Audit Wizard

Feature InformationReleasesFeature Name

No change from Release 5.1.5.2(1)Security Audit Wizard



This feature was introduced.4.0(1)Security Audit Wizard


Using the Layer 2 Security Audit WizardFeature History for the Security Audit Wizard


Using the Layer 2 Security Audit WizardFeature History for the Security Audit Wizard

C H A P T E R 4Configuring AAA

This chapter describes how to configure authentication, authorization, and accounting (AAA) on CiscoNX-OS devices.


• Information About AAA, page 23

• Prerequisites for AAA, page 27

• Licensing Requirements for AAA, page 27

• Platform Support for AAA, page 27

• Configuring AAA, page 28

• Field Descriptions for AAA, page 37

• Additional References for AAA, page 39

• Feature History for AAA, page 40

Information About AAAThis section includes information about AAA on Cisco NX-OS devices.

AAA Security ServicesThe AAA feature allows you to verify the identity of, grant access to, and track the actions of users managinga Cisco NX-OS device. Cisco NX-OS devices support Remote Access Dial-In User Service (RADIUS) orTerminal Access Controller Access Control System Plus (TACACS+) protocols.

Based on the user ID and password combination that you provide, Cisco NX-OS devices perform localauthentication or authorization using the local database or remote authentication or authorization using oneor more AAA servers. A preshared secret key provides security for communication between the Cisco NX-OSdevice and AAA servers. You can configure a common secret key for all AAA servers or for only a specificAAA server.

AAA security provides the following services:


Identifies users, including login and password dialog, challenge and response, messagingsupport, and, depending on the security protocol that you select, encryption.Authentication is the process of verifying the identity of the person or device accessing theCisco NX-OS device, which is based on the user ID and password combination provided

Authentication

by the entity trying to access the Cisco NX-OS device. Cisco NX-OS devices allow you toperform local authentication (using the local lookup database) or remote authentication(using one or more RADIUS or TACACS+ servers).

Provides access control.AAA authorization is the process of assembling a set of attributes that describe what theuser is authorized to perform. Authorization in the Cisco NX-OS software is provided by

Authorization

attributes that are downloaded fromAAA servers. Remote security servers, such as RADIUSand TACACS+, authorize users for specific rights by associating attribute-value (AV) pairs,which define those rights with the appropriate user.

Provides the method for collecting information, logging the information locally, and sendingthe information to the AAA server for billing, auditing, and reporting.The accounting feature tracks and maintains a log of every management session used toaccess the Cisco NX-OS device. You can use this information to generate reports for

Accounting

troubleshooting and auditing purposes. You can store accounting logs locally or send themto remote AAA servers.

The Cisco NX-OS software supports authentication, authorization, and accounting independently. Forexample, you can configure authentication and authorization without configuring accounting.

Note

Benefits of Using AAAAAA provides the following benefits:

• Increased flexibility and control of access configuration

• Scalability

• Standardized authentication methods, such as RADIUS and TACACS+

• Multiple backup devices

Remote AAA ServicesRemote AAA services provided through RADIUS and TACACS+ protocols have the following advantagesover local AAA services:

• It is easier to manage user password lists for each Cisco NX-OS device in the fabric.

• AAA servers are already deployed widely across enterprises and can be easily used for AAA services.

• You can centrally manage the accounting log for all Cisco NX-OS devices in the fabric.

• It is easier to manage user attributes for each Cisco NX-OS device in the fabric than using the localdatabases on the Cisco NX-OS devices.


Configuring AAABenefits of Using AAA

AAA Server GroupsYou can specify remote AAA servers for authentication, authorization, and accounting using server groups.A server group is a set of remote AAA servers that implement the same AAA protocol. The purpose of aserver group is to provide for failover servers in case a remote AAA server fails to respond. If the first remoteserver in the group fails to respond, the next remote server in the group is tried until one of the servers sendsa response. If all the AAA servers in the server group fail to respond, then that server group option is considereda failure. If required, you can specify multiple server groups. If the Cisco NX-OS device encounters errorsfrom the servers in the first group, it tries the servers in the next server group.

AAA Service Configuration OptionsThe AAA configuration in Cisco NX-OS devices is service based, which means that you can have separateAAA configurations for the following services:

• Console login authentication

• 802.1X authentication

• User management session accounting

• 802.1X accounting

You can specify the following authentication methods for the AAA services:

Uses the global pool of RADIUS servers for authentication.All RADIUS servers

Specified server groups

Uses the local username or password database for authentication.Local

Specifies that no AAA authentication be used.None

If you specify the all RADIUS servers method, rather than a specified server group method, the CiscoNX-OS device chooses the RADIUS server from the global pool of configured RADIUS servers, in theorder of configuration. Servers from this global pool are the servers that can be selectively configured ina RADIUS server group on the Cisco NX-OS device.

Note

This table shows the AAA authentication methods that you can configure for the AAA services.

Table 9: AAA Authentication Methods for AAA Services

AAA MethodsAAA Service

Server groups, local, and noneConsole login authentication

Server groups, local, and noneUser login authentication

Server groups only802.1X authentication


Configuring AAAAAA Server Groups

AAA MethodsAAA Service

Server groups and localUser management session accounting

Server groups and local802.1X accounting

For console login authentication, user login authentication, and user management session accounting, theCisco NX-OS device tries each option in the order specified. The local option is the default method whenother configured options fail.

Note

Authentication and Authorization Process for User LoginThe following list explains the process:

• When you log in to the required Cisco NX-OS device, you can use the Telnet, SSH, or console loginoptions.

• When you have configured the AAA server groups using the server group authentication method, theCisco NX-OS device sends an authentication request to the first AAA server in the group as follows:

◦ If the AAA server fails to respond, the next AAA server is tried and so on until the remote serverresponds to the authentication request.

◦ If all AAA servers in the server group fail to respond, the servers in the next server group are tried.

◦ If all configured methods fail, the local database is used for authentication.

• If the Cisco NX-OS device successfully authenticates you through a remote AAA server, then thefollowing possibilities apply:

◦ If the AAA server protocol is RADIUS, then user roles specified in the cisco-av-pair attribute aredownloaded with an authentication response.

◦ If the AAA server protocol is TACACS+, then another request is sent to the same server to get theuser roles specified as custom attributes for the shell.

◦ If the user roles are not successfully retrieved from the remote AAA server, then the user is assignedwith the vdc-operator role.

• If your username and password are successfully authenticated locally, the Cisco NX-OS device logsyou in and assigns you the roles configured in the local database.

"No more server groups left" means that there is no response from any server in all server groups. "Nomore servers left" means that there is no response from any server within this server group.

Note


Configuring AAAAuthentication and Authorization Process for User Login

Prerequisites for AAAThe following prerequisites are required for using this feature on Cisco DCNM. For a full list of feature-specificprerequisites, see the platform-specific documentation.

• System-message logging levels for AAA must meet or exceed Cisco DCNM requirements. Duringdevice discovery, Cisco DCNM detects inadequate logging levels and raises them to the minimumrequirements. Cisco Nexus 7000 Series switches that run Cisco NX-OS Release 4.0 are an exception.For Cisco NX-OS Release 4.0, prior to device discovery, use the command-line interface to configurelogging levels to meet or exceed Cisco DCNM requirements. For more information, see the .

Licensing Requirements for AAAThe following table shows the licensing requirements for this feature:


AAA requires no license. Any feature not includedin a license package is bundled with the Cisco DCNM

Cisco DCNM

and is provided at no charge to you. For anexplanation of the Cisco DCNM licensing scheme,see the Cisco DCNM Installation and LicensingGuide, Release 5.x.

AAA requires no license. Any feature not includedin a license package is bundled with the Cisco NX-OS

Cisco NX-OS

system images and is provided at no extra charge toyou. For an explanation of the Cisco NX-OS licensingscheme for your platform, see the licensing guide foryour platform.

Platform Support for AAAThe following platforms support this feature but may implement it differently. For platform-specific information,including guidelines and limitations, system defaults, and configuration limits, see the correspondingdocumentation.


Cisco Nexus 1000V Series Switches DocumentationCisco Nexus 1000V Series Switches






Configuring AAAPrerequisites for AAA






Configuring AAAThis section describes the tasks for configuring AAA on Cisco NX-OS devices.

Changing an AAA Authentication Rule MethodYou can change an AAA authentication rule method.

The methods include the following:

RADIUS server groupsGroup

Local database on the Cisco NX-OS deviceLocal

Username onlyNone

The default method is local.

The rules are applied in the sequence order. If all methods fail, the device uses the default local method.

Before You Begin

Configure RADIUS or TACACS+ server groups, as needed.

Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Rules.Step 2 Double-click Authentication Rules to display the list of accounting rules.Step 3 Click the rule to which to add a method.Step 4 Click the rule to change.

The Authentication Rules tab appears in the Details pane.

Step 5 From the Authentication Rules tab, click the method to change.Step 6 Double-click the method cell under Type and choose the method type from the drop-down list.Step 7 If you chose the Group method type, double-click the method cell under Server Group Name and choose a

server group name from the drop-down list. Click OK.Step 8 From the menu bar, choose File > Deploy to apply your changes to the device.

Related Topics

• Rearranging an AAA Authentication Rule Method, page 29

Adding an AAA Authentication Rule MethodYou can change an AAA authentication rule method.




Configuring AAAConfiguring AAA


Username onlyNone


The rules are applied in the sequence order. If all methods fail, the Cisco NX-OS device uses the default localmethod.

The configuration and operation of the AAA for the console login only apply to the default VDC.Note

Before You Begin


Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Rules.Step 2 From the Summary pane, double-click the device.Step 3 Double-click Authentication Rules to display the list of accounting rules.Step 4 Click the rule to which to add a method.


Step 5 Right-click on a method and click Add Method from the pop-up menu.A new rule displays at the end of the list with a sequence number and blank fields.

Step 6 Double-click the cell under Type in the new method and choose the method type from the drop-down list.If you chose None for the method type, it must always be the last method in thelist.

Note

Step 7 If you chose the Group method type, double-click the method cell under Server Group Name and choose aserver group name from the drop-down list. Click OK.

Step 8 From the menu bar, choose File > Deploy to apply your changes to the device.

Rearranging an AAA Authentication Rule MethodYou can rearrange the sequence of the methods for an AAA authentication rule.

The None method must always be the last method in the list.Note


Configuring AAARearranging an AAA Authentication Rule Method

Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Rules.Step 2 From the Summary pane, double-click the device.Step 3 Double-click Authentication Rules to display the list of accounting rules.Step 4 Click the rule which has the method that you want to rearrange.Step 5 The Authentication Rules tab appears in the Details pane with the list of methods.Step 6 Click the method that you want to rearrange.Step 7 Right-click and clickMove Up orMove Up from the pop-up menu.Step 8 From the menu bar, choose File > Deploy to apply your changes to the device.

Deleting an AAA Authentication Rule MethodYou can delete an AAA authentication rule method.

An AAA authentication rule must have at least one method. You can only delete a method when the rulehad more than one method.

Note

Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Rules.Step 2 From the Summary pane, double-click the device.Step 3 Double-click Authentication Rules to display the list of accounting rules.Step 4 Click the rule from which to delete a method.


Step 5 Click the method that you want to delete.You can only delete a method with sequence number 2 or greater. To delete the rule with sequencenumber 1, you must first rearrange the methods.

Note

Step 6 Right-click and click Delete Method from the pop-up menu.The rule disappears from the list and the sequence numbers are updated.


Related Topics

• Rearranging an AAA Authentication Rule Method, page 29


Configuring AAADeleting an AAA Authentication Rule Method

Enabling or Disabling the Default User Role for AAA AuthenticationYou can allow remote users who do not have a user role to log in to the Cisco NX-OS device through aRADIUS or TACACS+ remote authentication server using a default user role. When you disable the AAAdefault user role feature, remote users who do not have a user role cannot log in to the device.

You can enable or disable this feature for the VDC as needed. For the default VDC, the default role isnetwork-operator. For nondefault VDCs, the default VDC is vdc-operator.

Before You Begin

Make sure that you are in the correct VDC.

Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Server Groups.The available devices appear in the Summary pane.

Step 2 From the Summary pane, click the device on which you want to enable or disable the default user role forAAA authentication.Tabs appear for the server group settings and events in the Details pane.

Step 3 Do one of the following:

• To enable the default user role for AAA authentication, on the Settings tab, check Assign default userrole. This is the default setting.

• To disable the default user role for AAA authentication, on the Settings tab, uncheck Assign defaultuser role.


Enabling or Disabling Login Authentication Failure MessagesWhen you log in, the login is processed by rolling over to the local user database if the remote AAA serversdo not respond. In such cases, the following messages display on the user’s terminal if you have enabled loginfailure messages:Remote AAA servers unreachable; local authentication done.Remote AAA servers unreachable; local authentication failed.

Before You Begin


Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Server Groups.


Configuring AAAEnabling or Disabling the Default User Role for AAA Authentication

The available devices appear in the Summary pane.

Step 2 From the Summary pane, click the device on which you want to enable or disable login authentication failuremessages.Tabs appear for the server group settings and events in the Details pane.


• To enable login authentication failure messages, on the Settings tab, check Display failure message inconsole.

• To disable login authentication failure messages, on the Settings tab, uncheck Display failure messagein console. This is the default setting.


Enabling or Disabling AAA AuthenticationYou can enable or disable AAA authentication for user logins on a Cisco NX-OS device.

You can use Microsoft Challenge Handshake Authentication Protocol (MSCHAP), the Microsoft version ofCHAP, for user logins to a Cisco NX-OS device through either a RADIUS or TACACS+ remote authenticationserver, MSCHAP V2 for user logins through a RADIUS server, or ASCII for user passwords on a TACACS+server. By default, AAA authentication is disabled.

By default, the Cisco NX-OS device uses Password Authentication Protocol (PAP) authentication betweenthe CiscoNX-OS device and the remote server. If you enableMSCHAP orMSCHAPV2, you need to configureyour RADIUS server to recognize the MSCHAP and MSCHAP V2 vendor-specific attributes (VSAs).

This table shows the RADIUS VSAs required for MSCHAP and MSCHAP V2.

Table 10: MSCHAP and MSCHAP V2 RADIUS VSAs

DescriptionVSAVendor-Type NumberVendor-ID Number

Contains the challengesent by an AAA server to

MSCHAP-Challenge11311

an MSCHAP orMSCHAP V2 user. It canbe used in bothAccess-Request andAccess-Challengepackets.

Contains the responsevalue provided by an

MSCHAP-Response11211

MSCHAP or MSCHAPV2 user in response to thechallenge. It is only usedin Access-Requestpackets.


Configuring AAAEnabling or Disabling AAA Authentication

Before You Begin


Procedure


Step 2 From the Summary pane, click the device on which you want to enable or disable AAA authentication.Tabs appear for the server group settings and events in the Details pane.

Step 3 Choose ASCII,MSCHAP, orMSCHAPv2 to enable a particular type of AAA authentication or NONE todisable AAA authentication. The default setting is NONE.


Changing an AAA Accounting Rule MethodYou can change an AAA accounting rule method. The device supports TACACS+ and RADIUS methods foraccounting, which report user activity to TACACS+ or RADIUS security servers in the form of accountingrecords.

You can specify the following accounting methods:

Uses a specified RADIUS or TACACS+ server group for accounting.Server group

Uses the local username or password database for accounting.Local


If you have configured server groups and the server groups do not respond, by default, the local databaseis used for authentication.

Note

Before You Begin


Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Rules.Step 2 From the Summary pane, double-click the device.Step 3 Double-click Accounting Rules to display the list of accounting rules.Step 4 Click the rule to change.

The Accounting Rules tab appears in the Details pane.


Configuring AAAChanging an AAA Accounting Rule Method

Step 5 From the Accounting Rules tab, click the method to change.Step 6 Double-click the method cell under Type and choose the method type from the drop-down list.Step 7 If you chose the Group method type, double-click the method cell under Server Group Name and choose a

server group name from the drop-down list. Click OK.Step 8 From the menu bar, choose File > Deploy to apply your changes to the device.

Related Topics

• Adding an AAA Accounting Rule Method, page 34

Adding an AAA Accounting Rule MethodYou can add an AAA accounting rule method.





The rules are applied in the sequence order. If all methods fail, the device uses the default local method.

Before You Begin


Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Rules.Step 2 From the Summary pane, double-click the device.Step 3 Double-click Accounting Rules to display the list of accounting rules.Step 4 Click the rule to which to add a method.


Step 5 Right-click a method to add the new method after and click Add Method from the pop-up menu.A new method displays at the end of the list with a sequence number and blank fields.

Step 6 If the new method is after a method with type Local, right-click the new method and clickMove Up from thepop-up menu.

You cannot add methods after a method with typeLocal.

Note

Step 7 Double-click the cell under Type in the new method and click Group from the drop-down list.Step 8 Double-click the new method cell under Server Group Name.Step 9 Enter the server group name or choose a server group name from the drop-down list and click OK.Step 10 From the menu bar, choose File > Deploy to apply your changes to the device.


Configuring AAAAdding an AAA Accounting Rule Method

Rearranging an AAA Accounting Rule MethodYou can rearrange the sequence of the methods for an AAA accounting rule.

Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Rules.Step 2 From the Summary pane, double-click the device.Step 3 Double-click Accounting Rules to display the list of accounting rules.Step 4 Click the rule that has the method that you want to rearrange.

The Accounting Rules tab appears in the Details pane with the list of methods.

Step 5 Click the method that you want to rearrange.Step 6 Right-click and clickMove Up orMove Up from the pop-up menu.Step 7 From the menu bar, choose File > Deploy to apply your changes to the device.

Deleting an AAA Accounting Rule MethodYou can delete an AAA accounting rule method.

An AAA accounting rule must have at least one method. You can only a delete method when the rule hasmore than one method.

Note

Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Rules.Step 2 From the Summary pane, double-click the device.Step 3 Double-click Accounting Rules to display the list of accounting rules.Step 4 Click the rule from which to delete a method.


Step 5 Click the method that you want to delete.You can only delete a method with sequence number 2 or greater. To delete the rule with sequencenumber 1, you must first rearrange the methods.

Note

Step 6 Right-click and click Delete Method from the pop-up menu.The rule disappears from the list and the sequence numbers are updated.



Configuring AAARearranging an AAA Accounting Rule Method

Related Topics

• Rearranging an AAA Accounting Rule Method, page 35

Using AAA Server VSAs with Cisco NX-OS DevicesYou can use vendor-specific attributes (VSAs) to specify Cisco NX-OS user roles and SNMPv3 parameterson AAA servers.

About VSAsThe Internet Engineering Task Force (IETF) draft standard specifies a method for communicating VSAsbetween the network access server and the RADIUS server. The IETF uses attribute 26. VSAs allow vendorsto support their own extended attributes that are not suitable for general use. The Cisco RADIUS implementationsupports one vendor-specific option using the format recommended in the specification. The Cisco vendorID is 9, and the supported option is vendor type 1, which is named cisco-av-pair. The value is a string withthe following format:protocol : attribute separator value *

The protocol is a Cisco attribute for a particular type of authorization, the separator is = (equal sign) formandatory attributes, and * (asterisk) indicates optional attributes.

When you use RADIUS servers for authentication on a Cisco NX-OS device, the RADIUS protocol directsthe RADIUS server to return user attributes, such as authorization information, along with authenticationresults. This authorization information is specified through VSAs.

VSA FormatThe following VSA protocol options are supported by the Cisco NX-OS software:

Protocol used in access-accept packets to provide user profile information.Shell

Protocol used in accounting-request packets. If a value contains any white spaces,put it within double quotation marks.

Accounting

The following attributes are supported by the Cisco NX-OS software:

Lists all the roles assigned to the user. The value field is a string that stores the list of groupnames delimited by white space. For example, if you belong to roles network-operator and

roles

vdc-admin, the value field would be network-operator vdc-admin. This subattribute is sentin the VSA portion of the Access-Accept frames from the RADIUS server, and it can onlybe used with the shell protocol value. These examples use the roles attribute:shell:roles=network-operator vdc-admin

shell:roles*network-operator vdc-admin

The following examples show the roles attribute as supported by FreeRADIUS:Cisco-AVPair = shell:roles=\network-operator vdc-admin\

Cisco-AVPair = shell:roles*\network-operator vdc-admin\


Configuring AAAUsing AAA Server VSAs with Cisco NX-OS Devices

When you specify a VSA as shell:roles*"network-operator vdc-admin" or"shell:roles*\"network-operator vdc-admin\"", this VSA is flagged as an optionalattribute and other Cisco devices ignore this attribute.

Note

Stores accounting information in addition to the attributes covered by a standard RADIUSaccounting protocol. This attribute is sent only in the VSA portion of the Account-Request

accountinginfo

frames from the RADIUS client on the switch, and it can only be used with the accountingprotocol-related PDUs.

Specifying Cisco NX-OS User Roles and SMNPv3 Parameters on AAA ServersYou can use the VSA cisco-av-pair on AAA servers to specify user role mapping for the Cisco NX-OS deviceusing this format:shell:roles="roleA roleB …"

If you do not specify the role option in the cisco-av-pair attribute, the default user role is network-operator.

You can also specify your SNMPv3 authentication and privacy protocol attributes as follows:shell:roles="roleA roleB..." snmpv3:auth=SHA priv=AES-128

The SNMPv3 authentication protocol options are SHA and MD5. The privacy protocol options are AES-128and DES. If you do not specify these options in the cisco-av-pair attribute, MD5 and DES are the defaultauthentication protocols.

Field Descriptions for AAAThis section describes the fields for configuring AAA in the Cisco Data Center Network Manager (DCNM).

Security: AAA: Rules: Summary PaneTable 11: Security: AAA: Rules: Summary Pane

DescriptionField

Rule name. The name for all rules is default.Name

Service type.Service

Subservice type.Sub Service

Methods for the rule.Methods


Configuring AAAField Descriptions for AAA

Security: AAA: Rules: device: Authentication Rules: Rule: Authentication RulesTab

Table 12: Security: AAA: Rules: Device: Authentication Rules: Rule: Authentication Rules Tab

DescriptionField

Rule name. The name for all rulesis default.

Rule name

Service type.Service Type

Subservice type.Sub Service Type

Methods

Sequence Sequence number that determinesthe order in which the methods areexecuted.

Method type.Type

Server group nameServer Group Name

Security: AAA: Rules: device: Accounting Rules: Rule: Accounting Rules TabThis tab allows you to configure an AAA accounting rule.

Table 13: Security: AAA: Rules: Device: Accounting Rules: Rule: Accounting Rules Tab

DescriptionField

Name of rule. The name for allrules is default.

Rule name

Type of service.Service Type

Unused.Notify

Unused.BroadCast

Methods

Sequence Sequence number that determinesthe order in which the methods areexecuted.


Configuring AAASecurity: AAA: Rules: device: Authentication Rules: Rule: Authentication Rules Tab

DescriptionField

Type of method.Type

Name of the server group.Server Group Name

Security: AAA: Server Groups: device: Settings TabTable 14: Security: AAA: Server Groups: device: Settings Tab

DescriptionField

AAA authentication type. The options are ASCII,MSCHAP, MSCHAPv2, and NONE. The defaultsetting is NONE.

AAA authentication

Used to enable the default user role for AAAauthentication. The default setting is enabled.

Assign default user role

Used to enable login authentication failure messages.The default setting is disabled.

Display failure message in console

Additional References for AAAThis section includes additional information related to implementing AAA.

Related Documents





Standards

TitleStandards

—No new or modified standards are supported by thisfeature, and support for existing standards has notbeen modified by this feature.


Configuring AAASecurity: AAA: Server Groups: device: Settings Tab

MIBs

MIBs LinkMIBs

To locate and download MIBs, go to the followingURL:• CISCO-AAA-SERVER-MIB

• CISCO-AAA-SERVER-EXT-MIB http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml

Feature History for AAAThis table lists the release history for this feature.

Table 15: Feature History for AAA


Added support for the Cisco Nexus 3000Series Switches.

5.2(1)AAA

No change from Release 5.0.5.1(1)AAA

Added support for enabling or disablingAAA authentication for user logins.

5.0(2)AAA authentication

Added support for remote users who donot have a user role to log in to the Cisco

5.0(2)AAA authentication

NX-OS device through a RADIUS orTACACS+ remote authentication serverusing a default user role.

Added support for enabling or disablinglogin authentication failure messages.

5.0(2)Login authentication


Configuring AAAFeature History for AAA

http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml


C H A P T E R 5Configuring RADIUS

This chapter describes how to configure the Remote Access Dial-In User Service (RADIUS) protocol onCisco NX-OS devices.


• Information About RADIUS, page 41

• Licensing Requirements for RADIUS, page 44

• Prerequisites for RADIUS, page 45

• Platform Support for RADIUS, page 45

• Configuring RADIUS Servers, page 45

• Displaying RADIUS Server Statistics, page 57

• Where to Go Next , page 57

• Field Descriptions for RADIUS Server Groups and Servers, page 57

• Additional References for RADIUS, page 60

• Feature History for RADIUS, page 61

Information About RADIUSThe RADIUS distributed client/server system allows you to secure networks against unauthorized access. Inthe Cisco implementation, RADIUS clients run onCiscoNX-OS devices and send authentication and accountingrequests to a central RADIUS server that contains all user authentication and network service access information.

RADIUS Network EnvironmentsRADIUS can be implemented in a variety of network environments that require high levels of security whilemaintaining network access for remote users.

You can use RADIUS in the following network environments that require access security:

• Networks with multiple-vendor network devices, each supporting RADIUS. For example, networkdevices from several vendors can use a single RADIUS server-based security database.


• Networks already using RADIUS. You can add a Cisco NX-OS device with RADIUS to the network.This action might be the first step when you make a transition to a AAA server.

• Networks that require resource accounting. You can use RADIUS accounting independent of RADIUSauthentication or authorization. The RADIUS accounting functions allow data to be sent at the start andend of services, indicating the amount of resources (such as time, packets, bytes, and so on) used duringthe session. An Internet service provider (ISP) might use a freeware-based version of the RADIUS accesscontrol and accounting software to meet special security and billing needs.

• Networks that support authentication profiles. Using the RADIUS server in your network, you canconfigure AAA authentication and set up per-user profiles. Per-user profiles enable the Cisco NX-OSdevice to better manage ports using their existing RADIUS solutions and to efficiently manage sharedresources to offer different service-level agreements.

RADIUS OperationWhen a user attempts to log in and authenticate to a Cisco NX-OS device using RADIUS, the followingprocess occurs:

• The user is prompted for and enters a username and password.

• The username and encrypted password are sent over the network to the RADIUS server.

• The user receives one of the following responses from the RADIUS server:

The user is authenticated.ACCEPT

The user is not authenticated and is prompted to reenter the usernameand password, or access is denied.

REJECT

A challenge is issued by the RADIUS server. The challenge collectsadditional data from the user.

CHALLENGE

A request is issued by the RADIUS server, asking the user to select anew password.

CHANGE PASSWORD

The ACCEPT or REJECT response is bundled with additional data that is used for EXEC or networkauthorization. You must first complete RADIUS authentication before using RADIUS authorization. Theadditional data included with the ACCEPT or REJECT packets consists of the following:

• Services that the user can access, including Telnet, rlogin, or local-area transport (LAT) connections,and Point-to-Point Protocol (PPP), Serial Line Internet Protocol (SLIP), or EXEC services.

• Connection parameters, including the host or client IPv4 or IPv6 address, access list, and user timeouts.

RADIUS Server MonitoringAn unresponsive RADIUS server can cause a delay in processing AAA requests. You can configure the CiscoNX-OS device to periodically monitor a RADIUS server to check whether it is responding (or alive) to savetime in processing AAA requests. The Cisco NX-OS device marks unresponsive RADIUS servers as deadand does not send AAA requests to any dead RADIUS servers. The Cisco NX-OS device periodically monitorsthe dead RADIUS servers and brings them to the alive state once they respond. This monitoring processverifies that a RADIUS server is in a working state before real AAA requests are sent its way. Whenever a


Configuring RADIUSRADIUS Operation

RADIUS server changes to the dead or alive state, a Simple Network Management Protocol (SNMP) trap isgenerated and the Cisco NX-OS device displays an error message that a failure is taking place.

This figure shows the states for RADIUS server monitoring.

Figure 9: RADIUS Server States

The monitoring interval for alive servers and dead servers are different and can be configured by the user.The RADIUS server monitoring is performed by sending a test authentication request to the RADIUSserver.

Note

Vendor-Specific AttributesThe Internet Engineering Task Force (IETF) draft standard specifies a method for communicating VSAsbetween the network access server and the RADIUS server. The IETF uses attribute 26. VSAs allow vendorsto support their own extended attributes that are not suitable for general use. The Cisco RADIUS implementationsupports one vendor-specific option using the format recommended in the specification. The Cisco vendorID is 9, and the supported option is vendor type 1, which is named cisco-av-pair. The value is a string withthe following format:protocol : attribute separator value *


When you use RADIUS servers for authentication on a Cisco NX-OS device, the RADIUS protocol directsthe RADIUS server to return user attributes, such as authorization information, with authentication results.This authorization information is specified through VSAs.

The following VSA protocol options are supported by the Cisco NX-OS software:



Configuring RADIUSVendor-Specific Attributes

Protocol used in accounting-request packets. If a value contains any white spaces,you should enclose the value within double quotation marks.

Accounting

The Cisco NX-OS software supports the following attributes:

Lists all the roles to which the user belongs. The value field is a string that lists the rolenames delimited by white space. For example, if the user belongs to roles network-operator

roles

and vdc-admin, the value field would be network-operator vdc-admin. This subattribute,which the RADIUS server sends in the VSA portion of the Access-Accept frames, can onlybe used with the shell protocol value. The following examples show the roles attribute thatis supported by the Cisco Access Control Server (ACS):

shell:roles=network-operator vdc-admin

shell:roles*“network-operator vdc-admin

The following examples show the roles attribute that is supported by FreeRADIUS:

Cisco-AVPair = shell:roles=\network-operator vdc-admin\

Cisco-AVPair = shell:roles*\network-operator vdc-admin\

When you specify a VSA as shell:roles*"network-operator vdc-admin" or"shell:roles*\"network-operator vdc-admin\"", this VSA is flagged as an optionalattribute and other Cisco devices ignore this attribute.

Note

Stores accounting information in addition to the attributes covered by a standard RADIUSaccounting protocol. This attribute is sent only in the VSA portion of the Account-Request

accountinginfo

frames from the RADIUS client on the switch. It can be used only with the accountingprotocol data units (PDUs).

Licensing Requirements for RADIUSThis table shows the licensing requirements for this feature.


RADIUS requires no license. Any feature notincluded in a license package is bundled with the

Cisco DCNM

Cisco DCNM and is provided at no charge to you.For an explanation of the Cisco DCNM licensingscheme, see the Cisco DCNM Installation andLicensing Guide, Release 5.x.

RADIUS requires no license. Any feature notincluded in a license package is bundled with the

Cisco NX-OS

Cisco NX-OS system images and is provided at noextra charge to you. For an explanation of the CiscoNX-OS licensing scheme for your platform, see thelicensing guide for your platform.


Configuring RADIUSLicensing Requirements for RADIUS

Prerequisites for RADIUSThe following prerequisites are required for using this feature on Cisco DCNM. For a full list of feature-specificprerequisites, see the platform-specific documentation.

• System-message logging levels for RADIUS must meet or exceed Cisco DCNM requirements. Duringdevice discovery, Cisco DCNM detects inadequate logging levels and raises them to the minimumrequirements. Cisco Nexus 7000 Series switches that run Cisco NX-OS Release 4.0 are an exception.For Cisco NX-OS Release 4.0, prior to device discovery, use the command-line interface to configurelogging levels to meet or exceed Cisco DCNM requirements. For more information, see the .

Platform Support for RADIUSThe following platforms support this feature but may implement it differently. For platform-specific information,including guidelines and limitations, system defaults, and configuration limits, see the correspondingdocumentation.







Configuring RADIUS ServersThis section describes how to configure RADIUS servers on a Cisco NX-OS device.

RADIUS Server Configuration Process1 Establish the RADIUS server connections to the Cisco NX-OS device.

2 Configure the RADIUS secret keys for the RADIUS servers.

3 If needed, configure RADIUS server groups with subsets of the RADIUS servers for AAA authenticationmethods.

4 If needed, configure any of the following optional parameters:

• Dead-time interval

• RADIUS server specification allowed at user login

• Timeout interval

• TCP port


Configuring RADIUSPrerequisites for RADIUS






Related Topics

• Adding a RADIUS Server Host, page 46• Configuring a Global RADIUS Key, page 48

Adding a RADIUS Server HostTo access a remote RADIUS server, you must configure the IP address or hostname of a RADIUS server.You can configure up to 64 RADIUS servers.

By default, when you configure a RADIUS server IP address or hostname the Cisco NX-OS device, theRADIUS server is added to the default RADIUS server group. You can also add the RADIUS server toanother RADIUS server group.

Note

Before You Begin

Ensure that the server is already configured as a member of the server group.

Ensure that the server is configured to authenticate RADIUS traffic.

Ensure that the Cisco NX-OS device is configured as a RADIUS client of the AAA servers.

Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Server Groups.Step 2 From the Summary pane, double-click the device to display the server groups.Step 3 Click Default RADIUS Server Group.Step 4 From the menu bar, choose Server Groups > Add Server.

The Server Details appear in the Details pane.

Step 5 In the Server field, enter the RADIUS server IPv4 address, IPv6 address, or hostname in the Server field.Step 6 From the Server drop-down list, choose either the IPv4 address, IPv6 address, or hostname as the correct

server identifier type.If the server identifier format matches the identifier type selected, Cisco DCNM outlines the Serverfield in yellow to indicate that it is correct. If the server identifier format does not match the identifiertype, Cisco DCNM outlines the Server field in red to indicate an error. Change the address or theaddress type to correct this problem.

Note

Step 7 (Optional) In the Authentication Port field, enter a new UDP port number or clear the field to disableauthentication.The default authentication UDP port is 1812.

Step 8 (Optional) In the Accounting Port field, enter a new UDP port number or clear the field to disable accounting.The default accounting UDP port is 1813.

Step 9 (Optional) In the Test area, you can enter a username, password, and idle time interval in minutes for periodicserver host monitoring.The default username is test, the default password is test, and the default idle time interval is 0 minutes, whichdisables periodic monitoring.



Configuring RADIUSAdding a RADIUS Server Host

Related Topics

• Adding a RADIUS Server Group, page 49

Copying a RADIUS Server HostYou can copy the configuration of a RADIUS server host from one RADIUS server to another server group,either on the same Cisco NX-OS device or on another Cisco NX-OS device.

Before You Begin

Ensure that you have configured the server in the default RADIUS server group.

Ensure that you have created the target RADIUS server group.

Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Server Groups.Step 2 From the Summary pane, double-click the device to display the server groups.Step 3 Double-click Default RADIUS Server Group.

The list of RADIUS server hosts appears.

Step 4 Click the RADIUS server host you want to copy.Step 5 From the menu bar, choose Actions > Copy.

The RADIUS server host appears in the list of servers for the server group.

Step 6 Click the destination RADIUS server group.You can copy the server host configuration to a server group within the same device or in anotherdevice.

Note

Step 7 From the menu bar, choose Actions > Paste.Step 8 From the menu bar, choose File > Deploy to apply your changes to the device.

Related Topics

• Adding a RADIUS Server Host, page 46• Adding a RADIUS Server Group, page 49

Deleting a RADIUS Server HostYou can delete a RADIUS server host from a RADIUS server group.

Before You Begin

Add one or more RADIUS server hosts.


Configuring RADIUSCopying a RADIUS Server Host

Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Server Groups.Step 2 From the Summary pane, double-click the device to display the server groups.Step 3 Click Default RADIUS Server Group.Step 4 Click the desired RADIUS server.Step 5 From the menu bar, choose Server Groups > Delete Server.

The RADIUS server disappears from the list of servers.Step 6 From the menu bar, choose File > Deploy to apply your changes to the device.

Related Topics

• Adding a RADIUS Server Host, page 46

Configuring a Global RADIUS KeyYou can configure a RADIUS key for all servers used by the Cisco NX-OS device. A RADIUS key is a sharedsecret text string between the Cisco NX-OS device and the RADIUS server hosts. You can also configure aRADIUS key specific to a RADIUS server.

Before You Begin

Obtain the RADIUS key values for the remote RADIUS servers.

Configure the RADIUS key on the remote RADIUS servers.

Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Server Groups.Step 2 From the Summary pane, double-click the device to display the server groups.Step 3 Click Default RADIUS Server Group.Step 4 From the Details pane, click the Global Settings tab.Step 5 In the Key field, enter the RADIUS key.Step 6 (Optional) Check Encrypt if the key is in an encrypted format.

The default is clear text. The Cisco NX-OS software encrypts a clear text key before saving it to the runningconfiguration.


Related Topics

• Configuring a Key for a Specific RADIUS Server, page 49


Configuring RADIUSConfiguring a Global RADIUS Key

Configuring a Key for a Specific RADIUS ServerYou can configure a key on the Cisco NX-OS device for a specific RADIUS server. A RADIUS key is asecret text string shared between the Cisco NX-OS device and a specific RADIUS server.

Before You Begin

Configure one or more RADIUS server hosts.

Obtain the key value for the remote RADIUS server.

Configure the key on the RADIUS server.

Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Server Groups.Step 2 From the Summary pane, double-click the device to display the server groups.Step 3 Double-click Default RADIUS Server Group to display the list of RADIUS servers.Step 4 Click the desired RADIUS server.Step 5 From the Details pane, click the Server Details tab.Step 6 Check Override Defaults.Step 7 In the Key field, enter the RADIUS key.Step 8 The default is the global RADIUS key.Step 9 (Optional) Check Encrypt to encrypt the key.Step 10 From the menu bar, choose File > Deploy to apply your changes to the device.

Related Topics

• Adding a RADIUS Server Host, page 46• Configuring a Global RADIUS Key, page 48

Adding a RADIUS Server GroupYou can reference one or more remote AAA servers to authenticate users using server groups. All membersof a group must belong to the RADIUS protocol. The servers are tried in the same order in which you configurethem.

You can configure these server groups at any time but they only take effect when you apply them to an AAAservice.

Before You Begin



Configuring RADIUSConfiguring a Key for a Specific RADIUS Server

Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Server Groups.Step 2 From the Summary pane, click the device.Step 3 From the menu bar, choose Server Groups > RADIUS Server Group.

A new line appears at the end of the server group list for the device and the Details tab appears in the Detailspane.

Step 4 In the Server Group Name field, enter the name and press the Enter key.The server group name is a case-sensitive alphanumeric string with a maximum length of 127 characters.

Step 5 (Optional) In the Dead time(mins) field, enter the number of minutes for the dead-time interval.The default dead-time interval is 0 minutes.

Step 6 In the VRF Name field, click the down arrow to display the VRF Name dialog and click a VRF. Click OK.Step 7 From the menu bar, choose File > Deploy to apply your changes to the device.

Adding a RADIUS Server Host to a RADIUS Server GroupYou can add a RADIUS server host to a RADIUS server group.

Before You Begin

Ensure that you have added the RADIUS server host to the Default RADIUS Server Group.

Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Server Groups.Step 2 From the Summary pane, double-click the device to display the server groups.Step 3 Click a RADIUS server group.Step 4 From the menu bar, choose Server Groups > Add Server.

The Server Details appear in the Details pane.

Step 5 In the Server field, enter the RADIUS server IPv4 address, IPv6 address, or hostname in the Server field.Step 6 From the Server drop-down list, choose either the IPv4 address, IPv6 address, or hostname as the correct


Note


Related Topics



Configuring RADIUSAdding a RADIUS Server Host to a RADIUS Server Group

Deleting a RADIUS Server Host from a RADIUS Server GroupYou can delete a RADIUS server host from a RADIUS server group.

Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Server Groups.Step 2 From the Summary pane, double-click the device to display the server groups.Step 3 Double-click the server group to display the list of server hosts.Step 4 Click the RADIUS server host to delete.Step 5 From the menu bar, choose Server Groups > Delete Server and click Yes on the confirmation dialog.Step 6 The RADIUS server host disappears from the list.Step 7 From the menu bar, choose File > Deploy to apply your changes to the device.

Related Topics

• Adding a RADIUS Server Host to a RADIUS Server Group, page 50

Deleting a RADIUS Server GroupYou can delete a RADIUS server group.

Before You Begin

Ensure that all servers in the group are RADIUS servers.

Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Server Groups.Step 2 From the Summary pane, double-click the device to display the list of server groups.Step 3 Click the RADIUS server group to delete.Step 4 From the menu bar, choose Server Groups > Delete Server Group and clickYes in the confirmation dialog.

The server group disappears from the server group list.Step 5 From the menu bar, choose File > Deploy to apply your changes to the device.

Configuring the Global Source Interface for RADIUS Server GroupsYou can configure a global source interface for RADIUS server groups to use when accessing RADIUSservers. This configuration forces the RADIUS servers to use the IP address of the source interface for alloutgoing RADIUS packets. By default, the Cisco NX-OS software uses any available interface.


Configuring RADIUSDeleting a RADIUS Server Host from a RADIUS Server Group

Before You Begin


Procedure


Step 2 From the Summary pane, double-click the device to display the server groups.Step 3 Click Default RADIUS Server Group.Step 4 From the Details pane, click the Global Settings tab.Step 5 From the Source Interface drop-down list, choose an Ethernet interface, a loopback interface, a port-channel

interface, a tunnel interface, a VLAN interface, or the management interface (mgmt 0).Step 6 Click OK.Step 7 From the menu bar, choose File > Deploy to apply your changes to the device.

Related Topics

• Configuring a Source Interface for a Specific RADIUS Server Group, page 52

Configuring a Source Interface for a Specific RADIUS Server GroupYou can configure a source interface for a specific RADIUS server group to use when accessing RADIUSservers. This configuration forces the RADIUS servers to use the IP address of the source interface for alloutgoing RADIUS packets.

This configuration overrides the global source interface for this server group.Note

Before You Begin


Procedure


Step 2 From the Summary pane, double-click the device to display the server groups.Step 3 Click the desired RADIUS server group.Step 4 From the Details pane, click the Details tab.Step 5 From the Source Interface drop-down list, choose an Ethernet interface, a loopback interface, a port-channel



Configuring RADIUSConfiguring a Source Interface for a Specific RADIUS Server Group

Related Topics

• Configuring the Global Source Interface for RADIUS Server Groups, page 51

Allowing Users to Specify a RADIUS Server at LoginBy default, the CiscoNX-OS device forwards an authentication request based on the default AAA authenticationmethod. You can configure the Cisco NX-OS device to allow the user to specify a VRF and RADIUS serverto send the authentication request by enabling the directed-request option. If you enable this option, the usercan log in as username@vrfname:hostname, where vrfname is the VRF to use and hostname is the name ofa configured RADIUS server.

If you enable the directed-request option, the device uses only the RADIUS method for authenticationand not the default local method.

Note

User-specified logins are supported only for Telnet sessions.Note

Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Server Groups.Step 2 From the Summary pane, double-click the device to display the server groups.Step 3 Click Default RADIUS Server Group.Step 4 From the Details pane, click the Global Settings tab.Step 5 Click Direct Req.Step 6 From the menu bar, choose File > Deploy to apply your changes to the device.

Configuring the Global RADIUS Transmission Retry Count and Timeout IntervalYou can configure a global retransmission retry count and timeout interval for all RADIUS servers. By default,a Cisco NX-OS device retries transmission to a RADIUS server only once before reverting to localauthentication. You can increase this number up to a maximum of five retries per server. The timeout intervaldetermines how long the Cisco NX-OS device waits for responses from RADIUS servers before declaring atimeout failure.


Configuring RADIUSAllowing Users to Specify a RADIUS Server at Login

Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Server Groups.Step 2 From the Summary pane, double-click the device to display the server groups.Step 3 Click Default RADIUS Server Group.Step 4 From the Details pane, click the Global Settings tab.Step 5 In the Retransmit field, enter a number of retransmit attempts.

The default is 1.

Step 6 In the Time out(secs) field, enter the number of seconds for the timeout interval.The default is 1.


Related Topics

• Configuring the RADIUS Transmission Retry Count and Timeout Interval for a Server, page 54

Configuring the RADIUS Transmission Retry Count and Timeout Interval for aServer

By default, a Cisco NX-OS device retries a transmission to a RADIUS server only once before reverting tolocal authentication. You can increase this number up to a maximum of five retries per server. You can alsoset a timeout interval that the Cisco NX-OS device waits for responses fromRADIUS servers before declaringa timeout failure.

Before You Begin


Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Server Groups.Step 2 From the Summary pane, double-click the device to display the server groups.Step 3 Double-click Default RADIUS Server Group to display the list of RADIUS servers.Step 4 Click the desired RADIUS server.Step 5 From the Details pane, click the Server Details tab.Step 6 Check Override Defaults.Step 7 In the Retransmit field, enter the number of retransmit attempts.

The default is 1.

Step 8 In the Timeout(secs) field, enter the number of seconds for the retransmission interval.The default is 5 seconds.



Configuring RADIUSConfiguring the RADIUS Transmission Retry Count and Timeout Interval for a Server

Related Topics

• Configuring the Global RADIUS Transmission Retry Count and Timeout Interval, page 53

Configuring Accounting and Authentication Attributes for RADIUS ServersYou can specify that a RADIUS server is to be used only for accounting purposes or only for authenticationpurposes. By default, RADIUS servers are used for both accounting and authentication. You can also specifythe destination UDP port numbers where RADIUS accounting and authentication messages should be sent ifthere is a conflict with the default port.

Before You Begin


Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Server Groups.Step 2 From the Summary pane, double-click the device to display the server groups.Step 3 Double-click Default RADIUS Server Group to display the list of RADIUS servers.Step 4 Click the desired RADIUS server.Step 5 From the Details pane, click the Server Details tab.Step 6 (Optional) In the Authentication Port field, enter a new UDP port number or clear the field to disable

authentication.The default authentication UDP port is 1812.

Step 7 (Optional) In the Accounting Port field, enter a new UDP port number or clear the field to disable accounting.The default accounting UDP port is 1813.


Related Topics


Configuring Periodic RADIUS Server MonitoringYou can monitor the availability of RADIUS servers. These parameters include the username and passwordto use for the server and an idle timer. The idle timer specifies the interval during which a RADIUS serverreceives no requests before the Cisco NX-OS device sends out a test packet. You can configure this optionto test servers periodically.

For security reasons, we recommend that you do not configure a test username that is the same as anexisting user in the RADIUS database.

Note


Configuring RADIUSConfiguring Accounting and Authentication Attributes for RADIUS Servers

The test idle timer specifies the interval during which a RADIUS server receives no requests before the CiscoNX-OS device sends out a test packet.

The default idle timer value is 0 minutes. When the idle time interval is 0 minutes, the Cisco NX-OSdevice does not perform periodic RADIUS server monitoring.

Note

Before You Begin

Add one or more RADIUS server hosts.

Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Server Groups.Step 2 From the Summary pane, double-click the device to display the server groups.Step 3 Double-click Default RADIUS Server Group to display the list of RADIUS servers.Step 4 Click the desired RADIUS server.Step 5 From the Details pane, click the Server Details tab.Step 6 In the User Name field, enter a username.Step 7 In the Password field, enter a password.Step 8 In the Idle Time field, enter the number of minutes for periodic monitoring.Step 9 From the menu bar, choose File > Deploy to apply your changes to the device.

Related Topics


Configuring the RADIUS Dead-Time IntervalYou can configure the dead-time interval for all RADIUS servers. The dead-time interval specifies the timethat the Cisco NX-OS device waits after declaring a RADIUS server is dead, before sending out a test packetto determine if the server is now alive. The default value is 0 minutes.

When the dead-time interval is 0 minutes, RADIUS servers are not marked as dead even if they are notresponding. You can configure the dead-time interval for a RADIUS server group.

Note


Configuring RADIUSConfiguring the RADIUS Dead-Time Interval

Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Server Groups.Step 2 From the Summary pane, double-click the device to display the server groups.Step 3 Click Default RADIUS Server Group.Step 4 From the Details pane, click the Global Settings tab.Step 5 In the Dead time(mins) field, enter the number of minutes.

The default is 0 minutes.


Related Topics

• Adding a RADIUS Server Group, page 49

Displaying RADIUS Server StatisticsYou can display the statistics that the Cisco NX-OS device maintains for the RADIUS servers.

Before You Begin


Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Server Groups.Step 2 From the Summary pane, double-click the device to display the server groups.Step 3 Double-click Default RADIUS Server Group to display the list of RADIUS servers.Step 4 Click the desired RADIUS server.Step 5 From the Details pane, click the Statistics tab.

Where to Go NextYou can now configure AAA authentication methods to include the server groups.

Field Descriptions for RADIUS Server Groups and ServersThis section includes field descriptions for RADIUS server groups and servers.


Configuring RADIUSDisplaying RADIUS Server Statistics

Security: AAA: Server Groups: Summary PaneTable 16: Security: AAA: Server Groups: Summary Pane

DescriptionFields

UDP port number for authentication traffic for theservers. The default is 49.

Authentication Port

UDP port used for accounting for the servers.Accounting Port

Number of seconds for the timeout interval for theservers. The default is 5 seconds.

Timeout

Status of the servers.Status

Security: AAA: Server Groups: device: Default RADIUS Server Group: GlobalSettings Tab

Table 17: Security: AAA: Server Groups: device: Default RADIUS Server Group: Global Settings Tab

DescriptionField

Server group type.Server Group Type

Number of seconds for the timeout interval. Thedefault is 5 seconds.

Time out(secs)

Global RADIUS key.Key

Source interface for a specific RADIUS server groupto use when accessing RADIUS servers. The options

Source Interface

are an Ethernet interface, a loopback interface, or themanagement interface (mgmt 0).

Number of retransmissions when the server does notrespond.

Retransmit

Number of minutes for the dead time interval. Thedefault is 0 minutes.

Dead time(mins)

Users can specify a RADIUS server at login.Direct Req


Configuring RADIUSSecurity: AAA: Server Groups: Summary Pane

Security: AAA: Server Groups: device: Default RADIUS Server Group: server:Server Details Tab

Table 18: Security: AAA: Server Groups: device: Default RADIUS Server Group: Server: Server Details Tab

DescriptionFields

General

Server Type Server type.

Server IPv4 address, IPv6 address,or alphanumeric name and theserver name type.

Server

UDP port number forauthentication traffic. The defaultis 1812.

Authentication Port

UDP port number for accountingtraffic. The default is 1813.

Accounting Port

Test

User Name Username for periodic monitoringof the RADIUS server.

Password for periodic monitoringof the RADIUS server.

Password

Number of minutes for the idletime interval for periodic

Idle Time

monitoring of the RADIUS server.The default is 0, which disablesperiodic monitoring.

Global values that you can overrideand configure for the RADIUS

Override Default

server. The default is to use theglobal values.

Secret key for the RADIUS server.Key

RADIUS server key encryptionstatus. The default is clear text.

Encrypt

Number of seconds for the timeoutinterval. The default is 5 seconds.

Timeout(secs)


Configuring RADIUSSecurity: AAA: Server Groups: device: Default RADIUS Server Group: server: Server Details Tab

DescriptionFields

Number of retransmissions whenthe server does not respond. Thedefault is 3.

Retransmit

Security: AAA: Server Groups: device: server group: Details TabTable 19: Security: AAA: Server Groups: device: server group : Details Tab

DescriptionFields

Displays RADIUS for the server group type.Type

Displays the server group name.Server Group Name

Number of minutes for the dead-time interval for theserver group. The default is 0 minutes.

Dead time(mins)

VRF name.VRF Name


Source Interface


Additional References for RADIUSThis section describes additional information related to implementing RADIUS.

Related Documents





VRF configuration


Configuring RADIUSSecurity: AAA: Server Groups: device: server group: Details Tab

Standards

TitleStandards


MIBs

MIBs LinkMIBs



Feature History for RADIUSThis table lists the release history for this feature.

Table 20: Feature History for RADIUS


Added support for the Cisco Nexus3000 Series Switches.

5.2(1)RADIUS

No change from Release 5.0.5.1(1)RADIUS

Added support for configuring theglobal source interface for allRADIUS server groups.

5.0(2)RADIUS server groups

Added support for configuring asource interface for a specificRADIUS server group.

5.0(2)RADIUS server groups


Configuring RADIUSFeature History for RADIUS




Configuring RADIUSFeature History for RADIUS

C H A P T E R 6Configuring TACACS+

This chapter describes how to configure the Terminal Access Controller Access Control System Plus(TACACS+) protocol on Cisco NX-OS devices.


• Information About TACACS+, page 63

• Licensing Requirements for TACACS+, page 67

• Prerequisites for TACACS+, page 68

• Platform Support for TACACS+, page 68

• Configuring TACACS+, page 68

• Displaying TACACS+ Statistics, page 80

• Where to Go Next , page 81

• Field Descriptions for TACACS+ Server Groups and Servers, page 81

• Additional References for TACACS+, page 84

• Feature History for TACACS+, page 84

Information About TACACS+The TACACS+ security protocol provides centralized validation of users attempting to gain access to a CiscoNX-OS device. TACACS+ services are maintained in a database on a TACACS+ daemon running, typically,on a UNIX or Windows NT workstation. You must have access to and must configure a TACACS+ serverbefore the configured TACACS+ features on your Cisco NX-OS device are available.

TACACS+ provides for separate authentication, authorization, and accounting facilities. TACACS+ allowsfor a single access control server (the TACACS+ daemon) to provide each service—authentication,authorization, and accounting—independently. Each service can be tied into its own database to take advantageof other services available on that server or on the network, depending on the capabilities of the daemon.

The TACACS+ client/server protocol uses TCP (TCP port 49) for transport requirements. Cisco NX-OSdevices provide centralized authentication using the TACACS+ protocol.


TACACS+ AdvantagesTACACS+ has the following advantages over RADIUS authentication:

• Provides independent AAA facilities. For example, the Cisco NX-OS device can authorize access withoutauthenticating.

• Uses the TCP transport protocol to send data between the AAA client and server, making reliable transferswith a connection-oriented protocol.

• Encrypts the entire protocol payload between the switch and the AAA server to ensure higher dataconfidentiality. The RADIUS protocol only encrypts passwords.

TACACS+ Operation for User LoginWhen a user attempts a Password Authentication Protocol (PAP) login to a Cisco NX-OS device usingTACACS+, the following actions occur:

TACACS+ allows an arbitrary conversation between the daemon and the user until the daemon receivesenough information to authenticate the user. This action is usually done by prompting for a username andpassword combination, but may include prompts for other items, such as your mother’s maiden name.

Note

1 When the Cisco NX-OS device establishes a connection, it contacts the TACACS+ daemon to obtain theusername and password.

2 The Cisco NX-OS device will eventually receive one of the following responses from the TACACS+daemon:

User authentication succeeds and service begins. If the Cisco NX-OS device requiresuser authorization, authorization begins.

ACCEPT

User authentication failed. The TACACS+ daemon either denies further access tothe user or prompts the user to retry the login sequence.

REJECT

An error occurred at some time during authentication either at the daemon or in thenetwork connection between the daemon and the Cisco NX-OS device. If the Cisco

ERROR

NX-OS device receives an ERROR response, the Cisco NX-OS device tries to usean alternative method for authenticating the user.

After authentication, the user also undergoes an additional authorization phase if authorization has beenenabled on the NX-OS device. Users must first successfully complete TACACS+ authentication beforeproceeding to TACACS+ authorization.

3 If TACACS+ authorization is required, the Cisco NX-OS device again contacts the TACACS+ daemonand it returns an ACCEPT or REJECT authorization response. An ACCEPT response contains attributesthat are used to direct the EXEC or NETWORK session for that user and determines the services that theuser can access.

Services include the following:

• Telnet, rlogin, Point-to-Point Protocol (PPP), Serial Line Internet Protocol (SLIP), or EXEC services


Configuring TACACS+TACACS+ Advantages

• Connection parameters, including the host or client IP address (IPv4 or IPv6), access list, and usertimeouts

Default TACACS+ Server Encryption Type and Secret KeyYou must configure the TACACS+ secret key to authenticate the switch to the TACACS+ server. A secretkey is a secret text string shared between the Cisco NX-OS device and the TACACS+ server host. The lengthof the key is restricted to 63 characters and can include any printable ASCII characters (white spaces are notallowed). You can configure a global secret key for all TACACS+ server configurations on the Cisco NX-OSdevice to use.

You can override the global secret key assignment when configuring an individual TACACS+ server.

TACACS+ Server MonitoringAn unresponsive TACACS+ server can delay the processing of AAA requests. A Cisco NX-OS device canperiodically monitor a TACACS+ server to check whether it is responding (or alive) to save time in processingAAA requests. The Cisco NX-OS device marks unresponsive TACACS+ servers as dead and does not sendAAA requests to any dead TACACS+ servers. A Cisco NX-OS device periodically monitors dead TACACS+servers and brings them to the alive state once they are responding. This process verifies that a TACACS+server is in a working state before real AAA requests are sent its way. Whenever a TACACS+ server changesto the dead or alive state, a Simple Network Management Protocol (SNMP) trap is generated and the CiscoNX-OS device displays an error message that a failure is taking place before it can impact performance.

This figure shows the server states for TACACS+ server monitoring.

Figure 10: TACACS+ Server States


Configuring TACACS+Default TACACS+ Server Encryption Type and Secret Key

The monitoring interval for alive servers and dead servers are different and can be configured by the user.The TACACS+ server monitoring is performed by sending a test authentication request to the TACACS+server.

Note

TACACS+ Configuration DistributionCisco Fabric Services (CFS) allows the Cisco NX-OS device to distribute the TACACS+ configuration toother Cisco NX-OS devices in the network. When you enable CFS distribution for a feature on your device,the device belongs to a CFS region containing other devices in the network that you have also enabled forCFS distribution for the feature. CFS distribution for TACACS+ is disabled by default.

Youmust explicitly enable CFS for TACACS+ on each device to which you want to distribute configurationchanges.

Note

After you enable CFS distribution for TACACS+ on your Cisco NX-OS device, the first TACACS+configuration command that you enter causes the Cisco NX-OS software to take the following actions:

• Creates a CFS session on your Cisco NX-OS device.

• Locks the TACACS+ configuration on all Cisco NX-OS devices in the CFS region with CFS enabledfor TACACS+.

• Saves the TACACS+ configuration changes in a temporary buffer on the Cisco NX-OS device.

The changes stay in the temporary buffer on the Cisco NX-OS device until you explicitly commit them to bedistributed to the devices in the CFS region. When you commit the changes, the Cisco NX-OS software takesthe following actions:

• Applies the changes to the running configuration on your Cisco NX-OS device.

• Distributes the updated TACACS+ configuration to the other Cisco NX-OS devices in the CFS region.

• Unlocks the TACACS+ configuration in the devices in the CFS region.

• Terminates the CFS session.

CFS does not distribute the TACACS+ server group configuration, periodic TACACS+ server testingconfigurations, or server and global keys. The keys are unique to the Cisco NX-OS device and are not sharedwith other Cisco NX-OS devices.

For detailed information on CFS, see the .

Vendor-Specific Attributes for TACACS+The Internet Engineering Task Force (IETF) draft standard specifies a method for communicatingvendor-specific attributes (VSAs) between the network access server and the TACACS+ server. The IETFuses attribute 26. VSAs allow vendors to support their own extended attributes that are not suitable for generaluse.


Configuring TACACS+TACACS+ Configuration Distribution

Cisco VSA Format for TACACS+The Cisco TACACS+ implementation supports one vendor-specific option using the format recommendedin the IETF specification. The Cisco vendor ID is 9, and the supported option is vendor type 1, which is namedcisco-av-pair. The value is a string with the following format:protocol : attribute separator value *


When you use TACACS+ servers for authentication on a Cisco NX-OS device, the TACACS+ protocol directsthe TACACS+ server to return user attributes, such as authorization information, along with authenticationresults. This authorization information is specified through VSAs.

The following VSA protocol options are supported by the Cisco NX-OS software:


Protocol used in accounting-request packets. If a value contains any white spaces,you should enclose the value within double quotation marks.

Accounting

The Cisco NX-OS software supports the following attributes:

Lists all the roles to which the user belongs. The value field is a string that lists the rolenames delimited by white space. For example, if the user belongs to roles network-operator

roles

and vdc-admin, the value field would be network-operator vdc-admin. This subattribute,which the TACACS+ server sends in the VSA portion of the Access-Accept frames, canonly be used with the shell protocol value. The following examples show the roles attributeas supported by Cisco ACS:shell:roles=network-operator vdc-admin

shell:roles*network-operator vdc-admin

When you specify a VSA as shell:roles*"network-operator vdc-admin", thisVSA is flagged as an optional attribute and other Cisco devices ignore thisattribute.

Note

Stores accounting information in addition to the attributes covered by a standard TACACS+accounting protocol. This attribute is sent only in the VSA portion of the Account-Request

accountinginfo

frames from the TACACS+ client on the switch. It can be used only with the accountingprotocol data units (PDUs).

Licensing Requirements for TACACS+The following table shows the licensing requirements for this feature:


TACACS+ requires no license. Any feature notincluded in a license package is bundled with the

Cisco DCNM

Cisco DCNM and is provided at no charge to you.


Configuring TACACS+Licensing Requirements for TACACS+


For an explanation of the Cisco DCNM licensingscheme, see the Cisco DCNM Installation andLicensing Guide, Release 5.x.

TACACS+ requires no license. Any feature notincluded in a license package is bundled with the

Cisco NX-OS


Prerequisites for TACACS+The following prerequisites are required for using this feature on Cisco DCNM. For a full list of feature-specificprerequisites, see the platform-specific documentation.

• System-message logging levels for TACACS+must meet or exceed Cisco DCNM requirements. Duringdevice discovery, Cisco DCNM detects inadequate logging levels and raises them to the minimumrequirements. Cisco Nexus 7000 Series switches that run Cisco NX-OS Release 4.0 are an exception.For Cisco NX-OS Release 4.0, prior to device discovery, use the command-line interface to configurelogging levels to meet or exceed Cisco DCNM requirements. For more information, see the .

Platform Support for TACACS+The following platforms support this feature but may implement it differently. For platform-specific information,including guidelines and limitations, system defaults, and configuration limits, see the correspondingdocumentation.







Configuring TACACS+This section describes how to configure TACACS+ on a Cisco NX-OS device.


Configuring TACACS+Prerequisites for TACACS+






If you are familiar with the Cisco IOS CLI, be aware that the Cisco NX-OS commands for this featuremight differ from the Cisco IOS commands that you would use.

Note

TACACS+ Server Configuration Process

Procedure

Step 1 Enable TACACS+.Step 2 Establish the TACACS+ server connections to the Cisco NX-OS device.Step 3 Configure the secret keys for the TACACS+ servers.Step 4 If needed, configure TACACS+ server groups with subsets of the TACACS+ servers for AAA authentication

methods.Step 5 (Optional) Configure the TCP port.Step 6 (Optional) If needed, configure periodic TACACS+ server monitoring.

Enabling TACACS+By default, the TACACS+ feature is disabled on the device. You must explicitly enable the TACACS+ featureto access the configuration and verification commands for authentication.

Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Server Groups.Step 2 From the Summary pane, click the device.Step 3 From the menu bar, choose Actions > Enable TACACS.Step 4 From the menu bar, choose File > Deploy to apply your changes to the device.

Related Topics

• Disabling TACACS+ , page 80

Adding a TACACS+ Server HostTo access a remote TACACS+ server, you must add the TACACS+ server hosts and configure the IP addressor the hostname for the TACACS+ server on the device. You can add up to 64 TACACS+ servers.


Configuring TACACS+TACACS+ Server Configuration Process

By default, when you configure a TACACS+ server IP address or hostname on the Cisco NX-OS device,the TACACS+ server is added to the default TACACS+ server group. You can also add the TACACS+server to another TACACS+ server group.

Note

Before You Begin

Obtain the IPv4 or IPv6 addresses or the hostnames for the remote TACACS+ servers.

Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Server Groups.Step 2 From the Summary pane, double-click the device to display the server groups.Step 3 Click Default TACACS Server Group.Step 4 From the menu bar, choose Actions > Add Server.

The Server Details appears in the Details pane.Step 5 In the Server field, enter the TACACS+ server IPv4 address, IPv6 address, or hostname.Step 6 From the Server drop-down list, choose either the IPv4 address, IPv6 address, or hostname as the correct


Note

Step 7 (Optional) In the Authentication Port field, enter a new TCP port number or clear it to disable authentication.The default authentication TCP port is 49.

Step 8 (Optional) In the Test area, you can enter a username, password, and idle time interval in minutes for periodicserver host monitoring.The default username is test, the default password is test, and the default idle time interval is 0 minutes, whichdisables periodic monitoring.


Related Topics

• Enabling TACACS+ , page 69

Copying a TACACS+ Server HostYou can copy the configuration of a TACACS+ server host from one TACACS+ server to another servergroup, either on the same Cisco NX-OS device or on another Cisco NX-OS device.

Before You Begin

Ensure that you have configured the server in the default TACACS+ server group.

Ensure that you have created the target TACACS+ server group.


Configuring TACACS+Copying a TACACS+ Server Host

Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Server Groups.Step 2 From the Summary pane, double-click the device to display the server groups.Step 3 Double-click Default TACACS Server Group.

The list of TACACS+ server hosts appears.

Step 4 Click the TACACS+ server host you want to copy.Step 5 From the menu bar, choose Actions > Copy.

The TACACS+ server host appears in the list of servers for the server group.

Step 6 Click the destination TACACS+ server group.You can copy the server host configuration to a server group within the same device or in anotherdevice.

Note

Step 7 From the menu bar, choose Actions > Paste.Step 8 From the menu bar, choose File > Deploy to apply your changes to the device.

Related Topics

• Adding a TACACS+ Server Host, page 69• Deleting a TACACS+ Server Group, page 75

Deleting a TACACS+ Server HostYou can delete a TACACS+ server host from a server group.

Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Server Groups.Step 2 From the Summary pane, double-click the device to display the server groups.Step 3 Double-click the server group to display the list of server hosts.Step 4 Click the TACACS+ server host to delete.Step 5 From the menu bar, choose Actions > Delete Server and click Yes on the confirmation dialog.

The TACACS+ server host disappears from the list.Step 6 From the menu bar, choose File > Deploy to apply your changes to the device.

Related Topics

• Adding a TACACS+ Server Host, page 69


Configuring TACACS+Deleting a TACACS+ Server Host

Configuring a Global TACACS+ KeyYou can configure secret keys at the global level for all servers used by the device. A secret key is a sharedsecret text string between the device and the TACACS+ server hosts.

Before You Begin

Obtain the secret key values for the remote TACACS+ servers.

Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Server Groups.Step 2 From the Summary pane, double-click the device to display the server groups.Step 3 Click Default TACACS Server Group.Step 4 From the Details pane, click the Global Settings tab.Step 5 In the Key field, enter the secret key.Step 6 (Optional) Check Encrypt to encrypt the key.

The default is clear text. The Cisco NX-OS software encrypts a clear text key before saving it to the runningconfiguration.


Related Topics

• Enabling TACACS+ , page 69• Configuring a Key for a Specific TACACS+ Server, page 72

Configuring a Key for a Specific TACACS+ ServerYou can configure secret keys for a TACACS+ server. A secret key is a shared secret text string between theCisco NX-OS device and the TACACS+ server host.

Before You Begin

Configure one or more TACACS+ server hosts.

Obtain the secret key values for the remote TACACS+ servers.


Configuring TACACS+Configuring a Global TACACS+ Key

Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Server Groups.Step 2 From the Summary pane, double-click the device to display the server groups.Step 3 Double-click Default TACACS Server Group to display the list of TACACS+ servers.Step 4 Click the desired TACACS+ server.Step 5 From the Details pane, click the Server Details tab.Step 6 Check Override Defaults.Step 7 In the Key field, enter the secret key.

The default is the global secret key.Step 8 (Optional) Check Encrypt to encrypt the key.

The default is clear text.Step 9 From the menu bar, choose File > Deploy to apply your changes to the device.

Related Topics

• Adding a TACACS+ Server Host, page 69• Configuring a Global TACACS+ Key, page 72

Adding a TACACS+ Server GroupYou can reference one or more remote AAA servers to authenticate users using server groups. All membersof a group must belong to the TACACS+ protocol. The servers are tried in the same order in which youconfigure them.

You can configure these server groups at any time but they only take effect when you apply them to an AAAservice.

Before You Begin


Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Server Groups.Step 2 From the Summary pane, click the device.Step 3 From the menu bar, choose Actions > Add Server Group.

A new line appears at the end of the server group list for the device and the Details tab appears in the Detailspane.

Step 4 In the Server Group Name field, enter the name and press the Enter key.The server group name is a case-sensitive alphanumeric string with a maximum length of 127 characters.

Step 5 (Optional) In the Dead time(mins) field, enter the number of minutes for the dead-time interval.The default dead-time interval is 0 minutes.

Step 6 In the VRF Name field, click the down arrow to display the VRF Name dialog and click a VRF. Click OK.Step 7 From the menu bar, choose File > Deploy to apply your changes to the device.


Configuring TACACS+Adding a TACACS+ Server Group

Related Topics


Adding a TACACS+ Server Host to a TACACS+ Server GroupYou can add a TACACS+ server host to a TACACS+ server group.

Before You Begin

Ensure that you have added the TACACS+ server host to the Default TACACS+ Server Group.

Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Server Groups.Step 2 From the Summary pane, double-click the device to display the server groups.Step 3 Click a TACACS+ server group.Step 4 From the menu bar, choose Actions > Add Server.

The Server Details appear in the Details pane.Step 5 In the Server field, enter the TACACS+ server IPv4 address, IPv6 address, or hostname.Step 6 From the Server drop-down list, choose either the IPv4 address, IPv6 address, or hostname as the correct


Note


Related Topics

• Adding a TACACS+ Server Group, page 73

Deleting a TACACS+ Server Host from a TACACS+ Server GroupYou can delete a TACACS+ server host from a TACACS+ server group.

Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Server Groups.Step 2 From the Summary pane, double-click the device to display the server groups.Step 3 Double-click the server group to display the list of server hosts.Step 4 Click the TACACS+ server host to delete.Step 5 From the menu bar, choose Actions > Delete Server and click Yes on the confirmation dialog.


Configuring TACACS+Adding a TACACS+ Server Host to a TACACS+ Server Group

The TACACS+ server host disappears from the list.Step 6 From the menu bar, choose File > Deploy to apply your changes to the device.

Related Topics

• Adding a TACACS+ Server Host to a TACACS+ Server Group, page 74

Deleting a TACACS+ Server GroupYou can delete a TACACS+ server group.

Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Server Groups.Step 2 From the Summary pane, double-click the device to display the list of server groups.Step 3 Click the TACACS+ server group to delete.Step 4 From the menu bar, choose Actions > Delete Server Group and click Yes in the confirmation dialog.

The server group disappears from the server group list.Step 5 From the menu bar, choose File > Deploy to apply your changes to the device.

Configuring the Global Source Interface for TACACS+ Server GroupsYou can configure a global source interface for TACACS+ server groups to use when accessing TACACS+servers. This configuration forces the TACACS+ servers to use the IP address of the source interface for alloutgoing TACACS+ packets. By default, the Cisco NX-OS software uses any available interface.

Before You Begin


Procedure


Step 2 From the Summary pane, double-click the device to display the server groups.Step 3 Click Default TACACS Server Group.Step 4 From the Details pane, click the Global Settings tab.Step 5 From the Source Interface drop-down list, choose an Ethernet interface, a loopback interface, a port-channel



Configuring TACACS+Deleting a TACACS+ Server Group

Configuring a Source Interface for a Specific TACACS+ Server GroupYou can configure a source interface for a specific TACACS+ server group to use when accessing TACACS+servers. This configuration forces the TACACS+ servers to use the IP address of the source interface for alloutgoing TACACS+ packets.

This configuration overrides the global source interface for this server group.Note

Before You Begin


Enable TACACS+.

Procedure


Step 2 From the Summary pane, double-click the device to display the server groups.Step 3 Click the desired TACACS+ server group.Step 4 From the Details pane, click the Details tab.Step 5 From the Source Interface drop-down list, choose an Ethernet interface, a loopback interface, a port-channel


Related Topics

• Configuring the Global Source Interface for TACACS+ Server Groups, page 75

Allowing Users to Specify a TACACS+ Server at LoginYou can configure the switch to allow the user to specify which TACACS+ server to send the authenticationrequest by enabling the directed-request option. By default, a device forwards an authentication request basedon the default AAA authentication method. If you enable this option, the user can log in asusername@vrfname:hostname, where vrfname is the VRF to use and hostname is the name of a configuredTACACS+ server.

If you enable the directed-request option, the device uses only the TACACS+ method for authenticationand not the default local method.

Note


Configuring TACACS+Configuring a Source Interface for a Specific TACACS+ Server Group

User-specified logins are supported only for Telnet sessions.Note

Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Server Groups.Step 2 From the Summary pane, double-click the device to display the server groups.Step 3 Click Default TACACS Server Group.Step 4 From the Details pane, click the Global Settings tab.Step 5 Check Direct Req.Step 6 From the menu bar, choose File > Deploy to apply your changes to the device.

Related Topics


Configuring the Global TACACS+ Timeout IntervalYou can set a global timeout interval that the device waits for responses from all TACACS+ servers beforedeclaring a timeout failure. The timeout interval determines how long the device waits for responses fromTACACS+ servers before declaring a timeout failure.

Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Server Groups.Step 2 From the Summary pane, double-click the device to display the server groups.Step 3 Click Default TACACS Server Group.Step 4 From the Details pane, click the Global Settings tab.Step 5 In the Time out(secs) field, enter the number of seconds for the timeout interval.

The default is 5 seconds.Step 6 From the menu bar, choose File > Deploy to apply your changes to the device.

Related Topics

• Enabling TACACS+ , page 69• Configuring the Timeout Interval for a TACACS+ Server, page 77

Configuring the Timeout Interval for a TACACS+ ServerYou can set a timeout interval that the device waits for responses from a TACACS+ server before declaringa timeout failure. The timeout interval determines how long the device waits for responses from a TACACS+server before declaring a timeout failure.


Configuring TACACS+Configuring the Global TACACS+ Timeout Interval

Before You Begin


Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Server Groups.Step 2 From the Summary pane, double-click the device to display the server groups.Step 3 Double-click Default TACACS Server Group to display the list of TACACS+ servers.Step 4 Click the desired TACACS+ server.Step 5 From the Details pane, click the Server Details tab.Step 6 Check Override Defaults.Step 7 In the Timeout(secs) field, enter the number of seconds for the timeout interval.

The default is 5 seconds.Step 8 From the menu bar, choose File > Deploy to apply your changes to the device.

Related Topics

• Enabling TACACS+ , page 69• Configuring the Global TACACS+ Timeout Interval, page 77

Configuring TCP PortsYou can configure another TCP port for the TACACS+ servers if there are conflicts with another application.By default, devices use port 49 for all TACACS+ requests.

Before You Begin


Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Server Groups.Step 2 From the Summary pane, double-click the device to display the server groups.Step 3 Double-click Default TACACS Server Group to display the list of TACACS+ servers.Step 4 Click the desired TACACS+ server.Step 5 From the Details pane, click the Server Details tab.Step 6 In the Authentication Port field, enter a new TCP port number or clear it to disable authentication.

The default authentication TCP port is 49.Step 7 From the menu bar, choose File > Deploy to apply your changes to the device.

Related Topics



Configuring TACACS+Configuring TCP Ports

Configuring Periodic TACACS+ Server MonitoringYou can monitor the availability of TACACS+ servers. These parameters include the username and passwordto use for the server and an idle timer. The idle timer specifies the interval in which a TACACS+ serverreceives no requests before the device sends out a test packet. You can configure this option to test serversperiodically, or you can run a one-time only test.

To protect network security, we recommend that you use a username that is not the same as an existingusername in the TACACS+ database.

Note

The test idle timer specifies the interval in which a TACACS+ server receives no requests before the devicesends out a test packet.

The default idle timer value is 0 minutes. When the idle time interval is 0 minutes, periodic TACACS+server monitoring does not occur.

Note

Before You Begin


Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Server Groups.Step 2 From the Summary pane, double-click the device to display the server groups.Step 3 Double-click Default TACACS Server Group to display the list of TACACS+ servers.Step 4 Click the desired TACACS+ server.Step 5 From the Details pane, click the Server Details tab.Step 6 In the User Name field, enter a username.Step 7 In the Password field, enter a password.Step 8 In the Idle Time field, enter the number of minutes for periodic monitoring.Step 9 From the menu bar, choose File > Deploy to apply your changes to the device.

Related Topics


Configuring the TACACS+ Dead-Time IntervalYou can configure the dead-time interval for all TACACS+ servers. The dead-time interval specifies the timethat the device waits, after declaring a TACACS+ server is dead, before sending out a test packet to determineif the server is now alive.


Configuring TACACS+Configuring Periodic TACACS+ Server Monitoring

When the dead-timer interval is 0 minutes, TACACS+ servers are not marked as dead even if they are notresponding. You can configure the dead-timer per group.

Note

Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Server Groups.Step 2 From the Summary pane, double-click the device to display the server groups.Step 3 Click Default TACACS Server Group.Step 4 From the Details pane, click the Global Settings tab.Step 5 In the Dead time(mins) field, enter the number of minutes.

The default is 0 minutes.Step 6 From the menu bar, choose File > Deploy to apply your changes to the device.

Related Topics


Disabling TACACS+You can disable TACACS+.

When you disable TACACS+, all related configurations are automatically discarded.Caution

Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Server Groups.Step 2 From the Summary pane, click the device.Step 3 From the menu bar, choose Actions > Disable TACACS.Step 4 From the menu bar, choose File > Deploy to apply your changes to the device.

Related Topics


Displaying TACACS+ StatisticsYou can display the statistics that the device maintains for TACACS+ activity.


Configuring TACACS+Disabling TACACS+

Before You Begin


Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Server Groups.Step 2 From the Summary pane, double-click the device to display the server groups.Step 3 Double-click Default TACACS Server Group to display the list of TACACS+ servers.Step 4 Click the desired TACACS+ server.Step 5 From the Details pane, click the Statistics tab.

Where to Go NextYou can now configure AAA authentication methods to include the server groups.

Field Descriptions for TACACS+ Server Groups and ServersThis section describes the fields for TACACS+ in Cisco DCNM.

Security: AAA: Server Groups: Summary PaneTable 21: Security: AAA: Server Groups: Summary Pane

DescriptionFields

UDP port number for authentication traffic for theservers. The default is 49.

Authentication Port

UDP port used for accounting for the servers.Accounting Port

Number of seconds for the timeout interval for theservers. The default is 5 seconds.

Timeout

Status of the servers.Status


Configuring TACACS+Where to Go Next

Security: AAA: Server Groups: device: Default TACACS Server Group: GlobalSettings Tab

Table 22: Security: AAA: Server Groups: device: Default TACACS Server Group: Global Settings Tab

DescriptionField

TACACS+ for the server group type.Server Group Type

Number of seconds for the timeout interval. Thedefault is 5 seconds.

Time out(secs)

Secret global key.Key

Source interface for a specific TACACS+ servergroup to use when accessing TACACS+ servers. The

Source Interface

options are an Ethernet interface, a loopback interface,or the management interface (mgmt 0).

Number of minutes for the dead time interface. Thedefault is 0 minutes.

Dead time(mins)

Users can specify a TACACS+ server at login.Direct Req

Security: AAA: Server Groups: device: Default TACACS Server Group: server:Server Details Tab

Table 23: Security: AAA: Server Groups: device: Default TACACS Server Group: server: Server Details Tab

DescriptionFields

General

Server Type TACACS+ for the server type.

Server IPv4 address, IPv6 address,or alphanumeric name and theserver name type.

Server

TCP port number for authenticationtraffic. The default is 49.

Authentication Port

TCP port used for accounting.Accounting Port

Test


Configuring TACACS+Security: AAA: Server Groups: device: Default TACACS Server Group: Global Settings Tab

DescriptionFields

User Name Username for periodic monitoringof the TACACS+ server.

Password for periodic monitoringof the TACACS+ server.

Password

Number of minutes for the idletime interval for periodic

Idle Time

monitoring of the TACACS+server. The default is 0, whichdisables periodic monitoring.

Global values that you can overrideand configure for the TACACS+

Override Default

server. The default is to use theglobal values.

Secret server key for theTACACS+ server.

Key

Secret server key encryption status.The default is clear text.

Encrypt

Number of seconds for the timeoutinterval. The default is 5 seconds.

Timeout(secs)

Security: AAA: Server Groups: device: server group: Details TabTable 24: Security: AAA: Server Groups: device: server group : Details Tab

DescriptionFields

Displays RADIUS for the server group type.Type

Displays the server group name.Server Group Name

Number of minutes for the dead-time interval for theserver group. The default is 0 minutes.

Dead time(mins)

VRF name.VRF Name


Source Interface



Configuring TACACS+Security: AAA: Server Groups: device: server group: Details Tab

Additional References for TACACS+This section includes additional information related to implementing TACACS+.

Related Documents


Cisco NX-OS Licensing GuideCisco NX-OS licensing


Cisco DCNM licensing

VRF configuration

Standards

TitleStandards


MIBs

MIBs LinkMIBs



Feature History for TACACS+This table lists the release history for this feature.

Table 25: Feature History for TACACS+


Added support for the CiscoNexus 3000 Series Switches.

5.2(1)TACACS+

No change from Release 5.0.5.1(1)TACACS+

Added support forconfiguring the global source

5.0(2)TACACS+ server groups


Configuring TACACS+Additional References for TACACS+




interface for all TACACS+server groups.

Added support forconfiguring a source interface

5.0(2)TACACS+ server groups

for a specific TACACS+server group.


Configuring TACACS+Feature History for TACACS+


Configuring TACACS+Feature History for TACACS+

C H A P T E R 7Configuring User Accounts and RBAC

This chapter describes how to configure user accounts and role-based access control (RBAC) on CiscoNX-OS devices.


• Information About User Accounts and RBAC, page 87

• Licensing Requirements for User Accounts and RBAC, page 89

• Platform Support for User Accounts and RBAC, page 90

• Configuring User Accounts, page 90

• Configuring Roles, page 98

• Field Descriptions for RBAC, page 106

• Additional References for User Accounts and RBAC, page 108

• Feature History for User Accounts and RBAC, page 109

Information About User Accounts and RBACYou can create andmanage users accounts and assign roles that limit access to operations on the Cisco NX-OSdevice. RBAC allows you to define the rules for an assign role that restrict the authorization that the user hasto access management operations.

About User AccountsYou can configure up to a maximum of 256 user accounts. By default, the user account does not expire unlessyou explicitly configure it to expire. The expire option determines the date when the user account is disabled.

Users can have user accounts on multiple VDCs. These users can move between VDCs after an initialconnection to a VDC.

The following words are reserved and cannot be used to configure users: bin, daemon, adm, lp, sync, shutdown,halt, mail, news, uucp, operator, games, gopher, ftp, nobody, nscd, mailnull, root, rpc, rpcuser, xfs, gdm,mtsuser, ftpuser, man, and sys.


User passwords are not displayed in the configuration files.Note

Usernames must begin with an alphanumeric character and can contain only these special characters: ( += . _ \ -). The # and ! symbols are not supported. If the username contains characters that are not allowed,the specified user is unable to log in.

Caution

Characteristics of Strong PasswordsA strong password has the following characteristics:

• Is at least eight characters long

• Does not contain many consecutive characters (such as abcd)

• Does not contain many repeating characters (such as aaabbb)

• Does not contain dictionary words

• Does not contain proper names

• Contains both uppercase and lowercase characters

• Contains numbers

The following are examples of strong passwords:

• If2CoM18

• 2004AsdfLkj30

• Cb1955S21

If a password is trivial (such as a short, easy-to-decipher password), the Cisco NX-OS software will rejectyour password configuration if password-strength checking is enabled. Be sure to configure a strong passwordas shown in the sample configuration. Passwords are case sensitive.

About User RolesUser roles contain rules that define the operations allowed for the user who is assigned the role. Each userrole can contain multiple rules and each user can have multiple roles. For example, if role1 allows access onlyto configuration operations, and role2 allows access only to debug operations, then users who belong to bothrole1 and role2 can access configuration and debug operations. You can also limit access to specific VLANs,virtual routing and forwarding instances (VRFs), and interfaces.

The Cisco NX-OS software provides four default user roles:

• network-admin—Complete read-and-write access to the entire Cisco NX-OS device (only available inthe default VDC)

• network-operator—Complete read access to the entire Cisco NX-OS device (only available in the defaultVDC)


Configuring User Accounts and RBACCharacteristics of Strong Passwords

• vdc-admin—Read-and-write access limited to a VDC

• vdc-operator—Read access limited to a VDC

You cannot change the default user roles.Note

You can create custom roles within a VDC. By default, the user accounts without administrator roles canonly display feature information. You can add rules to allow users to configure features.The VDCs on the same physical device do not share user roles. Each VDC maintains an independent userrole database. Within a VDC, roles are configured by rule and attribute assignment.

If you belong to multiple roles, you can execute a combination of all the commands permitted by theseroles. Access to a command takes priority over being denied access to a command. For example, supposea user has RoleA, which denied access to the configuration commands. However, the user also has RoleB,which has access to the configuration commands. In this case, the user has access to the configurationcommands.

Note

About User Role RulesThe rule is the basic element of a role. A rule defines what operations the role allows the user to perform. Youcan apply rules for the following parameters:

A command or group of commands defined in a regular expression.Command

A command or group of commands defined in a regular expression.Feature

Default or user-defined group of features.Feature group

These parameters create a hierarchical relationship. The most basic control parameter is the command. Thenext control parameter is the feature, which represents all commands associated with the feature. The lastcontrol parameter is the feature group. The feature group combines related features and allows you to easilymanage the rules. The Cisco NX-OS software also supports the predefined feature group L3 that you can use.

You can configure up to 256 rules for each role. The user-specified rule number determines the order in whichthe rules are applied. Rules are applied in descending order. For example, if a role has three rules, rule 3 isapplied before rule 2, which is applied before rule 1.

Licensing Requirements for User Accounts and RBACThe following table shows the licensing requirements for this feature:


User accounts and RBAC require no license. Anyfeature not included in a license package is bundled

Cisco DCNM

with the Cisco DCNM and is provided at no chargeto you. For an explanation of the Cisco DCNM


Configuring User Accounts and RBACAbout User Role Rules


licensing scheme, see the Cisco DCNM Installationand Licensing Guide, Release 5.x.

User accounts and RBAC require no license. Anyfeature not included in a license package is bundled

Cisco NX-OS

with the Cisco NX-OS system images and is providedat no extra charge to you. For an explanation of theCisco NX-OS licensing scheme for your platform,see the licensing guide for your platform.

Platform Support for User Accounts and RBACThe following platforms support this feature but may implement it differently. For platform-specific information,including guidelines and limitations, system defaults, and configuration limits, see the correspondingdocumentation.







Configuring User AccountsThis section describes how to configure user accounts for the Cisco NX-OS device.

Creating a User AccountYou can create a maximum of 256 user accounts on a Cisco NX-OS device. User accounts have the followingattributes:

• Username

• Password

• Expiry date

• User roles

The username is a case-sensitive, alphanumeric character string with a maximum length of 28 characters.

User accounts can have a maximum of 64 user roles.


Configuring User Accounts and RBACPlatform Support for User Accounts and RBAC






User accounts are local to a VDC. However, users with the network-admin or network-operator role can login to the default VDC and access other VDCs.

If you do not specify a password, the user might not be able to log in to the Cisco NX-OS device.Note

Procedure

Step 1 From the Feature Selector pane, choose Security > RBAC > Users.Step 2 From the Summary pane, double-click the device to display the users.Step 3 From the menu bar, choose Actions > Add User.

A new row appears in the list of users.Step 4 Enter the username.

The username is a case-sensitive character string with a maximum length of 28 characters. Valid charactersare uppercase letters A through Z, lowercase letters a through z, numbers 0 through 9, hyphen (-), period (.),underscore (_), plus sign (+), and equal sign (=).

Step 5 Double-click the Password cell and click the down arrow to display the password dialog box.

This figure shows the password dialog box.

Figure 11: Password Dialog Box

Step 6 From the password dialog box, enter the password in the Password and Confirm Password fields.Step 7 From the Encryption Type menu list, choose Clear Text or Strongly Encrypted.Step 8 Click OK.Step 9 Double-click the Expiry Date cell and click the down arrow to display the Expiry Date dialog box.


Configuring User Accounts and RBACCreating a User Account

This figure shows the Expiry Date dialog box.

Figure 12: Expiry Date Dialog Box

Step 10 Navigate to the desired expiry date and click OK.The default expiry date is Never.

Step 11 Double-click the Roles cell and click the down arrow to display the user role dialog box.

This figure shows the user role dialog box.

Figure 13: User Role Dialog Box

Step 12 Choose one or more user roles by moving them to the Permitted column and click OK.Step 13 From the menu bar, choose File > Deploy to apply your changes to the device.

Related Topics

• Configuring Roles, page 98• Creating a User Account, page 90


Configuring User Accounts and RBACCreating a User Account

Copying a User AccountYou can copy the configuration of a user account from one Cisco NX-OS device to another Cisco NX-OSdevice.

Before You Begin

Create one or more user accounts.

Ensure that the roles assigned to the user account exist on the target device.

Procedure

Step 1 From the Feature Selector pane, choose Security > RBAC > Users.Step 2 From the Summary pane, double-click the device to display the users.Step 3 Click on the user account that you want to copy.Step 4 From the menu bar, choose Actions > Copy.Step 5 Click the destination device.Step 6 From the menu bar, choose Actions > Paste.

The user account appears in the list of users for the device.

Step 7 Double-click the Password cell and click the down arrow to display the password dialog box.

This figure shows the password dialob box.


Step 8 From the password dialog box, enter the password in the Password and Confirm Password fields.Step 9 From the Encryption Type menu list, choose Clear Text or Strongly Encrypted.Step 10 Click OK.Step 11 From the menu bar, choose File > Deploy to apply your changes to the device.

Related Topics

• Creating a User Account, page 90• Creating a User Role, page 98

Changing a User Account PasswordYou can change the password for any user account.


Configuring User Accounts and RBACCopying a User Account

Changes to user account password do not take effect until the user logs in and creates a new session.Note

Before You Begin


Procedure

Step 1 From the Feature Selector pane, choose Security > RBAC > Users.Step 2 From the Summary pane, double-click the device to display the users.Step 3 Click the user account to change.Step 4 Double-click the Password cell and click the down arrow to display the password dialog box.

This figure shows the password dialog box.


Step 5 From the password dialog box, enter the password in the Password and Confirm Password fields.Step 6 From the Encryption Type menu list, choose Clear Text or Strongly Encrypted and click OK.Step 7 From the menu bar, choose File > Deploy to apply your changes to the device.

Related Topics

• Creating a User Account, page 90

Changing a User Account Expiry DateYou can change the expiry date for any user account.

Changes to the user account expiry date do not take effect until the user logs in and creates a new session.Note

Before You Begin



Configuring User Accounts and RBACChanging a User Account Expiry Date

Procedure

Step 1 From the Feature Selector pane, choose Security > RBAC > Users.Step 2 From the Summary pane, double-click the device to display the users.Step 3 Click the user account to change.Step 4 Double-click the Expiry Date cell and click the down arrow to display the Expiry Date dialog box.

This figure shows the Expiry Date dialog box.

Figure 16: Expiry Date Dialog Box

Step 5 Navigate to the desired expiry date and click OK.The default expiry date is Never.


Adding a User Account RoleYou can add roles to a user account.

Changes to user account roles do not take effect until the user logs in and creates a new session.Note

Before You Begin



Configuring User Accounts and RBACAdding a User Account Role

Procedure

Step 1 From the Feature Selector pane, choose Security > RBAC > Users.Step 2 From the Summary pane, double-click the device to display the users.Step 3 Click the user account to change.Step 4 Double-click the Roles cell and click the down arrow to display the user roles dialog box.



Step 5 Choose one or more user roles by moving them to the Permitted Roles column and click OK.Step 6 From the menu bar, choose File > Deploy to apply your changes to the device.

Related Topics

• Creating a User Account, page 90

Deleting a User Account RoleYou can delete the roles from a user account.

Changes to a user account role do not take effect until the user logs in and creates a new session.Note

Before You Begin


Add a role to the user account.


Configuring User Accounts and RBACDeleting a User Account Role

Procedure

Step 1 From the Feature Selector pane, choose Security > RBAC > Users.Step 2 From the Summary pane, double-click the device to display the users.Step 3 Click the user account to change.Step 4 Double-click the Roles cell and click the down arrow to display the user roles dialog box.



Step 5 Delete one or more user roles by moving them to the Available Roles column and click OK.A user account must have at least one userrole.

Note


Related Topics

• Adding a User Account Role, page 95

Deleting a User AccountYou can delete a user account.

Before You Begin



Configuring User Accounts and RBACDeleting a User Account

Procedure

Step 1 From the Feature Selector pane, choose Security > RBAC > Users.Step 2 From the Summary pane, double-click the device to display the users.Step 3 Click the user account to delete.Step 4 From the top menu bar, choose Users > Delete User and click Yes in the confirmation dialog.

The user account name disappears from the user account list.Step 5 From the menu bar, choose File > Deploy to apply your changes to the device.

Configuring RolesThis section describes how to configure user roles.

This figure shows the RBAC Roles content pane.

Figure 19: Roles Content Pane

Creating a User RoleYou can configure up to 64 user roles in a VDC. You can assign a user role to more that one user account.


Configuring User Accounts and RBACConfiguring Roles

Procedure

Step 1 From the Feature Selector pane, choose Security > RBAC > Roles.Step 2 From the Summary pane, double-click the device to display the roles.Step 3 From the menu bar, choose Actions > Add Role.

A new row appears in the list of roles.

Step 4 In the Name cell, enter the role name.The maximum length of the role name is 16 characters.

Step 5 (Optional) In the Description cell, enter the role description.Step 6 From the menu bar, choose File > Deploy to apply your changes to the device.

Copying a User RoleYou can copy the configuration of a user role within a Cisco NX-OS device or from one Cisco NX-OS deviceto another Cisco NX-OS device.

Procedure

Step 1 From the Feature Selector pane, choose Security > RBAC > Roles.Step 2 From the Summary pane, double-click the device to display the roles.Step 3 Click the role you that want to copy.Step 4 From the menu bar, choose Actions > Copy.Step 5 Click the destination device.Step 6 From the menu bar, choose Actions > Paste.

The role appears in the list of roles for the device.


Adding a Rule to a User RoleYou can use rules to define the actions that users can perform on the Cisco NX-OS device. Each user role canhave up to 256 rules.

The rule number that you specify determines the order in which the rules are applied. Rules are applied indescending order. For example, if a role has three rules, rule 3 is applied before rule 2, which is applied beforerule 1.

Before You Begin

Create one or more user roles.


Configuring User Accounts and RBACCopying a User Role

Procedure

Step 1 From the Feature Selector pane, choose Security > RBAC > Roles.Step 2 From the Summary pane, double-click the device to display the user roles.

The Details tab appears in the Details pane.Step 3 Click the user role to which to add a rule.

You cannot modify the default roles network-admin, network-operator, vdc-admin, and vdc-operator.Note

Step 4 From the Details tab, click Command Authorization Rules.Step 5 From the menu bar, choose Actions > Add Rule or Actions > Insert Rule Above or Actions > Insert Rule

Below.A new rule appears in the Details pane.

Step 6 Double-click the Permission cell for the new rule and choose Permit or Deny.Step 7 Double-click theMatch Command Type cell for the new rule and choose from the drop-down list.Step 8 Double-click theMatch Value (Component/Command) cell for the new rule.Step 9 Click the down arrow to display the match value dialog box.

This figure shows the match value dialog box.

Figure 20: Match Value Dialog Box

Step 10 From the dialog box, specify the match value for the rule and click OK.Step 11 From the menu bar, choose File > Deploy to apply your changes to the device.

Related Topics

• Creating a User Role, page 98

Changing a Rule in a User RoleYou can change the command authorization criteria for a rule in a user role.

Before You Begin

Add one or more rules to a user role.


Configuring User Accounts and RBACChanging a Rule in a User Role

Procedure


The Details tab appears in the Details pane.Step 3 Click the user role to change.


Step 4 From the Details tab, click Command Authorization Rules.Step 5 Click the rule to rearrange.Step 6 Double-click theMatch Command Type cell for the rule and choose from the drop-down list.Step 7 Double-click theMatch Value (Component/Command) cell for the rule.Step 8 Click the down arrow to display the match value dialog box.




Related Topics

• Adding a Rule to a User Role, page 99

Rearranging a Rule in a User RoleYou can rearrange a rule in a user role.

Before You Begin


Procedure



Configuring User Accounts and RBACRearranging a Rule in a User Role

The Details tab appears in the Details pane.Step 3 Click the user role to change.


Step 4 From the Details tab, click Command Authorization Rules.Step 5 Click the rule to rearrange.Step 6 From the menu bar, choose Actions > Move Up or Actions > Move Down.Step 7 Double-click theMatch Value (Component/Command) cell for the rule.Step 8 Click the down arrow to display the match value dialog box.




Related Topics

• Adding a Rule to a User Role, page 99

Deleting a Rule from a User RoleYou can delete rules from a user role. Each role must have at least one rule.

Before You Begin


Procedure


The Details tab appears in the Details pane.

Step 3 Click the user role from which to delete the rule.You cannot modify the default roles network-admin, network-operator, vdc-admin, and vdc-operator.Note


Configuring User Accounts and RBACDeleting a Rule from a User Role

Step 4 From the Details tab, click Command Authorization Rules.Step 5 Click the rule that you want to delete.Step 6 From the menu bar, choose Actions > Delete Rule and click Yes in the confirmation dialog box.

The rule disappears from the Details pane.


Changing a User Role Interface PolicyYou can change a user role interface policy to limit the interfaces that the user can access. By default, a userrole allows access to all interfaces in the VDC.

Before You Begin


Procedure

Step 1 From the Feature Selector pane, choose Security > RBAC > Roles.Step 2 From the Summary pane, double-click the device to display the roles.Step 3 Click the role to change.



Step 4 From the Details pane, click General.Step 5 From the Permitted Interfaces field, click the down arrow to display the permitted interfaces dialog box.


Configuring User Accounts and RBACChanging a User Role Interface Policy

This figure shows the permitted interfaces dialog box.

Figure 23: Permitted Interfaces Dialog Box

Step 6 From the dialog box, you can enter the range of interfaces to permit, specify selected interfaces to permit,deny all interfaces, or permit all interfaces.

Step 7 Click OK.Step 8 From the menu bar, choose File > Deploy to apply your changes to the device.

Related Topics


Changing a User Role VLAN PolicyYou can change a user role VLAN policy to limit the VLANs that the user can access. By default, a user roleallows access to all VLANs in the VDC.

Before You Begin


Procedure




Configuring User Accounts and RBACChanging a User Role VLAN Policy


Step 4 From the Details pane, click General.Step 5 From the Permitted VLANs field, click the down arrow to display the permitted VLANs dialog box.

This figure shows the permitted VLANs dialog box.

Figure 24: Permitted VLANs Dialog Box

Step 6 From the dialog box, you can enter the range of VLANs to permit, specify selected VLANs to permit, denyall VLANs, or permit all VLANs.


Related Topics


Changing a User Role VRF PolicyYou can change a user role VRF policy to limit the VRFs that the user can access. By default, a user roleallows access to all VRFs in the VDC.

Before You Begin



Configuring User Accounts and RBACChanging a User Role VRF Policy

Procedure




Step 4 From the Details pane, click General.Step 5 From the Permitted VRFs field, click the down arrow to display the permitted VRFs dialog box.

This figure shows the permitted VRFs dialog box.

Figure 25: Permitted VRFs Dialog Box

Step 6 From the dialog box, you can enter the range of VRFs to permit, specify selected VRFs to permit, deny allVRFs, or permit all VRFs.


Related Topics


Field Descriptions for RBACThis section describes the fields for RBAC.


Configuring User Accounts and RBACField Descriptions for RBAC

Security: RBAC: Roles: Summary PaneTable 26: Security: RBAC: Roles: Summary Pane

DescriptionElement

Role nameName

Role descriptionDescription

Object Access Policy

Permitted VLANs Permitted VLANs

Permitted interfacesPermitted Interfaces

Permitted VRFsPermitted VRFs

Security: RBAC: Roles: device: role: Details Tab: General AreaTable 27: Security: RBAC: Roles: device: role: Details Tab

DescriptionElement

Role nameName

Role descriptionDescription

Object Access Policy

Permitted VLANs Permitted VLANs

Permitted interfacesPermitted Interfaces

Permitted VRFsPermitted VRFs

Security: RBAC: Roles: device: role: Details Tab: Command Authorization RulesArea

Table 28: Security: RBAC: Roles: device: role: Details Tab

DescriptionElement

Rule sequence numberRule No


Configuring User Accounts and RBACSecurity: RBAC: Roles: Summary Pane

DescriptionElement

Rule permissionPermission

Match command typeMatch Command Type

Match valueMatch Value (Component/Command)

Security: RBAC: Users: Summary PaneTable 29: Security: RBAC: Users: Summary Pane

DescriptionElement

User account name.Name

User account password. The default password is none.Password

User account expiry date. The default is never.Expiry Date

User account roles. The default is network-operatorfor user accounts created in the default VDC by a user

Roles

with the network-admin role. For all other accounts,the default is vdc-operator.

Additional References for User Accounts and RBACThis section includes additional information related to implementing user accounts and RBAC.

Related Documents





VRF configuration

Standards

TitleStandards



Configuring User Accounts and RBACSecurity: RBAC: Users: Summary Pane

MIBs

MIBs LinkMIBs

To locate and download MIBs, go to the followingURL:• CISCO-COMMON-MGMT-MIB


Feature History for User Accounts and RBACThis table lists the release history for this feature.

Table 30: Feature History for User Accounts and RBAC



5.2(1)User accounts and RBAC

No change from Release 5.0.5.1(1)User accounts and RBAC

No change from Release 4.2.5.0(2)User accounts and RBAC


Configuring User Accounts and RBACFeature History for User Accounts and RBAC




Configuring User Accounts and RBACFeature History for User Accounts and RBAC

C H A P T E R 8Configuring 802.1X

This chapter describes how to configure IEEE 802.1X port-based authentication on Cisco NX-OS devices.


• Information About 802.1X, page 111

• Licensing Requirements for 802.1X, page 118

• Prerequisites for 802.1X, page 118

• Platform Support for 802.1X, page 119

• Configuring 802.1X, page 119

• Displaying 802.1X Statistics, page 130

• Field Descriptions for 802.1X, page 130

• Additional References for 802.1X, page 133

• Feature History for 802.1X, page 134

Information About 802.1X802.1X defines a client-server-based access control and authentication protocol that restricts unauthorizedclients from connecting to a LAN through publicly accessible ports. The authentication server authenticateseach client connected to a Cisco NX-OS device port.

Until the client is authenticated, 802.1X access control allows only Extensible Authentication Protocol overLAN (EAPOL) traffic through the port to which the client is connected. After authentication is successful,normal traffic can pass through the port.

Device RolesWith 802.1X port-based authentication, the devices in the network have specific roles.


This figure shows the device roles in 802.1X.

Figure 26: 802.1X Device Roles

The specific roles are as follows:

The client device that requests access to the LAN and Cisco NX-OS device services andresponds to requests from the Cisco NX-OS device. The workstation must be running

Supplicant

802.1X-compliant client software such as that offered in theMicrosoftWindowsXP operatingdevice.

To resolve Windows XP network connectivity and Cisco 802.1X port-basedauthentication issues, read the Microsoft Knowledge Base article at this URL:http://support.microsoft.com/support/kb/articles/Q303/5/97.ASP

Note

The authentication server performs the actual authentication of the supplicant. Theauthentication server validates the identity of the supplicant and notifies the Cisco NX-OS

Authenticationserver

device regarding whether the supplicant is authorized to access the LAN and Cisco NX-OSdevice services. Because the Cisco NX-OS device acts as the proxy, the authenticationservice is transparent to the supplicant. The Remote Authentication Dial-In User Service(RADIUS) security device with Extensible Authentication Protocol (EAP) extensions is theonly supported authentication server; it is available in Cisco Secure Access Control Server,version 3.0. RADIUS uses a supplicant-server model in which secure authenticationinformation is exchanged between the RADIUS server and one or more RADIUS clients.

The authenticator controls the physical access to the network based on the authenticationstatus of the supplicant. The authenticator acts as an intermediary (proxy) between the

Authenticator

supplicant and the authentication server, requesting identity information from the supplicant,verifying the requested identity information with the authentication server, and relaying aresponse to the supplicant. The authenticator includes the RADIUS client, which is responsiblefor encapsulating and decapsulating the EAP frames and interacting with the authenticationserver.

When the authenticator receives EAPOL frames and relays them to the authentication server, the authenticatorstrips off the Ethernet header and encapsulates the remaining EAP frame in the RADIUS format. Thisencapsulation process does not modify or examine the EAP frames, and the authentication server must supportEAP within the native frame format. When the authenticator receives frames from the authentication server,the authenticator removes the server’s frame header, leaving the EAP frame, which the authenticator thenencapsulates for Ethernet and sends to the supplicant.


Configuring 802.1XDevice Roles

http://support.microsoft.com/support/kb/articles/Q303/5/97.ASP

The Cisco NX-OS device can only be an 802.1X authenticator.Note

Authentication Initiation and Message ExchangeEither the authenticator (Cisco NX-OS device) or the supplicant (client) can initiate authentication. If youenable authentication on a port, the authenticator must initiate authentication when it determines that the portlink state transitions from down to up. The authenticator then sends an EAP-request/identity frame to thesupplicant to request its identity (typically, the authenticator sends an initial identity/request frame followedby one or more requests for authentication information). When the supplicant receives the frame, it respondswith an EAP-response/identity frame.

If the supplicant does not receive an EAP-request/identity frame from the authenticator during bootup, thesupplicant can initiate authentication by sending an EAPOL-start frame, which prompts the authenticator torequest the supplicant’s identity.

If 802.1X is not enabled or supported on the network access device, the Cisco NX-OS device drops anyEAPOL frames from the supplicant. If the supplicant does not receive an EAP-request/identity frame afterthree attempts to start authentication, the supplicant transmits data as if the port is in the authorized state.A port in the authorized state means that the supplicant has been successfully authenticated.

Note

When the supplicant supplies its identity, the authenticator begins its role as the intermediary, passing EAPframes between the supplicant and the authentication server until authentication succeeds or fails. If theauthentication succeeds, the authenticator port becomes authorized.

The specific exchange of EAP frames depends on the authentication method being used.


Configuring 802.1XAuthentication Initiation and Message Exchange

This figure shows a message exchange initiated by the supplicant using the One-Time-Password (OTP)authentication method with a RADIUS server. The OTP authentication device uses a secret pass-phrase togenerate a sequence of one-time (single use) passwords.

Figure 27: Message Exchange

The user’s secret pass-phrase never crosses the network at any time such as during authentication or duringpass-phrase changes.

Related Topics

• Ports in Authorized and Unauthorized States, page 114

Ports in Authorized and Unauthorized StatesThe authenticator port state determines if the supplicant is granted access to the network. The port starts inthe unauthorized state. In this state, the port disallows all ingress and egress traffic except for 802.1X protocolpackets. When a supplicant is successfully authenticated, the port transitions to the authorized state, allowingall traffic for the supplicant to flow normally.

If a client that does not support 802.1X is connected to an unauthorized 802.1X port, the authenticator requeststhe client’s identity. In this situation, the client does not respond to the request, the port remains in theunauthorized state, and the client is not granted access to the network.

In contrast, when an 802.1X-enabled client connects to a port that is not running the 802.1X protocol, theclient initiates the authentication process by sending the EAPOL-start frame. When no response is received,the client sends the request for a fixed number of times. Because no response is received, the client beginssending frames as if the port is in the authorized state.

Ports can have the following authorization states:


Configuring 802.1XPorts in Authorized and Unauthorized States

Disables 802.1X port-based authentication and transitions to the authorized state withoutrequiring any authentication exchange. The port transmits and receives normal trafficwithout 802.1X-based authentication of the client. This authorization state is the default.

Forceauthorized

Causes the port to remain in the unauthorized state, ignoring all attempts by the client toauthenticate. The authenticator cannot provide authentication services to the client throughthe interface.

Forceunauthorized

Enables 802.1X port-based authentication and causes the port to begin in the unauthorizedstate, allowing only EAPOL frames to be sent and received through the port. The

Auto

authentication process begins when the link state of the port transitions from down to upor when an EAPOL-start frame is received from the supplicant. The authenticator requeststhe identity of the client and begins relaying authentication messages between the clientand the authentication server. Each supplicant that attempts to access the network isuniquely identified by the authenticator by using the supplicant’s MAC address.

If the supplicant is successfully authenticated (receives an Accept frame from the authentication server), theport state changes to authorized, and all frames from the authenticated supplicant are allowed through theport. If the authentication fails, the port remains in the unauthorized state, but authentication can be retried.If the authentication server cannot be reached, the authenticator can retransmit the request. If no response isreceived from the server after the specified number of attempts, authentication fails, and the supplicant is notgranted network access.

When a supplicant logs off, it sends an EAPOL-logoff message, which causes the authenticator port to transitionto the unauthorized state.

If the link state of a port transitions from up to down, or if an EAPOL-logoff frame is received, the port returnsto the unauthorized state.

MAC Authentication BypassYou can configure the Cisco NX-OS device to authorize a supplicant based on the supplicant MAC addressby using the MAC authentication bypass feature. For example, you can enable this feature on interfacesconfigured for 802.1X that are connected to devices such as printers.

If 802.1X authentication times out while waiting for an EAPOL response from the supplicant, the CiscoNX-OS device tries to authorize the client by using MAC authentication bypass.

When you enable the MAC authentication bypass feature on an interface, the Cisco NX-OS device uses theMAC address as the supplicant identity. The authentication server has a database of supplicantMAC addressesthat are allowed network access. After detecting a client on the interface, the Cisco NX-OS device waits foran Ethernet packet from the client. The Cisco NX-OS device sends the authentication server aRADIUS-access/request frame with a username and password based on the MAC address. If authorizationsucceeds, the Cisco NX-OS device grants the client access to the network. If authorization fails, the CiscoNX-OS device assigns the port to the guest VLAN if one is configured.

If an EAPOL packet is detected on the interface during the lifetime of the link, the Cisco NX-OS devicedetermines that the device connected to that interface is an 802.1X-capable supplicant and uses 802.1Xauthentication (not MAC authentication bypass) to authorize the interface. EAPOL history is cleared if theinterface link status goes down.

If the Cisco NX-OS device already authorized an interface by using MAC authentication bypass and detectsan 802.1X supplicant, the Cisco NX-OS device does not unauthorize the client connected to the interface.When reauthentication occurs, the Cisco NX-OS device uses 802.1X authentication as the preferred


Configuring 802.1XMAC Authentication Bypass

reauthentication process if the previous session ended because the Termination-Action RADIUS attributevalue is DEFAULT.

Clients that were authorized with MAC authentication bypass can be reauthenticated. The reauthenticationprocess is the same as that for clients that were authenticated with 802.1X. During reauthentication, the portremains in the previously assigned VLAN. If reauthentication is successful, the switch keeps the port in thesame VLAN. If reauthentication fails, the switch assigns the port to the guest VLAN, if one is configured.

If reauthentication is based on the Session-Timeout RADIUS attribute (Attribute[27]) and theTermination-Action RADIUS attribute (Attribute [29]) and if the Termination-Action RADIUS attribute(Attribute [29]) action is Initialize (the attribute value is DEFAULT), the MAC authentication bypass sessionends, and connectivity is lost during reauthentication. If MAC authentication bypass is enabled and the 802.1Xauthentication times out, the switch uses the MAC authentication bypass feature to initiate reauthorization.For more information about these AV pairs, see RFC 3580, IEEE 802.1X Remote Authentication Dial In UserService (RADIUS) Usage Guidelines.

MAC authentication bypass interacts with the following features:

• 802.1X authentication—You can enable MAC authentication bypass only if 802.1X authentication isenabled on the port.

• Port security— You can configure 802.1X authentication and port security on the same Layer 2 ports.

• Network admission control (NAC) Layer 2 IP validation—This feature takes effect after an 802.1X portis authenticated with MAC authentication bypass, including hosts in the exception list.

Related Topics

• 802.1X and Port Security, page 194

802.1X and Port SecurityYou can configure port security and 802.1X on the same interfaces of a Cisco Nexus 7000 Series Switch. Portsecurity secures the MAC addresses that 802.1X authenticates. 802.1X processes packets before port securityprocesses them, so when you enable both on an interface, 802.1X is already preventing inbound traffic on theinterface from unknown MAC addresses.

When you enable 802.1X and port security on the same interface, port security continues to learn MACaddresses by the sticky or dynamic method, as configured. Additionally, depending on whether you enable802.1X in single-host mode or multiple-host mode, one of the following occurs:

Port security learns the MAC address of the authenticated host.Single host mode

Port security drops any MAC addresses learned for this interface by thedynamic method and learns the MAC address of the first host authenticatedby 802.1X.

Multiple host mode

If aMAC address that 802.1X passes to port security would violate the applicable maximum number of secureMAC addresses, the device sends an authentication failure message to the host.

The device treats MAC addresses authenticated by 802.1X as though they were learned by the dynamicmethod, even if port security previously learned the address by the sticky or static methods. If you attempt todelete a secure MAC address that has been authenticated by 802.1X, the address remains secure.

If the MAC address of an authenticated host is secured by the sticky or static method, the device treats theaddress as if it were learned by the dynamic method, and you cannot delete the MAC address manually.


Configuring 802.1X802.1X and Port Security

Port security integrates with 802.1X to reauthenticate hosts when the authenticated and secure MAC addressof the host reaches its port security age limit. The device behaves differently depending upon the type ofaging, as follows:

Port security notifies 802.1X and the device attempts to reauthenticate the host. The resultof reauthentication determines whether the address remains secure. If reauthentication

Absolute

succeeds, the device restarts the aging timer on the secure address; otherwise, the devicedrops the address from the list of secure addressees for the interface.

Port security drops the secure address from the list of secure addresses for the interface andnotifies 802.1X. The device attempts to reauthenticate the host. If reauthentication succeeds,port security secures the address again.

Inactivity

Single Host and Multiple Hosts SupportThe 802.1X feature can restrict traffic on a port to only one endpoint device (single-host mode) or allow trafficfrom multiple endpoint devices on a port (multi-host mode).

Single-host mode allows traffic from only one endpoint device on the 802.1X port. Once the endpoint deviceis authenticated, the Cisco NX-OS device puts the port in the authorized state. When the endpoint deviceleaves the port, the Cisco NX-OS device put the port back into the unauthorized state. A security violation in802.1X is defined as a detection of frames sourced from anyMAC address other than the single MAC addressauthorized as a result of successful authentication. In this case, the interface on which this security associationviolation is detected (EAPOL frame from the other MAC address) will be disabled. Single host mode isapplicable only for host-to-switch topology and when a single host is connected to the Layer 2 (Ethernetaccess port) or Layer 3 port (routed port) of the Cisco NX-OS device.

Only the first host has to be authenticated on the 802.1X port configured with multiple host mode. The portis moved to the authorized state after the successful authorization of the first host. Subsequent hosts are notrequired to be authorized to gain network access once the port is in the authorized state. If the port becomesunauthorized when reauthentication fails or an EAPOL logoff message is received, all attached hosts aredenied access to the network. The capability of the interface to shut down upon security association violationis disabled in multiple host mode. This mode is applicable for both switch-to-switch and host-to-switchtopologies.

Supported TopologiesThe 802.1X port-based authentication is supported in two topologies:

• Point-to-point

• Wireless LAN

In a point-to-point configuration, only one supplicant (client) can connect to the 802.1X-enabled authenticator(Cisco NX-OS device) port. The authenticator detects the supplicant when the port link state changes to theup state. If a supplicant leaves or is replaced with another supplicant, the authenticator changes the port linkstate to down, and the port returns to the unauthorized state.


Configuring 802.1XSingle Host and Multiple Hosts Support

This figure shows 802.1X port-based authentication in a wireless LAN. The 802.1X port is configured as amultiple-host port that becomes authorized as soon as one supplicant is authenticated.

Figure 28: Wireless LAN Example

When the port is authorized, all other hosts indirectly attached to the port are granted access to the network.If the port becomes unauthorized (reauthentication fails or an EAPOL-logoff message is received), the CiscoNX-OS device denies access to the network to all of the attached supplicants.

Licensing Requirements for 802.1XThe following table shows the licensing requirements for this feature:


802.1X requires a LAN Enterprise license. For anexplanation of the Cisco DCNM licensing scheme

Cisco DCNM

and how to obtain and apply licenses, see the CiscoDCNM Installation and Licensing Guide, Release5.x.

802.1X requires no license. Any feature not includedin a license package is bundled with the Cisco NX-OS

Cisco NX-OS


Prerequisites for 802.1XThe following prerequisites are required for using this feature on Cisco DCNM. For a full list of feature-specificprerequisites, see the platform-specific documentation.

• System-message logging levels for 802.1X must meet or exceed Cisco DCNM requirements. Duringdevice discovery, Cisco DCNM detects inadequate logging levels and raises them to the minimumrequirements. Cisco Nexus 7000 Series switches that run Cisco NX-OS Release 4.0 are an exception.For Cisco NX-OS Release 4.0, prior to device discovery, use the command-line interface to configurelogging levels to meet or exceed Cisco DCNM requirements. For more information, see the .


Configuring 802.1XLicensing Requirements for 802.1X

Platform Support for 802.1XThe following platform supports this feature. For platform-specific information, including guidelines andlimitations, system defaults, and configuration limits, see the corresponding documentation.



Configuring 802.1XThis section describes how to configure the 802.1X feature.

Process for Configuring 802.1XThis section describes the process for configuring 802.1X.

Procedure

Step 1 Enable the 802.1X feature.Step 2 Configure the connection to the remote RADIUS server.Step 3 Enable 802.1X feature on the Ethernet interfaces.

Related Topics

• Enabling the 802.1X Service, page 119• Configuring AAA Accounting Methods for 802.1X, page 128• Controlling 802.1X Authentication on an Interface, page 120

Enabling the 802.1X ServiceYou must enable the 802.1X service on the device before authenticating any supplicant devices.

Procedure

Step 1 From the Feature Selector pane, choose Security > Dot1X.Step 2 From the Summary pane, click a device.Step 3 From the menu bar, choose Action > Enable 802.1X Service.Step 4 From the menu bar, choose File > Deploy to apply your changes to the device.


Configuring 802.1XPlatform Support for 802.1X


Enabling the 802.1X Feature on an InterfaceYou must enable the 802.1X feature on the interfaces you want to use for 802.1X authentication.

Procedure

Step 1 From the Feature Selector pane, choose Security > Dot1X.Step 2 From the Summary pane, double-click a device to display the slots.Step 3 Double-click a slot to display the interfaces.Step 4 Click an interface.Step 5 From the Interface Settings tab, click Enable Dot1X.Step 6 From the menu bar, choose File > Deploy to apply your changes to the device.

Controlling 802.1X Authentication on an InterfaceYou can control the 802.1X authentication performed on an interface. An interface can have the following802.1X authentication states:

Enables 802.1X authentication on the interface.Auto

Disables 802.1X authentication on the interface and allows all traffic onthe interface without authentication. This state is the default.

Force-authorized

Disallows all traffic on the interface.Force-unauthorized

Procedure

Step 1 From the Feature Selector pane, choose Security > Dot1X.Step 2 From the Summary pane, double-click a device to display the slots.Step 3 Double-click a slot to display the interfaces.Step 4 Click an interface.Step 5 Click the Interface Settings tab.Step 6 Click General.Step 7 From the Port Control drop-down list, choose the port control type.Step 8 From the menu bar, choose File > Deploy to apply your changes to the device.

Related Topics

• Enabling the 802.1X Service, page 119• Enabling the 802.1X Feature on an Interface, page 120


Configuring 802.1XEnabling the 802.1X Feature on an Interface

Enabling Global Periodic ReauthenticationYou can enable global periodic 802.1X reauthentication and specify how often it occurs. If you do not specifya time period before enabling reauthentication, the number of seconds between reauthentication attempts is3600 (1 hour).

During the reauthentication process, the status of an already authenticated supplicant is not disrupted.Note

Procedure

Step 1 From the Feature Selector pane, choose Security > Dot1X.Step 2 From the Summary pane, click a device.Step 3 Click the Global Settings tab.Step 4 Click General.Step 5 Check Enable Re-authentication.Step 6 (Optional) In the Re-auth Period(secs), enter the number of seconds between period reauthentication for

supplicants on the interface.The default is 3600 seconds (10 hours).


Related Topics

• Enabling the 802.1X Service, page 119• Enabling Periodic Reauthentication for an Interface, page 121

Enabling Periodic Reauthentication for an InterfaceYou can enable periodic 802.1X reauthentication on an interface and specify how often it occurs. If you donot specify a time period before enabling reauthentication, the number of seconds between reauthenticationdefaults to the global value.

During the reauthentication process, the status of an already authenticated supplicant is not disrupted.Note


Configuring 802.1XEnabling Global Periodic Reauthentication

Procedure

Step 1 From the Feature Selector pane, choose Security > Dot1X.Step 2 From the Summary pane, double-click a device to display the slots.Step 3 Double-click a slot to display the interfaces.Step 4 Click an interface.Step 5 Click the Interface Settings tab.Step 6 Click General.Step 7 Check Enable Re-authentication.Step 8 (Optional) In the Re-auth Period(secs), enter the number of seconds between period reauthentication for

supplicants on the interface.The default is the global setting.


Related Topics

• Enabling the 802.1X Service, page 119• Enabling Global Periodic Reauthentication, page 121

Changing Global 802.1X Authentication TimersThe following global 802.1X authentication timers are supported on the device:

When the device cannot authenticate the supplicant, the device remains idle for aset period of time, and then tries again. The quiet-period timer value determines

Quiet-period time

the idle period. An authentication failure might occur because the supplicantprovided an invalid password. You can provide a faster response time to the userby entering a number smaller than the default. The default is 60 seconds. The rangeis from 1 to 65535.

The client responds to the EAP-request/identity frame from the device with anEAP-response/identity frame. If the device does not receive this response, it waits

Switch-to-supplicantretransmission periodtimer a set period of time (known as the retransmission time) and then retransmits the

frame. The default is 30. The range is from 1 to 65535 seconds.

You can also configure the quiet-period timer and switch-to-supplicant transmission period timer at theinterface level.

Note

You should change the default values only to adjust for unusual circumstances such as unreliable links orspecific behavioral problems with certain supplicants and authentication servers.

Note


Configuring 802.1XChanging Global 802.1X Authentication Timers

Procedure

Step 1 From the Feature Selector pane, choose Security > Dot1X.Step 2 From the Summary pane, click a device.Step 3 Click the Global Settings tab.Step 4 Click Timers.Step 5 (Optional) In the Quiet Period(secs) field, enter the number of seconds for the quiet-period timer.

The default is 60 seconds.Step 6 (Optional) In the TX Period(secs) field, enter the number of seconds for the switch-to-supplicant retransmission

timer.The default is 30 seconds.


Related Topics

• Enabling the 802.1X Service, page 119• Changing 802.1X Authentication Timers for an Interface, page 123

Changing 802.1X Authentication Timers for an InterfaceYou can change the following 802.1X authentication timers on the device interfaces:

When the Cisco NX-OS device cannot authenticate the supplicant, theswitch remains idle for a set period of time and then tries again. The

Quiet-period time

quiet-period timer value determines the idle period. An authenticationfailure might occur because the supplicant provided an invalid password.You can provide a faster response time to the user by entering a smallernumber than the default. The default is the value of the global quiet periodtimer. The range is from 1 to 65535 seconds.

The rate-limit period throttles EAPOL-Start packets from supplicants thatare sending too many EAPOL-Start packets. The authenticator ignores

Rate-limit timer

EAPOL-Start packets from supplicants that have successfully authenticatedfor the rate-limit period duration. The default value is 0 seconds and theauthenticator processes all EAPOL-Start packets. The range is from 1 to65535 seconds.

The authentication server notifies the switch each time that it receives aLayer 4 packet. If the switch does not receive a notification after sending

Switch-to-authentication-serverretransmission timer forLayer 4 packets a packet, the Cisco NX-OS device waits a set period of time and then

retransmits the packet. The default is 30 seconds. The range is from 1 to65535 seconds.

The supplicant responds to the EAP-request/identity frame from the CiscoNX-OS device with an EAP-response/identity frame. If the Cisco NX-OS

Switch-to-supplicantretransmission timer for EAPresponse frames device does not receive this response, it waits a set period of time (known

as the retransmission time) and then retransmits the frame. The default is30 seconds. The range is from 1 to 65535 seconds.


Configuring 802.1XChanging 802.1X Authentication Timers for an Interface

Switch-to-supplicant retransmission timer for EAP request frames—Thesupplicant notifies the CiscoNX-OS device that it received the EAP request

Switch-to-supplicantretransmission timer for EAPrequest frame frame. If the authenticator does not receive this notification, it waits a set

period of time and then retransmits the frame. The default is the value ofthe global retransmission period timer. The range is from 1 to 65535seconds.

You should change the default values only to adjust for unusual circumstances such as unreliable links orspecific behavioral problems with certain supplicants and authentication servers.

Note

Procedure

Step 1 From the Feature Selector pane, choose Security > Dot1X.Step 2 From the Summary pane, double-click a device to display the slots.Step 3 Double-click a slot to display the interfaces.Step 4 Click an interface.Step 5 Click the Interface Settings tab.Step 6 Click Timers.Step 7 (Optional) In the Quiet Period(secs) field, enter the number of seconds for the quiet-period timer.

The default is the global setting.Step 8 (Optional) In the TX Period(secs) field, enter the number of seconds for the switch-to-supplicant retransmission

timer for EAP request frames.The default is the global setting.

Step 9 (Optional) (Optional) In the Supplicant Period(secs) field, enter the number of seconds for theswitch-to-supplicant retransmission timer for EAP response frames interval.The default is the value of the global quiet period timer.

Step 10 (Optional) In the Server Period(secs) field, enter the number of seconds for the switch-to-authentication-serverretransmission timer for Layer 4 packets.The default is 30 seconds.

Step 11 (Optional) In the Rate Limit Period(secs) field, enter the number of seconds for the rate-limit timer.The default value is 0 seconds and the authenticator processes all EAPOL-Start packets.


Related Topics

• Enabling the 802.1X Service, page 119• Changing Global 802.1X Authentication Timers, page 122

Enabling Single Host or Multiple Hosts ModeYou can enable single host or multiple hosts mode on an interface.


Configuring 802.1XEnabling Single Host or Multiple Hosts Mode

Procedure

Step 1 From the Feature Selector pane, choose Security > Dot1X.Step 2 From the Summary pane, double-click a device to display the slots.Step 3 Double-click a slot to display the interfaces.Step 4 Click an interface.Step 5 Click the Interface Settings tab.Step 6 Click General.Step 7 From the Host Mode drop-down list, choose Single orMultiple.

The default is Single.Step 8 From the menu bar, choose File > Deploy to apply your changes to the device.

Related Topics

• Enabling the 802.1X Service, page 119

Enabling MAC Address Authentication BypassYou can enable MAC address authentication bypass on an interface that has no supplicant connected.

Procedure

Step 1 From the Feature Selector pane, choose Security > Dot1X.Step 2 From the Summary pane, double-click a device to display the slots.Step 3 Double-click a slot to display the interfaces.Step 4 Click an interface.Step 5 Click the Interface Settings tab.Step 6 Click General.Step 7 Check theMac-auth-bypass check box.

The default is disabled.Step 8 (Optional) Check the EAP Authentication check box to enable MAC authentication bypass for EAP

authentication.Step 9 From the menu bar, choose File > Deploy to apply your changes to the device.

Related Topics


Disabling 802.1X Authentication on the DeviceYou can disable 802.1X authentication on the device. By default, the Cisco NX-OS software enables 802.1Xauthentication after you enable the 802.1X feature. However, when you disable the 802.1X feature, the


Configuring 802.1XEnabling MAC Address Authentication Bypass

configuration is removed from the device. The Cisco NX-OS software allow you to disable 802.1Xauthentication without losing the 802.1X configuration.

When you disable 802.1X authentication, the port mode for all interfaces defaults to force-authorizedregardless of the configured port mode. When you reenable 802.1X authentication, the Cisco NX-OSsoftware restores the configured port mode on the interfaces.

Note

Procedure

Step 1 From the Feature Selector pane, choose Security > Dot1X.Step 2 From the Summary pane, click a device.Step 3 Click the Global Settings tab.Step 4 Click General.Step 5 Uncheck Sys Auth Enable.

The default is enabled.


Related Topics

• Enabling the 802.1X Service, page 119• Controlling 802.1X Authentication on an Interface, page 120

Disabling the 802.1X FeatureYou can disable the 802.1X feature on the device.

Disabling 802.1X removes all 802.1X configuration from the device.Caution

Procedure

Step 1 From the Feature Selector pane, choose Security > Dot1X.Step 2 From the Summary pane, click a device.Step 3 From the menu bar, choose Dot1X > Disable 802.1X.Step 4 From the menu bar, choose File > Deploy to apply your changes to the device.

Related Topics

• Enabling the 802.1X Service, page 119• Disabling 802.1X Authentication on the Device, page 125


Configuring 802.1XDisabling the 802.1X Feature

Setting Global Maximum Authenticator-to-Supplicant Frame RetransmissionRetry Count

In addition to changing the authenticator-to-supplicant retransmission time, you can set the number of timesthat the device sends an EAP-request/identity frame (assuming no response is received) to the supplicantbefore restarting the authentication process.

You should change the default value of this command only to adjust for unusual circumstances such asunreliable links or specific behavioral problems with certain supplicants and authentication servers.

Note

Procedure

Step 1 From the Feature Selector pane, choose Security > Dot1X.Step 2 From the Summary pane, click a device.Step 3 Click the Global Settings tab.Step 4 Click General.Step 5 In the Max Request field, enter the maximum request retry count.

The default is 2.Step 6 From the menu bar, choose File > Deploy to apply your changes to the device.

Related Topics

• Enabling the 802.1X Service, page 119• Configuring the Maximum Authenticator-to-Supplicant Frame Retransmission Retry Count for anInterface, page 127

Configuring the Maximum Authenticator-to-Supplicant Frame RetransmissionRetry Count for an Interface

You can configure the maximum number of times that the device retransmits authentication requests to thesupplicant on an interface before the session times out. The default is 2 times and the range is from 1 to 10.


Configuring 802.1XSetting Global Maximum Authenticator-to-Supplicant Frame Retransmission Retry Count

Procedure

Step 1 From the Feature Selector pane, choose Security > Dot1X.Step 2 From the Summary pane, double-click a device to display the slots.Step 3 Double-click a slot to display the interfaces.Step 4 Click an interface.Step 5 Click the Interface Settings tab.Step 6 Click General.Step 7 In the Max Request field, enter the maximum request retry count.


Related Topics

• Enabling the 802.1X Service, page 119• Setting Global Maximum Authenticator-to-Supplicant Frame Retransmission Retry Count, page 127

Enabling RADIUS Accounting for 802.1X AuthenticationYou can enable RADIUS accounting for the 802.1X authentication activity.

Procedure

Step 1 From the Feature Selector pane, choose Security > Dot1X.Step 2 From the Summary pane, click a device.Step 3 Click the Global Settings tab.Step 4 Click General.Step 5 Check RADIUS Accounting.

The default is disabled.Step 6 From the menu bar, choose File > Deploy to apply your changes to the device.

Related Topics


Configuring AAA Accounting Methods for 802.1XYou can enable AAA accounting methods for the 802.1X feature.


Configuring 802.1XEnabling RADIUS Accounting for 802.1X Authentication

Procedure

Step 1 From the Feature Selector pane, choose Security > AAA > Rules.Step 2 From the Summary table pane, click the expand icon by the device to display the list of rules.Step 3 Click Accounting Rules.Step 4 Click the expand icon by Accounting Rules.Step 5 From the menu bar, choose Rules > Add Rule.

A new default rule appears in the list and the Authentication Rules tab appears in the Details pane.Step 6 From the Service Type drop-down list, choose Dot1x.Step 7 (Optional) Double-click the cell under Type in the new method.

Group appears in the method cell.Step 8 Double-click the method cell under Server Group Name.Step 9 Enter the server group name or choose a server group name from the drop-down list and click OK.Step 10 (Optional) To add more methods, right-click on a method, choose Add Method from the pop-up menu, and

repeat Step 6 through Step 8 for the new method.Step 11 From the menu bar, choose File > Deploy to apply your changes to the device.

Related Topics

• Configuring AAA, page 23• Configuring RADIUS, page 41• Enabling the 802.1X Service, page 119

Setting the Maximum Reauthentication Retry Count on an InterfaceYou can set the maximum number of times that the device retransmits reauthentication requests to the supplicanton an interface before the session times out. The default is 2 times and the range is from 1 to 10.

Procedure

Step 1 From the Feature Selector pane, choose Security > Dot1X.Step 2 From the Summary pane, double-click a device to display the slots.Step 3 Double-click a slot to display the interfaces.Step 4 Click an interface.Step 5 Click the Interface Settings tab.Step 6 Click General.Step 7 In the Max Reauth Request field, enter the maximum reauthentication request retry count.



Configuring 802.1XSetting the Maximum Reauthentication Retry Count on an Interface

Related Topics


Displaying 802.1X StatisticsYou can display the statistics that the device maintains for the 802.1X activity.

Procedure

Step 1 From the Feature Selector pane, choose Security > Dot1X.Step 2 From the Summary pane, click a device.Step 3 From the Details pane, click the Statistics tab for 802.1X statistics for the device.Step 4 From the Summary pane, double-click a device to display the slots.Step 5 Double-click a slot to display the interfaces.Step 6 Click an interface.Step 7 From the Details pane, click the Statistics tab to display 802.1X statistics for the interface.

Related Topics


Field Descriptions for 802.1XThis section includes field descriptions for the 802.1X feature in Cisco DCNM.

Security: Dot1X: Summary PaneTable 31: Security: Dot1X: Summary Pane

DescriptionElement

Displays the name of the notifies.Interface Name

Displays the description of the interfaces.Description

Displays the 802.1X status for the interfaces.Dot1x State

Host mode for 802.1X on the interfaces, either singleor multiple. The default is single.

Host Mode

802.1X authentication on the interfaces. The defaultis force authorized.

Port Control

Displays the operating status for the interfaces.Oper Status


Configuring 802.1XDisplaying 802.1X Statistics

Security: Dot1X: device: Global Settings Tab: GeneralTable 32: Security: Dot1X: device: Global Settings Tab: General

DescriptionElement

Enables or disables 802.1X authentication for theentire device without removing the configuration.The default is enabled.

Sys Auth Enable

Enables or disables RADIUS accounting for 802.1Xusing the AAA accounting configuration for the802.1X accounting rule. The default is disabled.

Radius Accounting

Maximum number of times that the device sends anEAP-request/identity frame (assuming no response

Max Request

is received) to the supplicant before restarting theauthentication process. The default is 2.

Enables or disables global supplicant reauthentication.The default is disabled.

Enable Re-authentication

Period for automatic reauthentication of supplicants.The default is 3600 seconds (60 minutes).

Re-auth Period(secs)

Security: Dot1X: device: Global Settings Tab: TimersTable 33: Security: Dot1X: device: Global Settings Tab: Timers

DescriptionElement

Number of seconds between attempts by the deviceto authenticate the supplicant. The default is 60seconds.

Quiet Period(secs)

Retransmission time during which the device waitsafter it sends an EAP-request/identity frame before

TX Period(secs)

it receives an EAP-response/identity frame from theclient and then retransmits the request frame. Thedefault is 30 seconds.


Configuring 802.1XSecurity: Dot1X: device: Global Settings Tab: General

Security: Dot1X: device: slot: interface: Interface Settings Tab: GeneralTable 34: Security: Dot1X: device: slot: interface: Interface Settings Tab: General

DescriptionElement

Displays the type and location of the interface.Interface Name

Displays the interface description.Description

Host mode for 802.1X, either single or multiple. Thedefault is single.

Host Mode

802.1X authentication on the interface. The defaultis force authorized.

Port Control

Displays the device role.PAE Type

Enables or disables MAC address authenticationbypass. The default is disabled.

Mac-Auth-Bypass

Enables or disables EAP authentication for MACaddress authentication bypass. The default is disabled.

EAP Authentication

Displays the operation status for the interface.Oper Status

Maximum number of times that the device retransmitsreauthentication requests to the supplicant on an

Max Reauth Request

interface before the session times out. The default is2.

Maximum number of times that the device sends anEAP-request/identity frame (assuming no response

Max Request

is received) to the supplicant before restarting theauthentication process. The default is 2.

Enables or disables global supplicant reauthentication.The default is disabled.

Enable Re-authentication

Time period for automatic reauthentication ofsupplicants. The default is 3600 seconds (60minutes).

Re-auth Period(secs)


Configuring 802.1XSecurity: Dot1X: device: slot: interface: Interface Settings Tab: General

Security: Dot1X: device: slot: interface: Interface Settings Tab: TimersTable 35: Security: Dot1X: device: slot: interface: Interface Settings Tab: Timers

DescriptionElement

Number of seconds between attempts by the deviceto authenticate the supplicant. The default is 60seconds.

Quiet Period(secs)

Retransmission time during which the device waitsafter it sends an EAP-request/identity frame before

TX Period(secs)

it receives an EAP-response/identity frame from theclient and then retransmits the request frame. Thedefault is 30 seconds.

Number of seconds for the switch-to-supplicantretransmission for EAP response frames interval. Thedefault is 30 seconds.

Supplicant Period(secs)

Number of seconds for theswitch-to-authentication-server retransmission forLayer 4 packets. The default is 30 seconds.

Server Period(secs)

Number of seconds for the rate limit timer. The ratelimit timer throttles the EAPOL-Start packets from

Rate Limit Period(secs)

supplicants that are sending too many EAPOL-Startpackets. The authenticator ignores EAPOL-Startpackets from supplicants that have successfullyauthenticated for the rate-limit period duration. Thedefault value is 0 seconds and the authenticatorprocesses all EAPOL-Start packets.

Additional References for 802.1XThis section includes additional information related to implementing 802.1X.

Related Documents





Command reference


Configuring 802.1XSecurity: Dot1X: device: slot: interface: Interface Settings Tab: Timers


VRF configuration

Standards

TitleStandards

802.1X IEEE Standard for Local and MetropolitanArea Networks Port-Based Network Access Control

IEEE Std 802.1X- 2004 (Revision of IEEE Std802.1X-2001)

PPP Extensible Authentication Protocol (EAP)RFC 2284

IEEE 802.1X Remote Authentication Dial In UserService (RADIUS) Usage Guidelines

RFC 3580

MIBs

MIBs LinkMIBs

To locate and download MIBs, go to the followingURL:• IEEE8021-PAE-MIB


Feature History for 802.1XThis table lists the release history for this feature:

Table 36: Feature History for 802.1X


No change from Release 5.1.5.2(1)802.1X




Configuring 802.1XFeature History for 802.1X



C H A P T E R 9Configuring IP ACLs

This chapter describes how to configure IP access control lists (ACLs) on Cisco NX-OS devices.

Unless otherwise specified, the term IP ACL refers to IPv4 and IPv6 ACLs.

The Cisco NX-OS release that is running on a managed device may not support all documented featuresor settings. For the latest feature information and caveats, see the documentation and release notes foryour platform and software release.

Note


• Information About ACLs, page 135

• Licensing Requirements for IP ACLs, page 143

• Platform Support for IP ACLs, page 144

• Configuring IP ACLs, page 145

• Displaying IP ACL Statistics, page 149

• Field Descriptions for IPv4 ACLs, page 150

• Field Descriptions for IPv6 ACLs, page 155

• Configuring Object Groups, page 162

• Configuring Time Ranges, page 164

• Field Descriptions for Time Ranges, page 167

• Additional References for IP ACLs, page 168

• Feature History for IP ACLs, page 168

Information About ACLsAn ACL is an ordered set of rules that you can use to filter traffic. Each rule specifies a set of conditions thata packet must satisfy to match the rule. When the device determines that an ACL applies to a packet, it teststhe packet against the conditions of all rules. The first matching rule determines whether the packet is permitted


or denied. If there is no match, the device applies the applicable implicit rule. The device continues processingpackets that are permitted and drops packets that are denied.

You can use ACLs to protect networks and specific hosts from unnecessary or unwanted traffic. For example,you could use ACLs to disallow HTTP traffic from a high-security network to the Internet. You could alsouse ACLs to allow HTTP traffic but only to specific sites, using the IP address of the site to identify it in anIP ACL.

ACL Types and ApplicationsThe device supports the following types of ACLs for security traffic filtering:

The device applies IPv4 ACLs only to IPv4 traffic.IPv4 ACLs

The device applies IPv6 ACLs only to IPv6 traffic.IPv6 ACLs

The device applies MAC ACLs only to non-IP traffic by default; however,you can configure Layer 2 interfaces to apply MAC ACLs to all traffic.

MAC ACLs

IP and MAC ACLs have the following types of applications:

Filters Layer 2 trafficPort ACL

Filters Layer 3 trafficRouter ACL

Filters VLAN trafficVLAN ACL

This table summarizes the applications for security ACLs.

Table 37: Security ACL Applications

Types of ACLs SupportedSupported InterfacesApplication

Port ACL• IPv4 ACLs• Layer 2 interfaces

• •Layer 2 Ethernet port-channelinterfaces

IPv6 ACLs

• MAC ACLs

When a port ACL is applied to atrunk port, the ACL filters trafficon all VLANs on the trunk port.

Router ACL• IPv4 ACLs• VLAN interfaces

• •Physical Layer 3 interfaces IPv6 ACLs

• Layer 3 Ethernetsubinterfaces

• Layer 3 Ethernet port-channelinterfaces

• Layer 3 Ethernet port-channelsubinterfaces

• Tunnels


Configuring IP ACLsACL Types and Applications

Types of ACLs SupportedSupported InterfacesApplication

• Management interfaces

VLAN ACL• IPv4 ACLs• VLANs

• IPv6 ACLs

• MAC ACLs

Order of ACL ApplicationWhen the device processes a packet, it determines the forwarding path of the packet. The path determineswhich ACLs that the device applies to the traffic. The device applies the ACLs in the following order:

1 Port ACL

2 Ingress VACL

3 Ingress router ACL

4 Egress router ACL

5 Egress VACL

If the packet is bridged within the ingress VLAN, the device does not apply router ACLs.

The following figure shows the order in which the device applies ACLs.Figure 29: Order of ACL Application

The following figure shows where the device applies ACLs, depending upon the type of ACL. The red pathindicates a packet sent to a destination on a different interface than its source. The blue path indicates a packetthat is bridged within its VLAN.

The device applies only the applicable ACLs. For example, if the ingress port is a Layer 2 port and the trafficis on a VLAN that is a VLAN interface, a port ACL and a router ACL both can apply. In addition, if a VACLis applied to the VLAN, the device applies that ACL too.


Configuring IP ACLsOrder of ACL Application

Figure 30: ACLs and Packet Flow

About RulesRules are what you create, modify, and remove when you configure how an ACL filters network traffic. Rulesappear in the running configuration. When you apply an ACL to an interface or change a rule within an ACLthat is already applied to an interface, the supervisor module creates ACL entries from the rules in the runningconfiguration and sends those ACL entries to the applicable I/O module. Depending upon how you configurethe ACL, there may be more ACL entries than rules, especially if you implement policy-based ACLs by usingobject groups when you configure rules.

You can create rules in ACLs and the device allows traffic that matches the criteria in a permit rule and blockstraffic that matches the criteria in a deny rule. You have many options for configuring the criteria that trafficmust meet in order to match the rule.

This section describes some of the options that you can use when you configure a rule.

ProtocolsIPv4, IPv6, and MAC ACLs allow you to identify traffic by protocol. For your convenience, you can specifysome protocols by name. For example, in an IPv4 or IPv6 ACL, you can specify ICMP by name.

You can specify any protocol by number. In MAC ACLs, you can specify protocols by the EtherType numberof the protocol, which is a hexadecimal number. For example, you can use 0x0800 to specify IP traffic in aMAC ACL rule.

In IPv4 and IPv6 ACLs, you can specify protocols by the integer that represents the Internet protocol number.For example, you can use 115 to specify Layer 2 Tunneling Protocol (L2TP) traffic.


Configuring IP ACLsAbout Rules

Source and DestinationIn each rule, you specify the source and the destination of the traffic that matches the rule. You can specifyboth the source and destination as a specific host, a network or group of hosts, or any host. How you specifythe source and destination depends on whether you are configuring IPv4, IPv6, or MAC ACLs.

Implicit RulesIP and MAC ACLs have implicit rules, which means that although these rules do not appear in the runningconfiguration, the device applies them to traffic when no other rules in an ACL match. When you configurethe device to maintain per-rule statistics for an ACL, the device does not maintain statistics for implicit rules.

All IPv4 ACLs include the following implicit rule:deny ip any any

This implicit rule ensures that the device denies unmatched IP traffic.

All IPv6 ACLs include the following implicit rules:permit icmp any any nd-napermit icmp any any nd-nspermit icmp any any router-advertisementpermit icmp any any router-solicitationdeny ipv6 any any

Unless you configure an IPv6 ACL with a rule that denies ICMPv6 neighbor discovery messages, the firstfour rules ensure that the device permits neighbor discovery advertisement and solicitation messages. Thefifth rule ensures that the device denies unmatched IPv6 traffic.

If you explicitly configure an IPv6 ACL with a deny ipv6 any any rule, the implicit permit rules cannever permit traffic. If you explicitly configure a deny ipv6 any any rule but want to permit ICMPv6neighbor discovery messages, explicitly configure a rule for all five implicit IPv6 ACL rules.

Note

All MAC ACLs include the following implicit rule:

deny any any protocol

This implicit rule ensures that the device denies the unmatched traffic, regardless of the protocol specified inthe Layer 2 header of the traffic.

Additional Filtering OptionsYou can identify traffic by using additional options. These options differ by ACL type. The following listincludes most but not all additional filtering options:

• IPv4 ACLs support the following additional filtering options:

◦ Layer 4 protocol

◦ Authentication Header Protocol

◦ Enhanced Interior Gateway Routing Protocol (EIGRP)

◦ Encapsulating Security Payload



◦ General Routing Encapsulation (GRE)

◦ KA9Q NOS-compatible IP-over-IP tunneling

◦ Open Shortest Path First (OSPF)

◦ Payload Compression Protocol

◦ Protocol-independent multicast (PIM)

◦ TCP and UDP ports

◦ ICMP types and codes

◦ IGMP types

◦ Precedence level

◦ Differentiated Services Code Point (DSCP) value

◦ TCP packets with the ACK, FIN, PSH, RST, SYN, or URG bit set

◦ Established TCP connections

◦ Packet length

• IPv6 ACLs support the following additional filtering options:


◦ Authentication Header Protocol

◦ Encapsulating Security Payload

◦ Payload Compression Protocol

◦ Stream Control Transmission Protocol (SCTP)

◦ SCTP, TCP, and UDP ports

◦ ICMP types and codes

◦ IGMP types

◦ Flow label

◦ DSCP value

◦ TCP packets with the ACK, FIN, PSH, RST, SYN, or URG bit set

◦ Established TCP connections

◦ Packet length

• MAC ACLs support the following additional filtering options:


◦ VLAN ID

◦ Class of Service (CoS)



Logical Operators and Logical Operation UnitsIP ACL rules for TCP and UDP traffic can use logical operators to filter traffic based on port numbers. Thedevice stores operator-operand couples in registers called logical operator units (LOUs). Cisco Nexus7000-series devices support 104 LOUs.

The LOU usage for each type of operator is as follows:

Is never stored in an LOUeq

Uses 1/2 LOUgt

Uses 1/2 LOUlt

Uses 1/2 LOUneq

Uses 1 LOUrange

The following guidelines determine when the devices store operator-operand couples in LOUs:

• If the operator or operand differs from other operator-operand couples that are used in other rules, thecouple is stored in an LOU.

For example, the operator-operand couples "gt 10" and "gt 11" would be stored separately in half anLOU each. The couples "gt 10" and "lt 10" would also be stored separately.

• Whether the operator-operand couple is applied to a source port or a destination port in the rule affectsLOU usage. Identical couples are stored separately when one of the identical couples is applied to asource port and the other couple is applied to a destination port.

For example, if a rule applies the operator-operand couple "gt 10" to a source port and another ruleapplies a "gt 10" couple to a destination port, both couples would also be stored in half an LOU, resultingin the use of one whole LOU. Any additional rules using a "gt 10" couple would not result in furtherLOU usage.

LoggingYou can enable the device to create an informational log message for packets that match a rule. The logmessage contains the following information about the packet:

• Protocol

• Status of whether the packet is a TCP, UDP, or ICMP packet, or if the packet is only a numbered packet.

• Source and destination address

• Source and destination port numbers, if applicable

Time RangesYou can use time ranges to control when an ACL rule is in effect. For example, if the device determines thata particular ACL applies to traffic arriving on an interface, and a rule in the ACL uses a time range that is notin effect, the device does not compare the traffic to that rule. The device evaluates time ranges based on itsclock.


Configuring IP ACLsTime Ranges

When you apply an ACL that uses time ranges, the device updates the affected I/O module whenever a timerange referenced in the ACL starts or ends. Updates that are initiated by time ranges occur on a best-effortpriority. If the device is especially busy when a time range causes an update, the device may delay the updateby up to a few seconds.

IPv4, IPv6, and MAC ACLs support time ranges. When the device applies an ACL to traffic, the rules ineffect are as follows:

• All rules without a time range specified

• Rules with a time range that includes the second when the device applies the ACL to traffic

The device supports named, reusable time ranges, which allows you to configure a time range once and specifyit by namewhen you configuremanyACL rules. Time range names have amaximum length of 64 alphanumericcharacters.

A time range contains one or more rules. The two types of rules are as follows:

A rule with a specific start date and time, specific end date and time, both, or neither. The followingitems describe how the presence or absence of a start or end date and time affect whether anabsolute time range rule is active:

Absolute

• Start and end date and time both specified—The time range rule is active when the currenttime is later than the start date and time and earlier than the end date and time.

• Start date and time specified with no end date and time—The time range rule is active whenthe current time is later than the start date and time.

• No start date and time with end date and time specified—The time range rule is active whenthe current time is earlier than the end date and time.

• No start or end date and time specified—The time range rule is always active.

For example, you could prepare your network to allow access to a new subnet by specifying atime range that allows access beginning at midnight of the day that you plan to place the subnetonline. You can use that time range in ACL rules that apply to the subnet. After the start time anddate have passed, the device automatically begins applying the rules that use this time range whenit applies the ACLs that contain the rules.

A rule that is active one or more times per week. For example, you could use a periodic timerange to allow access to a lab subnet only duringwork hours onweekdays. The device automatically

Periodic

applies ACL rules that use this time range only when the range is active and when it applies theACLs that contain the rules.

The order of rules in a time range does not affect how a device evaluates whether a time range is active.Note

Time ranges also allow you to include remarks, which you can use to insert comments into a time range.Remarks have a maximum length of 100 alphanumeric characters.

The device determines whether a time range is active as follows:

• The time range contains one or more absolute rules—The time range is active if the current time is withinone or more absolute rules.


Configuring IP ACLsTime Ranges

• The time range contains one or more periodic rules—The time range is active if the current time is withinone or more periodic rules.

• The time range contains both absolute and periodic rules—The time range is active if the current timeis within one or more absolute rules and within one or more periodic rules.

When a time range contains both absolute and periodic rules, the periodic rules can only be active when atleast one absolute rule is active.

Statistics and ACLsThe device can maintain global statistics for each rule that you configure in IPv4, IPv6, and MAC ACLs. Ifan ACL is applied to multiple interfaces, the maintained rule statistics are the sum of packet matches (hits)on all the interfaces on which that ACL is applied.

The device does not support interface-level ACL statistics.Note

For each ACL that you configure, you can specify whether the device maintains statistics for that ACL, whichallows you to turn ACL statistics on or off as needed to monitor traffic filtered by an ACL or to helptroubleshoot the configuration of an ACL.

The device does not maintain statistics for implicit rules in an ACL. For example, the device does not maintaina count of packets that match the implicit deny ip any any rule at the end of all IPv4 ACLs. If you want tomaintain statistics for implicit rules, you must explicitly configure the ACL with rules that are identical to theimplicit rules.

Related Topics

• Displaying IP ACL Statistics, page 149• Implicit Rules, page 139

Atomic ACL UpdatesBy default, when a supervisor module of a Cisco Nexus 7000 Series device updates an I/O module withchanges to an ACL, it performs an atomic ACL update. An atomic update does not disrupt traffic that theupdated ACL applies to; however, an atomic update requires that an I/O module that receives an ACL updatehas enough available resources to store each updated ACL entry in addition to all pre-existing entries in theaffected ACL. After the update occurs, the additional resources used for the update are freed. If the I/Omodulelacks the required resources, the device generates an error message and the ACL update to the I/O modulefails.

If an I/Omodule lacks required resources, you can disable atomic updates by using the command-line interfaceof the device. DCNM cannot configure the atomic ACL update feature.

Licensing Requirements for IP ACLsThe following table shows the licensing requirements for this feature:


Configuring IP ACLsStatistics and ACLs


IP ACLs require no license. Any feature not includedin a license package is bundled with the Cisco DCNM

Cisco DCNM

and is provided at no charge to you. For anexplanation of the Cisco DCNM licensing scheme,see the Cisco DCNM Installation and LicensingGuide, Release 5.x.

No license is required to use IP ACLs. Any featurenot included in a license package is bundled with the

Cisco NX-OS


Platform Support for IP ACLsThe following platforms support these features but may implement them differently. For platform-specificinformation, including guidelines and limitations, system defaults, and configuration limits, see thecorresponding documentation.

DocumentationPlatformFeature

Cisco Nexus 1000V Series SwitchesDocumentation

Cisco Nexus 1000V Series SwitchesIPv4 ACLs

Cisco Nexus 3000 Series SwitchesDocumentation

Cisco Nexus 3000 Series Switches








Cisco Nexus 5000 Series SwitchesIPv6 ACLs




Cisco Nexus 7000 Series SwitchesTime range


Cisco Nexus 7000 Series SwitchesObject group


Configuring IP ACLsPlatform Support for IP ACLs



















Configuring IP ACLs

Creating an IP ACLYou can create an IP ACL on the device and add rules to it.

Procedure

Step 1 From the Feature Selector pane, choose Security ➤ Access Control ➤ IPv4 ACL or IPv6 ACL.The available devices appear in the Summary pane.

Step 2 From the Summary pane, double-click the device to which you want to add an ACL.Step 3 (Optional) From the menu bar, choose File ➤ New ➤ IPv4 ACL or IPv6 ACL.

A new row appears in the S tummary pane. The Details tab appears in the Details pane.

Step 4 From the Details tab, in the Name field, type a name for the ACL.Step 5 (Optional) If you want the device to maintain global statistics for rules in this MAC ACL, check Statistics.Step 6 For each rule that you want to add to the ACL, from the menu bar, choose File ➤ New and choose the type

of rule. From the Details tab, configure fields as needed.Step 7 (Optional) From the menu bar, choose File ➤ Deploy to apply your changes to the device.

Changing an IP ACLYou can change, reorder, add, and remove rules in an existing IP ACL.

Procedure


Step 2 (Optional) From the Summary pane, double-click the device that has the ACL that you want to change andthen double-click the ACL.The ACLs on the device and the rules of the ACL that you double-clicked appear in the Summary pane.

Step 3 (Optional) If you change whether the device maintains global statistics for rules in this IP ACL, click theACL in the Summary pane and then, on the Details tab, check or uncheck Statistics as needed.

Step 4 (Optional) If you want to change the details of a rule, click the rule in the Summary pane. From the Detailstab, configure fields as needed.

Step 5 (Optional) If you want to add a rule, click the ACL in the Summary pane and then from the menu bar, chooseFile ➤ New and choose the type of rule. On the Details tab, configure fields as needed.

Step 6 (Optional) If you want to remove a rule, click the rule and then from the menu bar, chooseActions➤Delete.Step 7 (Optional) If you want to move a rule to a different position in the ACL, click the rule in the Summary pane

and then from the menu bar, choose one of the following, as applicable:


Configuring IP ACLsConfiguring IP ACLs

• Actions ➤ Move Up

• Actions ➤ Move Down

The rule swaps places and sequence numbers with the rule above it or below it, as you chose.

Step 8 (Optional) From the menu bar, choose File ➤ Deploy to apply your changes to the device.

Related Topics

• Changing Sequence Numbers in an IP ACL, page 146

Changing Sequence Numbers in an IP ACLYou can change all the sequence numbers assigned to the rules in an IP ACL.

Procedure


Step 2 From the Summary pane, double-click the device that has the ACL that you want to change and thendouble-click the ACL.The ACLs on the device and the rules of the ACL that you double-clicked appear in the Summary pane. TheSeq No column shows the sequence number assigned to each rule.

Step 3 Click the rule whose sequence number you want to change.The Details pane shows the Sequence Number field for the rule.

Step 4 Click the Sequence Number field, edit the number, and press Tab.In the Summary pane, the new sequence number appears and, if applicable, the rule moves to the positiondetermined by the new sequence number.

Step 5 From the menu bar, choose File ➤ Deploy to apply your changes to the device.

Removing an IP ACLYou can remove an IP ACL from the device.

Before You Begin

Ensure that you know whether the ACL is applied to an interface. The device allows you to remove ACLsthat are currently applied. Removing an ACL does not affect the configuration of interfaces where you haveapplied the ACL. Instead, the device considers the removed ACL to be empty.


Configuring IP ACLsChanging Sequence Numbers in an IP ACL

Procedure


Step 2 From the Summary pane, double-click the device from which you want to remove an ACL.The ACLs currently on the device appear in the Summary pane.

Step 3 Click the ACL that you want to remove.Step 4 From the menu bar, choose Actions ➤ Delete.

The ACL disappears from the Summary pane.


Applying an IP ACL to a Physical PortYou can apply an IP ACL to a physical Ethernet port.

DCNM allows you to apply IP ACLs directionally; that is, you can specify separate ACLs for incoming trafficand outgoing traffic on a physical Ethernet port.

Before You Begin

Ensure that the ACL that you want to apply exists and that it is configured to filter traffic in the manner thatyou need for this application.

Procedure

Step 1 From the Feature Selector pane, choose Interfaces ➤ Physical ➤ Ethernet.Available devices appear in the Summary pane.

Step 2 From the Summary pane, double-click the applicable device and then double-click the slot that contains theport.The ports in the slot that you double-clicked appear in the Summary pane.

Step 3 Click the port to which you want to apply an IP ACL.Step 4 From the Details pane, click the Port Details tab and expand the Advanced Settings section, if necessary.

The following drop-down lists appear in the Advanced Settings section:

• Incoming Ipv4 Traffic

• Outgoing Ipv4 Traffic



Step 5 For each ACL type and traffic direction that you want to apply an ACL, from the applicable drop-down list,choose the ACL that you want to apply.



Configuring IP ACLsApplying an IP ACL to a Physical Port

Related Topics

• Creating an IP ACL, page 145

Applying an IP ACL to a Virtual Ethernet InterfaceYou can apply an IP ACL to a virtual Ethernet port.

DCNM allows you to apply IP ACLs directionally; that is, you can specify separate ACLs for incoming trafficand outgoing traffic on a physical Ethernet port.

Before You Begin


Procedure

Step 1 From the Feature Selector pane, choose Interfaces ➤ Logical ➤ Virtual Ethernet.Available devices appear in the Summary pane.

Step 2 From the Summary pane, double-click the applicable device and then double-click the slot that contains theport.The ports in the slot that you double-clicked appear in the Summary pane.

Step 3 Click the interface to which you want to apply an IP ACL.Settings for the interface that you clicked appear in the Details pane.

Step 4 From the Details pane, click the Port Details tab and expand the Advanced Settings section, if necessary.The following drop-down lists appear in the Advanced Settings section:



Step 5 For traffic direction that you want to apply an ACL, from the applicable drop-down list, choose the ACL thatyou want to apply.


Applying an IP ACL to a Port ChannelYou can apply IP ACLs to an Ethernet port channel.

DCNM allows you to apply IP ACLs directionally; you can specify separate ACLs for incoming traffic andoutgoing traffic on an Ethernet port channel.


Configuring IP ACLsApplying an IP ACL to a Virtual Ethernet Interface

Before You Begin

Ensure that the ACL you want to apply exists and that it is configured to filter traffic in the manner that youneed for this application.

Procedure

Step 1 From the Feature Selector pane, choose Ports ➤ Logical ➤ Port Channel.Available devices appear in the Summary pane.

Step 2 From the Summary pane, double-click the applicable device.Port channels on the device that you double-clicked appear in the Summary pane.

Step 3 Click the port channel to which you want to apply an IP ACL.Settings about the port channel appear in the Details pane.

Step 4 From the Details pane, click the Port Channel Advanced Settings tab and expand the Advanced Settingssection, if necessary.In the Advanced Settings section, the IPv4 ACL and IPv6 ACL areas each contain an Incoming Trafficdrop-down list and an Outgoing Traffic drop-down list.

Step 5 For each ACL type and traffic direction that you want to apply an ACL, from the applicable drop-down list,choose the ACL that you want to apply.


Related Topics

• Creating an IP ACL, page 145

Applying an IP ACL as a VACLYou can apply an IP ACL as a VACL.

Displaying IP ACL StatisticsThe following window appears in the Statistics tab:

Information about the number of packets that match the selectedIP ACL rule.

Access Rule Statistics Chart

See the , for more information on collecting statistics for this feature.


Configuring IP ACLsApplying an IP ACL as a VACL

Field Descriptions for IPv4 ACLs

IPv4 ACL: Details TabTable 38: IPv4 ACL: Details Tab

DescriptionField

Name of the IPv4 ACL. Names can be a maximumof 64 alphanumeric characters but must begin with

Name

an alphabetic character. No name is assigned bydefault.

Whether the device logs statistics about traffic filteredby the ACL. This check box is unchecked by default.

Statistics

IPv4 Access Rule: Details TabTable 39: IPv4 Access Rule: Details Tab

DescriptionField

Display only. Sequence number assigned to the rule.Sequence Number

Action taken by the device when it determines thatthe rule applies to the packet. Valid values are asfollows:

Action

• Deny—Stops processing the packet and dropsit. This is the default value.

• Permit—Continues processing the packet.

IPv4 Access Rule: Details: Source and Destination SectionTable 40: IPv4 Access Rule: Details: Source and Destination Section

DescriptionField

Type of source. Valid values are as follows:Source

• Any—The rule matches packets from any IPv4source. This is the default value. When youchoose Any, the IPAddress andWildcardMask


Configuring IP ACLsField Descriptions for IPv4 ACLs

DescriptionField

fields below this list are unavailable becauseyou do not need to specify either of them.

• Host—The rule matches packets from a specificIPv4 address. When you choose Host, the IPAddress field below this list is available but theWildcard Mask field remains unavailable.

• Network—The rule matches packets from anIPv4 network. When you choose Network, theIP Address and Wildcard Mask fields belowthis list are both available.

IPv4 address of a host or a network. Valid addressesare in dotted decimal format. This field is available

IP Address (Source)

when you choose Host or Network from the Sourcedrop-down list. This field is unavailable by default.

Wildcard mask of an IPv4 network. Valid masks arein dotted decimal format. For example, if you

Wildcard Mask (Source)

specified 192.168.0.0 in the IP Address field, youwould enter 0.0.255.255 in this field. This field isavailable when you choose Network from the Sourcedrop-down list. This field is unavailable by default.

Type of destination. Valid values are as follows:Destination

• Any—The rulematches packets sent to any IPv4source. This is the default value. When youchoose Any, the IPAddress andWildcardMaskfields below this list are unavailable becauseyou do not need to specify either of them.

• Host—The rule matches packets sent to aspecific IPv4 address. When you choose Host,the IP Address field below this list is availablebut the Wildcard Mask field remainsunavailable.

• Network—The rule matches packets sent to anIPv4 network. When you choose Network, theIP Address and Wildcard Mask fields belowthis list are both available.

IPv4 address of a host or a network. Valid addressesare in dotted decimal format. This field is available

IP Address (Destination)

when you choose Host or Network from theDestination drop-down list. This field is unavailableby default.


Configuring IP ACLsIPv4 Access Rule: Details: Source and Destination Section

DescriptionField

Wildcard mask of an IPv4 network. Valid masks arein dotted decimal format. For example, if you

Wildcard Mask (Destination)

specified 192.168.0.0 in the IP Address field, youwould enter 0.0.255.255 in this field. This field isavailable when you choose Network from theDestination drop-down list. This field is unavailableby default.

IPv4 Access Rule: Details: Protocol and Others SectionTable 41: IPv4 Access Rule: Details: Protocol and Others Section

DescriptionField

All Access Rules

Display only. Protocol of the access rule. Possible values are as follows:Protocol

• IP

• TCP

• UDP

• ICMP

• IGMP

Named time range that applies to the access rule. If you want the ruleto be always in effect, do not specify a time range. This field is blankby default.

Time range

Whether the device logs statistics about traffic to which the access ruleapplies. This check box is unchecked by default.

Log this entry

IP Access Rule

Type of traffic that the access rule applies to. The default value is Ip,which applies to all IP protocols. To specify a well-known protocol,

IP Protocol

choose the protocol name. The list is ordered by the protocol number.For the IANA list of assigned internet protocol numbers, see http://www.iana.org/assignments/protocol-numbers.

TCP and UDP Access Rules

Source port or range of source ports to which the access rule applies.By default, no source port is assigned.

Source Port


Configuring IP ACLsIPv4 Access Rule: Details: Protocol and Others Section

http://www.iana.org/assignments/protocol-numbers


DescriptionField

The left list specifies the operator that the device uses when comparingthe source port of packets to the port or ports specified in the accessrule.

The right field is either a drop-down list or a pair of text fields. Whenthe operator is not Range, the drop-down list allows you to specify awell-known port by name.

When the operator is Range, the text fields allow you to enter thebeginning and ending port numbers of the range. Valid port numbersin both fields are from 0 to 65535.

To specify a single port by number, choose Range from the operatordrop-down list and enter the port number in both source port fields.

Destination port or range of destination ports to which the access ruleapplies. By default, no source port is assigned.

Destination

The left list specifies the operator that the device uses when comparingthe destination port of packets to the port or ports specified in the accessrule.




ICMP Access Rule

Rule filters based on the ICMP message that you choose in thedrop-down list. By default, the radio button is selected and the list isblank.

ICMP Message

Rule filters based on the values that you specify in the drop-down listand ICMP Code field. By default, the radio button is not selected andthe list is unavailable.

ICMP Type

ICMPmessage code that the rule uses to filter ICMP traffic. Valid inputfor this field varies depending upon the ICMP Type drop-down list. Bydefault, the list is unavailable.

ICMP Code

IGMP Access Rule

Rule filters based on the IGMP message that you choose in the IGMPMessage drop-down list. The radio button is selected by default. Thedefault value for the list is 0 (zero).

IGMP Message



DescriptionField

Rule filters based on the IGMP message type. By default, the radiobutton is not selected and the list is unavailable.

IGMP Type

IPv4 Access Rule: Details: Advanced SectionTable 42: IPv4 Access Rule: Details: Advanced Section

DescriptionField

All Access Rules

Differentiated services value of theDSCP header field in IP packets.

DSCP

The rule applies only to packetswith a matching value. No value isselected by default.

IP Precedence field value. The ruleapplies only to packets with a

Precedence

matching value. No value isselected by default.

Rule that can only match packetsthat are noninitial fragments. Thischeck box is unchecked by default.

Fragments

TCP Access Rules

Rule that can only match packetsthat belong to an established TCP

Established

connection. The device considersTCP packets with the ACK or RSTbits set to belong to an establishedconnection. This check box isunchecked by default.

Rule that can only match TCPpackets that have the FIN control

Fin

bit flag set. This check box isunchecked by default.

Rule that can only match TCPpackets that have the PSH control

Psh



Configuring IP ACLsIPv4 Access Rule: Details: Advanced Section

DescriptionField

Rule that can only match TCPpackets that have the RST control

Rst


Rule that can only match TCPpackets that have the SYN control

Syn


Rule that can only match TCPpackets that have the URG control

Urg


Rule that can only match TCPpackets that have the ACK control

Ack


IPv4 ACL Remark: Remark Details TabTable 43: IPv4 ACL Remark: Remark Details Tab

DescriptionField

Display only. Sequence number assigned to theremark.

Sequence Number

Remark text, with a maximum length of 100alphanumeric characters. By default, this field isempty.

Remark Description

Field Descriptions for IPv6 ACLs

IPv6 ACL: Details TabTable 44: IPv6 ACL: Details Tab

DescriptionField

Name of the IPv6 ACL. Names can be a maximumof 64 alphanumeric characters but must begin with

Name


Configuring IP ACLsIPv4 ACL Remark: Remark Details Tab

DescriptionField



Statistics

IPv6 Access Rule: Details TabTable 45: IPv6 Access Rule: Details Tab

DescriptionField

Display only. The sequence number assigned to therule.

Sequence Number


Action

• Deny—Stops processing the packet and dropsit.

• Permit—Continues processing the packet.

IPv6 Access Rule: Details: Source and Destination SectionTable 46: IPv6 Access Rule: Details: Source and Destination Section

DescriptionField


• Any—The rule matches packets from any IPv6source. This is the default value. When youchoose Any, the IPAddress andWildcardMaskfields below this list are unavailable becauseyou do not need to specify either of them.

• Host—The rule matches packets from a specificIPv6 address. When you choose Host, the IPv6Address field below this list is available but theIPv6 Prefix Length field remains unavailable.

• Network—The rule matches packets from anIPv6 network. When you choose Network, theIPv6 Address and IPv6 Prefix Length fieldsbelow this list are both available.


Configuring IP ACLsIPv6 Access Rule: Details Tab

DescriptionField

IPv6 address of a source host or a network. This fieldis available when you choose Host or Network from

IPv6 Address (Source)

the Source drop-down list. By default, this field isunavailable.

Variable-length subnet mask for the source addressgiven in the IPv6 Address field. Valid entries are

IPv6 Prefix Length (Source)

whole numbers from 1 to 128. For example, if youchoose Network from the Source drop-down list andspecify 2001:0db8:85a3:: in the IPv6 Address field,you would enter 128 in this field.

This field is available when you choose Network fromthe Source drop-down list. By default, this field isunavailable.


• Any—The rulematches packets sent to any IPv6destination. This is the default value.When youchoose Any, the IPAddress andWildcardMaskfields below this list are unavailable becauseyou do not need to specify either of them.

• Host—The rule matches packets sent to aspecific IPv6 address. When you choose Host,the IPv6 Address field below this list isavailable but the IPv6 Prefix Length fieldremains unavailable.

• Network—The rule matches packets sent to anIPv6 network. When you choose Network, theIPv6 Address and IPv6 Prefix Length fieldsbelow this list are both available.

IPv6 address of a destination host or a network. Thisfield is available when you choose Host or Network

IPv6 Address (Destination)

from the Source drop-down list. By default, this fieldis unavailable.

Variable-length subnet mask for the destinationaddress given in the IPv6 Address field. Valid entries

IPv6 Prefix Length (Destination)

are whole numbers from 1 to 128. For example, ifyou choose Network from the Source drop-down listand specify 2001:0db8:85a3:: in the IPv6 Addressfield, you would enter 128 in this field.

This field is available when you choose Network fromthe Source drop-down list. By default, this field isunavailable.


Configuring IP ACLsIPv6 Access Rule: Details: Source and Destination Section

IPv6 Access Rule: Details: Protocol and Others SectionTable 47: IPv6 Access Rule: Details: Protocol and Others Section

DescriptionField

All Access Rules

Display only. Protocol of the access rule. Possible values are as follows:Protocol

• IPv6

• TCP

• UDP

• ICMP

• SCTP

Named time range that applies to the access rule. If you want the ruleto be always in effect, do not specify a time range. By default, this listis blank.

Time range

Whether the device logs statistics about traffic to which the access ruleapplies. By default, this check box is unchecked.

Log this entry

Flow label value of traffic that the access rule applies to. The flow labelvalue is in the Flow Label header field of IPv6 packets. The flow label

Flow Label

value can be a whole number from 0 to 1048575. By default, this fieldis blank.

IPv6 Access Rule

IP protocol of traffic that the access rule applies to. The default valueis Ipv6, which applies to all IPv6 protocols. To specify a well-known

IP Protocol

protocol, choose the protocol name. The list is ordered by the protocolnumber. For the IANA list of assigned internet protocol numbers, seehttp://www.iana.org/assignments/protocol-numbers.

TCP and UDP Access Rules


Source Port






DescriptionField



Destination port or range of destination ports that the access rule appliesto. By default, no source port is assigned.

Destination





ICMP Access Rule

Rule filters based on the ICMP message that you choose in the ICMPMessage drop-down list. By default, the radio button is selected but thelist is blank.

ICMP Message

Rule filters based on the values that you specify in the ICMP Typedrop-down list and ICMP Code field. By default, the radio button is notselected and the list is unavailable.

ICMP Type

ICMPmessage code that the rule uses to filter ICMP traffic. Valid inputfor this field varies depending upon the ICMP Type drop-down list. Bydefault, this list is unavailable.

ICMP Code

SCTP Access Rule


Source Port





DescriptionField



Destination port or range of destination ports that the access rule appliesto. By default, no source port is assigned.

Destination





IPv6 Access Rule: Details: Advanced SectionTable 48: IPv6 Access Rule: Details: Advanced Section

DescriptionField

All Access Rules

Differentiated services value of theDSCP header field in IP packets.

DSCP

The rule applies only to packetswith a matching value. By default,this list is blank.

Rule that can only match packetsthat are noninitial fragments. By

Fragments

default, this check box isunchecked.

TCP Access Rules

Rule that can only match packetsbelong to an established TCP

Established

connection. The device considersTCP packets with the ACK or RST


Configuring IP ACLsIPv6 Access Rule: Details: Advanced Section

DescriptionField

bits set to belong to an establishedconnection. By default, this checkbox is unchecked.

Rule that can only match TCPpackets that have the FIN control

Fin

bit flag set. By default, this checkbox is unchecked.

Rule that can only match TCPpackets that have the PSH control

Psh


Rule that can only match TCPpackets that have the RST control

Rst


Rule that can only match TCPpackets that have the SYN control

Syn


Rule that can only match TCPpackets that have the URG control

Urg


Rule that can only match TCPpackets that have the ACK control

Ack


IPv6 ACL Remark: Remark Details TabTable 49: IPv6 ACL Remark: Remark Details Tab

DescriptionField


Remark Sequence Number

Remark text, with a maximum length of 100alphanumeric characters. By default, this field isblank.

Remark Description


Configuring IP ACLsIPv6 ACL Remark: Remark Details Tab

Configuring Object GroupsYou can use object groups to specify source and destination addresses and protocol ports in IPv4 ACL andIPv6 ACL rules.

Creating an Address Object GroupYou can create an IPv4 or IPv6 address object group and add entries to it.

Procedure

Step 1 From the Feature Selector pane, choose Security ➤ Object Group ➤ Address Group.The Summary pane displays available devices.

Step 2 From the Summary pane, double-click the device to which you want to add an address object group.Step 3 Click IPv4 or IPv6, as needed, and then from the menu bar, choose Actions ➤ New ➤ Address Group.

The cursor appears in a blank row for the new address object group.

Step 4 Type a name for the address object group and press Enter.Step 5 For each address object group entry that you want to create, follow these steps:

a) Click the address object group and then from the menu bar choose Actions ➤ New ➤ Address GroupEntry.A new address object group entry appears below other entries in the group, if any. The Details pane showsthe Entry Details tab for the type of address object group that you created.

b) On the Details tab, configure fields as needed.

Step 6 From the menu bar, choose File ➤ Deploy to apply your changes to the device.Cisco DCNM creates the address object group and its entries on the device.

Creating a Port Object GroupYou can create a port object group and add entries to it.

Procedure

Step 1 From the Feature Selector pane, choose Security ➤ Object Group ➤ Port Group.The Summary pane displays available devices.

Step 2 From the Summary pane, click the device to which you want to add a port object group.Step 3 From the menu bar, choose Actions ➤ New ➤ Port Group.

The cursor appears in a blank row for the new port object group.

Step 4 Type a name for the port object group and press Enter.Step 5 For each port object group entry that you want to create, follow these steps:


Configuring IP ACLsConfiguring Object Groups

a) Click the port object group and then from the menu bar choose Actions ➤ New ➤ Port Group Entry.A new port object group entry appears below other entries in the group, if any. The Details pane showsthe Details tab for the port object group entry that you created.

b) On the Details tab, configure fields as needed.

Step 6 From the menu bar, choose File ➤ Deploy to apply your changes to the device.Cisco DCNM creates the port object group and its entries on the device.

Changing an Object GroupYou can change, reorder, add, and remove entries in an existing object group.

Procedure

Step 1 From the Feature Selector pane, choose Security ➤ Access Control ➤ Object Group and then choose theapplicable object group type: Address Group or Port Group.The available devices appear in the Summary pane.

Step 2 From the Summary pane, double-click the device that has the object group that you want to change.Step 3 (Optional) If you are changing an address object group, double-click the type of address object group: IPv4

or IPv6.Step 4 Double-click the object group.

The entries of the object group that you double-clicked appear in the Summary pane.

Step 5 (Optional) If you want to change the details of an object group entry, click the entry in the Summary pane.From the Details tab, configure fields as needed.

Step 6 (Optional) If you want to add an entry, click the object group in the Summary pane and then from the menubar, choose Action ➤ New ➤ Address Group Entry or Port Group Entry. On the Details tab, configurefields as needed.

Step 7 (Optional) If you want to remove an object group entry, click the object group entry and then from the menubar, choose Actions ➤ Delete.

Step 8 (Optional) If you want to move an object group entry to a different position in the object group, click theentry in the Summary pane and then from the menu bar, choose one of the following, as applicable:



The entry swaps places and sequence numbers with the rule above it or below it, as you chose.


Changing Sequence Numbers in an Object GroupYou can change all the sequence numbers assigned to the entries in an object group.


Configuring IP ACLsChanging an Object Group

Procedure

Step 1 From the Feature Selector pane, choose Security ➤ Access Control ➤ Object Group and then choose theapplicable object group type: Address Group or Port Group.The available devices appear in the Summary pane.

Step 2 From the Summary pane, double-click the device that has the object group that you want to change.Step 3 (Optional) If you are changing an address object group, double-click the type of address object group: IPv4

or IPv6.Step 4 Double-click the object group.

The entries of the object group that you double-clicked appear in the Summary pane. The Sequence Numbercolumn shows the sequence number assigned to each entry.

Step 5 Click the entry whose sequence number you want to change.The Details pane shows the Sequence Number field for the entry.

Step 6 Click the Sequence Number field, edit the number, and press Tab.In the Summary pane, the new sequence number appears and, if applicable, the entry moves to the positiondetermined by the new sequence number.


Configuring Time RangesThis figure shows the Time-range content pane.


Configuring IP ACLsConfiguring Time Ranges

Figure 31: Time-range Content Pane

Creating a Time RangeYou can create a time range on the device and add rules to it.

Procedure

Step 1 From the Feature Selector pane, choose Security ➤ Access Control ➤ Time-range.The available devices appear in the Summary pane.

Step 2 From the Summary pane, double-click the device to which you want to add a time range.The time ranges present on the device, if any, appear in the Summary pane.

Step 3 From the menu bar, choose File ➤ New ➤ New Time-range.A blank row appears in the Summary pane.

Step 4 In the row, enter a name for the time range.Step 5 For each rule or remark that you want to add to the time range, from the menu bar, choose File ➤ New and

choose the type of rule or remark. On the Time Range Details tab, configure fields as needed.Step 6 (Optional) From the menu bar, choose File ➤ Deploy to apply your changes to the device.

Changing a Time RangeYou can change, reorder, add, and remove rules in an existing time range.


Configuring IP ACLsCreating a Time Range

Procedure


Step 2 (Optional) From the Summary pane, double-click the device that has the time range that you want to changeand then double-click the time range.Time ranges on the device and the rules of the time range that you double-clicked appear in the Summarypane.

Step 3 (Optional) If you want to change the details of a rule, click the rule in the Summary pane and then, on theTime Range Details tab, configure fields as needed.

Step 4 (Optional) If you want to move a rule to a different position in the time range, click the rule and then fromthe menu bar, choose one of the following, as applicable:



The rule moves up or down, as you chose. The sequence number of the rules adjust accordingly.

Step 5 (Optional) If you want to add a rule, click the time range in the Summary pane and then from the menu bar,choose File ➤ New and choose the type of rule. On the Time Range Details tab, configure fields as needed.

Step 6 (Optional) If you want to remove a rule, click the rule in the Summary pane and then from the menu bar,choose Actions ➤ Delete.


Removing a Time RangeYou can remove a time range from the device.

Before You Begin

Ensure that you know whether the time range is used in any ACL rules. The device allows you to removetime ranges that are used in ACL rules. Removing a time range that is in use in an ACL rule does not affectthe configuration of interfaces where you have applied the ACL. Instead, the device considers the ACL ruleusing the removed time range to be empty.

Procedure


Step 2 From the Summary pane, double-click the device from which you want to remove a time range.Time ranges currently on the device appear in the Summary pane.

Step 3 From the Summary pane, click the time range that you want to remove.Step 4 From the menu bar, choose Actions ➤ Delete.

DCNM removes the time range from the device and the time range disappears from the Summary pane.


Configuring IP ACLsRemoving a Time Range

Field Descriptions for Time RangesThis table describes the fields for time range rules and remarks.

Table 50: Time Range Rule or Remark: Time Range Details Tab

DescriptionField

All Time Range Rules and Remarks

Display only. Sequence number assigned to the rule.Seq No

Remarks

Remark text, with a maximum length of 100 alphanumeric characters.By default, this field is blank.

Description

Absolute Rules

Time and date that the absolute time range becomes active. By default,this list is blank.

Date (Start)

You must configure either the start Date drop-down list, the end Datedrop-down list, or both.

Time and date that the absolute time range becomes inactive. By default,this list is blank.

Date (End)

You must configure either the start Date drop-down list, the end Datedrop-down list, or both.

Periodic Rules

Days of the week that the periodic rule is active. You can choose oneof the following radio buttons:

Days

• Daily: The range is active every day of the week.

• Weekdays: The range is active Monday through Friday only.

• Weekend: The range is active Saturday and Sunday only.

• Specific Days: The range is active on the days specified in theDays of the week check boxes. This is the default value. The Daydrop-down list (End) is available only when you choose this radiobutton and choose only one day in the Days of the week checkboxes.


Configuring IP ACLsField Descriptions for Time Ranges

DescriptionField

Days of the week that the periodic rule is active. These check boxes areavailable only if the Specific Days radio button is selected. By default,these check boxes are unchecked.

Days of the week

Time that the range becomes active. The time in this spin box must bebefore the time in the Time (End) spin box. The default value is00:00:00.

Time (Start)

Day of the week that the time range becomes inactive. This drop-downlist is available only if you select the Specific Days radio button and

Day

select only one of the check boxes under Days of the week. By default,this list is unavailable.

Time that the range becomes inactive. The time in this spin box mustbe after the time in the Time (End) spin box. The default value is00:00:00.

Time (End)

Additional References for IP ACLsStandards

TitleStandards


Feature History for IP ACLsThis table lists the release history for this feature.

Table 51: Feature History for IP ACLs



5.2(1)IPv4 ACLs

No change from Release 5.0.5.1(1)IP ACLs

Added support for objectgroups.

5.0(2)IP ACLs


Configuring IP ACLsAdditional References for IP ACLs

C H A P T E R 10Configuring MAC ACLs

This chapter describes how to configure MAC access lists (ACLs) on Cisco NX-OS devices.

The Cisco NX-OS release that is running on a managed device may not support all the features or settingsdescribed in this chapter. For the latest feature information and caveats, see the documentation and releasenotes for your platform and software release.

Note

This chapter contains the following sections:

• Information About MAC ACLs, page 169

• Licensing Requirements for MAC ACLs, page 169

• Platform Support for MAC ACLs, page 170

• Configuring MAC ACLs, page 170

• Monitoring and Clearing MAC ACL Statistics, page 175

• Field Descriptions for MAC ACLs, page 175

• Additional References for MAC ACLs, page 178

• Feature History for MAC ACLs, page 178

Information About MAC ACLsMACACLs are ACLs that use information in the Layer 2 header of packets to filter traffic. MACACLs sharemany fundamental concepts with IP ACLs, including support for virtualization.

Licensing Requirements for MAC ACLsThis table shows the licensing requirements for this feature.



MAC ACLs require no license. Any feature notincluded in a license package is bundled with the

Cisco DCNM

Cisco DCNM and is provided at no charge to you.For an explanation of the Cisco DCNM licensingscheme, see the Cisco DCNM Installation andLicensing Guide, Release 5.x.

MAC ACLs require no license. Any feature notincluded in a license package is bundled with the

Cisco NX-OS


Platform Support for MAC ACLsThe following platforms support this feature but may implement it differently. For platform-specific information,including guidelines and limitations, system defaults, and configuration limits, see the correspondingdocumentation.






Configuring MAC ACLs

Creating a MAC ACLYou can create a MAC ACL and add rules to it.

Procedure

Step 1 From the Feature Selector pane, choose Security ➤ Access Control ➤ MAC ACL.The Summary pane displays available devices.

Step 2 From the Summary pane, double-click the device to which you want to add an ACL.Step 3 (Optional) From the menu bar, choose File ➤ New ➤ MAC ACL.


Configuring MAC ACLsPlatform Support for MAC ACLs





A new row appears in the Summary pane and the ACL Details tab appears in the Details pane.

Step 4 On the ACL Details tab, in the Name field, type a name for the ACL.Step 5 (Optional) If you want the device to maintain global statistics for rules in this MAC ACL, check Statistics.Step 6 For each rule that you want to add to the ACL, from the menu bar, choose File ➤ New and choose the type

of rule. On the Details tab, configure fields as needed.Step 7 (Optional) From the menu bar, choose File ➤ Deploy to apply your changes to the device.

Changing a MAC ACLIn an existing MAC ACL, you can change, reorder, add, and remove rules.

Procedure


Step 2 (Optional) From the Summary pane, double-click the device that has the ACL you want to change and thendouble-click the ACL.The ACLs on the device and the rules of the ACL that you double-clicked appear in the Summary pane.

Step 3 (Optional) If you change whether the device maintains global statistics for rules in this MAC ACL, click theACL in the Summary pane and then, on the ACL Details tab, check or uncheck Statistics as needed.

Step 4 (Optional) If you want to change the details of a rule, click the rule in the Summary pane and then, on theDetails tab, configure fields as needed.

Step 5 (Optional) If you want to add a rule, click the ACL in the Summary pane and then from the menu bar, chooseFile ➤ New, choose the type of rule, and then, on the Details tab, configure fields as needed.

Step 6 (Optional) If you want to remove a rule, click the rule and then from the menu bar, chooseActions➤Delete.Step 7 (Optional) If you want to move a rule to a different position in the ACL, click the rule and then from the

menu bar, choose one of the following, as applicable:





Related Topics

• Changing Sequence Numbers in a MAC ACL, page 172


Configuring MAC ACLsChanging a MAC ACL

Changing Sequence Numbers in a MAC ACLYou can change all the sequence numbers assigned to rules in a MAC ACL. Resequencing is useful whenyou need to insert rules into an ACL and there are not enough available sequence numbers.

Procedure

Step 1 From the Feature Selector pane, choose Security ➤ Access Control ➤ MAC ACL.The available devices appear in the Summary pane.

Step 2 From the Summary pane, double-click the device that has the ACL that you want to change and thendouble-click the ACL.The ACLs on the device and the rules of the ACL that you double-clicked appear in the Summary pane. TheSeq No column shows the sequence number assigned to each rule.

Step 3 Click the rule whose sequence number you want to change.The Details pane shows the Sequence Number field for the rule.

Step 4 Click the Sequence Number field, edit the number, and press Tab.In the Summary pane, the new sequence number appears and, if applicable, the rule moves to the positiondetermined by the new sequence number.


Removing a MAC ACLYou can remove a MAC ACL from the device.

Procedure


Step 2 From the Summary pane, double-click the device from which you want to remove an ACL.The Summary pane displays the ACLs currently on the device.

Step 3 Click the ACL that you want to remove, and then from the menu bar, choose Actions ➤ Delete.Cisco DCNM removes the ACL from the Summary pane.


Applying a MAC ACL to a Physical PortYou can apply a MAC ACL to incoming or outgoing traffic on a physical Ethernet port, regardless of the portmode.


Configuring MAC ACLsChanging Sequence Numbers in a MAC ACL

Before You Begin


Procedure

Step 1 From the Feature Selector pane, choose Interfaces ➤ Physical ➤ Ethernet.The Summary pane displays available devices.

Step 2 From the Summary pane, double-click the applicable device and then double-click the slot containing theport.The Summary pane displays the ports in the slot that you double-clicked.

Step 3 Click the port to which you want to apply a MAC ACL.Step 4 From the Details pane, click the Details tab and expand the Advanced Settings section, if necessary.

The following drop-down lists appear in the MAC ACL area:

• Incoming Traffic

• Outgoing Traffic

Step 5 For each traffic direction that you want to apply an ACL, from the applicable drop-down list, choose the ACLthat you want to apply.


Related Topics

• Creating a MAC ACL, page 170• Changing a MAC ACL, page 171

Applying a MAC ACL to a Virtual Ethernet InterfaceYou can apply a MAC ACL to incoming or outgoing traffic on a virtual Ethernet interface.

Before You Begin


Procedure

Step 1 From the Feature Selector pane, choose Interfaces ➤ Logical ➤ Virtual Ethernet.The Summary pane displays available devices.

Step 2 From the Summary pane, double-click the applicable device and then double-click the slot containing theport.


Configuring MAC ACLsApplying a MAC ACL to a Virtual Ethernet Interface

The Summary pane displays the ports in the slot that you double-clicked.

Step 3 Click the port to which you want to apply a MAC ACL.Step 4 From the Details pane, click the Details tab and expand the Advanced Settings section, if necessary.

The following drop-down lists appear in the MAC ACL area:

• Incoming Traffic

• Outgoing Traffic

Step 5 For each traffic direction that you want to apply an ACL, from the applicable drop-down list, choose the ACLthat you want to apply.


Related Topics


Applying a MAC ACL to a Port ChannelYou can apply a MAC ACL to an Ethernet port channel.

DCNM allows you to apply a MAC ACL in incoming traffic only on an Ethernet port channel.

Before You Begin

Ensure that the ACL you want to apply exists and that it is configured to filter traffic in the manner that youneed for this application.

Procedure

Step 1 From the Feature Selector pane, choose Interfaces ➤ Logical ➤ Port Channel.Available devices appear in the Summary pane.

Step 2 From the Summary pane, double-click the applicable device.Port channels on the device that you double-clicked appear in the Summary pane.

Step 3 Click the port channel to which you want to apply a MAC ACL.Settings about the port channel appear in the Details pane.

Step 4 From the Details pane, click the Port Channel Advanced Settings tab and expand the Advanced Settingssection, if necessary.In the Advanced Settings section, the MAC ACL areas contains an Incoming Traffic drop-down list.

Step 5 From the Incoming Traffic drop-down list, choose the MAC ACL that you want to apply.Step 6 From the menu bar, choose File ➤ Deploy to apply your changes to the device.


Configuring MAC ACLsApplying a MAC ACL to a Port Channel

Related Topics


Applying a MAC ACL as a VACLYou can apply a MAC ACL as a VACL.

Related Topics


Monitoring and Clearing MAC ACL StatisticsThe following window appears in the Statistics tab:

• Access Rule Statistics Chart—Information about the number of packets that match the selected MACACL rule.

For more information on collecting statistics for this feature, see the .

Field Descriptions for MAC ACLs

MAC ACL: ACL Details TabTable 52: MAC ACL: ACL Details Tab

DescriptionField

Specifies the name of the MAC ACL. Names can bealphanumeric characters but must begin with an

Name

alphabetic character. Maximum length is 64characters. No name is assigned by default.


Statistics

MAC Access Rule: Details: General SectionTable 53: MAC Access Rule: Details: General Section

DescriptionField

Display only. Shows the sequence number assignedto the rule.

Sequence Number


Configuring MAC ACLsApplying a MAC ACL as a VACL

DescriptionField


Action

• Deny—Stop processing the packet and drop it.This is the default value.

• Permit—Continue processing the packet.

Type of traffic that the access rule applies to. Bydefault, no protocol is selected. To specify a protocol,

Protocol

choose the protocol name. The list is ordered by theprotocol number but the protocol number is notshown.

Named time range that applies to the access rule. Ifyou want the rule to be always in effect, do notspecify a time range. This field is blank by default.

Time-range

Specifies that the rule matches only packets with anIEEE 802.1Q header that contains the Class of Service

Cost of Service

(CoS) value given in the cos-value argument. Thecos-value argument can be an integer from 0 to 7.

Specifies that the rule matches only packets with anIEEE 802.1Q header that contains the VLAN ID ofthe VLAN that you select.

VLAN

MAC Access Rule: Details: Source and Destination SectionTable 54: MAC Access Rule: Details: Source and Destination Section

DescriptionField


• Any—The rule matches packets from anysource. This is the default value. When youchoose Any, the MAC Address and WildcardMask fields below this list are unavailablebecause you do not need to specify either ofthem.

• Host—The rule matches packets from a specificMACaddress.When you chooseHost, theMACAddress field below this list is available but theWildcard Mask field remains unavailable.


Configuring MAC ACLsMAC Access Rule: Details: Source and Destination Section

DescriptionField

• Network—The rule matches packets from aMAC network. When you choose Network, theMACAddress andWildcardMask fields belowthis list are both available.

MAC address of a host or a network. Valid addressesare in dotted hexadecimal format. This field is

MAC Address (Source)

available when you choose Host or Network from theSource drop-down list. By default, this field is blank.

Wildcard mask of a MAC network. Valid masks arein dotted hexadecimal format. For example, if you

Wildcard Mask (Source)

specified 00c0.4f03.0000 in the MAC Address field,you would enter 0000.0000.ffff in this field. This fieldis available when you choose Network from theSource drop-down list. By default, this field is blank.


• Any—The rule matches packets sent to anysource. This is the default value. When youchoose Any, the MAC Address and WildcardMask fields below this list are unavailablebecause you do not need to specify either ofthem.

• Host—The rule matches packets sent to aspecific MAC address. When you choose Host,the MAC Address field below this list isavailable but the Wildcard Mask field remainsunavailable.

• Network—The rule matches packets sent to aMAC network. When you choose Network, theMACAddress andWildcardMask fields belowthis list are both available.

MAC address of a host or a network. Valid addressesare in dotted hexadecimal format. This field is

MAC Address (Destination)

available when you choose Host or Network from theSource drop-down list. By default, this field is blank.

Wildcard mask of a MAC network. Valid masks arein dotted hexadecimal format. For example, if you

Wildcard Mask (Destination)

specified 00c0.4f03.0000 in the IP Address field, youwould enter 0000.0000.ffff in this field. This field isavailable when you choose Network from the Sourcedrop-down list. By default, this field is blank.


Configuring MAC ACLsMAC Access Rule: Details: Source and Destination Section

MAC ACL Remark: Remark Details TabTable 55: MAC ACL Remark: Remark Details Tab

DescriptionField


Remark Sequence Number

Remark text. Maximum length is 100 characters. Bydefault, this field is blank.

Remark Description

Additional References for MAC ACLsStandards

TitleStandards


Feature History for MAC ACLsThis table lists the release history for this feature.

Table 56: Feature History for MAC ACLs


No change from Release 5.1.5.2(1)MAC ACLs



Support was added for MACpacket classification.

4.2(1)MAC ACLs


Configuring MAC ACLsMAC ACL Remark: Remark Details Tab

C H A P T E R 11Configuring VLAN ACLs

This chapter describes how to configure VLAN access lists (ACLs) on Cisco NX-OS devices.


Note


• Information About VLAN ACLs, page 179

• Licensing Requirements for VACLs, page 180

• Platform Support for VACLs, page 180

• Configuring VACLs, page 181

• Field Descriptions for VACLs, page 184

• Additional References for VACLs, page 185

• Feature History for VLAN ACLs, page 185

Information About VLAN ACLsA VLAN ACL (VACL) is one application of a MAC ACL or IP ACL. You can configure VACLs to applyto all packets that are routed into or out of a VLAN or are bridged within a VLAN. VACLs are strictly forsecurity packet filtering and for redirecting traffic to specific physical interfaces. VACLs are not defined bydirection (ingress or egress).

VLAN Access Maps and EntriesVACLs use access maps to contain an ordered list of one or more map entries. Each map entry associates IPACLs to an action. Each entry has a sequence number, which allows you to control the precedence of entries.

When the device applies a VACL to a packet, it applies the action that is configured in the first access mapentry that contains an ACL that permits the packet.


VACLs and ActionsIn each VLAN access map entry, you can specify one of the following actions:

Sends the traffic to the destination determined by the normal operation of the switch.Forward

Drops the traffic. If you specify drop as the action, you can also specify that thedevice logs the dropped packets.

Drop

VACL StatisticsThe device can maintain global statistics for each rule in a VACL. If a VACL is applied to multiple VLANs,the maintained rule statistics are the sum of packet matches (hits) on all the interfaces on which that VACLis applied.

The device does not support interface-level VACL statistics.Note

For each VLAN access map that you configure, you can specify whether the device maintains statistics forthat VACL. This feature allows you to turn VACL statistics on or off as needed to monitor traffic filtered bya VACL or to help troubleshoot VLAN access-map configuration.

Licensing Requirements for VACLsThis table shows the licensing requirements for this feature.


VACLs require no license. Any feature not includedin a license package is bundled with the Cisco NX-OS

Cisco NX-OS


Platform Support for VACLsThe following platforms support this feature but may implement it differently. For platform-specific information,including guidelines and limitations, system defaults, and configuration limits, see the correspondingdocumentation.





Configuring VLAN ACLsVACLs and Actions







Configuring VACLs

Adding a VACLYou can create a VACL. Creating a VACL includes creating at least one VLAN access map entry that associatesan IP ACL with an action to be applied to the matching traffic.

Procedure

Step 1 From the Feature Selector pane, choose Security ➤ Access Control ➤ VLAN ACL.The Summary pane displays available devices.

Step 2 From the Summary pane, double-click the device to which you want to add a VACL.Step 3 From the menu bar, choose File ➤ New ➤ VLAN Access Map.

Below the device that you selected, a new row appears in the Summary pane.

Step 4 In the new row, enter a name for the VACL.The VACL remains selected in the Summary pane.

Step 5 For each VLAN access map entry that you want to create, follow these steps:a) From the menu bar, choose File ➤ New ➤ VLAN Access Map.

Below the VACL, a new row appears in the Summary pane.

b) From the Details pane, click the Details tab and expand theMatch Condition And Action section, ifnecessary.

c) From the Match ACL Type drop-down list, select the type of ACL that you want to use in the VACL.The ACLs drop-down list contains ACLs that are the type you selected and that exist on the currentlyselected device.

d) From the ACLs drop-down list, select the ACL that you want to use.e) From the Action drop-down list, select the action that the device should take on traffic matching the VACL.

Step 6 From the menu bar, choose File ➤ Save to apply your changes to the device.

Changing a VACLYou can change a VACL.


Configuring VLAN ACLsConfiguring VACLs




Procedure

Step 1 From the Feature Selector pane, choose Security ➤ Access Control ➤ VLAN ACL.The Summary pane displays available devices.

Step 2 From the Summary pane, double-click the device that contains the VACL that you want to change and thenclick the VACL.

Step 3 (Optional) To add a VLAN access map entry, from the menu bar, choose File➤New➤VLANAccess MapEntry.Below the VACL, the new VLAN access map entry appears in the Summary pane.

Step 4 (Optional) To change a new or existing VLAN access map entry, follow these steps:a) Click the VLAN access map entry that you want to change.b) From the Details pane, click the Details tab and expand theMatch Condition And Action section, if

necessary.c) From the Match ACL Type drop-down list, select the type of ACL that you want to use in the VACL. You

can choose IPv4 .The ACLs drop-down list contains ACLs that are the type you selected and that exist on the currentlyselected device.

d) From the ACLs drop-down list, select the ACL that you want to use.e) From the Action drop-down list, select the action that the device should take upon traffic matching the

VACL.

Step 5 (Optional) If you want to move a VLAN access map entry to a different position in the VACL, click the entryin the Summary pane and then from the menu bar, choose one of the following, as applicable:



The entry swaps places and sequence numbers with the entry above it or below it, as you chose.

Step 6 To remove a VLAN access map entry, click the VLAN access map entry and then choose Actions ➤ Delete.Step 7 From the menu bar, choose File ➤ Deploy to apply your changes to the device.

Removing a VACL or VLAN Access-Map EntryYou can remove a VACL, which means that you will delete the VLAN access map.

You can also remove a single VLAN access-map entry from a VACL.

Before You Begin

Ensure that you know whether the VACL is applied to a VLAN. The allows you to remove VACLs that arecurrently applied. Removing a VACL does not affect the configuration of VLANs where you have appliedthe VACL. Instead, the considers the removed VACL to be empty.


Configuring VLAN ACLsRemoving a VACL or VLAN Access-Map Entry

Procedure

Step 1 From the Feature Selector pane, choose Security ➤ Access Control ➤ VLAN ACL.Available devices appear in the Summary pane.

Step 2 From the Summary pane, double-click the from which you want to remove a VACL.The VACLs on the appear in the Summary pane.

Step 3 (Optional) If you want to delete a VACL, follow these steps:a) Click the VACL that you want to remove.b) From the menu bar, choose Actions ➤ Delete.

The VACL disappears from the Summary pane.

Step 4 (Optional) If you want to delete a VLAN access map entry, follow these steps:a) Double-click the VACL that contains the entry that you want to delete.

The VLAN access-map entries list below the VACL.

b) Click the VLAN access map entry that you want to delete.c) From the menu bar, choose Actions ➤ Delete.

The VLAN access map entry disappears from the Summary pane.

Step 5 (Optional) From the menu bar, choose File ➤ Deploy to apply your changes to the .

Applying a VACL to a VLANYou can apply a VACL to a VLAN.

Before You Begin

If you are applying a VACL, ensure that the VACL exists and is configured to filter traffic in the manner thatyou need for this application.

Procedure

Step 1 From the Feature Selector pane, choose Switching ➤ VLAN.Available devices appear in the Summary pane.

Step 2 From the Summary pane, double-click the applicable device.VLANs on the device that you double-clicked appear in the Summary pane.

Step 3 Click the VLAN to which you want to apply a VACL.Step 4 From the Details pane, click the VLAN Details tab and expand the Advanced Settings section, if necessary.

The VACL drop-down list appears in the Advanced Settings section.

Step 5 From the VACL drop-down list, choose the VACL that you want to apply.Step 6 (Optional) From the menu bar, choose File ➤ Save to apply your changes to the device.


Configuring VLAN ACLsApplying a VACL to a VLAN

Field Descriptions for VACLs

VLAN Access Map Entry: Details TabTable 57: VLAN Access Map Entry: Details Tab

DescriptionField

Display only. Sequence number assigned to the rule.Sequence Number

VLAN Access Map Entry: Details: Match Condition And Action SectionTable 58: VLAN Access Map Entry: Details: Match Condition And Action Section

DescriptionField

Type of ACL that the VLAN access map entry usesto filter traffic. Valid values are as follows:

Match ACL Type

• IPv4 ACL—This is the default value.

• IPv6 ACL

• MAC ACL.

Name of the ACL that the VLAN access map uses tofilter traffic. By default, this list is blank.

ACLs

Action taken by the device when a packets ispermitted by the VLAN access map entry. Validvalues are as follows:

Action

• Drop—Stop processing the packet and drop it.

• Forward—Continue processing the packetwithout modifying the destination. This is thedefault value.

• Redirect—Continue processing the packet butsend it to the interfaces that you choose fromthe Redirect Interfaces drop-down list.

Whether the device logs packets permitted by theVLAN access map entry. This check box appears

Log this entry

only when you choose Drop from the Actiondrop-down list. By default, this check box isunchecked.


Configuring VLAN ACLsField Descriptions for VACLs

DescriptionField

Interfaces to which the device forwards packetspermitted by the VLAN accessmap entry. This check

Redirect Interfaces

box appears only when you choose Redirect from theAction drop-down list. By default, this list is blank.

Additional References for VACLsStandards

TitleStandards


Feature History for VLAN ACLsThis table lists the release history for this feature.

Table 59: Feature History for VLAN ACLs



5.2(1)VLAN ACLs

No change from Release 5.0.5.1(1)VLAN ACLs

No change from Release 4.2.5.0(2)VLAN ACLs

No change from Release 4.1.4.2(1)VLAN access maps


Configuring VLAN ACLsAdditional References for VACLs


Configuring VLAN ACLsFeature History for VLAN ACLs

C H A P T E R 12Configuring Port Security

This chapter describes how to configure port security on Cisco NX-OS devices.


Note


• Information About Port Security, page 187

• Licensing Requirements for Port Security, page 194

• Prerequisites for Port Security, page 195

• Platform Support for Port Security, page 195

• Configuring Port Security, page 195

• Displaying Secure MAC Addresses, page 203

• Field Descriptions for Port Security, page 204

• Additional References for Port Security, page 208

• Feature History for Port Security, page 208

Information About Port SecurityPort security allows you to configure Layer 2 physical interfaces and Layer 2 port-channel interfaces thatallow inbound traffic from only a restricted set of MAC addresses. The MAC addresses in the restricted setare called secure MAC addresses. In addition, the device does not allow traffic from these MAC addresseson another interface within the same VLAN. The number of MAC addresses that the device can secure isconfigurable per interface.


Unless otherwise specified, the term interface refers to both physical interfaces and port-channel interfaces;likewise, the term Layer 2 interface refers to both Layer 2 physical interfaces and Layer 2 port-channelinterfaces.

Note

Secure MAC Address LearningThe process of securing a MAC address is called learning. A MAC address can be a secure MAC address onone interface only. For each interface that you enable port security on, the device can learn a limited numberof MAC addresses by the static, dynamic, or sticky methods. The way that the device stores secure MACaddresses varies depending upon how the device learned the secure MAC address.

Related Topics

• Secure MAC Address Maximums, page 189

Static MethodThe static learning method allows you to manually add or remove secure MAC addresses to the runningconfiguration of an interface. If you copy the running configuration to the startup configuration, static secureMAC addresses are unaffected if the device restarts.

A static secure MAC address entry remains in the configuration of an interface until one of the followingevents occurs:

• You explicitly remove the address from the configuration.

• You configure the interface to act as a Layer 3 interface.

Adding secure addresses by the static method is not affected by whether dynamic or sticky address learningis enabled.

Related Topics

• Removing a Static Secure MAC Address on an Interface, page 199• Port Type Changes, page 193

Dynamic MethodBy default, when you enable port security on an interface, you enable the dynamic learning method. With thismethod, the device secures MAC addresses as ingress traffic passes through the interface. If the address isnot yet secured and the device has not reached any applicable maximum, it secures the address and allowsthe traffic.

The device stores dynamic secure MAC addresses in memory. A dynamic secure MAC address entry remainsin the configuration of an interface until one of the following events occurs:

• The device restarts.

• The interface restarts.

• The address reaches the age limit that you configured for the interface.

• You explicitly remove the address.


Configuring Port SecuritySecure MAC Address Learning


Related Topics

• Dynamic Address Aging, page 189• Removing a Dynamic or Sticky Secure MAC Address, page 200

Sticky MethodIf you enable the sticky method, the device secures MAC addresses in the same manner as dynamic addresslearning, but the device stores addresses learned by this method in nonvolatile RAM (NVRAM). As a result,addresses learned by the sticky method persist through a device restart. Sticky secure MAC addresses do notappear in the running configuration of an interface.

Dynamic and sticky address learning are mutually exclusive.When you enable sticky learning on an interface,the device stops dynamic learning and performs sticky learning instead. If you disable sticky learning, thedevice resumes dynamic learning.

A sticky secure MAC address entry remains in the configuration of an interface until one of the followingevents occurs:

• You explicitly remove the address.


Related Topics

• Removing a Dynamic or Sticky Secure MAC Address, page 200

Dynamic Address AgingThe device agesMAC addresses learned by the dynamic method and drops them after the age limit is reached.You can configure the age limit on each interface. The range is from 0 to 1440 minutes, where 0 disablesaging.

The method that the device uses to determine that theMAC address age is also configurable. The twomethodsof determining address age are as follows:

The length of time after the device last received a packet from the address on theapplicable interface.

Inactivity

The length of time after the device learned the address. This is the default agingmethod; however, the default aging time is 0 minutes, which disables aging.

Absolute

Secure MAC Address MaximumsBy default, an interface can have only one secure MAC address. You can configure the maximum number ofMAC addresses permitted per interface or per VLAN on an interface. Maximums apply to secure MACaddresses learned by any method: dynamic, sticky, or static.


Configuring Port SecurityDynamic Address Aging

To ensure that an attached device has the full bandwidth of the port, set the maximum number of addressesto one and configure the MAC address of the attached device.

Tip

The following three limits can determine how many secure MAC addresses are permitted on an interface:

The device has a nonconfigurable limit of 8192 secure MAC addresses. If learninga new address would violate the device maximum, the device does not permit the

Device maximum

new address to be learned, even if the interface or VLAN maximum has not beenreached.

You can configure a maximum number of secure MAC addresses for each interfaceprotected by port security. The default interface maximum is one address. Interfacemaximums cannot exceed 1025 secure MAC addresses.

Interface maximum

You can configure the maximum number of secure MAC addresses per VLAN foreach interface protected by port security. A VLAN maximum cannot exceed the

VLAN maximum

configured interface maximum. VLAN maximums are useful only for trunk ports.There are no default VLAN maximums.

You can configure VLAN and interface maximums per interface, as needed; however, when the new limit isless than the applicable number of secure addresses, you must reduce the number of secure MAC addressesfirst.

Related Topics

• Security Violations and Actions, page 190• Configuring a Maximum Number of MAC Addresses, page 200• Removing a Dynamic or Sticky Secure MAC Address, page 200• Removing a Static Secure MAC Address on an Interface, page 199

Security Violations and ActionsPort security triggers security violations when either of the two following events occur:

• Ingress traffic arrives at an interface from a nonsecure MAC address and learning the address wouldexceed the applicable maximum number of secure MAC addresses.

When an interface has both a VLANmaximum and an interface maximum configured, a violation occurswhen either maximum is exceeded. For example, consider the following on a single interface configuredwith port security:

◦ VLAN 1 has a maximum of 5 addresses

◦ The interface has a maximum of 10 addresses

The device detects a violation when any of the following occurs:

◦ The device has learned five addresses for VLAN 1 and inbound traffic from a sixth address arrivesat the interface in VLAN 1.

◦ The device has learned 10 addresses on the interface and inbound traffic from an 11th addressarrives at the interface.


Configuring Port SecuritySecurity Violations and Actions

• Ingress traffic from a secure MAC address arrives at a different interface in the same VLAN as theinterface on which the address is secured.

After a secure MAC address is configured or learned on one secure port, the sequenceof events that occurs when port security detects that secure MAC address on a differentport in the same VLAN is known as a MAC move violation.

Note

When a security violation occurs, the device increments the security violation counter for the interface andtakes the action specified by the port security configuration of the interface. The possible actions that thedevice can take are as follows:

Shuts down the interface that received the packet triggering the violation. The interface iserror disabled. This action is the default. After you reenable the interface, it retains its portsecurity configuration, including its secure MAC addresses.

Shutdown

Drops ingress traffic from any nonsecure MAC addresses. Address learning continues until100 security violations have occurred on the interface. Traffic from addresses learned afterthe first security violation is dropped.

Restrict

After 100 security violations occur, the device disables learning on the interface and dropsall ingress traffic from nonsecure MAC addresses. In addition, the device generates anSNMP notification for each security violation.

Prevents further violations from occurring. The address that triggered the security violationis learned but any traffic from the address is dropped. Further address learning stops.

Protect

If a violation occurs because ingress traffic from a secure MAC address arrives at a different interface thanthe interface on which the address is secure, the device applies the action on the interface that received thetraffic.

Port Security and Port TypesYou can configure port security only on Layer 2 interfaces. Details about port security and different types ofinterfaces or ports are as follows:

You can configure port security on interfaces that you have configured as Layer2 access ports. On an access port, port security applies only to the access VLAN.

Access ports

You can configure port security on interfaces that you have configured as Layer2 trunk ports. VLAN maximums are not useful for access ports. The deviceallows VLAN maximums only for VLANs associated with the trunk port.

Trunk ports

You can configure port security on SPAN source ports but not on SPANdestination ports.

SPAN ports

You can configure port security on Layer 2 Ethernet port channels in eitheraccess mode or trunk mode.

Ethernet port channels

Port security is not supported on virtual port channels.Virtual port channels


Configuring Port SecurityPort Security and Port Types

Port Security and Port-Channel InterfacesPort security is supported on Layer 2 port-channel interfaces. Port security operates on port-channel interfacesin the same manner as on physical interfaces, except as described in this section.

Port security on a port-channel interface operates in either access mode or trunk mode.In trunk mode, the MAC address restrictions enforced by port security apply to allmember ports on a per-VLAN basis.

Generalguidelines

Enabling port security on a port-channel interface does not affect port-channel loadbalancing.

Port security does not apply to port-channel control traffic passing through theport-channel interface. Port security allows port-channel control packets to pass withoutcausing security violations. Port-channel control traffic includes the following protocols:

• Port Aggregation Protocol (PAgP)

• Link Aggregation Control Protocol (LACP)

• Inter-Switch Link (ISL)

• IEEE 802.1Q

The port security configuration of a port-channel interface has no effect on the portsecurity configuration of member ports.

Configuringsecure memberports

If you add a secure interface as a member port of a port-channel interface, the devicediscards all dynamic secure addresses learned on the member port but retains all other

Adding amember port

port-security configuration of the member port in the running configuration. Sticky andstatic secure MAC addresses learned on the secure member port are also stored in therunning configuration rather than NVRAM.

If port security is enabled on the member port and not enabled on the port-channelinterface, the device warns you when you attempt to add the member port to theport-channel interface.

While a port is a member of a port-channel interface, you cannot configure port securityon the member port. To do so, you must first remove the member port from theport-channel interface.

If you remove a member port from a port-channel interface, the device restores the portsecurity configuration of the member port. Static and sticky secure MAC addresses that

Removing amember port

were learned on the port before you added it to the port-channel interface are restoredto NVRAM and removed from the running configuration.

To ensure that all ports are secure as needed after you remove a port-channelinterface, we recommend that you closely inspect the port-security configurationof all member ports.

Note


Configuring Port SecurityPort Security and Port-Channel Interfaces

If you remove a secure port-channel interface, the following occurs:Removing aport-channelinterface • The device discards all secureMAC addresses learned for the port-channel interface,

including static and sticky secure MAC addresses learned on the port-channelinterface.

• The device restores the port-security configuration of eachmember port. The staticand sticky secure MAC addresses that were learned on member ports before youadded them to the port-channel interface are restored to NVRAM and removedfrom the running configuration. If a member port did not have port security enabledprior to joining the port-channel interface, port security is not enabled on themember port after the port-channel interface is removed.

To ensure that all ports are secure as needed after you remove a port-channelinterface, we recommend that you closely inspect the port-security configurationof all member ports.

Note

If port security is enabled on any member port, the device does not allow you to disableport security on the port-channel interface. To do so, remove all secure member ports

Disabling portsecurity

from the port-channel interface first. After disabling port security on a member port,you can add it to the port-channel interface again, as needed.

Port Type ChangesWhen you have configured port security on a Layer 2 interface and you change the port type of the interface,the device behaves as follows:

When you change a Layer 2 interface from an access port to a trunk port, thedevice drops all secure addresses learned by the dynamic method. The device

Access port to trunkport

moves the addresses learned by the static or sticky method to the native trunkVLAN.

When you change a Layer 2 interface from a trunk port to an access port, thedevice drops all secure addresses learned by the dynamic method. It also moves

Trunk port to accessport

all addresses learned by the sticky method on the native trunk VLAN to the accessVLAN. The device drops secure addresses learned by the sticky method if theyare not on the native trunk VLAN.

When you change an interface from a Layer 2 interface to a Layer 3 interface,the device disables port security on the interface and discards all port security

Switched port to routedport

configuration for the interface. The device also discards all secureMAC addressesfor the interface, regardless of the method used to learn the address.

When you change an interface from a Layer 3 interface to a Layer 2 interface,the device has no port security configuration for the interface.

Routed port to switchedport


Configuring Port SecurityPort Type Changes

802.1X and Port SecurityYou can configure port security and 802.1X on the same interfaces of a Cisco Nexus 7000 Series Switch. Portsecurity secures the MAC addresses that 802.1X authenticates. 802.1X processes packets before port securityprocesses them, so when you enable both on an interface, 802.1X is already preventing inbound traffic on theinterface from unknown MAC addresses.

When you enable 802.1X and port security on the same interface, port security continues to learn MACaddresses by the sticky or dynamic method, as configured. Additionally, depending on whether you enable802.1X in single-host mode or multiple-host mode, one of the following occurs:

Port security learns the MAC address of the authenticated host.Single host mode

Port security drops any MAC addresses learned for this interface by thedynamic method and learns the MAC address of the first host authenticatedby 802.1X.

Multiple host mode

If aMAC address that 802.1X passes to port security would violate the applicable maximum number of secureMAC addresses, the device sends an authentication failure message to the host.

The device treats MAC addresses authenticated by 802.1X as though they were learned by the dynamicmethod, even if port security previously learned the address by the sticky or static methods. If you attempt todelete a secure MAC address that has been authenticated by 802.1X, the address remains secure.

If the MAC address of an authenticated host is secured by the sticky or static method, the device treats theaddress as if it were learned by the dynamic method, and you cannot delete the MAC address manually.

Port security integrates with 802.1X to reauthenticate hosts when the authenticated and secure MAC addressof the host reaches its port security age limit. The device behaves differently depending upon the type ofaging, as follows:

Port security notifies 802.1X and the device attempts to reauthenticate the host. The resultof reauthentication determines whether the address remains secure. If reauthentication

Absolute

succeeds, the device restarts the aging timer on the secure address; otherwise, the devicedrops the address from the list of secure addressees for the interface.

Port security drops the secure address from the list of secure addresses for the interface andnotifies 802.1X. The device attempts to reauthenticate the host. If reauthentication succeeds,port security secures the address again.

Inactivity

Licensing Requirements for Port SecurityThe following table shows the licensing requirements for this feature:


Port security requires a LAN Enterprise license. Foran explanation of the Cisco DCNM licensing scheme

Cisco DCNM



Configuring Port Security802.1X and Port Security


Port security requires no license. Any feature notincluded in a license package is bundled with the

Cisco NX-OS

Cisco NX-OS device images and is provided at noextra charge to you. For an explanation of the CiscoNX-OS licensing scheme for your platform, see thelicensing guide for your platform.

Prerequisites for Port SecurityThe following prerequisites are required for using this feature on Cisco DCNM. For a full list of feature-specificprerequisites, see the platform-specific documentation.

• System-message logging levels for the Port Security feature must meet or exceed Cisco DCNMrequirements. During device discovery, Cisco DCNM detects inadequate logging levels and raises themto the minimum requirements. Cisco Nexus 7000 Series switches that run Cisco NX-OS Release 4.0 arean exception. For Cisco NX-OS Release 4.0, prior to device discovery, use the command-line interfaceto configure logging levels to meet or exceed Cisco DCNM requirements. For more information, seethe .

Platform Support for Port SecurityThe following platform supports this feature. For platform-specific information, including guidelines andlimitations, system defaults, and configuration limits, see the corresponding documentation.



Configuring Port Security

Enabling or Disabling Port Security GloballyYou can enable or disable port security globally on a device. By default, port security is disabled globally.

When you disable port security globally, all port security configuration is lost, including any staticallyconfigured secure MAC addresses and all dynamic or sticky secured MAC addresses.

Procedure

Step 1 From the Feature Selector pane, choose Switching ➤ Layer 2 Security ➤ Port Security.


Configuring Port SecurityPrerequisites for Port Security



Step 2 From the Summary pane, click the device on which you want to enable or disable port security.Step 3 From the menu bar, do one of the following:

• If you want to enable port security globally on the device, choose Actions ➤ Enable Port SecurityService.

• If you want to disable port security globally on the device, choose Actions ➤ Disable Port SecurityService.

When port security is enabled, the Stop Learning check box appears on the Global Settings tab in the Detailspane.

When port security is disabled, the Port Security is disabled on device message appears on the Global Settingstab in the Details pane.

You do not need to save your changes.

Enabling or Disabling Port Security on a Layer 2 InterfaceYou can enable or disable port security on a Layer 2 physical interface or Layer 2 port-channel interface. Bydefault, port security is disabled on all interfaces.

Enabling port security on an interface also enables dynamic MAC address learning.

You cannot enable port security on a routed interface.Note

Procedure

Step 1 From the Feature Selector pane, choose Switching ➤ Layer 2 Security ➤ Port Security.The available devices appear in the Summary pane.


• If you want to configure a physical interface, expand Device ➤ Physical Interfaces ➤ Slot.

• If you want to configure a port-channel interface, expand Device ➤ Port Channels.

Interfaces with port security enabled appear, in addition to other interfaces that were previously added to theport security summary table.

Step 3 If the interface that you want to configure does not appear, do the following:a) From the menu bar, choose Actions ➤ Add Interface.

Below the selected interface type, a new row contains a drop-down list in the Interface column.

b) In the Interface column, from the drop-down list, choose the interface on which you want to enable portsecurity.


Configuring Port SecurityEnabling or Disabling Port Security on a Layer 2 Interface

The interface name appears in the new row of the Summary pane.

Step 4 Click the interface and then do one of the following:

• To enable port security on the selected interface, in the Port Security column, check the check box.

• To disable port security on the selected interface, in the Port Security column, uncheck the check box.

DCNM enables or disables port security on the interface, as specified. You do not need to save your changes.

Related Topics

• Secure MAC Address Learning, page 188• Enabling or Disabling Sticky MAC Address Learning, page 197

Enabling or Disabling Sticky MAC Address LearningYou can disable or enable sticky MAC address learning on an interface. If you disable sticky learning, thedevice returns to dynamic MAC address learning on the interface, which is the default learning method.

By default, sticky MAC address learning is disabled.

Procedure










Step 4 Click the interface on which you want to enable or disable sticky MAC address learning.Step 5 Do one of the following:

• To enable sticky MAC address learning on the selected interface, in the Stickiness column, check thecheck box.


Configuring Port SecurityEnabling or Disabling Sticky MAC Address Learning

• To disable sticky MAC address learning on the selected interface, in the Stickiness column, uncheckthe check box.


Adding a Static Secure MAC Address on an InterfaceYou can add a static secure MAC address on a Layer 2 interface. If the interface is in trunk port mode, youmust assign the new static secure MAC address to a VLAN.

By default, no static secure MAC addresses are configured on an interface.

Procedure










Step 4 Click the interface on which you want to configure an address.Step 5 From the Details pane, click the Secure Interface Details tab.Step 6 Expand the Secure Address Configuration section, if necessary.

A table of secure MAC addresses appears in the Secure Address Configuration section. If the interface thatyou selected is in trunk port mode, the table is organized by VLAN ID.

Step 7 If the interface is in trunk port mode and the VLAN for the new secure address does not appear, do thefollowing:a) Right-click either on an existing VLAN entry or on a blank row.b) Choose Add VLAN.

A new row appears, with a drop-down list in the VLAN ID column.

c) From the drop-down list, choose the VLAN ID that you need to associate the secure address with.

Step 8 Under the Host MAC Address heading, right-click on a blank area and choose Add Host.


Configuring Port SecurityAdding a Static Secure MAC Address on an Interface

A new row appears under the Host MAC Address heading.

Step 9 Double-click on the new row, type the new static secure MAC address, and press Enter.Valid entries are dotted hexadecimal MAC addresses.

DCNM configures the static secure MAC address on the interface. You do not need to save your changes.

Related Topics

• Configuring a Maximum Number of MAC Addresses, page 200• Removing a Dynamic or Sticky Secure MAC Address, page 200• Removing a Static Secure MAC Address on an Interface, page 199

Removing a Static Secure MAC Address on an InterfaceYou can remove a static secure MAC address from a Layer 2 interface.

Procedure






Step 3 Click the interface from which you want to delete an address.Step 4 From the Details pane, click the Secure Interface Details tab.Step 5 If necessary, expand the Secure Address Configuration section.

A table of secure MAC addresses appears in the Secure Address Configuration section. If the interface thatyou selected is in trunk port mode, the table is organized by VLAN ID.

Step 6 If the interface is in trunk port mode, expand the VLAN that you need to remove the secure address from.Secure MAC addresses associated with the selected VLAN appear in the table below the Host MAC Addressheading.

Step 7 Right-click the address that you need to remove and choose Delete Host.A confirmation warning appears.

Step 8 Click Yes.DCNM removes the static secure MAC address from the interface configuration. If the interface is in trunkport mode and you removed the last static secure MAC address from a VLAN, that VLAN no longer appearsin the Secure Address Configuration section.



Configuring Port SecurityRemoving a Static Secure MAC Address on an Interface

Removing a Dynamic or Sticky Secure MAC AddressYou can remove dynamically learned, secure MAC addresses, including sticky secure MAC addresses.

Procedure






Step 3 Click the interface from which you want to delete a dynamic or sticky secure MAC address.Step 4 From the Details pane, click the Dynamic MAC Addresses tab.

A table of dynamic secure MAC addresses, organized by VLAN ID, appears.

Step 5 If necessary, expand the VLAN that you need to remove the secure address from.Secure MAC addresses associated with the selected VLAN appear in the table below the Host MAC Addressheading.

Step 6 Right-click the address that you need to remove and choose Clear MAC Address.A confirmation warning appears.

Step 7 Click Yes.DCNM removes the secure MAC address from the interface configuration. If you removed the last secureMAC address from a VLAN, that VLAN no longer appears in the Dynamic Address Configuration section.


Configuring a Maximum Number of MAC AddressesYou can configure the maximum number of MAC addresses that can be learned or statically configured ona Layer 2 interface. You can also configure the maximum number of MAC addresses per VLAN on a Layer2 interface. The largest maximum number of addresses that you can configure is 1025 addresses.

By default, an interface has a maximum of one secure MAC address. VLANs have no default maximumnumber of secure MAC addresses.


Configuring Port SecurityRemoving a Dynamic or Sticky Secure MAC Address

When you specify a maximum number of addresses that is less than the number of addresses alreadylearned or statically configured on the interface, the device rejects the command.

Note

Procedure










Step 4 Click the interface on which you want to configure the maximum number of secure MAC addresses.Step 5 From the Details pane, click the Secure Interface Details tab.Step 6 (Optional) If you want to configure the maximum number of secure MAC addresses for the interface, do the

following:a) Expand the Secure Interface Configuration section, if necessary.b) In the Maximum Number of Address field, enter the new maximum number.

Step 7 (Optional) If you want to configure the maximum number of secure MAC addresses for a VLAN on theinterface, do the following:a) Expand the Secure Address Configuration section, if necessary.b) If the VLAN that you need does not appear, right-click either on an existing VLAN entry or on a blank

row, choose Add VLAN, and then from the drop-down list, choose the VLAN ID.c) In the Maximum Number of Secure Addresses column, double-click the entry for the VLAN and enter

the new maximum number.

Step 8 (Optional) From the menu bar, choose File ➤ Deploy to apply your changes to the device.DCNM configures the interface with the secure MAC address maximums that you specified.

Related Topics

• Removing a Dynamic or Sticky Secure MAC Address, page 200• Removing a Static Secure MAC Address on an Interface, page 199


Configuring Port SecurityConfiguring a Maximum Number of MAC Addresses

Configuring an Address Aging Type and TimeYou can configure the MAC address aging type and the length of time that the device uses to determine whenMAC addresses learned by the dynamic method have reached their age limit.

Absolute aging is the default aging type.

By default, the aging time is 0 minutes, which disables aging.

Procedure










Step 4 Click the interface on which you want to configure secure MAC address aging.Step 5 From the Details pane, click the Dynamic MAC Addresses tab.Step 6 From the Aging Type drop-down list, pick the aging type.Step 7 In the Age field, enter the number of minutes for the aging period.Step 8 From the menu bar, choose File ➤ Deploy to apply your changes to the device.

DCNM configures the interface with the secure MAC address aging type and time that you specified.

Configuring a Security Violation ActionYou can configure the action that the device takes if a security violation occurs. The violation action isconfigurable on each interface that you enable with port security.

The default security action is to shut down the port on which the security violation occurs.


Configuring Port SecurityConfiguring an Address Aging Type and Time

Procedure










Step 4 Click the interface on which you want to configure the security violation action.Step 5 From the Details pane, click the Secure Interface Details tab and then expand the Secure Interface

Configuration section, if necessary.Step 6 In the Interface Setting area, from the Violation Action drop-down list, choose the security violation action.Step 7 (Optional) From the menu bar, choose File ➤ Deploy to apply your changes to the device.

Displaying Secure MAC AddressesYou can display secure MAC addresses for an interface.

Procedure






Step 3 Click the interface.


Configuring Port SecurityDisplaying Secure MAC Addresses

The Secure Interface Details tab and the Dynamic MAC Addresses tab appear in the Details pane.

Step 4 (Optional) To display dynamic or sticky secure MAC addresses, click the Dynamic MAC Addresses tab.The Dynamic MAC Addresses tab displays the Host MAC Address table. If the interface is in trunk portmode, DCNM groups the dynamic or sticky secure MAC addresses by VLAN.

Step 5 (Optional) To display static secure MAC addresses, click the Secure Interface Details tab and then expandthe Secure Address Configuration section, if necessary.The Secure MAC Addresses tab displays the Host MAC Address table. If the interface is in trunk port mode,DCNM groups the static secure MAC addresses by VLAN.

Field Descriptions for Port Security

Device: Global Settings TabTable 60: Device: Global Settings Tab

DescriptionField

Link that enables the port security feature globallyon the device. This link appears only when port

Enable Port Security service

security is not enabled on the selected device. Bydefault, port security is not enabled.

Whether dynamic secure MAC address learning isglobally permitted on the device. By default, thischeck box is unchecked.

Stop learning

Interface: Secure Interface Details: Secure Interface Configuration SectionTable 61: Interface: Secure Interface Details: Secure Interface Configuration Section

DescriptionField

Display only.Name of the physicalinterface. Appears only when theinterface is a physical interface.

Interface

Display only. Name of theport-channel interface. Appears

Port Channel

only when the interface is aport-channel interface.


Configuring Port SecurityField Descriptions for Port Security

DescriptionField

Display only. Access VLAN forthe interface. Appears only whenthe interface is in access mode.

Access VLAN

Display only. VLANs that packetsusing the interface can belong to.

Port Security Configured VLANs

Appears only when the interface isin trunk mode.

Display only. Primary VLAN forthe interface. Appears only when

Host Primary VLAN

the interface is a physical interfacein PVLAN host mode.

Display only. Primary VLAN forthe interface. Appears only when

Promiscuous Primary VLAN

the interface is a physical interfacein PVLAN promiscuous mode.

Display only. Port mode of theinterface. Possible values are asfollows:

Port Type

• Access

• Trunk

• PVLAN Host (physicalinterfaces only)

• PVLAN Promiscuous(physical interfaces only)

Port security does notsupport interfaces inRouted port mode.

Note

Action that the device takes whenit detects a security violation on the

Violation Action

interface. You can choose one ofthe following settings:

• Protect

• Restrict

• Shutdown (Default)

Secure Address Count


Configuring Port SecurityInterface: Secure Interface Details: Secure Interface Configuration Section

DescriptionField

Number of secure MAC addressesallowed on the interface. Thedefault is one secureMAC address.

Maximum number of addresses

Display only. Number of staticsecure MAC addresses configuredfor the interface.

Number of configured MAC addresses

Display only. Number of dynamicor sticky secure MAC addresseslearned for the interface.

Number of learnt MAC addresses

Interface: Secure Interface Details: Secure Address Configuration SectionTable 62: Interface: Secure Interface Details: Secure Address Configuration Section

DescriptionField

Display only.Trunk mode only. IDof the VLAN on which the MACaddress is secured.

VLAN ID

Trunk mode only.Maximumnumber of secure MAC addresses

Maximum Number of Secure Addresses

allowed on the VLAN for theinterface.

Trunk mode only.Number of staticsecure MAC addresses on theVLAN for the interface.

Number of configured MAC addresses

Trunk mode only.Number of stickyor dynamic secureMAC addresseson the VLAN for the interface.

Number of learnt MAC addresses

Static secure MAC address. Validentries are dotted hexadecimal

Host MAC Address

MAC addresses. By default, thereare no static secure MACaddresses.


Configuring Port SecurityInterface: Secure Interface Details: Secure Address Configuration Section

Interface: Dynamic MAC Addresses TabTable 63: Interface: Dynamic MAC Addresses Tab

DescriptionField

Display only. Physical interface name. Appears onlywhen the interface is a physical interface.

Interface

Display only. Port-channel interface name. Appearsonly when the interface is a port-channel interface.

Port Channel

Display only. Port mode of the interface. Possiblevalues are as follows:

Port Type

• Access

• Trunk

• PVLAN Host (physical interfaces only)

• PVLANPromiscuous (physical interfaces only)

Port security does not support interfaces inRouted port mode.

Note

Aging type for dynamically learned, secure MACaddresses. You can choose one of the followingsettings:

Aging Type

• Absolute—Addresses age based how long agothe device learned the address. This is thedefault setting.

• InActivity—Addresses age based on how longago the device last received traffic from theMAC address on the current interface.

Aging time, in minutes, for dynamically learned,secure MAC addresses. Valid entries are wholenumbers from 1 to 1440.

Age

Whether the device learns secure MAC address bythe sticky method. If this field is selected, the devices

Dynamic MAC Stickiness

stores addresses that it learns in NVRAM. By default,the device learns addresses by the dynamic method.

Display only.MAC addresses secured by the dynamicor sticky address learning method.

Host MAC Address


Configuring Port SecurityInterface: Dynamic MAC Addresses Tab

Additional References for Port SecurityRelated Documents


Layer 2 switching

Standards

TitleStandards


MIBs

Cisco NX-OS provides read-only SNMP support for port security.

MIBs LinkMIBs

To locate and download MIBs, go to the followingURL:• CISCO-PORT-SECURITY-MIB


Traps are supported for notification of secureMAC address violations.

Note

Feature History for Port SecurityThis table lists the release history for this feature.

Table 64: Feature History for Port Security


No change from Release 5.1.5.2(1)Port security





Configuring Port SecurityAdditional References for Port Security



C H A P T E R 13Configuring DHCP

This chapter describes how to configure the Dynamic Host Configuration Protocol (DHCP) on a CiscoNX-OS device.


Note


• Information About DHCP Snooping, page 209

• Licensing Requirements for DHCP, page 213

• Prerequisites for DHCP, page 213

• Platform Support for DHCP, page 214

• Configuring DHCP, page 214

• Displaying DHCP Bindings , page 222

• Field Descriptions for DHCP Snooping, page 223

• Additional References for DHCP, page 225

• Feature History for DHCP, page 225

Information About DHCP SnoopingDHCP snooping acts like a firewall between untrusted hosts and trusted DHCP servers. DHCP snoopingperforms the following activities:

• Validates DHCP messages received from untrusted sources and filters out invalid messages.

• Builds and maintains the DHCP snooping binding database, which contains information about untrustedhosts with leased IP addresses.

• Uses the DHCP snooping binding database to validate subsequent requests from untrusted hosts.


DHCP snooping can be enabled globally and on a per-VLAN basis. By default, the feature is disabled globallyand on all VLANs. You can enable the feature on a single VLAN or a range of VLANs.

Trusted and Untrusted SourcesYou can configure whether DHCP snooping trusts traffic sources. An untrusted source may initiate trafficattacks or other hostile actions. To prevent such attacks, DHCP snooping filters messages from untrustedsources.

In an enterprise network, a trusted source is a device that is under your administrative control. These devicesinclude the switches, routers, and servers in the network. Any device beyond the firewall or outside the networkis an untrusted source. Generally, host ports are treated as untrusted sources.

In a service provider environment, any device that is not in the service provider network is an untrusted source(such as a customer switch). Host ports are untrusted sources.

In the Cisco NX-OS device, you indicate that a source is trusted by configuring the trust state of its connectinginterface.

The default trust state of all interfaces is untrusted. You must configure DHCP server interfaces as trusted.You can also configure other interfaces as trusted if they connect to devices (such as switches or routers)inside your network. You usually do not configure host port interfaces as trusted.

For DHCP snooping to function properly, all DHCP servers must be connected to the device throughtrusted interfaces.

Note

DHCP Snooping Binding DatabaseUsing information extracted from intercepted DHCP messages, DHCP snooping dynamically builds andmaintains a database. The database contains an entry for each untrusted host with a leased IP address if thehost is associated with a VLAN that has DHCP snooping enabled. The database does not contain entries forhosts connected through trusted interfaces.

The DHCP snooping binding database is also referred to as the DHCP snooping binding table.Note

DHCP snooping updates the database when the device receives specific DHCP messages. For example, thefeature adds an entry to the database when the device receives a DHCPACK message from the server. Thefeature removes the entry in the database when the IP address lease expires or the device receives aDHCPRELEASE message from the host.

Each entry in the DHCP snooping binding database includes the MAC address of the host, the leased IPaddress, the lease time, the binding type, and the VLAN number and interface information associated withthe host.

Dynamic ARP inspection (DAI) and IP Source Guard also use information stored in the DHCP snoopingbinding database.


Configuring DHCPTrusted and Untrusted Sources

DHCP Relay AgentYou can configure the device to run a DHCP relay agent, which forwards DHCP packets between clients andservers. This feature is useful when clients and servers are not on the same physical subnet. Relay agentforwarding is distinct from the normal forwarding of an IP router, where IP datagrams are switched betweennetworks somewhat transparently. By contrast, relay agents receive DHCP messages and then generate a newDHCP message to send out on another interface. The relay agent sets the gateway address (giaddr field of theDHCP packet) and, if configured, adds the relay agent information option (Option 82) in the packet andforwards it to the DHCP server. The reply from the server is forwarded back to the client after removingOption 82.

When the device relays a DHCP request that already includes Option 82 information, the device forwardsthe request with the original Option 82 information without altering it.

Note

Packet ValidationThe device validates DHCP packets received on the untrusted interfaces of VLANs that have DHCP snoopingenabled. The device forwards the DHCP packet unless any of the following conditions occur (in which case,the packet is dropped):

• The device receives a DHCP response packet (such as a DHCPACK, DHCPNAK, or DHCPOFFERpacket) on an untrusted interface.

• The device receives a packet on an untrusted interface, and the source MAC address and the DHCPclient hardware address do not match. This check is performed only if the DHCP snoopingMAC addressverification option is turned on.

• The device receives a DHCPRELEASE or DHCPDECLINE message from an untrusted host with anentry in the DHCP snooping binding table, and the interface information in the binding table does notmatch the interface on which the message was received.

DHCP Snooping Option 82 Data InsertionDHCP can centrally manage the IP address assignments for a large number of subscribers. When you enableOption 82, the device identifies a subscriber device that connects to the network (in addition to its MACaddress). Multiple hosts on the subscriber LAN can connect to the same port on the access device and areuniquely identified.

When you enable Option 82 on the Cisco NX-OS device, the following sequence of events occurs:

1 The host (DHCP client) generates a DHCP request and broadcasts it on the network.

2 When the Cisco NX-OS device receives the DHCP request, it adds the Option 82 information in the packet.The Option 82 information contains the device MAC address (the remote ID suboption) and the portidentifier, vlan-mod-port, from which the packet is received (the circuit ID suboption). For hosts behindthe port channel, the circuit ID is filled with the if_index of the port channel.

3 The device forwards the DHCP request that includes the Option 82 field to the DHCP server.


Configuring DHCPDHCP Relay Agent

4 The DHCP server receives the packet. If the server is Option 82 capable, it can use the remote ID, thecircuit ID, or both to assign IP addresses and implement policies, such as restricting the number of IPaddresses that can be assigned to a single remote ID or circuit ID. The DHCP server echoes the Option82 field in the DHCP reply.

5 The DHCP server sends the reply to the Cisco NX-OS device. The Cisco NX-OS device verifies that itoriginally inserted the Option 82 data by inspecting the remote ID and possibly the circuit ID fields. TheCisco NX-OS device removes the Option 82 field and forwards the packet to the interface that connectsto the DHCP client that sent the DHCP request.

If the previously described sequence of events occurs, the following values do not change:

• Circuit ID suboption fields

◦ Suboption type

◦ Length of the suboption type

◦ Circuit ID type

◦ Length of the circuit ID type

• Remote ID suboption fields

◦ Suboption type

◦ Length of the suboption type

◦ Remote ID type

◦ Length of the circuit ID type

This figure shows the packet formats for the remote ID suboption and the circuit ID suboption. The CiscoNX-OS device uses the packet formats when you globally enable DHCP snooping and when you enableOption 82 data insertion and removal. For the circuit ID suboption, the module field is the slot number of themodule.


Configuring DHCPDHCP Snooping Option 82 Data Insertion

Figure 32: Suboption Packet Formats

Licensing Requirements for DHCPThis table shows the licensing requirements for DHCP.


DHCP requires a LAN Enterprise license. For anexplanation of the Cisco DCNM licensing scheme

Cisco DCNM


DHCP requires no license. Any feature not includedin a license package is bundled with the Cisco NX-OS

Cisco NX-OS


Prerequisites for DHCPThe following prerequisites are required for using this feature on Cisco DCNM. For a full list of feature-specificprerequisites, see the platform-specific documentation.

• You should be familiar with DHCP before you configure DHCP snooping or the DHCP relay agent.


Configuring DHCPLicensing Requirements for DHCP

• System-message logging levels for DHCP must meet or exceed Cisco DCNM requirements. Duringdevice discovery, Cisco DCNM detects inadequate logging levels and raises them to the minimumrequirements. Cisco Nexus 7000 Series switches that run Cisco NX-OS Release 4.0 are an exception.For Cisco NX-OS Release 4.0, prior to device discovery, use the command-line interface to configurelogging levels to meet or exceed Cisco DCNM requirements. For more information, see the .

Platform Support for DHCPThe following platforms support this feature. For platform-specific information, including guidelines andlimitations, system defaults, and configuration limits, see the corresponding documentation.


Cisco Nexus 1000V Series Switches DocumentationCisco Nexus 1000 Series Switches




Configuring DHCP

Minimum DHCP Configuration

Procedure

Step 1 Enable the DHCP snooping feature.When the DHCP snooping feature is disabled, you cannot configure DHCP snooping.

Step 2 Enable DHCP snooping globally.Step 3 Enable DHCP snooping on at least one VLAN.

By default, DHCP snooping is disabled on all VLANs.

Step 4 Ensure that the DHCP server is connected to the device using a trusted interface.Step 5 (Optional) Configure an interface with the IP address of the DHCP server.

Related Topics

• Enabling or Disabling the DHCP Snooping Feature, page 215• Enabling or Disabling DHCP Snooping Globally, page 215• Enabling or Disabling DHCP Snooping on a VLAN, page 216• Configuring a Layer 2 Interface as Trusted or Untrusted, page 218• Enabling or Disabling the DHCP Relay Agent, page 219


Configuring DHCPPlatform Support for DHCP





• Configuring a DHCP Server Address on a Layer 3 Ethernet Interface, page 220• Configuring a DHCP Server Address on a Port Channel, page 221• Configuring a DHCP Server Address on a VLAN Interface, page 221

Enabling or Disabling the DHCP Snooping FeatureYou can enable or disable the DHCP snooping feature on the device. By default, DHCP snooping is disabled.

If you disable the DHCP snooping feature, all DHCP snooping configuration is lost. If you want to turn offDHCP snooping and preserve the DHCP snooping configuration, disable DHCP globally.

Procedure

Step 1 From the Feature Selector pane, choose Switching ➤ Layer 2 Security ➤ DHCP Snooping.The available devices appear in the Summary pane.

Step 2 From the Summary pane, click the device on which you want to enable or disable DHCP snooping.Step 3 Do one of the following:

• To enable DHCP snooping, from the menu bar, choose Actions ➤ Enable DHCP Snooping Service.

• To disable DHCP snooping, from the menu bar, choose Actions ➤ Disable DHCP Snooping Service.

When DCHP snooping is enabled,the Global Settings and DHCP Trust State sections appear on theConfiguration tab in the Details pane.

When DHCP snooping is disabled, the Enable DHCP Snooping service link appears on the Configuration tabin the Details pane.


Related Topics

• Enabling or Disabling DHCP Snooping Globally, page 215

Enabling or Disabling DHCP Snooping GloballyYou can enable or disable the DHCP snooping globally on the device. Globally disabling DHCP snoopingstops the device from performing any DHCP snooping or relaying DHCP messages. It preserves DCHPsnooping configuration. By default, DHCP snooping is globally disabled.

Procedure


Step 2 From the Summary pane, click the device on which you want to enable or disable DHCP snooping globally.Step 3 From the Details pane, click the Configuration tab and expand the Global Settings section, if necessary.Step 4 Do one of the following:


Configuring DHCPEnabling or Disabling the DHCP Snooping Feature

• To enable DCHP snooping globally, check DHCP Snooping.

• To disable DCHP snooping globally, uncheck DHCP Snooping.


Related Topics

• Enabling or Disabling the DHCP Snooping Feature, page 215

Enabling or Disabling DHCP Snooping on a VLANYou can enable or disable DHCP snooping on one or more VLANs.

By default, DHCP snooping is disabled on all VLANs.

Before You Begin

If a VACL is configured on a VLAN that you are configuring with DHCP snooping, ensure that the VACLpermits DHCP traffic between DHCP servers and DHCP hosts.

Note

Procedure


Step 2 From the Summary pane, double-click the device on which you want to enable or disable per-VLAN DHCPsnooping.The VLANs for the device that you double-clicked appear in the Summary pane.

Step 3 Click the VLAN that you want to configure with DHCP snooping.In the Details pane, the DHCP VLAN Details tab appears.


• To enable DHCP snooping on a VLAN, on the DHCP VLAN Details tab, check DHCP Snooping.

• To disable per-VLAN DHCP snooping, on the DHCP VLAN Details tab, uncheck DHCP Snooping.


Related Topics



Configuring DHCPEnabling or Disabling DHCP Snooping on a VLAN

Enabling or Disabling DHCP Snooping MAC Address VerificationYou can enable or disable DHCP snooping MAC address verification. If the device receives a packet on anuntrusted interface and the source MAC address and the DHCP client hardware address do not match, addressverification causes the device to drop the packet.

MAC address verification is enabled by default.

Procedure


Step 2 From the Summary pane, click the device on which you want to enable or disable DHCP snooping MACaddress verification.

Step 3 From the Details pane, click the Configuration tab and expand the Global Settings section, if necessary.Step 4 Do one of the following:

• To enable MAC address verification, check Source MAC Validation.

• To disable MAC address verification, uncheck Source MAC Validation.


Related Topics


Enabling or Disabling Option 82 Data Insertion and RemovalYou can enable or disable the insertion and removal of Option 82 information for DHCP packets forwardedwithout the use of the DHCP relay agent. By default, the device does not include Option 82 information inDHCP packets.

DHCP relay agent support for Option 82 is configured separately.Note

Procedure


Step 2 From the Summary pane, click the device on which you want to enable or disable Option 82 data insertionand removal.



Configuring DHCPEnabling or Disabling DHCP Snooping MAC Address Verification

• To enable option-82 data insertion and removal, check DHCP Snooping - Option 82.

• To disable option-82 data insertion and removal, uncheck DHCP Snooping - Option 82.


Related Topics

• Enabling or Disabling the DHCP Snooping Feature, page 215• Enabling or Disabling Option 82 for the DHCP Relay Agent, page 219

Configuring a Layer 2 Interface as Trusted or UntrustedYou can configure whether an interface is a trusted or untrusted source of DHCPmessages. You can configurethis on interfaces operating in any the following port modes:

• Access

• Trunk

• Private VLAN Host

• Private VLAN Promiscuous

By default, all interfaces are untrusted.

Procedure


Step 2 From the Summary pane, click the device on which you want to configure an interface trust state.Step 3 From the Details pane, click the Configuration tab and expand the DHCP Trust State section, if necessary.Step 4 From the DHCP Trust State section, expand the slot that contains the interface that you want to configure, if

necessary.The Layer 2 interfaces on the slot appear in the Details pane. For each interface, a check box in the Trust Statecolumn indicates whether the device trusts the interface.

Step 5 For each interface whose trust state you want to configure, do one of the following:

• To make the interface a trusted interface, check the check box in the Trust State column.

• To make the interface an untrusted interface, uncheck the check box in the Trust State column.


Related Topics



Configuring DHCPConfiguring a Layer 2 Interface as Trusted or Untrusted

Enabling or Disabling the DHCP Relay AgentYou can enable or disable the DHCP relay agent.

By default, the DHCP relay agent is disabled.

Procedure


Step 2 From the Summary pane, click the device on which you want to enable or disable option-82 data insertionand removal.


• To enable the DHCP relay agent, check Relay Agent.

• To disable the DHCP relay agent, uncheck Relay Agent.


Related Topics


Enabling or Disabling Option 82 for the DHCP Relay AgentYou can enable or disable the device to insert and remove Option 82 information on DHCP packets forwardedby the relay agent.

By default, the DHCP relay agent does not include Option 82 information in DHCP packets.

Procedure


Step 2 From the Summary pane, click the device on which you want to enable or disable Option 82 data insertionand removal.


• To enable Option 82 for the relay agent, check Relay Agent - Option 82.

• To disable Option 82 for the relay agent, uncheck Relay Agent - Option 82.



Configuring DHCPEnabling or Disabling the DHCP Relay Agent

Configuring a DHCP Server Address on a Layer 3 Ethernet InterfaceYou can configure a DHCP server IP address on a Layer 3 Ethernet interface or subinterface. A Layer 3Ethernet interface is an interface that is operating in routed port mode. When an inbound DHCPBOOTREQUEST packet arrives on a port that is a member of the port channel, the relay agent forwards thepacket to the IP address specified.

By default, there is no DHCP server IP address configured on a Layer 3 interface.

Before You Begin

Ensure that the DHCP server is correctly configured.

Determine the IP address of the DHCP server.

If an ingress router ACL is configured on an interface that you are configuring with a DHCP server address,ensure that the router ACL permits DHCP traffic between DHCP servers and DHCP hosts.

Note

Procedure

Step 1 From the Feature Selector pane, choose Interfaces ➤ Physical ➤ Ethernet.The available devices appear in the Summary pane.

Step 2 From the Summary pane, double-click the device that has the interface that you want to configure.Available slots on the device appear in the Summary pane.

Step 3 Double-click the slot that has the interface that you want to configure.Available interfaces on the slot appear in the Summary pane.

Step 4 (Optional) Double-click the interface that you want to configure or that has the subinterface that you wantto configure.The Port Details tab appears in the Details pane.

Step 5 (Optional) Click the subinterface that you want to configure.Step 6 From the Details pane, click the Port Details tab and expand the Port Mode Settings section, if necessary.Step 7 For each DHCP server IP address that you want to specify, perform the following steps:

a) In the Port Mode Settings section, in the Helper area, right-click and choose Add Helper IP.b) Enter the IPv4 address of the DHCP server.


Related Topics



Configuring DHCPConfiguring a DHCP Server Address on a Layer 3 Ethernet Interface

Configuring a DHCP Server Address on a Port ChannelYou can configure a DHCP server IP address on a port channel that is in routed mode. When an inboundDHCPBOOTREQUEST packet arrives on a port that is a member of the port channel, the relay agent forwardsthe packet to the IP address specified.

By default, there is no DHCP server IP address configured on a port channel.

Before You Begin



Procedure

Step 1 From the Feature Selector pane, choose Interfaces ➤ Logical ➤ Port Channel.The available devices appear in the Summary pane.

Step 2 From the Summary pane, double-click the device that has the port channel that you want to configure.Available port channels on the device appear in the Summary pane.

Step 3 Click the channel ID of the routed port channel that you want to configure.The Port Channel Advanced Settings tab appears in the Details pane.

Step 4 From the Details pane, click the Port Channel Advanced Settings tab and expand the IP Address Settingssection, if necessary.

Step 5 For each DHCP server IP address that you want to specify, perform the following steps:a) In the IP Address Settings section, in the Helper area, right-click and choose Add Helper IP.b) Enter the IPv4 address of the DHCP server.


Related Topics


Configuring a DHCP Server Address on a VLAN InterfaceYou can configure a DHCP server IP address on a VLAN interface.When an inboundDHCPBOOTREQUESTpacket arrives on the VLAN interface, the relay agent forwards the packet to the IP address specified.

By default, there is no DHCP server IP address configured on a VLAN interface.

Before You Begin




Configuring DHCPConfiguring a DHCP Server Address on a Port Channel

Procedure

Step 1 From the Feature Selector pane, choose Interfaces ➤ Logical ➤ VLAN Network Interface.The available devices appear in the Summary pane.

Step 2 From the Summary pane, double-click the device that has the interface that you want to configure.Available VLAN interfaces on the device appear in the Summary pane.

Step 3 Click the VLAN ID of the VLAN interface that you want to configure.The Details tab appears in the Details pane.

Step 4 From the Details pane, click the Details tab and expand the IP Address Settings section, if necessary.Step 5 For each DHCP server IP address that you want to specify, perform the following steps:

a) In the IP Address Settings section, in the Helper area, right-click and choose Add Helper IP.b) Enter the IPv4 address of the DHCP server.


Related Topics


Displaying DHCP BindingsYou can display DHCP bindings for a managed device.

Procedure


Step 2 From the Summary pane, click the device.The Dynamic Binding tab appears in the Details pane.

Step 3 Double-click the slot that has the interface.Step 4 From the Details pane, click the Dynamic Binding tab.

The Dynamic Binding tab displays a table that lists the DHCP bindings per VLAN.


Configuring DHCPDisplaying DHCP Bindings

Field Descriptions for DHCP Snooping

Device: Configuration TabTable 65: Device: Configuration Tab

DescriptionField

Link that enables the DHCP snooping feature globallyon the device. This link appears only when DHCP

Enable DHCP Snooping service

snooping is not enabled on the selected device. Bydefault, DHCP snooping is not enabled.

Device: Configuration: Global Settings SectionTable 66: Device: Configuration: Global Settings Section

DescriptionFigure

Whether DHCP snooping is enabled globally on thedevice. By default, this check box is unchecked.

DHCP Snooping

Whether option-82 data insertion and removal isenabled on the device. By default, this check box isunchecked.

DHCP Snooping - Option 82

Whether MAC address verification is enabled forDHCP snooping. When this check box is checked,

Source MAC Validation

the device verifies that in packets received on anuntrusted interface, the source MAC address and theDHCP client hardware address match. If they do not,the device drops the packet. By default, this checkbox is checked.

Whether option-82 data insertion and removal by theDHCP relay agent is enabled on the device. Bydefault, this check box is unchecked.

Relay Agent - Option 82

Whether the DHCP relay agent is enabled on thedevice. By default, this check box is unchecked.

Relay Agent


Configuring DHCPField Descriptions for DHCP Snooping

Device: Configuration: DHCP Trust State SectionTable 67: Device: Configuration: DHCP Trust State Section

DescriptionFigure

Display only. Name of the Layer 2 interface or thename of the slot containing Layer 2 interfaces.

Interface

Whether the interface is trusted.When this check boxis checked, the device does not trust DHCP sources

Trust State

on the interface. By default, this check box isunchecked.

Device: Dynamic Binding TabTable 68: Device: Dynamic Binding Tab

DescriptionFigure

Display only.VLAN ID associated with the dynamicDHCP binding.

VLAN

Display only.MAC address of the dynamic DHCPbinding.

MAC Address

Display only. IP address of the dynamic DHCPbinding.

IP Address

Display only. Date and time when the DHCP IPaddress lease expires.

Lease Expiry Time

VLAN: DHCP VLAN Details TabTable 69: VLAN: DHCP VLAN Details Tab

DescriptionFigure

Display only. ID number of the VLAN.VLAN

Display only. Name assigned to the VLAN. Bydefault, VLAN 1 is named Default and all other

VLAN Name

VLANs are named by combining the text "VLAN"and the four-digit VLAN ID. For example, the defaultVLAN name for VLAN 50 is VLAN0050.


Configuring DHCPDevice: Configuration: DHCP Trust State Section

DescriptionFigure

Display only. By default, the number of staticbindings is zero (0).

Number of Static Bindings

Display only. By default, the number of dynamicbindings is zero (0).

Number of Dynamic Bindings

Whether DHCP snooping is enabled for the VLAN.By default, this check box is unchecked.

DHCP Snooping

Display only.Whether DHCP snooping is active onthe interface.

DHCP Operational State

Additional References for DHCPStandards

TitleStandards

Dynamic Host Configuration Protocol (http://tools.ietf.org/html/rfc2131)

RFC-2131

DHCP Relay Agent Information Option (http://tools.ietf.org/html/rfc3046)

RFC-3046

Feature History for DHCPThis table lists the release history for this feature.

Table 70: Feature History for DHCP


Added support for the CiscoNexus 1000V Series

5.2(1)DHCP

Switches, Cisco Nexus 3000Series Switches, and CiscoNexus 5000 Series Switches.

No change from Release 5.0.5.1(1)DHCP




Configuring DHCPAdditional References for DHCP

http://tools.ietf.org/html/rfc2131





Configuring DHCPFeature History for DHCP

C H A P T E R 14Configuring Dynamic ARP Inspection

This chapter describes how to configure dynamic Address Resolution Protocol (ARP) inspection (DAI) ona Cisco NX-OS device.


Note


• Information About DAI, page 228

• Licensing Requirements for DAI, page 231

• Prerequisites for DAI, page 232

• Platform Support for DAI and ARP ACLs, page 232

• Configuring DAI, page 232

• Monitoring and Clearing DAI Statistics, page 237

• Field Descriptions for DAI, page 237

• Configuring ARP ACLs, page 239

• Field Descriptions for ARP ACLs, page 241

• Additional References for DAI, page 245

• Feature History for DAI, page 245


Information About DAI

Understanding ARPARP provides IP communication within a Layer 2 broadcast domain by mapping an IP address to a MACaddress. For example, host B wants to send information to host A but does not have the MAC address ofhost A in its ARP cache. In ARP terms, host B is the sender and host A is the target.

To get the MAC address of host A, host B generates a broadcast message for all hosts within the broadcastdomain to obtain the MAC address associated with the IP address of host A. All hosts within the broadcastdomain receive the ARP request, and host A responds with its MAC address.

Understanding ARP Spoofing AttacksARP spoofing attacks and ARP cache poisoning can occur because ARP allows a reply from a host even ifan ARP request was not received. After the attack, all traffic from the device under attack flows through theattacker’s computer and then to the router, switch, or host.

An ARP spoofing attack can affect hosts, switches, and routers connected to your Layer 2 network by sendingfalse information to the ARP caches of the devices connected to the subnet. Sending false information to anARP cache is known as ARP cache poisoning. Spoof attacks can also intercept traffic intended for other hostson the subnet.

This figure shows an example of ARP cache poisoning.Figure 33: ARP Cache Poisoning

Hosts A, B, and C are connected to the device on interfaces A, B, and C, all of which are on the same subnet.Their IP and MAC addresses are shown in parentheses; for example, host A uses IP address IA and MACaddress MA. When host A needs to send IP data to host B, it broadcasts an ARP request for the MAC addressassociated with IP address IB. When the device and host B receive the ARP request, they populate their ARPcaches with an ARP binding for a host with the IP address IA and aMAC addressMA; for example, IP addressIA is bound to MAC address MA. When host B responds, the device and host A populate their ARP cacheswith a binding for a host with the IP address IB and the MAC address MB.

Host C can poison the ARP caches of the device, host A, and host B by broadcasting two forged ARP responseswith bindings: one for a host with an IP address of IA and a MAC address of MC and another for a host withthe IP address of IB and a MAC address of MC. Host B and the device then use the MAC address MC as thedestinationMAC address for traffic intended for IA, which means that host C intercepts that traffic. Likewise,host A and the device use the MAC address MC as the destination MAC address for traffic intended for IB.


Configuring Dynamic ARP InspectionInformation About DAI

Because host C knows the true MAC addresses associated with IA and IB, it can forward the interceptedtraffic to those hosts by using the correct MAC address as the destination. This topology, in which host C hasinserted itself into the traffic stream from host A to host B, is an example of a man-in-the middle attack.

Understanding DAI and ARP Spoofing AttacksDAI ensures that only valid ARP requests and responses are relayed. When DAI is enabled and properlyconfigured, a Cisco NX-OS device performs these activities:

• Intercepts all ARP requests and responses on untrusted ports

• Verifies that each of these intercepted packets has a valid IP-to-MAC address binding before updatingthe local ARP cache or before forwarding the packet to the appropriate destination

• Drops invalid ARP packets

DAI can determine the validity of an ARP packet based on valid IP-to-MAC address bindings stored in aDynamic Host Configuration Protocol (DHCP) snooping binding database. This database is built by DHCPsnooping if DHCP snooping is enabled on the VLANs and on the device. It can also contain static entries thatyou create. If the ARP packet is received on a trusted interface, the device forwards the packet without anychecks. On untrusted interfaces, the device forwards the packet only if it is valid.

DAI can validate ARP packets against user-configured ARP access control lists (ACLs) for hosts with staticallyconfigured IP addresses. The device logs dropped packets.

You can configure DAI to drop ARP packets when the IP addresses in the packets are invalid or when theMAC addresses in the body of the ARP packets do not match the addresses specified in the Ethernet header.

Related Topics

• Applying ARP ACLs to VLANs for DAI Filtering , page 234• Logging DAI Packets, page 231• Enabling or Disabling Additional Validation, page 235

Interface Trust States and Network SecurityDAI associates a trust state with each interface on the device. Packets that arrive on trusted interfaces bypassall DAI validation checks, and packets that arrive on untrusted interfaces go through the DAI validationprocess.

In a typical network configuration, the guidelines for configuring the trust state of interfaces are as follows:

Interfaces that are connected to hostsUntrusted

Interfaces that are connected to devicesTrusted

With this configuration, all ARP packets that enter the network from a device bypass the security check. Noother validation is needed at any other place in the VLAN or in the network.

Use the trust state configuration carefully. Configuring interfaces as untrusted when they should be trustedcan result in a loss of connectivity.

Caution


Configuring Dynamic ARP InspectionUnderstanding DAI and ARP Spoofing Attacks

In this figure, assume that both device A and device B are running DAI on the VLAN that includes host 1and host 2. If host 1 and host 2 acquire their IP addresses from the DHCP server connected to device A, onlydevice A binds the IP-to-MAC address of host 1. If the interface between device A and device B is untrusted,the ARP packets from host 1 are dropped by device B and connectivity between host 1 and host 2 is lost.

Figure 34: ARP Packet Validation on a VLAN Enabled for DAI

If you configure interfaces as trusted when they should be untrusted, youmay open a security hole in a network.If device A is not running DAI, host 1 can easily poison the ARP cache of device B (and host 2, if youconfigured the link between the devices as trusted). This condition can occur even though device B is runningDAI.

DAI ensures that hosts (on untrusted interfaces) connected to a device that runs DAI do not poison the ARPcaches of other hosts in the network; however, DAI does not prevent hosts in other portions of the networkfrom poisoning the caches of the hosts that are connected to a device that runs DAI.

If some devices in a VLAN run DAI and other devices do not, then the guidelines for configuring the truststate of interfaces on a device running DAI becomes the following:

Interfaces that are connected to hosts or to devices that are not running DAIUntrusted

Interfaces that are connected to devices that are running DAITrusted

To validate the bindings of packets from devices that are not running DAI, configure ARPACLs on the devicerunning DAI. When you cannot determine the bindings, isolate at Layer 3 the devices that run DAI fromdevices that do not run DAI.

Depending on your network setup, you may not be able to validate a given ARP packet on all devices inthe VLAN.

Note

Related Topics

• Configuring the DAI Trust State of a Layer 2 Interface , page 233


Configuring Dynamic ARP InspectionInterface Trust States and Network Security

Prioritizing ARP ACLs and DHCP Snooping EntriesBy default, DAI filters DAI traffic by comparing DAI packets to IP-MAC address bindings in the DHCPsnooping database.

When you apply an ARP ACL to traffic, the ARP ACLs take precedence over the default filtering behavior.The device first compares ARP packets to user-configured ARP ACLs. If the ARP ACL denies the ARPpacket, the device denies the packet regardless of whether a valid IP-MAC binding exists in the DHCP snoopingdatabase.

VLAN ACLs (VACLs) take precedence over both ARP ACLs and DHCP snooping entries. For example,if you apply a VACL and an ARP ACL to a VLAN and you configured the VACL to act on ARP traffic,the device permits or denies ARP traffic as determined by the VACL, not the ARPACL or DHCP snoopingentries.

Note

Related Topics

• Configuring ARP ACLs, page 239• Applying ARP ACLs to VLANs for DAI Filtering , page 234

Logging DAI PacketsCisco NX-OS maintains a buffer of log entries about DAI packets processed. Each log entry contains flowinformation, such as the receiving VLAN, the port number, the source and destination IP addresses, and thesource and destination MAC addresses.

You can also specify the type of packets that are logged. By default, a Cisco NX-OS device logs only packetsthat DAI drops.

If the log buffer overflows, the device overwrites the oldest DAI log entries with newer entries. You canconfigure the maximum number of entries in the buffer.

Cisco NX-OS does not generate system messages about DAI packets that are logged.Note

Related Topics

• Configuring the DAI Logging Buffer Size , page 235• Configuring DAI Log Filtering, page 236

Licensing Requirements for DAIThis table shows the licensing requirements for DAI.


DAI requires a LAN Enterprise license. For anexplanation of the Cisco DCNM licensing scheme

Cisco DCNM


Configuring Dynamic ARP InspectionPrioritizing ARP ACLs and DHCP Snooping Entries



DAI requires no license. Any feature not included ina license package is bundled with the Cisco NX-OS

Cisco NX-OS


Prerequisites for DAIThe following prerequisites are required for using this feature on Cisco DCNM. For a full list of feature-specificprerequisites, see the platform-specific documentation.

• System-message logging levels for the DAI feature must meet or exceed Cisco DCNM requirements.During device discovery, Cisco DCNMdetects inadequate logging levels and raises them to the minimumrequirements. Cisco Nexus 7000 Series switches that run Cisco NX-OS Release 4.0 are an exception.For Cisco NX-OS Release 4.0, prior to device discovery, use the command-line interface to configurelogging levels to meet or exceed Cisco DCNM requirements. For more information, see the .

Platform Support for DAI and ARP ACLsThe following platform supports these features. For platform-specific information, including guidelines andlimitations, system defaults, and configuration limits, see the corresponding documentation.



Configuring DAI

Enabling or Disabling DAI on VLANsYou can enable or disable DAI on VLANs. By default, DAI is disabled on all VLANs.

Before You Begin

If you are enabling DAI, ensure the following:

• The VLANs on which you want to enable DAI are configured.


Configuring Dynamic ARP InspectionPrerequisites for DAI


Procedure

Step 1 From the Feature Selector pane, choose Switching ➤ Layer 2 Security ➤ ARP Inspection.The available devices appear in the Summary pane.

Step 2 From the Summary pane, double-click the device that has the VLAN that you want to configure with DAI.The VLANs on the device appear in the Summary pane.

Step 3 From the Summary pane, click the VLAN that you want to configure with DAI.The DAI VLAN Details tab appears in the Details pane.

Step 4 From the DAI VLAN Details tab, do one of the following:

• To enable DAI on the selected VLAN, check ARP Inspection.

• To disable DAI on the selected VLAN, uncheck ARP Inspection.


Configuring the DAI Trust State of a Layer 2 InterfaceYou can configure the DAI interface trust state of a Layer 2 interface. By default, all interfaces are untrusted.

A device forwards ARP packets that it receives on a trusted Layer 2 interface but does not check them.

On untrusted interfaces, the device verifies that all ARP requests and ARP responses have valid IP-MACaddress bindings before updating the local cache and forwarding the packet to the appropriate destination. Ifthe device determines that packets have invalid bindings, it drops the packets and logs them according to thelogging configuration.

Procedure


Step 2 From the Summary pane, click the device that has the Layer 2 interface whose DAI trust state you want toconfigure.The Details tab appears in the Summary pane.

Step 3 From the Details tab, expand the ARP Trust State section, if necessary.A table of slots on the selected device appears in the ARP Trust State section.

Step 4 Double-click the slot that contains the Layer 2 interface that you want to configure.The Layer 2 interfaces on the slot appear. For each interface, a check box in the Trust State column indicateswhether the device trusts the interface.

Step 5 In the Trust State column for the interface that you want to configure, do one of the following:

• To make the interface a trusted DAI interface, check Trust State.


Configuring Dynamic ARP InspectionConfiguring the DAI Trust State of a Layer 2 Interface

• To make the interface an untrusted DAI interface, uncheck Trust State.


Related Topics

• Interface Trust States and Network Security, page 229• Configuring DAI Log Filtering, page 236

Applying ARP ACLs to VLANs for DAI FilteringYou can apply an ARP ACL to one or more VLANs. The device permits packets only if the ACL permitsthem. By default, no VLANs have an ARP ACL applied.

Before You Begin

Ensure that the ARP ACL that you want to apply is correctly configured.

Procedure


Step 2 From the Summary pane, double-click the device that has the VLAN that you want to configure with an ARPACL.The VLANs on the device appear in the Summary pane.

Step 3 From the Summary pane, click the VLAN that you want to configure with an ARP ACL.The DAI VLAN Details tab appears in the Details pane. On the DAI VLAN Details tab, the ARP ACLdrop-down list appears.

Step 4 From the DAI VLAN Details tab, do one of the following:

• To add an ARP ACL to the VLAN, from the ARP ACL drop-down list, choose the ACL that you wantto apply.

• To remove an ARP ACL from the VLAN, from the menu bar, choose Actions ➤ Remove ARP ACLfrom VLAN.


Related Topics

• Configuring ARP ACLs, page 239


Configuring Dynamic ARP InspectionApplying ARP ACLs to VLANs for DAI Filtering

Enabling or Disabling Additional ValidationYou can enable or disable additional validation of ARP packets. By default, no additional validation of ARPpackets is enabled.

DAI intercepts, logs, and discards ARP packets with invalid IP-to-MAC address bindings. You can enableadditional validation on the destinationMAC address, the sender and target IP addresses, and the sourceMACaddress.

Procedure


Step 2 (Optional) From the Summary pane, double-click the device that you want to configure with error-disabledrecovery.The Details tab appears in the Summary pane.

Step 3 From the Details tab, expand the Global Settings section, if necessary.Step 4 (Optional) To enable or disable source MAC address validation, check or uncheck SourceMACValidation.Step 5 (Optional) To enable or disable destination MAC address validation, check or uncheck Destination MAC

Validation.Step 6 (Optional) To enable or disable source and target IP address validation, check or uncheck IP Address

Validation.Step 7 From the menu bar, choose File ➤ Deploy to apply your changes to the device.

Configuring the DAI Logging Buffer SizeYou can configure the DAI logging buffer size. The default buffer size is 32 messages.

Procedure


Step 2 From the Summary pane, click the device whose DAI logging buffer size you want to configure.The Details tab appears in the Summary pane.

Step 3 From the Details tab, expand the Global Settings section, if necessary.The Total Buffer Size field appears in the Global Settings section.

Step 4 Click the Total Buffer Size field and enter the maximum number of DAI messages that the buffer can have.Step 5 From the menu bar, choose File ➤ Deploy to apply your changes to the device.


Configuring Dynamic ARP InspectionEnabling or Disabling Additional Validation

Configuring the DAI System Logging RateYou can configure the DAI system logging rate. The default DAI system logging rate is five messages everysecond.

The DAI system logging rate is not configurable in Cisco NX-OS Releases 4.0, 4.1, 4.2, and 5.0.Note

Procedure


Step 2 From the Summary pane, click the device whose DAI logging buffer size you want to configure.The Details tab appears in the Summary pane.

Step 3 (Optional) From the Details tab, expand the Global Settings section, if necessary.The Log Messages field and the Log Interval (sec) field appear in the Global Settings section. The devicesends messages at the rate of the number of messages in the Log Messages field per the number of secondsin the Log Interval (sec) field.

Step 4 (Optional) Click the Log Messages field and enter the number of messages.Step 5 (Optional) Click the Log Interval(sec) field and enter the number of seconds.Step 6 From the menu bar, choose File ➤ Deploy to apply your changes to the device.

Configuring DAI Log FilteringYou can configure how the device determines whether to log a DAI packet. By default, the device logs DAIpackets that are dropped.

Procedure


Step 2 From the Summary pane, double-click the device that has the VLAN that you want to configure with DAIlog filtering.The VLANs on the device appear in the Summary pane.

Step 3 From the Summary pane, click the VLAN that you want to configure with DAI log filtering.The DAI VLAN Details tab appears in the Details pane. On the DAI VLAN Details tab, the DHCP Loggingdrop-down list appears.

Step 4 From the DHCP drop-down list, choose the DHCP-binding logging option that you want.Step 5 From the menu bar, choose File ➤ Deploy to apply your changes to the device.


Configuring Dynamic ARP InspectionConfiguring the DAI System Logging Rate

Monitoring and Clearing DAI StatisticsA Statistics tab appears in the Details pane when you click a device or VLAN in the Summary pane. When aVLAN is selected, the Statistics tab displays information about DAI that is specific to that VLAN. When adevice is selected, the Statistics tab displays information about DAI on all VLANs that are configured toperform DAI.

The following information appears in the Statistics tab:

• DAI Statistics displays information about ARP packets processed.

See the , for more information on collecting statistics for this feature.

Field Descriptions for DAI

Device: Details: Global Settings SectionTable 71: Device: Details: Global Settings Section

DescriptionField

Whether the device drops ARP packets when thesource MAC address in the Ethernet header does not

Source MAC Validation

match the sender MAC address in the ARP message.This field applies to ARP requests and responses. Bydefault, this check box is unchecked.

Whether the device drops ARP packets when thedestinationMAC address in the Ethernet header does

Destination MAC Validation

not match the target MAC address in the ARPmessage. This field applies to ARP responses only.By default, this check box is unchecked.

Whether the device drops ARP packets that containan invalid IP address for either the sender or target.

IP Address Validation

This field applies to ARP requests and responses. Bydefault, this check box is unchecked.

Number of messages that the DAI log buffer cancontain. By default, the buffer size is 64 messages.

Total Buffer Size

Number of DAI log messages for the DAI loggingrate limit. The device derives the limit by dividing

Log Messages

the value in this field with the value in the LogInterval (sec) field. By default, the number of logmessages in the rate limit is five.


Configuring Dynamic ARP InspectionMonitoring and Clearing DAI Statistics

DescriptionField

Number of seconds for the DAI logging rate limit.The device derives the limit by dividing the value in

Log Interval(sec)

the Log Messages field with the value in this field.By default, the number of seconds in the rate limit is1.

Device: Details: ARP Trust State SectionTable 72: Device: Details: ARP Trust State Section

DescriptionFigure

Display only. Name of the Layer 2 interface or thename of the slot containing Layer 2 interfaces.

Interface

Whether the interface is trusted.When this check boxis checked, the device does not trust ARP sources onthe interface. By default, this check box is unchecked.

Trust State

VLAN: DAI VLAN Details TabTable 73: VLAN: DAI VLAN Details Tab

DescriptionFigure

Display only. ID number of the VLAN.VLAN

Display only. Name assigned to the VLAN. By default, VLAN 1 isnamed Default and all other VLANs are named by combining the text

VLAN Name

"VLAN" and the four-digit VLAN ID. For example, the default VLANname for VLAN 50 is VLAN0050.

Whether ARP inspection is enabled for the VLAN. When this checkbox is checked, the device inspects ARP packets received on the VLAN.By default, this check box is unchecked.

ARP Inspection

Display only.Whether ARP inspection is active on the interface.ARP Operational State

Name of the ARP ACL applied to the VLAN. By default, this list isblank.

ARP ACL

Type of DCHP-binding logging for DAI packets on the VLAN. Validoptions are as follows:

DHCP Logging

• Permit—DAI packets permitted by DHCP bindings are logged.


Configuring Dynamic ARP InspectionDevice: Details: ARP Trust State Section

DescriptionFigure

• All—All DAI packets are logged.

• Deny—(Default) DAI packets denied by DHCP bindings arelogged.

• None—No DAI packets are logged.

Configuring ARP ACLsThis figure shows the ARP ACL content pane.Figure 35: ARP ACL Content Pane

Creating an ARP ACLYou can create an ARP ACL on the device and add rules to it.

Procedure

Step 1 From the Feature Selector pane, choose Security ➤ Access Control ➤ ARP ACL.


Configuring Dynamic ARP InspectionConfiguring ARP ACLs

Available devices appear in the Summary pane.

Step 2 From the Summary pane, double-click the device to which you want to add an ACL.Step 3 From the menu bar, choose File ➤ New ➤ ACL.

A blank row appears in the Summary pane. The Details tab appears in the Details pane.

Step 4 On the Details tab, in the Name field, type a name for the ACL.Step 5 For each rule or remark that you want to add to the ACL, from the menu bar, choose File ➤ New and choose

Access Rule or Remark. On the Details tab, configure fields as needed.Step 6 (Optional) If you want to log packets that match a rule in the ACL, check Log.Step 7 From the menu bar, choose File ➤ Deploy to apply your changes to the device.

Changing an ARP ACLYou can change, reorder, add , and remove rules in an existing ARP ACL.

Procedure

Step 1 From the Feature Selector pane, choose Security ➤ Access Control ➤ ARP ACL.Available devices appear in the Summary pane.

Step 2 From the Summary pane, double-click the device that has the ACL that you want to change and thendouble-click the ACL.The ACLs on the device and the rules of the ACL that you double-clicked appear in the Summary pane.

Step 3 (Optional) If you want to change the details of a rule, click the rule in the Summary pane. On the Details tab,configure fields as needed.

Step 4 (Optional) If you want to add a rule or remark, click the ACL in the Summary pane and then from the menubar, choose File ➤ New and choose Access Rule or Remark. On the Details tab, configure fields as needed.

Step 5 (Optional) If you want to remove a rule, click the rule and then from the menu bar, chooseActions➤Delete.Step 6 (Optional) If you want to move a rule or remark to a different position in the ACL, click the rule or remark

and then from the menu bar, choose one of the following, as applicable:





Related Topics

• Creating an ARP ACL , page 239


Configuring Dynamic ARP InspectionChanging an ARP ACL

Removing an ARP ACLYou can remove an ARP ACL from the device.

Before You Begin

Ensure that you know whether the ACL is applied to a VLAN. The device allows you to remove ACLs thatare currently applied. Removing an ACL does not affect the configuration of VLANs where you have appliedthe ACL. Instead, the device considers the removed ACL to be empty.

Procedure

Step 1 From the Feature Selector pane, choose Security ➤ Access Control ➤ ARP ACL.Available devices appear in the Summary pane.

Step 2 From the Summary pane, double-click the device from which you want to remove an ACL.The ACLs currently on the device appear in the Summary pane.

Step 3 Click the ACL that you want to remove.Step 4 From the menu bar, choose Actions ➤ Delete.

A confirmation dialog box appears.

Step 5 Choose Yes.DCNM removes the ARP ACL from the device and the ACL disappears from the Summary pane.


Field Descriptions for ARP ACLs

ARP ACL: ACL Details TabTable 74: ARP ACL: ACL Details Tab

DescriptionField

Name of the ARP ACL. Names can be a maximumof 64 alphanumeric characters but must begin with

Name



Configuring Dynamic ARP InspectionRemoving an ARP ACL

ARP Access Rule: ACE Details TabTable 75: ARP Access Rule: ACE Details Tab

DescriptionField

Sequence number of the rule. Must be a wholenumber between 1 and 4294967295. If you add a rule

Sequence Number

after another rule, the default sequence number is 10greater than the preceding rule. If you add a rulebefore another rule, the number is 10 less than thefollowing rule.


Action

• Deny—Stops processing the packet and dropsit.

• Permit—Continues processing the packet. Thisis the default value.

Whether the device logs statistics about traffic towhich the access rule applies. This check box isunchecked by default.

Log

ARP Access Rule: ACE Details: Source and Destination SectionTable 76: ARP Access Rule: ACE Details: Source and Destination Section

DescriptionField

Type of ARP packet that the rule matches:ARP Packet Type

• Response—The rule matches ARP responses only.

• Both—(Default) The rule matches ARP response and requestpackets.

• Request—The rule matches ARP requests only.

Sender

IP address of the sender, or if Both is selected in the ARP Packet Typelist, sender and target. You can choose one of the following radiobuttons:

IP Type


Configuring Dynamic ARP InspectionARP Access Rule: ACE Details Tab

DescriptionField

• Any—The rule matches the selected ARP packet type from anyIPv4 source. This is the default value.

• Host—The rule matches the selected ARP packet type from aspecific IPv4 address. When you select this radio button, the IPAddress field appears.

• Network—The rule matches the selected ARP packet type froman IPv4 network.When you select this radio button, the IP Addressfield and the Wildcard Mask field appear.

IPv4 address of a host or a network. Valid addresses are in dotteddecimal format. This field is available when you choose the Host radiobutton or the Network radio button. This field is unavailable by default.

IP Address

Wildcard mask of an IPv4 network. Valid masks are in dotted decimalformat. For example, if you specified 192.168.0.0 in the IP Address

Wildcard Mask (IP Type)

field, you would enter 0.0.255.255 in this field. This field is availablewhen you choose the Network radio button. This field is unavailableby default.

MAC address of sender, or if Both is selected in the ARP Packet Typelist, sender and target. You can choose one of the following radiobuttons:

MAC Type

• Any—The rule matches the selected ARP packet type from anyMAC source. This is the default value.

• Host—The rule matches the selected ARP packet type from aspecific MAC address. When you select this radio button, theMAC Address field appears.

• Network—The rule matches the selected ARP packet type froma MAC network. When you select this radio button, the MACAddress field and the Wildcard Mask field appear.

MAC address of a host or a network. Valid addresses are in dottedhexadecimal format. This field is available when you choose the Host

MAC Address

radio button or the Network radio button. This field is unavailable bydefault.

Wildcard mask of a MAC network. Valid masks are in dottedhexadecimal format. For example, if you specified 00c0.4f03.0000 in

Wildcard Mask (MAC Type)

the MAC Address field, you would enter 0000.0000.ffff in this field.This field is available when you choose the Network radio button. Thisfield is unavailable by default.

Target


Configuring Dynamic ARP InspectionARP Access Rule: ACE Details: Source and Destination Section

DescriptionField

IP address of the target. You can choose one of the following radiobuttons:

IP Type

• Any—The rule matches ARP response packets for any IPv4 targetaddress. This is the default value.

• Host—The rule matches ARP response packets for a specific IPv4target address. When you select this radio button, the IP Addressfield appears.

• Network—The rule matches ARP response packets for an IPv4network. When you select this radio button, the IP Address fieldand the Wildcard Mask field appear.

IPv4 address of a target host or a network. Valid addresses are in dotteddecimal format. This field is available when you choose the Host radiobutton or the Network radio button. This field is unavailable by default.

IP Address

Wildcard mask of an IPv4 target network. Valid masks are in dotteddecimal format. For example, if you specified 192.168.0.0 in the IP

Wildcard Mask (IP Type)

Address field, you would enter 0.0.255.255 in this field. This field isavailable when you choose the Network radio button. This field isunavailable by default.

MAC address of the target. You can choose one of the following radiobuttons:

MAC Type

• Any—The rulematchesARP response packets for anyMAC targetaddress. This is the default value.

• Host—The rule matches ARP response packets for a specific targetMAC address. When you select this radio button, the MACAddress field appears.

• Network—The rule matches ARP response packets for a specifictargetMAC network.When you select this radio button, theMACAddress field and the Wildcard Mask field appear.

MAC address of a target host or a network. Valid addresses are in dottedhexadecimal format. This field is available when you choose the Host

MAC Address

radio button or the Network radio button. This field is unavailable bydefault.

Wildcard mask of a target MAC network. Valid masks are in dottedhexadecimal format. For example, if you specified 00c0.4f03.0000 in

Wildcard Mask (MAC Type)

the MAC Address field, you would enter 0000.0000.ffff in this field.This field is available when you choose the Network radio button. Thisfield is unavailable by default.


Configuring Dynamic ARP InspectionARP Access Rule: ACE Details: Source and Destination Section

ARP ACL Remark: Remark Details TabTable 77: ARP ACL Remark: Remark Details Tab

DescriptionField

Sequence number of the remark. The number mustbe a whole number between 1 and 4294967295. If

Sequence Number

you add a rule after another rule, the default sequencenumber is 10 greater than the preceding rule. If youadd a rule before another rule, the number is 10 lessthan the following rule.

Remark text, up to 100 alphanumeric characters. Bydefault, this field is empty.

Description

Additional References for DAIStandards

TitleStandards

An Ethernet Address Resolution Protocol (http://tools.ietf.org/html/rfc826)

RFC-826

Feature History for DAIThis table lists the release history for this feature.

Table 78: Feature History for DAI


No change from Release 5.1.5.2(1)Dynamic ARP Inspection





Configuring Dynamic ARP InspectionARP ACL Remark: Remark Details Tab




Configuring Dynamic ARP InspectionFeature History for DAI

C H A P T E R 15Configuring IP Source Guard

This chapter describes how to configure IP Source Guard on Cisco NX-OS devices.


Note


• Information About IP Source Guard, page 247

• Licensing Requirements for IP Source Guard, page 248

• Prerequisites for IP Source Guard, page 248

• Platform Support for IP Source Guard, page 249

• Configuring IP Source Guard, page 249

• Displaying IP Source Guard Bindings, page 250

• Field Descriptions for IP Source Guard, page 251

• Additional References for IP Source Guard, page 252

• Feature History for IP Source Guard, page 252

Information About IP Source GuardIP Source Guard is a per-interface traffic filter that permits IP traffic only when the IP address and MACaddress of each packet matches one of two sources of IP and MAC address bindings:

• Entries in the Dynamic Host Configuration Protocol (DHCP) snooping binding table.

• Static IP source entries that you configure.

Filtering on trusted IP and MAC address bindings helps prevent spoofing attacks, in which an attacker usesthe IP address of a valid host to gain unauthorized network access. To circumvent IP Source Guard, an attackerwould have to spoof both the IP address and the MAC address of a valid host.


You can enable IP Source Guard on Layer 2 interfaces that are not trusted by DHCP snooping. IP SourceGuard supports interfaces that are configured to operate in access mode and trunk mode. When you initiallyenable IP Source Guard, all inbound IP traffic on the interface is blocked except for the following:

• DHCP packets, which DHCP snooping inspects and then forwards or drops, depending upon the resultsof inspecting the packet.

• IP traffic from static IP source entries that you have configured in the Cisco NX-OS device.

The device permits the IP traffic when DHCP snooping adds a binding table entry for the IP address andMACaddress of an IP packet or when you have configured a static IP source entry.

The device drops IP packets when the IP address and MAC address of the packet do not have a binding tableentry or a static IP source entry. For example, assume that the binding table contains the following entry:MacAddress IpAddress LeaseSec Type VLAN Interface---------- ---------- --------- ------ ------- ---------00:02:B3:3F:3B:99 10.5.5.2 6943 dhcp-snooping 10 Ethernet2/3

If the device receives an IP packet with an IP address of 10.5.5.2, IP Source Guard forwards the packet onlyif the MAC address of the packet is 00:02:B3:3F:3B:99.

Licensing Requirements for IP Source GuardThis table shows the licensing requirements for IP Source Guard.


IP Source Guard requires a LAN Enterprise license.For an explanation of the Cisco DCNM licensing

Cisco DCNM

scheme and how to obtain and apply licenses, see theCisco DCNM Installation and Licensing Guide,Release 5.x.

IP Source Guard requires no license. Any feature notincluded in a license package is bundled with the

Cisco NX-OS


Prerequisites for IP Source GuardThe following prerequisites are required for using this feature on Cisco DCNM. For a full list of feature-specificprerequisites, see the platform-specific documentation.

• System-message logging levels for the IP Source Guard feature must meet or exceed Cisco DCNMrequirements. During device discovery, Cisco DCNM detects inadequate logging levels and raises themto the minimum requirements. Cisco Nexus 7000 Series switches that run Cisco NX-OS Release 4.0 arean exception. For Cisco NX-OS Release 4.0, prior to device discovery, use the command-line interfaceto configure logging levels to meet or exceed Cisco DCNM requirements. For more information, seethe .


Configuring IP Source GuardLicensing Requirements for IP Source Guard

Platform Support for IP Source GuardThe following platform supports this feature. For platform-specific information, including guidelines andlimitations, system defaults, and configuration limits, see the corresponding documentation.




Configuring IP Source Guard

Enabling or Disabling IP Source Guard on a Layer 2 InterfaceYou can enable or disable IP Source Guard on a Layer 2 interface. By default, IP Source Guard is disabledon all interfaces.

Procedure

Step 1 From the Feature Selector pane, choose Switching ➤ Layer 2 Security ➤ IP Source Guard.The available devices appear in the Summary pane.

Step 2 From the Summary pane, double-click the device whose interface you want to configure with IP Source Guard.Slots on the selected device appear in the Summary pane.

Step 3 Double-click the slot whose interface you want to configure with IP Source Guard.The Layer 2 interfaces on the selected slot appear in the Summary pane.

Step 4 Click the interface that you want to configure with IP Source Guard.The Interface Configuration tab appears in the Details pane.

Step 5 From the Interface Configuration tab, do one of the following:

• To enable IP Source Guard on the interface, check IP Source Guard.

• To disable IP Source Guard on the interface, uncheck IP Source Guard.


Related Topics

• Adding or Removing a Static IP Source Entry, page 250


Configuring IP Source GuardPlatform Support for IP Source Guard



Adding or Removing a Static IP Source EntryYou can add or remove a static IP source entry on a device. By default, there are no static IP source entrieson a device.

Procedure

Step 1 From the Feature Selector pane, choose Switching ➤ Layer 2 Security ➤ IP Source Guard.The available devices appear in the Summary pane.

Step 2 From the Summary pane, click the device that you want to configure with static source entries.The Summary pane displays the Static Binding tab, which contains a table of static IP source entries, if anyexist on the device.

Step 3 Click the Static Binding tab.Step 4 To add a static IP source entry, follow these steps:

a) From the menu bar, choose Actions ➤ Add Source Binding.A new row appears.

b) From the drop-down list, choose the VLAN that the binding is associated with.c) Double-click the MAC Address field and enter the MAC address. Valid entries are in dotted hexadecimal

format.d) Double-click the IP Address field and enter the IPv4 address. Valid entries are in dotted decimal format.

Step 5 To delete a static IP source entry, follow these steps:a) Click the entry that you want to delete.b) From the menu bar, choose Actions ➤ Delete Source Binding.

A confirmation dialog box appears.

c) Click Yes.


Related Topics

• Enabling or Disabling IP Source Guard on a Layer 2 Interface, page 249• Displaying IP Source Guard Bindings, page 250

Displaying IP Source Guard BindingsYou can display static IP-MAC address bindings for a managed device.

Procedure

Step 1 From the Feature Selector pane, choose Switching > Layer 2 Security > IP Source Guard.Step 2 The available devices appear in the Summary pane.Step 3 From the Summary pane, click the device whose static IP-MAC address bindings you want to display.


Configuring IP Source GuardAdding or Removing a Static IP Source Entry

Field Descriptions for IP Source Guard

Device: Static Binding TabTable 79: Device: Static Binding Tab

DescriptionFigure

Display only. VLAN ID associated with the staticDHCP binding.

VLAN

Display only.MAC address of the static DHCPbinding.

MAC Address

Display only. IP address of the static DHCP binding.IP Address

Display only. Date and time when the DHCP IPaddress lease expires.

Lease Expiry Time

Interface: Interface Configuration TabTable 80: Device: Interface Configuration Tab

DescriptionFigure

Display only. Name of the Layer 2 interface.Interface

Display only. Number of static DHCP bindings forthe interface. By default, there are no static DHCPbindings.

Number of Static Bindings

Whether the IP Source Guard feature is enabled forthe interface. By default, this check box is unchecked.

IP Source Guard


Configuring IP Source GuardField Descriptions for IP Source Guard

Additional References for IP Source GuardStandards

TitleStandards


Feature History for IP Source GuardThis table lists the release history for this feature.

Table 81: Feature History for IP Source Guard



5.2(1)IP Source Guard

No change from Release 5.0.5.1(1)IP Source Guard




Configuring IP Source GuardAdditional References for IP Source Guard

C H A P T E R 16Configuring Keychain Management

This chapter describes how to configure keychain management on a Cisco NX-OS device.


Note


• Information About Keychain Management, page 253

• Licensing Requirements for Keychain Management, page 254

• Platform Support for Keychain Management, page 255

• Configuring Keychain Management, page 255

• Where to Go Next, page 258

• Field Descriptions for Keychain Management, page 259

• Additional References for Keychain Management, page 260

• Feature History for Keychain Management, page 260

Information About Keychain Management

Keychains and Keychain ManagementKeychain management allows you to create and maintain keychains, which are sequences of keys (sometimescalled shared secrets). You can use keychains with features that secure communications with other devicesby using key-based authentication. The device allows you to configure multiple keychains.

Some routing protocols that support key-based authentication can use a keychain to implement a hitless keyrollover for authentication. For more information, see the .


Lifetime of a KeyTomaintain stable communications, each device that uses a protocol that is secured by key-based authenticationmust be able to store and use more than one key for a feature at the same time. Based on the send and acceptlifetimes of a key, keychain management provides a secure mechanism to handle key rollover. The deviceuses the lifetimes of keys to determine which keys in a keychain are active.

Each key in a keychain has two lifetimes, as follows:

The time interval within which the device accepts the key during a keyexchange with another device.

Accept lifetime

The time interval within which the device sends the key during a key exchangewith another device.

Send lifetime

You define the send and accept lifetimes of a key using the following parameters:

The absolute time that the lifetime begins.Start-time

The end time can be defined in one of the following ways:End-time

• The absolute time that the lifetime ends

• The number of seconds after the start time that the lifetime ends

• Infinite lifetime (no end-time)

During a key send lifetime, the device sends routing update packets with the key. The device does not acceptcommunication from other devices when the key sent is not within the accept lifetime of the key on the device.

We recommend that you configure key lifetimes that overlap within every keychain. This practice avoidsfailure of neighbor authentication due to the absence of active keys.

Licensing Requirements for Keychain ManagementThis table shows the licensing requirements for keychain management.


Keychain management requires a LAN Enterpriselicense. For an explanation of the Cisco DCNM

Cisco DCNM

licensing scheme and how to obtain and applylicenses, see the Cisco DCNM Installation andLicensing Guide, Release 5.x.

Keychain management requires no license. Anyfeature not included in a license package is bundled

Cisco NX-OS

with the Cisco NX-OS system images and is providedat no extra charge to you. For an explanation of theCisco NX-OS licensing scheme for your platform,see the licensing guide for your platform.


Configuring Keychain ManagementLifetime of a Key

Platform Support for Keychain ManagementThe following platform supports this feature. For platform-specific information, including guidelines andlimitations, system defaults, and configuration limits, see the corresponding documentation.



Configuring Keychain Management

Creating a KeychainYou can create a keychain on the device. A new keychain contains no keys.

Procedure

Step 1 From the Feature Selector pane, choose Routing ➤ Gateway Redundancy ➤ Key Chain.The available devices appear in the Summary pane.

Step 2 From the Summary pane, click the device that you want to configure with a keychain.Step 3 From the menu bar, choose Actions ➤ Key Chain.

A new row appears in the Summary pane.

Step 4 Enter a name for the keychain. Valid keychain names are alphanumeric and can be up to 63 characters long.Step 5 (Optional) From the menu bar, choose File ➤ Deploy to apply your changes to the device.

Related Topics

• Configuring a Key, page 256

Removing a KeychainYou can remove a keychain on the device.

Removing a keychain removes any keys within the keychain.Note

Before You Begin

If you are removing a keychain, ensure that no feature uses it. If a feature is configured to use a keychain thatyou remove, that feature is likely to fail to communicate with other devices.


Configuring Keychain ManagementPlatform Support for Keychain Management


Procedure


Step 2 From the Summary pane, double-click the device that has a keychain that you want to delete.Keychains on the device appear in the Summary table.

Step 3 Click the keychain you want to delete.Step 4 From the menu bar, choose Actions ➤ Delete.

The keychain disappears from the Summary table.


Related Topics

• Creating a Keychain, page 255

Configuring a KeyYou can configure a key for a keychain. A new key contains no text (shared secret). The default accept andsend lifetimes for a new key are infinite.

Procedure


Step 2 From the Summary pane, double-click the device that you want to configure with a key.Keychains on the device appear in the Summary table.

Step 3 Double-click the keychain that you want to configure with a key.Step 4 (Optional) To create a new key, from the menu bar, choose Actions ➤ Key Chain Entry.

A new row appears below the keychain.

Step 5 Double-click theKey Chain Name/ID entry for the key that you want to configure. If you are creating a newkey, the entry is blank.

Step 6 Enter an identifier for the key. The identifier must be a whole number between 0 and 65535.Step 7 (Optional) From the menu bar, choose File ➤ Deploy to apply your changes to the device.

Related Topics

• Configuring Text for a Key, page 257• Configuring Accept and Send Lifetimes for a Key, page 257


Configuring Keychain ManagementConfiguring a Key

Configuring Text for a KeyYou can configure the text for a key. The text is the shared secret. The device stores the text in a secure format.

By default, accept and send lifetimes for a key are infinite, which means that the key is always valid. Afteryou configure the text for a key, configure the accept and send lifetimes for the key.

Before You Begin

Determine the text for the key. The text string can be up to 63 alphanumeric, case-sensitive characters, includingspecial characters.

Procedure


Step 2 From the Summary pane, double-click the device that has the key that you want to configure.Keychains on the device appear in the Summary table.

Step 3 Double-click the keychain that has the key that you want to configure.Keys in the keychain appear in the Summary table.

Step 4 Double-click the Key String entry for the key that you want to configure.The field becomes a drop-down list.

Step 5 Use the drop-down list to configure the text string, includingwhether the text string that you enter is unencryptedor encrypted. The text string can be up to 63 alphanumeric, case-sensitive characters. It also supports specialcharacters.


Configuring Accept and Send Lifetimes for a KeyYou can configure the accept lifetime and send lifetime for a key.

We recommend that you configure the keys in a keychain to have overlapping lifetimes. This practiceprevents loss of key-secured communication due to moments where no key is active.

Note

Before You Begin

By default, accept and send lifetimes for a key are infinite, which means that the key is always valid.

Procedure

Step 1 From the Feature Selector pane, choose Routing ➤ Gateway Redundancy ➤ Key Chain.


Configuring Keychain ManagementConfiguring Text for a Key


Step 2 From the Summary pane, double-click the device that has the key that you want to configure.Keychains on the device appear in the Summary table.

Step 3 Double-click the keychain that has the key that you want to configure.Keys in the keychain appear in the Summary table.

Step 4 Under Accept Life Time, double-click the Start entry for the key that you want to configure.The field becomes a drop-down list.

Step 5 Use the drop-down list to configure the start date and time for the accept lifetime.Step 6 Under Accept Life Time, double-click the End entry.

The field becomes a drop-down list.

Step 7 Use the drop-down list to configure when the accept lifetime ends.You can specify the end of the accept lifetime as a specific date and time, as the duration in seconds of thelifetime, or as unending (infinite).

Step 8 Under Send Life Time, double-click the Start entry for the key that you want to configure.The field becomes a drop-down list.

Step 9 Use the drop-down list to configure the start date and time for the send lifetime.Step 10 Under Send Life Time, double-click the End entry.

The field becomes a drop-down list.

Step 11 Use the drop-down list to configure when the send lifetime ends.You can specify the end of the send lifetime as a specific date and time, as the duration in seconds of thelifetime, or as unending (infinite).


Related Topics

• Lifetime of a Key, page 254

Where to Go NextFor information about routing features that use keychains, see the .


Configuring Keychain ManagementWhere to Go Next

Field Descriptions for Keychain Management

Keychain ObjectTable 82: Keychain Object

DescriptionField

Name assigned to the keychain. Valid names are 1 to63 alphanumeric characters.

Key Chain Name/ID

Keychain Entry ObjectTable 83: Keychain Entry Object

DescriptionField

Identification number assigned to the keychain. Valid identifier numbersare whole numbers from 0 to 65535.

Key Chain Name/ID

Text string that is the shared secret of the key. Entries in this field aremasked for security. Valid entries are alphanumeric, case-sensitive text

Key String

strings, including special characters. The minimum length is onecharacter. The maximum length is 63 characters.

Accept Life Time

Date and time, in UTC, that the accept lifetime becomes active. If youspecify no start date and time, the accept lifetime is always valid.

Start

When the accept lifetime becomes inactive. You can specify the end ofthe accept lifetime in one of the following ways:

End

• Specific—The date and time when the accept lifetime becomesinactive.

• Duration—The length in seconds of the accept lifetime. Themaximum length is 2147483646 seconds (approximately 68 years).

• Infinite—After the start time, the accept lifetime is always active.

Send Life Time

Date and time, in UTC, that the send lifetime becomes active. If youspecify no start date and time, the send lifetime is always active.

Start


Configuring Keychain ManagementField Descriptions for Keychain Management

DescriptionField

When the send lifetime becomes inactive. You can specify the end ofthe send lifetime in one of the following ways:

End

• Specific—The date and time when the send lifetime becomesinactive.

• Duration—The length in seconds of the send lifetime. Themaximum length is 2147483646 seconds (approximately 68 years).

• Infinite—After the start time, the send lifetime is always active.

Related FieldsFor information about fields that configure key chains, see the .

Additional References for Keychain ManagementRelated Documents


Gateway Load Balancing Protocol

Standards

TitleStandards


Feature History for Keychain ManagementThis table lists the release history for this feature.

Table 84: Feature History for Keychain Management


No change from Release 5.1.5.2(1)Keychain management




Configuring Keychain ManagementRelated Fields




Configuring Keychain ManagementFeature History for Keychain Management

C H A P T E R 17Configuring Traffic Storm Control

This chapter describes how to configure traffic storm control on the Cisco NX-OS device.


• Information About Traffic Storm Control, page 263

• Licensing Requirements for Traffic Storm Control, page 265

• Platform Support for Traffic Storm Control, page 265

• Configuring Traffic Storm Control, page 265

• Displaying Traffic Storm Control Statistics, page 266

• Field Descriptions for Traffic Storm Control, page 266

• Additional References for Traffic Storm Control, page 268

• Feature History for Traffic Storm Control, page 268

Information About Traffic Storm ControlA traffic storm occurs when packets flood the LAN, creating excessive traffic and degrading networkperformance. You can use the traffic storm control feature to prevent disruptions on Layer 2 ports by abroadcast, multicast, or unicast traffic storm on physical interfaces.

Traffic storm control (also called traffic suppression) allows you tomonitor the levels of the incoming broadcast,multicast, and unicast traffic over a 10-millisecond interval. During this interval, the traffic level, which is apercentage of the total available bandwidth of the port, is compared with the traffic storm control level thatyou configured. When the ingress traffic reaches the traffic storm control level that is configured on the port,traffic storm control drops the traffic until the interval ends.


This table shows the broadcast traffic patterns on a Layer 2 interface over a given interval. In this example,traffic storm control occurs between times T1 and T2 and between T4 and T5. During those intervals, theamount of broadcast traffic exceeded the configured threshold.

Figure 36: Broadcast Suppression

The traffic storm control threshold numbers and the time interval allow the traffic storm control algorithm towork with different levels of granularity. A higher threshold allows more packets to pass through.

Traffic storm control on the Cisco NX-OS device is implemented in the hardware. The traffic storm controlcircuitry monitors packets that pass from a Layer 2 interface to the switching bus. Using the Individual/Groupbit in the packet destination address, the circuitry determines if the packet is unicast or broadcast, tracks thecurrent count of packets within the 10-millisecond interval, and filters out subsequent packets when a thresholdis reached.

Traffic storm control uses a bandwidth-based method to measure traffic. You set the percentage of totalavailable bandwidth that the controlled traffic can use. Because packets do not arrive at uniform intervals, the10-millisecond interval can affect the behavior of traffic storm control.

The following are examples of traffic storm control behavior:

• If you enable broadcast traffic storm control, and broadcast traffic exceeds the level within the10-millisecond interval, traffic storm control drops all broadcast traffic until the end of the interval.

• If you enable broadcast and multicast traffic storm control, and the combined broadcast and multicasttraffic exceeds the level within the 10-millisecond interval, traffic storm control drops all broadcast andmulticast traffic until the end of the interval.

• If you enable broadcast and multicast traffic storm control, and broadcast traffic exceeds the level withinthe 10-millisecond interval, traffic storm control drops all broadcast and multicast traffic until the endof the interval.

• If you enable broadcast and multicast traffic storm control, and multicast traffic exceeds the level withinthe 10-millisecond interval, traffic storm control drops all broadcast and multicast traffic until the endof the interval.

By default, the Cisco NX-OS software takes no corrective action when the traffic exceeds the configuredlevel. However, you can configure an Embedded EventManagement (EEM) action to error-disable an interfaceif the traffic does not subside (drop below the threshold) within a certain time period. For information onconfiguring EEM, see the .


Configuring Traffic Storm ControlInformation About Traffic Storm Control

Licensing Requirements for Traffic Storm ControlThe following table shows the licensing requirements for this feature:


Traffic storm control requires a LAN Enterpriselicense. For an explanation of the Cisco DCNM

Cisco DCNM

licensing scheme and how to obtain and applylicenses, see the Cisco DCNM Installation andLicensing Guide, Release 5.x.

Traffic storm control requires no license. Any featurenot included in a license package is bundled with the

Cisco NX-OS


Platform Support for Traffic Storm ControlThe following platforms support this feature but may implement it differently. For platform-specific information,including guidelines and limitations, system defaults, and configuration limits, see the correspondingdocumentation.






Configuring Traffic Storm ControlYou can set the percentage of total available bandwidth that the controlled traffic can use.

Traffic storm control uses a 10-millisecond interval that can affect the behavior of traffic storm control.Note


Configuring Traffic Storm ControlLicensing Requirements for Traffic Storm Control





Procedure

Step 1 From the Feature Selector pane, choose Switching > Layer 2 Security > Traffic Storm Control.Step 2 Double-click on the device to display the list of interface types.Step 3 Double-click the Physical Interfaces to display the physical slots or double-click the Port-Channel interfaces

to display the port-channel interfaces.Step 4 (Optional) Double-click the slot to display the physical interfaces.Step 5 Click the interface.Step 6 From the Details pane, click the Interface Configuration tab.Step 7 Click the desired traffic type check boxes.

To apply traffic storm control for broadcast, multicast, and unicast traffic types, check the All checkbox.

Tip

Step 8 In the Threshold field, enter a traffic suppression level percentage.Step 9 From the menu bar, click File > Deploy to apply your changes to the device.

Displaying Traffic Storm Control StatisticsYou can display the statistics the Cisco NX-OS device maintains for traffic storm control activity.

Procedure

Step 1 From the Feature Selector pane, choose Switching > Layer 2 Security > Traffic Storm Control.Step 2 Double-click on the device to display the list of interface types.Step 3 Double-click the Physical Interfaces to display the physical slots or double-click the Port-Channel interfaces

to display the port-channel interfaces.Step 4 Double-click the slot to display the physical interfaces.Step 5 Click the interface.Step 6 From the Details pane, click the Statistics tab to display traffic storm control statistics for the interface.

Field Descriptions for Traffic Storm ControlThis section includes the field descriptions for the traffic storm control feature in Cisco DCNM.


Configuring Traffic Storm ControlDisplaying Traffic Storm Control Statistics

Switching: Traffic Storm Control: Summary PaneTable 85: Switching: Traffic Storm Control: Summary Pane

DescriptionElement


Check box to enable or disable unicast traffic control.Unicast Control

Check box to enable or disable multicast trafficcontrol.

Multicast Control

Check box to enable or disable broadcast trafficcontrol.

Broadcast Control

Check box to enable or disable unicast, multicast, andbroadcast traffic control.

All

Interface bandwidth in bits per second.Bandwidth(bps)

Traffic-storm control threshold percentage for theselected traffic. The default is 100 percent.

Threshold

Switching: Traffic Storm Control: device: interface type: interface: InterfaceConfiguration Tab

Table 86: Switching: Traffic Storm Control: device: interface type: interface: Interface Configuration Tab

DescriptionElement


Interface description.Description

Traffic-storm control threshold percentage for theselected traffic. The default is 100 percent.

Threshold

Interface bandwidth in bits per second.Bandwidth(bps)

Check box to enable or disable unicast, multicast, andbroadcast traffic control.

All

Check box to enable or disable unicast traffic control.Unicast Control

Check box to enable or disable multicast trafficcontrol.

Multicast Control


Configuring Traffic Storm ControlSwitching: Traffic Storm Control: Summary Pane

DescriptionElement

Check box to enable or disable broadcast trafficcontrol.

Broadcast Control

Additional References for Traffic Storm ControlThis section includes additional information related to implementing traffic storm control.

Related Documents





Feature History for Traffic Storm ControlThis table lists the release history for this feature.

Table 87: Feature History for Traffic Storm Control



5.2(1)Traffic storm control

No change from Release 5.0.5.1(1)Traffic storm control




Configuring Traffic Storm ControlAdditional References for Traffic Storm Control

I N D E X

802.1Xconfiguration process 119configuring 119configuring AAA accounting methods 128controlling on interfaces 120description 5, 111disabling authenticaiton 125disabling feature 126enabling global periodic reauthentication 121enabling MAC address authentication bypass 125enabling mulitple hosts mode 124enabling on interfaces 120enabling periodic reauthentication on interfaces 121enabling service 119enabling single host mode 124field descriptions 130licensing requirements 118MAC authenication bypass 115multiple host support 117platform support 119prerequisites 118setting global maximum retransmission retry count 127setting interface maximum retransmission retry count 127single host support 117supported topologies 117

802.1X authenticationauthorization states for ports 114changing global timers 122changing timers on interfaces 123enabling RADIUS accounting 128initiation 113

802.1X reauthenticationsetting maximum retry count on interfaces 129

802.1X statisticsdisplaying 130

A

AAA 3, 23, 24, 26, 27, 28, 32, 37, 65accounting 23authentication 23

AAA (continued)authorization 23benefits 24configuring 28description 3, 23enabling or disabling MSCHAP authentication 32enabling or disabling MSCHAP V2 authentication 32field descriptions 37licensing requirements 27monitoring TACACS+ servers 65platform support 27prerequisites 27user login process 26

AAA accountingadding rule methods 34changing rule methods 33configuring methods for 802.1X 128deleting rule methods 35rearranging rule methods 35

AAA authenticationadding a rule method 28changing rule methods 28deleting rule methods 30enabling or disabling 32enabling or disabling default user roles 31enabling or disabling login authentication failure messages 31rearranging rule methods 29

AAA protocolsRADIUS 23TACACS+ 23

AAA server groups 25description 25

AAA serversFreeRADIUS VSA format 43specifying SNMPv3 parameters 36, 37specifying user roles 37specifying user roles in VSAs 36

AAA servicesconfiguration options 25remote 24security 23

access control lists 135, 136, 137

Security Configuration Guide, Cisco DCNM for LAN, Release 5.x OL-20638-03 IN-1

access control lists (continued)See also ARP ACLsdescription 135order of application 137types of 136

See also ARP ACLsaccounting

description 23ARP ACLs 135, 231, 232, 239

description 239platform support 232priority of ARP ACLs and DHCP snooping entries 231

ARP inspection, See dynamic ARP inspectionauthentication

802.1X 113description 23methods 25user logins 26

authentication, authorization, and accounting, See AAAauthorization

description 23user logins 26

B

broadcast storms., See traffic storm control

C

CFSTACACS+ support 66

changed informationdescription 1

Ciscovendor ID 36, 43

cisco-av-pairspecifying AAA user parameters 36, 37

D

DAIdescription 6platform support 232

device rolesdescription for 802.1X 111

DHCP 209, 214description 209platform support 214

DHCP binding database, See DHCP snooping binding database

DHCP Option 82description 211

DHCP snoopingbinding database 210description 6message exchange process 211Option 82 211overview 209

DHCP snooping binding database 210See also DHCP snooping binding databasedescribed 210description 210entries 210

See also DHCP snooping binding databasedocumentation

additional publications xviiidynamic ARP inspection 227, 228, 229, 231

ARP cache poisoning 228ARP requests 228ARP spoofing attack 228description 227DHCP snooping binding database 229function of 229interface trust states 229logging of dropped packets 231network security issues and interface trust states 229priority of ARP ACLs and DHCP snooping entries 231

Dynamic Host Configuration Protocol, See DHCP

F

field descriptions802.1X 130AAA 37Security Audit Wizard 18TACACS+ 81

fields descriptionsRADIUS 57

FreeRADIUSVSA format for role attributes 36, 43

G

global source interfaceconfiguring for RADIUS server groups 51configuring for TACACS+ server groups 75

Security Configuration Guide, Cisco DCNM for LAN, Release 5.xIN-2 OL-20638-03

Index

I

IDsCisco vendor ID 36, 43

interface policieschanging in user roles 103

IP ACLs 5, 135, 143, 144, 145configuring 145description 5, 135licensing 143platform support 144

IP source guardplatform support 249

IP Source Guarddescription 7, 247

K

key chainend-time 254lifetime 254start-time 254

keychain managementdescription 7, 253platform support 255

keysTACACS+ 65

L

Layer 2 securityconfiguring using the Security Audit Wizard 10

licensing802.1X 118AAA 27IP ACLs 143RADIUS 44roles 89Security Audit Wizard 9TACACS+ 67traffic storm control 265user accounts 89

login authentication failure messagesenabling or disabling 31

M

MAC ACLs 5, 135, 169, 170description 5, 169platform support 170

MAC addressesenabling authentication bypass in 802.1X 125

MAC authenticationbypass for 802.1X 115

MSCHAPenabling or disabling authentication 32

MSCHAP V2enabling or disabling authentication 32

multicast storms., See traffic storm control

N

network-admin user role 88description 88

network-operator user roledescription 88

new informationdescription 1

O

object groupsconfiguring 162

P

passwordschanging for user accounts 93strong characteristics 88

port ACLs 135, 136definition 136

port securitydescription 6, 187MAC move 190platform support 195violations 190

portsauthorization states for 802.1X 114

R

RADIUSconfiguring dead-time intervals 56configuring global transmission retry count 53configuring global transmission timeout interval 53configuring servers 45description 4, 41field descriptions 57licensing 44


Index

RADIUS (continued)network environments 41operation 42platform support 45prerequisites 45process for configuring 45VSAs 43

RADIUS accountingenabling for 802.1X authentication 128

RADIUS server groupconfiguring a source interface 52

RADIUS server groupsadding 49adding server hosts 50configuring the global source interface 51deleting 51

RADIUS server hostscopying 47

RADIUS serversadding 46adding to server groups 50allowing specifying at login 53configuring accounting attributes 55configuring authentication attributes 55configuring global keys 48configuring periodic monitoring 55configuring transminssion timeout intervals 54configuring transmission retry counts 54deleting 47displaying statistics 57monitoring 42

RBACdescription 5, 88field descriptions 106

related documents xviiiroles

deleting from user accounts 96licensing 89

router ACLs 135, 136definition 136

rulesadding to roles 99changing 100changing VRF policies 105deleting 102rearranging 101

rules., See user role rules

S

Security Audit Wizarddescription 9

Security Audit Wizard (continued)field descriptions 18licensing requirements 9platform support 10prerequisites 10using to configure Layer 2 security 10

server groups., See AAA server groupsSNMPv3

specifying AAA parameters 36specifying parameters for AAA servers 37

source interfaceconfiguring for a specific RADIUS server group 52configuring for a specific TACACS+ server group 76

statisticsdisplaying for TACACS+ 80

superuser role., See network-admin user role

T

TACACS+advantages over RADIUS 64configuration distribution 66configuration process 69configuring 68configuring dead-time intervals 79configuring global keys 72configuring global timeout interval 77configuring TCP ports 78description 4, 63disabling 80enabling 69field descriptions 81keys 65licensing requirements 67platform support 68prerequisites 68user login operation 64VSAs 66

TACACS+ groupsadding 73adding servers 74deleting 75deleting servers 74

TACACS+ server groupconfiguring a source interface 76

TACACS+ server groupsconfiguring global source interface 75

TACACS+ server hostscopying 70

TACACS+ serversadding 69adding to groups 74


Index

TACACS+ servers (continued)configuring keys 72configuring periodic monitoring 79configuring timeout intervals 77deleting from groups 74field descriptions 81hosts 71monitoring 65

TACACS+ statisticsdisplaying 80

TCP portsconfiguring for TACACS+ 78

time rangedescription 164

time rangesabsolute 141configuring 164description 141field descriptions 167periodic 141

traffic storm control 7, 263, 265, 266description 7, 263displaying statistics 266field descriptions 266licensing 265platform support 265

U

unicast storms., See traffic storm controluser accounts

changing expiry date 94changing passwords 93configuring 90copying 93creating 90deleting 97deleting roles 96description 87licensing 89password characteristics 88

user accounts and RBACplatform support 90

user loginsauthentication process 26authorization process 26

user role rules 89description 89

user rolesadding rules 99changing interface policies 103changing rules 100changing VLAN policies 104configuring 98copying 99creating 98defaults 88deleting rules 102description 88rearranging rules 101specifying on AAA servers 36, 37

V

VACLsdescription 6platform support 180

vdc-admin user roledescription 88

vdc-operator user roledescription 88

vendor-specific attributes., See VSAsVLAN ACLs 135, 136, 179

definition 136description 179

VLAN policieschanging in user roles 104

VRF policieschanging in user roles 105

VSAs 36, 43, 67format 36protocol options 36, 43, 67support description 36


Index


Index