Short Description

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: https://www.cisco.com/c/en/us/about/legal/trademarks.html. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1721R)

Chapter 1. Preventing Unauthorized Access

- Finding Feature Information

- Preventing Unauthorized Access

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.

Preventing Unauthorized Access

You can prevent unauthorized users from reconfiguring your switch and viewing configuration information. Typically, you want network administrators to have access to your switch while you restrict access to users who dial from outside the network through an asynchronous port, connect from outside the network through a serial port, or connect through a terminal or workstation from within the local network.

To prevent unauthorized access into your switch, you should configure one or more of these security features:

- At a minimum, you should configure passwords and privileges at each switch port. These passwords are locally stored on the switch. When users attempt to access the switch through a port or line, they must enter the password specified for the port or line before they can access the switch.

- For an additional layer of security, you can also configure username and password pairs, which are locally stored on the switch. These pairs are assigned to lines or ports and authenticate each user before that user can access the switch. If you have defined privilege levels, you can also assign a specific privilege level (with associated rights and privileges) to each username and password pair.

- If you want to use username and password pairs, but you want to store them centrally on a server instead of locally, you can store them in a database on a security server. Multiple networking devices can then use the same database to obtain user authentication (and, if necessary, authorization) information.

- You can also enable the login enhancements feature, which logs both failed and unsuccessful login attempts. Login enhancements can also be configured to block future login attempts after a set number of unsuccessful attempts are made. For more information, see the Cisco IOS Login Enhancements documentation.

Chapter 2. Controlling Switch Access with Passwords and Privilege Levels

- Restrictions for Controlling Switch Access with Passwords and Privileges

- Monitoring Switch Access

- Configuration Examples for Setting Passwords and Privilege Levels

- Additional References

Restrictions for Controlling Switch Access with Passwords and Privileges

The following are the restrictions for controlling switch access with passwords and privileges:

- Disabling password recovery will not work if you have set the switch to boot up manually by using the boot manual global configuration command. This command produces the boot loader prompt (switch:) after the switch is power cycled.

- Restrictions and Guidelines for Reversible Password Types

- Restrictions and Guidelines for Irreversible Password Types

Restrictions and Guidelines for Reversible Password Types

- Password type 0 and type 7 are deprecated. So password type 0 and type 7, used for administrator login to Console, Telnet, SSH, webUI, and NETCONF, must be migrated to password type 8 or type 9.

- No action is required if username and password are type 0 and type 7 for local authentication such as CHAP, EAP and so on for ISG and Dot1x.

- Enable password type 0 and type 7 must be migrated to password type 8 or type 9.

- Type 6 encrypted password is supported for username and password. Auto-conversion of password type 0 and password type 7 to password type 6 is also supported.

Restrictions and Guidelines for Irreversible Password Types

- Password type 5 is deprecated. Password type 5 must be migrated to stronger password type 8 or type 9.

- For username secret password type 5 and for enable secret password type 5, migrate to type 8 or type 9.

- Plain text passwords are converted to non-reversible encrypted password type 9.

- Secret password type 4 is not supported.

Default Password and Privilege Level Configuration

A simple way of providing terminal access control in your network is to use passwords and assign privilege levels. Password protection restricts access to a network or network device. Privilege levels define what commands users can enter after they have logged into a network device.

This table shows the default password and privilege level configuration.

Default Password and Privilege Levels

Feature

Default Setting

Enable password and privilege level

No password is defined. The default is level 15 (privileged EXEC level). The password is not encrypted in the configuration file.

Enable secret password and privilege level

No password is defined. The default is level 15 (privileged EXEC level). The password is encrypted before it is written to the configuration file.

Line password

No password is defined.

Additional Password Security

To provide an additional layer of security, particularly for passwords that cross the network or that are stored on a Trivial File Transfer Protocol (TFTP) server, you can use either the enable password or enable secret global configuration commands. Both commands accomplish the same thing; that is, you can establish an encrypted password that users must enter to access privileged EXEC mode (the default) or any privilege level you specify.

We recommend that you use the enable secret command because it uses an improved encryption algorithm.

If you configure the enable secret command, it takes precedence over the enable password command; the two commands cannot be in effect simultaneously.

If you enable password encryption, it applies to all passwords including username passwords, authentication key passwords, the privileged command password, and console and virtual terminal line passwords.

Password Recovery

By default, any end user with physical access to the switch can recover from a lost password by interrupting the boot process while the switch is powering on and then by entering a new password.

The password-recovery disable feature protects access to the switch password by disabling part of this functionality. When this feature is enabled, the end user can interrupt the boot process only by agreeing to set the system back to the default configuration. With password recovery disabled, you can still interrupt the boot process and change the password, but the configuration file (config.text) and the VLAN database file (vlan.dat) are deleted.

If you disable password recovery, we recommend that you keep a backup copy of the configuration file on a secure server in case the end user interrupts the boot process and sets the system back to default values. Do not keep a backup copy of the configuration file on the switch. If the switch is operating in VTP transparent mode, we recommend that you also keep a backup copy of the VLAN database file on a secure server. When the switch is returned to the default system configuration, you can download the saved files to the switch by using the Xmodem protocol.

To re-enable password recovery, use the service password-recovery global configuration command.

Terminal Line Telnet Configuration

When you power-up your switch for the first time, an automatic setup program runs to assign IP information and to create a default configuration for continued use. The setup program also prompts you to configure your switch for Telnet access through a password. If you did not configure this password during the setup program, you can configure it when you set a Telnet password for a terminal line.

Username and Password Pairs

You can configure username and password pairs, which are locally stored on the switch. These pairs are assigned to lines or ports and authenticate each user before that user can access the switch. If you have defined privilege levels, you can also assign a specific privilege level (with associated rights and privileges) to each username and password pair.

Privilege Levels

Cisco devices use privilege levels to provide password security for different levels of switch operation. By default, the Cisco IOS software operates in two modes (privilege levels) of password security: user EXEC (Level 1) and privileged EXEC (Level 15). You can configure up to 16 hierarchical levels of commands for each mode. By configuring multiple passwords, you can allow different sets of users to have access to specified commands.

Privilege Levels on Lines

Users can override the privilege level you set using the privilege level line configuration command by logging in to the line and enabling a different privilege level. They can lower the privilege level by using the disable command. If users know the password to a higher privilege level, they can use that password to enable the higher privilege level. You might specify a high level or privilege level for your console line to restrict line usage.

For example, if you want many users to have access to the clear line command, you can assign it level 2 security and distribute the level 2 password fairly widely. But if you want more restricted access to the configure command, you can assign it level 3 security and distribute that password to a more restricted group of users.

Command Privilege Levels

When you set a command to a privilege level, all commands whose syntax is a subset of that command are also set to that level. For example, if you set the show ip traffic command to level 15, the show commands and show ip commands are automatically set to privilege level 15 unless you set them individually to different levels.

AES Password Encryption and Master Encryption Keys

You can enable strong, reversible 128-bit Advanced Encryption Standard (AES) password encryption, also known as type-6 encryption. To start using type-6 encryption, you must enable the AES password encryption feature and configure a master encryption key, which is used to encrypt and decrypt passwords.

After you enable AES password encryption and configure a master key, all existing and newly created clear-text passwords for supported applications are stored in type-6 encrypted format, unless you disable type-6 password encryption. You can also configure the device to convert all existing weakly encrypted passwords to type-6 encrypted passwords.

Type 0 and type 7 passwords can be autoconverted to type 6 if the AES password encryption feature and master encryption key are configured.

Note

Type 6 username and password are backward compatible to Cisco IOS XE Gibraltar 16.10.x. If you downgrade to any release version lower than Cisco IOS XE Gibraltar 16.10.1, type 6 username and password will be rejected. After autoconversion, to avoid an administrator password getting rejected during a downgrade, migrate the passwords used for administrator logins (management access) to irreversible password types manually.

Setting or Changing a Static Enable Password

The enable password controls access to the privileged EXEC mode. Follow these steps to set or change a static enable password:

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

enable password password

Example:

Device(config)# enable password secret321

Defines a new password or changes an existing password for access to privileged EXEC mode.

By default, no password is defined.

For password , specify a string from 1 to 25 alphanumeric characters. The string cannot start with a number, is case sensitive, and allows spaces but ignores leading spaces. It can contain the question mark (?) character if you precede the question mark with the key combination Crtl-v when you create the password; for example, to create the password abc?123, do this:

1. Enter abc.

2. Enter Crtl-v.

3. Enter ?123.

When the system prompts you to enter the enable password, you need not precede the question mark with the Ctrl-v; you can simply enter abc?123 at the password prompt.

Step 4

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 5

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 6

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Protecting Enable and Enable Secret Passwords with Encryption

Follow these steps to establish an encrypted password that users must enter to access privileged EXEC mode (the default) or any privilege level you specify:

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

Use one of the following:

- enable password [level level] {password | encryption-type encrypted-password}

- enable secret [level level] {password | encryption-type encrypted-password}

Example:

Device(config)# enable password example102

or

Device(config)# enable secret level 1 password secret123sample

- Defines a new password or changes an existing password for access to privileged EXEC mode.

- Defines a secret password, which is saved using a nonreversible encryption method.

- (Optional) For level , the range is from 0 to 15. Level 1 is normal user EXEC mode privileges. The default level is 15 (privileged EXEC mode privileges).

- For password , specify a string from 1 to 25 alphanumeric characters. The string cannot start with a number, is case sensitive, and allows spaces but ignores leading spaces. By default, no password is defined.

- (Optional) For encryption-type , the available options for enable password are type 0 and type 7, and type 0, type 5, type 8, and type 9 for enable secret. If you specify an encryption type, you must provide an encrypted password—an encrypted password that you copy from another switch configuration.

Note

If you specify an encryption type and then enter a clear text password, you can not re-enter privileged EXEC mode. You cannot recover a lost encrypted password by any method.

Step 4

service password-encryption

Example:

Device(config)# service password-encryption

(Optional) Encrypts the password when the password is defined or when the configuration is written.

Encryption prevents the password from being readable in the configuration file.

Step 5

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 6

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 7

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Disabling Password Recovery

Follow these steps to disable password recovery to protect the security of your switch:

Before you begin

If you disable password recovery, we recommend that you keep a backup copy of the configuration file on a secure server in case the end user interrupts the boot process and sets the system back to default values. Do not keep a backup copy of the configuration file on the switch. If the switch is operating in VTP transparent mode, we recommend that you also keep a backup copy of the VLAN database file on a secure server. When the switch is returned to the default system configuration, you can download the saved files to the switch by using the Xmodem protocol.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

system disable password recovery switch {all | <1-9> }

Example:

Device(config)# system disable password recovery switch all

Disables password recovery.

- all - Sets the configuration on switches in stack.

- <1-9> - Sets the configuration on the Switch Number selected.

This setting is saved in an area of the flash memory that is accessible by the boot loader and the Cisco IOS image, but it is not part of the file system and is not accessible by any user.

Step 4

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

What to do next

To remove disable password recovery , use the no system disable password recovery switch all global configuration command.

Setting a Telnet Password for a Terminal Line

Beginning in user EXEC mode, follow these steps to set a Telnet password for the connected terminal line:

Before you begin

- Attach a PC or workstation with emulation software to the switch console port, or attach a PC to the Ethernet management port.

- The default data characteristics of the console port are 9600, 8, 1, no parity. You might need to press the Return key several times to see the command-line prompt.

Procedure

Step 1

enable

Example:

Device> enable

Note

If a password is required for access to privileged EXEC mode, you will be prompted for it.

Enters privileged EXEC mode.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

line vty 0 15

Example:

Device(config)# line vty 0 15

Configures the number of Telnet sessions (lines), and enters line configuration mode.

There are 16 possible sessions on a command-capable Device. The 0 and 15 mean that you are configuring all 16 possible Telnet sessions.

Step 4

password password

Example:

Device(config-line)# password abcxyz543

Sets a Telnet password for the line or lines.

For password , specify a string from 1 to 25 alphanumeric characters. The string cannot start with a number, is case sensitive, and allows spaces but ignores leading spaces. By default, no password is defined.

Step 5

end

Example:

Device(config-line)# end

Returns to privileged EXEC mode.

Step 6

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 7

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Configuring Username and Password Pairs

Follow these steps to configure username and password pairs:

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

username name [privilege level] {password encryption-type password}

Example:

Device(config)# username adamsample privilege 1 password secret456

Device(config)# username 111111111111 mac attribute

Sets the username, privilege level, and password for each user.

- For name , specify the user ID as one word or the MAC address. Spaces and quotation marks are not allowed.

- You can configure a maximum of 12000 clients each, for both username and MAC filter.

- (Optional) For level , specify the privilege level the user has after gaining access. The range is 0 to 15. Level 15 gives privileged EXEC mode access. Level 1 gives user EXEC mode access.

- For encryption-type , enter 0 to specify that an unencrypted password will follow. Enter 7 to specify that a hidden password will follow. Enter 6 to specify an encrypted password will follow.

- For password , specify the password the user must enter to gain access to the device. The password must be from 1 to 25 characters, can contain embedded spaces, and must be the last option specified in the username command.

Step 4

Use one of the following:

- line console 0

- line vty 0 15

Example:

Device(config)# line console 0

or

Device(config)# line vty 15

Enters line configuration mode, and configures the console port (line 0) or the VTY lines (line 0 to 15).

Step 5

login local

Example:

Device(config-line)# login local

Enables local password checking at login time. Authentication is based on the username specified in Step 3.

Step 6

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 7

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 8

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Setting the Privilege Level for a Command

Follow these steps to set the privilege level for a command:

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

privilege mode level level command

Example:

Device(config)# privilege exec level 14 configure

Sets the privilege level for a command.

- For mode , enter configure for global configuration mode, exec for EXEC mode, interface for interface configuration mode, or line for line configuration mode.

- For level , the range is from 0 to 15. Level 1 is for normal user EXEC mode privileges. Level 15 is the level of access permitted by the enable password.

- For command , specify the command to which you want to restrict access.

Step 4

enable password level level password

Example:

Device(config)# enable password level 14 SecretPswd14

Specifies the password to enable the privilege level.

- For level , the range is from 0 to 15. Level 1 is for normal user EXEC mode privileges.

- For password , specify a string from 1 to 25 alphanumeric characters. The string cannot start with a number, is case sensitive, and allows spaces but ignores leading spaces. By default, no password is defined.

Step 5

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 6

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Changing the Default Privilege Level for Lines

Follow these steps to change the default privilege level for the specified line:

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

line vty line

Example:

Device(config)# line vty 10

Selects the virtual terminal line on which to restrict access.

Step 4

privilege level level

Example:

Device(config)# privilege level 15

Changes the default privilege level for the line.

For level , the range is from 0 to 15. Level 1 is for normal user EXEC mode privileges. Level 15 is the level of access permitted by the enable password.

Step 5

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 6

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

What to do next

Users can override the privilege level you set using the privilege level line configuration command by logging in to the line and enabling a different privilege level. They can lower the privilege level by using the disable command. If users know the password to a higher privilege level, they can use that password to enable the higher privilege level. You might specify a high level or privilege level for your console line to restrict line usage.

Logging into and Exiting a Privilege Level

Beginning in user EXEC mode, follow these steps to log into a specified privilege level and exit a specified privilege level.

Procedure

Step 1

enable level

Example:

Device> enable 15

Logs in to a specified privilege level.

Following the example, Level 15 is privileged EXEC mode.

For level , the range is 0 to 15.

Step 2

disable level

Example:

Device# disable 1

Exits to a specified privilege level.

Following the example, Level 1 is user EXEC mode.

For level , the range is 0 to 15.

Configuring an Encrypted Preshared Key

To configure an encrypted preshared key, perform the following steps.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

key config-key password-encrypt [text]

Example:

Device(config)# key config-key password-encrypt

Stores a type 6 encryption key in private NVRAM.

- If you want to key in interactively (using the enter key) and an encrypted key already exists, you will be prompted for the following: Old key, New key, and Confirm key.

- If you want to key in interactively but an encryption key is not present, you will be prompted for the following: New key and Confirm key.

- If you want to remove the password that is already encrypted, you will see the following prompt: "WARNING: All type 6 encrypted keys will become unusable. Continue with master key deletion? [yes/no]:".

Step 4

password encryption aes

Example:

Device(config)# password encryption aes

Enables the encrypted preshared key.

Step 5

end

Example:

Device(config)# end

Exits global configuration mode and returns to privileged EXEC mode.

Monitoring Switch Access

Commands for Displaying DHCP Information

show privilege

Displays the privilege level configuration.

Configuration Examples for Setting Passwords and Privilege Levels

- Example: Setting or Changing a Static Enable Password

- Example: Protecting Enable and Enable Secret Passwords with Encryption

- Example: Setting a Telnet Password for a Terminal Line

- Example: Setting the Privilege Level for a Command

- Example: Configuring an Encrypted Preshared Key

Example: Setting or Changing a Static Enable Password

This example shows how to change the enable password to l1u2c3k4y5. The password is not encrypted and provides access to level 15 (traditional privileged EXEC mode access):

Device(config)# enable password l1u2c3k4y5

Example: Protecting Enable and Enable Secret Passwords with Encryption

This example shows how to configure the encrypted password $1$FaD0$Xyti5Rkls3LoyxzS8 for privilege level 2:

Device(config)# enable secret level 2 5 $1$FaD0$Xyti5Rkls3LoyxzS8

Example: Setting a Telnet Password for a Terminal Line

This example shows how to set the Telnet password to let45me67in89:

Device(config)# line vty 10
Device(config-line)# password let45me67in89

Example: Setting the Privilege Level for a Command

This example shows how to set the configure command to privilege level 14 and define SecretPswd14 as the password users must enter to use level 14 commands:

Device(config)# privilege exec level 14 configure
Device(config)# enable password level 14 SecretPswd14

Example: Configuring an Encrypted Preshared Key

The following is an example of a configuration for which a type 6 preshared key has been encrypted. It includes the prompts and messages that a user might see.

Device> enable
Device# configure terminal
Device(config)# password encryption aes
Device(config)# key config-key password-encrypt
New key:
Confirm key:
Device(config)#
01:46:40: TYPE6_PASS: New Master key configured, encrypting the keys with
the new master key
Device(config)# end

Additional References

Error Message Decoder

Description

Link

To help you research and resolve system error messages in this release, use the Error Message Decoder tool.

https://www.cisco.com/cgi-bin/Support/Errordecoder/index.cgi

MIBs

MIB

MIBs Link

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

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

Technical Assistance

Description

Link

The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies.

To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.

Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.

http://www.cisco.com/support

Chapter 3. Configuring TACACS+

- Prerequisites for TACACS+

- How to Configure Switch Access with TACACS+

- Monitoring TACACS+

- Additional References For Switch Access with TACACS+

- Feature Information for Switch Access with TACACS+

Prerequisites for TACACS+

The following are the prerequisites for set up and configuration of switch access with TACACS+ (must be performed in the order presented):

1. Configure the switches with the TACACS+ server addresses.

2. Set an authentication key.

3. Configure the key from Step 2 on the TACACS+ servers.

4. Enable authentication, authorization, and accounting (AAA).

5. Create a login authentication method list.

6. Apply the list to the terminal lines.

7. Create an authorization and accounting method list.

The following are the prerequisites for controlling switch access with TACACS+:

- You must have access to a configured TACACS+ server to configure TACACS+ features on your switch. Also, you must have access to TACACS+ services maintained in a database on a TACACS+ daemon typically running on a LINUX or Windows workstation.

- We recommend a redundant connection between a switch stack and the TACACS+ server. This is to help ensure that the TACACS+ server remains accessible in case one of the connected stack members is removed from the switch stack.

- You need a system running the TACACS+ daemon software to use TACACS+ on your switch.

- To use TACACS+, it must be enabled.

- Authorization must be enabled on the switch to be used.

- Users must first successfully complete TACACS+ authentication before proceeding to TACACS+ authorization.

- To use any of the AAA commands listed in this section or elsewhere, you must first enable AAA with the aaa new-model command.

- At a minimum, you must identify the host or hosts maintaining the TACACS+ daemon and define the method lists for TACACS+ authentication. You can optionally define method lists for TACACS+ authorization and accounting.

- The method list defines the types of authentication to be performed and the sequence in which they are performed; it must be applied to a specific port before any of the defined authentication methods are performed. The only exception is the default method list (which, by coincidence, is named default ). The default method list is automatically applied to all ports except those that have a named method list explicitly defined. A defined method list overrides the default method list.

- Use TACACS+ for privileged EXEC access authorization if authentication was performed by using TACACS+.

- Use the local database if authentication was not performed by using TACACS+.

TACACS+ and Switch Access

This section describes TACACS+. TACACS+ provides detailed accounting information and flexible administrative control over the authentication and authorization processes. It is facilitated through authentication, authorization, accounting (AAA) and can be enabled only through AAA commands.

TACACS+ Overview

TACACS+ is a security application that provides centralized validation of users attempting to gain access to your switch.

TACACS+ provides for separate and modular authentication, authorization, and accounting facilities. TACACS+ allows for 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 advantage of other services available on that server or on the network, depending on the capabilities of the daemon.

The goal of TACACS+ is to provide a method for managing multiple network access points from a single management service. Your switch can be a network access server along with other Cisco routers and access servers.

Typical TACACS+ Network Configuration

TACACS+, administered through the AAA security services, can provide these services:

- Authentication—Provides complete control of authentication through login and password dialog, challenge and response, and messaging support.

The authentication facility can conduct a dialog with the user (for example, after a username and password are provided, to challenge a user with several questions, such as home address, mother’s maiden name, service type, and social security number). The TACACS+ authentication service can also send messages to user screens. For example, a message could notify users that their passwords must be changed because of the company’s password aging policy.

- Authorization—Provides fine-grained control over user capabilities for the duration of the user’s session, including but not limited to setting autocommands, access control, session duration, or protocol support. You can also enforce restrictions on what commands a user can execute with the TACACS+ authorization feature.

- Accounting—Collects and sends information used for billing, auditing, and reporting to the TACACS+ daemon. Network managers can use the accounting facility to track user activity for a security audit or to provide information for user billing. Accounting records include user identities, start and stop times, executed commands (such as PPP), number of packets, and number of bytes.

The TACACS+ protocol provides authentication between the switch and the TACACS+ daemon, and it ensures confidentiality because all protocol exchanges between the switch and the TACACS+ daemon are encrypted.

TACACS+ Operation

When a user attempts a simple ASCII login by authenticating to a switch using TACACS+, this process occurs:

1. When the connection is established, the switch contacts the TACACS+ daemon to obtain a username prompt to show to the user. The user enters a username, and the switch then contacts the TACACS+ daemon to obtain a password prompt. The switch displays the password prompt to the user, the user enters a password, and the password is then sent to the TACACS+ daemon.

TACACS+ allows a dialog between the daemon and the user until the daemon receives enough information to authenticate the user. The daemon prompts for a username and password combination, but can include other items, such as the user’s mother’s maiden name.

2. The switch eventually receives one of these responses from the TACACS+ daemon:

- ACCEPT—The user is authenticated and service can begin. If the switch is configured to require authorization, authorization begins at this time.

- REJECT—The user is not authenticated. The user can be denied access or is prompted to retry the login sequence, depending on the TACACS+ daemon.

- ERROR—An error occurred at some time during authentication with the daemon or in the network connection between the daemon and the switch. If an ERROR response is received, the switch typically tries to use an alternative method for authenticating the user.

- CONTINUE—The user is prompted for additional authentication information.

After authentication, the user undergoes an additional authorization phase if authorization has been enabled on the switch. Users must first successfully complete TACACS+ authentication before proceeding to TACACS+ authorization.

3. If TACACS+ authorization is required, the TACACS+ daemon is again contacted, and it returns an ACCEPT or REJECT authorization response. If an ACCEPT response is returned, the response contains data in the form of attributes that direct the EXEC or NETWORK session for that user and the services that the user can access:

- Telnet, Secure Shell (SSH), rlogin, or privileged EXEC services

- Connection parameters, including the host or client IP address, access list, and user timeouts

Method List

A method list defines the sequence and methods to be used to authenticate, to authorize, or to keep accounts on a user. You can use method lists to designate one or more security protocols to be used, thus ensuring a backup system if the initial method fails. The software uses the first method listed to authenticate, to authorize, or to keep accounts on users; if that method does not respond, the software selects the next method in the list. This process continues until there is successful communication with a listed method or the method list is exhausted.

If a method list is configured under VTY lines, the corresponding method list must be added to AAA. The following example shows how to configure a method list under a VTY line:

Device# configure terminal
Device(config)# line vty 0 4
Device(config)# authorization commands 15 auth1

The following example shows how to configure a method list in AAA:

Device# configure terminal
Device(config)# aaa new-model
Device(config)# aaa authorization commands 15 auth1 group tacacs+

If no method list is configured under VTY lines, the default method list must be added to AAA. The following example shows a VTY configuration without a method list:

Device# configure terminal
Device(config)# line vty 0 4

The following example shows how to configure the default method list:

Device# configure terminal
Device(config)# aaa new-model
Device(config)# aaa authorization commands 15 default group tacacs+

TACACS+ Configuration Options

You can configure the switch to use a single server or AAA server groups to group existing server hosts for authentication. You can group servers to select a subset of the configured server hosts and use them for a particular service. The server group is used with a global server-host list and contains the list of IP addresses of the selected server hosts.

TACACS+ Login Authentication

A method list describes the sequence and authentication methods to be queried to authenticate a user. You can designate one or more security protocols to be used for authentication, thus ensuring a backup system for authentication in case the initial method fails. The software uses the first method listed to authenticate users; if that method fails to respond, the software selects the next authentication method in the method list. This process continues until there is successful communication with a listed authentication method or until all defined methods are exhausted. If authentication fails at any point in this cycle—meaning that the security server or local username database responds by denying the user access—the authentication process stops, and no other authentication methods are attempted.

TACACS+ Authorization for Privileged EXEC Access and Network Services

AAA authorization limits the services available to a user. When AAA authorization is enabled, the switch uses information retrieved from the user’s profile, which is located either in the local user database or on the security server, to configure the user’s session. The user is granted access to a requested service only if the information in the user profile allows it.

TACACS+ Accounting

The AAA accounting feature tracks the services that users are accessing and the amount of network resources that they are consuming. When AAA accounting is enabled, the switch reports user activity to the TACACS+ security server in the form of accounting records. Each accounting record contains accounting attribute-value (AV) pairs and is stored on the security server. This data can then be analyzed for network management, client billing, or auditing.

Default TACACS+ Configuration

TACACS+ and AAA are disabled by default.

To prevent a lapse in security, you cannot configure TACACS+ through a network management application. When enabled, TACACS+ can authenticate users accessing the switch through the CLI.

Note

Although TACACS+ configuration is performed through the CLI, the TACACS+ server authenticates HTTP connections that have been configured with a privilege level of 15.

How to Configure Switch Access with TACACS+

This section describes how to configure your switch to support TACACS+.

- Identifying the TACACS+ Server Host and Setting the Authentication Key

- Configuring TACACS+ Login Authentication

- Configuring TACACS+ Authorization for Privileged EXEC Access and Network Services

- Starting TACACS+ Accounting

- Establishing a Session with a Router if the AAA Server is Unreachable

Identifying the TACACS+ Server Host and Setting the Authentication Key

Follow these steps to identify the TACACS+ server host and set the authentication key:

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

tacacs server server-name

Example:

Device(config)# tacacs server yourserver

Identifies the IP host or hosts maintaining a TACACS+ server. Enter this command multiple times to create a list of preferred hosts. The software searches for hosts in the order in which you specify them.

For server-name , specify the server name.

Step 4

address {ipv4 | ipv6} ip address

Example:

Device(config-server-tacacs)# address ipv4 10.0.1.12

Configures the IP address for the TACACS server.

Step 5

exit

Example:

Device(config-server-tacacs)# exit

Exits the TACACS server mode and enters the global configuration mode.

Step 6

aaa new-model

Example:

Device(config)# aaa new-model

Enables AAA.

Step 7

aaa group server tacacs+ group-name

Example:

Device(config)# aaa group server tacacs+ your_server_group

(Optional) Defines the AAA server-group with a group name.

This command puts the Device in a server group subconfiguration mode.

Step 8

server ip-address

Example:

Device(config)# server 10.1.2.3

(Optional) Associates a particular TACACS+ server with the defined server group. Repeat this step for each TACACS+ server in the AAA server group.

Each server in the group must be previously defined in Step 3.

Step 9

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 10

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 11

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Configuring TACACS+ Login Authentication

Follow these steps to configure TACACS+ login authentication:

Before you begin

To configure AAA authentication, you define a named list of authentication methods and then apply that list to various ports.

Note

To secure the for HTTP access by using AAA methods, you must configure the with the ip http authentication aaa global configuration command. Configuring AAA authentication does not secure the for HTTP access by using AAA methods.

For more information about the ip http authentication command, see the Cisco IOS Security Command Reference, Release 12.4.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

aaa new-model

Example:

Device(config)# aaa new-model

Enables AAA.

Step 4

aaa authentication login {default | list-name} method1 [method2...]

Example:

Device(config)# aaa authentication login default tacacs+ local

Creates a login authentication method list.

- To create a default list that is used when a named list is not specified in the login authentication command, use the default keyword followed by the methods that are to be used in default situations. The default method list is automatically applied to all ports.

- For list-name , specify a character string to name the list you are creating.

- For method1... , specify the actual method the authentication algorithm tries. The additional methods of authentication are used only if the previous method returns an error, not if it fails.

Select one of these methods:

- enable —Use the enable password for authentication. Before you can use this authentication method, you must define an enable password by using the enable password global configuration command.

- group tacacs+ —Uses TACACS+ authentication. Before you can use this authentication method, you must configure the TACACS+ server.

- line —Use the line password for authentication. Before you can use this authentication method, you must define a line password. Use the password password line configuration command.

- local —Use the local username database for authentication. You must enter username information in the database. Use the username password global configuration command.

- local-case —Use a case-sensitive local username database for authentication. You must enter username information in the database by using the username name password global configuration command.

- none —Do not use any authentication for login.

Step 5

line [console | tty | vty] line-number [ending-line-number]

Example:

Device(config)# line 2 4

Enters line configuration mode, and configures the lines to which you want to apply the authentication list.

Step 6

login authentication {default | list-name}

Example:

Device(config-line)# login authentication default

Applies the authentication list to a line or set of lines.

- If you specify default , use the default list created with the aaa authentication login command.

- For list-name , specify the list created with the aaa authentication login command.

Step 7

end

Example:

Device(config-line)# end

Returns to privileged EXEC mode.

Step 8

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 9

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Configuring TACACS+ Authorization for Privileged EXEC Access and Network Services

You can use the aaa authorization global configuration command with the tacacs+ keyword to set parameters that restrict a user’s network access to privileged EXEC mode.

Note

Authorization is bypassed for authenticated users who log in through the CLI even if authorization has been configured.

Follow these steps to specify TACACS+ authorization for privileged EXEC access and network services:

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

aaa authorization network tacacs+

Example:

Device(config)# aaa authorization network tacacs+

Configures the switch for user TACACS+ authorization for all network-related service requests.

Step 4

aaa authorization exec tacacs+

Example:

Device(config)# aaa authorization exec tacacs+

Configures the switch for user TACACS+ authorization if the user has privileged EXEC access.

The exec keyword might return user profile information (such as autocommand information).

Step 5

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 6

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 7

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Starting TACACS+ Accounting

Follow these steps to start TACACS+ Accounting:

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

aaa accounting network start-stop tacacs+

Example:

Device(config)# aaa accounting network start-stop tacacs+

Enables TACACS+ accounting for all network-related service requests.

Step 4

aaa accounting exec start-stop tacacs+

Example:

Device(config)# aaa accounting exec start-stop tacacs+

Enables TACACS+ accounting to send a start-record accounting notice at the beginning of a privileged EXEC process and a stop-record at the end.

Step 5

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 6

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 7

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

What to do next

To establish a session with a router if the AAA server is unreachable, use the aaa accounting system guarantee-first command. It guarantees system accounting as the first record, which is the default condition. In some situations, users might be prevented from starting a session on the console or terminal connection until after the system reloads, which can take more than 3 minutes.

To establish a console or Telnet session with the router if the AAA server is unreachable when the router reloads, use the no aaa accounting system guarantee-first command.

Establishing a Session with a Router if the AAA Server is Unreachable

To establishing a session with a router if the AAA server is unreachable, use the aaa accounting system guarantee-first command. It guarantees system accounting as the first record, which is the default condition. In some situations, users might be prevented from starting a session on the console or terminal connection until after the system reloads, which can take more than 3 minutes.

To establish a console or Telnet session with the router if the AAA server is unreachable when the router reloads, use the no aaa accounting system guarantee-first command.

Monitoring TACACS+

Commands for Displaying TACACS+ Information

Command

Purpose

show tacacs

Displays TACACS+ server statistics.

Additional References For Switch Access with TACACS+

Related Documents

Related Topic

Document Title

AAA configuration

Configuring Local Authentication and Authorization

MIBs

MIB

MIBs Link

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

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

Technical Assistance

Description

Link

The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies.

To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.

Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.

http://www.cisco.com/support

Feature Information for Switch Access with TACACS+

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

Feature Information for Switch Access with TACACS+

Feature Name

Releases

Feature Information

Switch Access with TACACS+

TACACS+ provides detailed accounting information and flexible administrative control over authentication and authorization processes. TACACS+ is facilitated through AAA and can be enabled only through AAA commands.

Chapter 4. Configuring RADIUS

- Prerequisites for Configuring RADIUS

- Restrictions for Configuring RADIUS

- Information about RADIUS

- Monitoring CoA Functionality

Prerequisites for Configuring RADIUS

This section lists the prerequisites for controlling Device access with RADIUS.

General:

- RADIUS and Authentication, Authorization, and Accounting (AAA) must be enabled to use any of the configuration commands in this chapter.

- RADIUS is facilitated through AAA and can be enabled only through AAA commands.

- Use the aaa new-model global configuration command to enable AAA.

- Use the aaa authentication global configuration command to define method lists for RADIUS authentication.

- Use line and interface commands to enable the defined method lists to be used.

- At a minimum, you must identify the host or hosts that run the RADIUS server software and define the method lists for RADIUS authentication. You can optionally define method lists for RADIUS authorization and accounting.

- You should have access to and should configure a RADIUS server before configuring RADIUS features on your Device.

- The RADIUS host is normally a multiuser system running RADIUS server software from Cisco (Cisco Secure Access Control Server Version 3.0), Livingston, Merit, Microsoft, or another software provider. For more information, see the RADIUS server documentation.

- To use the Change-of-Authorization (CoA) interface, a session must already exist on the switch. CoA can be used to identify a session and enforce a disconnect request. The update affects only the specified session.

- A redundant connection between a switch stack and the RADIUS server is recommended. This is to help ensure that the RADIUS server remains accessible in case one of the connected stack members is removed from the switch stack.

For RADIUS operation:

- Users must first successfully complete RADIUS authentication before proceeding to RADIUS authorization, if it is enabled.

Restrictions for Configuring RADIUS

This topic covers restrictions for controlling Device access with RADIUS.

General:

- To prevent a lapse in security, you cannot configure RADIUS through a network management application.

RADIUS is not suitable in the following network security situations:

- Multiprotocol access environments. RADIUS does not support AppleTalk Remote Access (ARA), NetBIOS Frame Control Protocol (NBFCP), NetWare Asynchronous Services Interface (NASI), or X.25 PAD connections.

- Switch-to-switch or router-to-router situations. RADIUS does not provide two-way authentication. RADIUS can be used to authenticate from one device to a non-Cisco device if the non-Cisco device requires authentication.

- Networks using a variety of services. RADIUS generally binds a user to one service model.

Information about RADIUS

- RADIUS and Switch Access

- RADIUS Overview

- RADIUS Operation

- RADIUS Change of Authorization

- Default RADIUS Configuration

- RADIUS Server Host

- RADIUS Login Authentication

- AAA Server Groups

- AAA Authorization

- RADIUS Accounting

- Vendor-Specific RADIUS Attributes

- Vendor-Proprietary RADIUS Server Communication

RADIUS and Switch Access

This section describes how to enable and configure RADIUS. RADIUS provides detailed accounting information and flexible administrative control over the authentication and authorization processes.

RADIUS Overview

RADIUS is a distributed client/server system that secures networks against unauthorized access. RADIUS clients run on supported Cisco routers and switches. Clients send authentication requests to a central RADIUS server, which contains all user authentication and network service access information.

Use RADIUS in these network environments that require access security:

- Networks with multiple-vendor access servers, each supporting RADIUS. For example, access servers from several vendors use a single RADIUS server-based security database. In an IP-based network with multiple vendors’ access servers, dial-in users are authenticated through a RADIUS server that has been customized to work with the Kerberos security system.

- Turnkey network security environments in which applications support the RADIUS protocol, such as in an access environment that uses a smart card access control system. In one case, RADIUS has been used with Enigma’s security cards to validates users and to grant access to network resources.

- Networks already using RADIUS. You can add a Cisco Device containing a RADIUS client to the network. This might be the first step when you make a transition to a TACACS+ server. See Figure: Transitioning from RADIUS to TACACS+ Services below.

- Network in which the user must only access a single service. Using RADIUS, you can control user access to a single host, to a single utility such as Telnet, or to the network through a protocol such as IEEE 802.1x. For more information about this protocol, see Configuring IEEE 802.1x Port-Based Authentication chapter.

- Networks that require resource accounting. You can use RADIUS accounting independently of RADIUS authentication or authorization. The RADIUS accounting functions allow data to be sent at the start and end of services, showing the amount of resources (such as time, packets, bytes, and so forth) used during the session. An Internet service provider might use a freeware-based version of RADIUS access control and accounting software to meet special security and billing needs.

Transitioning from RADIUS to TACACS+ Services

RADIUS Operation

When a user attempts to log in and authenticate to a Device that is access controlled by a RADIUS server, these events occur:

1. The user is prompted to enter a username and password.

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

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

- ACCEPT—The user is authenticated.

- REJECT—The user is either not authenticated and is prompted to re-enter the username and password, or access is denied.

- CHALLENGE—A challenge requires additional data from the user.

- CHALLENGE PASSWORD—A response requests the user to select a new password.

The ACCEPT or REJECT response is bundled with additional data that is used for privileged EXEC or network authorization. The additional data included with the ACCEPT or REJECT packets includes these items:

- Telnet, SSH, rlogin, or privileged EXEC services

- Connection parameters, including the host or client IP address, access list, and user timeouts

RADIUS Change of Authorization

The RADIUS Change of Authorization (CoA) provides a mechanism to change the attributes of an authentication, authorization, and accounting (AAA) session after it is authenticated. When a policy changes for a user or user group in AAA, administrators can send RADIUS CoA packets from the AAA server such as a Cisco Secure Access Control Server (ACS) to reinitialize authentication and apply the new policy. This section provides an overview of the RADIUS interface including available primitives and how they are used during a CoA.

- Change-of-Authorization Requests

- CoA Request Response Code

- CoA Request Commands

- Session Reauthentication

- Stacking Guidelines for Session Termination

A standard RADIUS interface is typically used in a pulled model where the request originates from a network attached device and the response come from the queried servers. Catalyst support the RADIUS CoA extensions defined in RFC 5176 that are typically used in a pushed model and allow for the dynamic reconfiguring of sessions from external AAA or policy servers.

The supports these per-session CoA requests:

- Session reauthentication

- Session termination

- Session termination with port shutdown

- Session termination with port bounce

This feature is integrated with Cisco Secure Access Control Server (ACS) 5.1.

The RADIUS interface is enabled by default on Catalyst . However, some basic configuration is required for the following attributes:

- Security and Password—refer to the “Preventing Unauthorized Access to Your Switch” section in this guide.

- Accounting—refer to the “Starting RADIUS Accounting” section in the Configuring Switch-Based Authentication chapter in this guide.

Cisco IOS software supports the RADIUS CoA extensions defined in RFC 5176 that are typically used in a push model to allow the dynamic reconfiguring of sessions from external AAA or policy servers. Per-session CoA requests are supported for session identification, session termination, host reauthentication, port shutdown, and port bounce. This model comprises one request (CoA-Request) and two possible response codes:

- CoA acknowledgement (ACK) [CoA-ACK]

- CoA nonacknowledgement (NAK) [CoA-NAK]

The request is initiated from a CoA client (typically a AAA or policy server) and directed to the device that acts as a listener.

The table below shows the RADIUS CoA commands and vendor-specific attributes (VSAs) supported by Identity-Based Networking Services. All CoA commands must include the session identifier between the device and the CoA client.

RADIUS CoA Commands Supported by Identity-Based Networking Services

CoA Command

Cisco VSA

Activate service

Cisco:Avpair=“subscriber:command=activate-service”

Cisco:Avpair=“subscriber:service-name=<service-name>”

Cisco:Avpair=“subscriber:precedence=<precedence-number>”

Cisco:Avpair=“subscriber:activation-mode=replace-all”

Deactivate service

Cisco:Avpair=“subscriber:command=deactivate-service”

Cisco:Avpair=“subscriber:service-name=<service-name>”

Bounce host port

Cisco:Avpair=“subscriber:command=bounce-host-port”

Disable host port

Cisco:Avpair=“subscriber:command=disable-host-port”

Session query

Cisco:Avpair=“subscriber:command=session-query”

Session reauthenticate

Cisco:Avpair=“subscriber:command=reauthenticate”

Cisco:Avpair=“subscriber:reauthenticate-type=last” or

Cisco:Avpair=“subscriber:reauthenticate-type=rerun”

Session terminate

This is a standard disconnect request and does not require a VSA.

Interface template

Cisco:AVpair="interface-template-name=<interfacetemplate>"

- Change-of-Authorization Requests

- CoA Request Response Code

- CoA Request Commands

- Stacking Guidelines for Session Termination

Change-of-Authorization Requests

Change of Authorization (CoA) requests, as described in RFC 5176, are used in a push model to allow for session identification, host reauthentication, and session termination. The model is comprised of one request (CoA-Request) and two possible response codes:

- CoA acknowledgment (ACK) [CoA-ACK]

- CoA non-acknowledgment (NAK) [CoA-NAK]

The request is initiated from a CoA client (typically a RADIUS or policy server) and directed to the switch that acts as a listener.

- RFC 5176 Compliance

RFC 5176 Compliance

The Disconnect Request message, which is also referred to as Packet of Disconnect (POD), is supported by the switch for session termination.

This table shows the IETF attributes are supported for this feature.

Supported IETF Attributes

Attribute Number

Attribute Name

24

State

31

Calling-Station-ID

44

Acct-Session-ID

80

Message-Authenticator

101

Error-Cause

This table shows the possible values for the Error-Cause attribute.

Error-Cause Values

Value

Explanation

201

Residual Session Context Removed

202

Invalid EAP Packet (Ignored)

401

Unsupported Attribute

402

Missing Attribute

403

NAS Identification Mismatch

404

Invalid Request

405

Unsupported Service

406

Unsupported Extension

407

Invalid Attribute Value

501

Administratively Prohibited

502

Request Not Routable (Proxy)

503

Session Context Not Found

504

Session Context Not Removable

505

Other Proxy Processing Error

506

Resources Unavailable

507

Request Initiated

508

Multiple Session Selection Unsupported

CoA Request Response Code

The CoA Request response code can be used to convey a command to the switch.

The packet format for a CoA Request Response code as defined in RFC 5176 consists of the following fields: Code, Identifier, Length, Authenticator, and Attributes in the Type:Length:Value (TLV) format. The Attributes field is used to carry Cisco vendor-specific attributes (VSAs).

- Session Identification

- CoA ACK Response Code

- CoA NAK Response Code

Session Identification

For disconnect and CoA requests targeted at a particular session, the switch locates the session based on one or more of the following attributes:

- Acct-Session-Id (IETF attribute #44)

- Audit-Session-Id (Cisco VSA)

- Calling-Station-Id (IETF attribute #31 which contains the host MAC address)

- IPv6 Attributes, which can be one of the following:

- Framed-IPv6-Prefix (IETF attribute #97) and Framed-Interface-Id (IETF attribute #96), which together create a full IPv6 address per RFC 3162

- Framed-IPv6-Address

- Plain IP Address (IETF attribute #8)

Unless all session identification attributes included in the CoA message match the session, the switch returns a Disconnect-NAK or CoA-NAK with the “Invalid Attribute Value” error-code attribute.

If more than one session identification attribute is included in the message, all the attributes must match the session or the switch returns a Disconnect- negative acknowledgment (NAK) or CoA-NAK with the error code “Invalid Attribute Value.”

The packet format for a CoA Request code as defined in RFC 5176 consists of the fields: Code, Identifier, Length, Authenticator, and Attributes in Type:Length:Value (TLV) format.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                         Authenticator                         |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-

The attributes field is used to carry Cisco vendor-specific attributes (VSAs).

For CoA requests targeted at a particular enforcement policy, the device returns a CoA-NAK with the error code “Invalid Attribute Value” if any of the above session identification attributes are included in the message.

CoA ACK Response Code

If the authorization state is changed successfully, a positive acknowledgment (ACK) is sent. The attributes returned within CoA ACK will vary based on the CoA Request and are discussed in individual CoA Commands.

CoA NAK Response Code

A negative acknowledgment (NAK) indicates a failure to change the authorization state and can include attributes that indicate the reason for the failure. Use show commands to verify a successful CoA.

CoA Request Commands

CoA Commands Supported on the

Command

[1]

Cisco VSA

Reauthenticate host

Cisco:Avpair=“subscriber:command=reauthenticate”

Terminate session

This is a standard disconnect request that does not require a VSA.

Bounce host port

Cisco:Avpair=“subscriber:command=bounce-host-port”

Disable host port

Cisco:Avpair=“subscriber:command=disable-host-port”

[1] All CoA commands must include the session identifier between the and the CoA client.

- Session Reauthentication

- Session Reauthentication in a Switch Stack

- Session Termination

- CoA Disconnect-Request

- CoA Request: Disable Host Port

- CoA Request: Bounce-Port

Session Reauthentication

The AAA server typically generates a session reauthentication request when a host with an unknown identity or posture joins the network and is associated with a restricted access authorization profile (such as a guest VLAN). A reauthentication request allows the host to be placed in the appropriate authorization group when its credentials are known.

To initiate session authentication, the AAA server sends a standard CoA-Request message which contains a Cisco VSA in this form: Cisco:Avpair=“subscriber:command=reauthenticate” and one or more session identification attributes.

The current session state determines the switch response to the message. If the session is currently authenticated by IEEE 802.1x, the switch responds by sending an EAPoL (Extensible Authentication Protocol over Lan) -RequestId message to the server.

If the session is currently authenticated by MAC authentication bypass (MAB), the switch sends an access-request to the server, passing the same identity attributes used for the initial successful authentication.

If session authentication is in progress when the switch receives the command, the switch terminates the process, and restarts the authentication sequence, starting with the method configured to be attempted first.

If the session is not yet authorized, or is authorized via guest VLAN, or critical VLAN, or similar policies, the reauthentication message restarts the access control methods, beginning with the method configured to be attempted first. The current authorization of the session is maintained until the reauthentication leads to a different authorization result.

Session Reauthentication in a Switch Stack

When a switch stack receives a session reauthentication message:

- It checkpoints the need for a re-authentication before returning an acknowledgment (ACK).

- It initiates reauthentication for the appropriate session.

- If authentication completes with either success or failure, the signal that triggered the reauthentication is removed from the stack's member switch.

- If the stack's active switch fails before authentication completes, reauthentication is initiated after active switch changeover based on the original command (which is subsequently removed).

- If the active switch fails before sending an ACK, the new active switch treats the re-transmitted command as a new command.

Session Termination

There are three types of CoA requests that can trigger session termination. A CoA Disconnect-Request terminates the session, without disabling the host port. This command causes re-initialization of the authenticator state machine for the specified host, but does not restrict that host access to the network.

To restrict a host’s access to the network, use a CoA Request with the Cisco:Avpair="subscriber:command=disable-host-port" VSA. This command is useful when a host is known to be causing problems on the network, and you need to immediately block network access for the host. When you want to restore network access on the port, re-enable it using a non-RADIUS mechanism.

When a device with no supplicant, such as a printer, needs to acquire a new IP address (for example, after a VLAN change), terminate the session on the host port with port-bounce (temporarily disable and then re-enable the port).

CoA Disconnect-Request

This command is a standard Disconnect-Request. If the session cannot be located, the switch returns a Disconnect-NAK message with the “Session Context Not Found” error-code attribute. If the session is located, the switch terminates the session. After the session has been completely removed, the switch returns a Disconnect-ACK.

If the switch fails-over to a standby switch before returning a Disconnect-ACK to the client, the process is repeated on the new active switch when the request is re-sent from the client. If the session is not found following re-sending, a Disconnect-ACK is sent with the “Session Context Not Found” error-code attribute.

CoA Request: Disable Host Port

The RADIUS server CoA disable port command administratively shuts down the authentication port that is hosting a session, resulting in session termination. This command is useful when a host is known to cause problems on the network and network access needs to be immediately blocked for the host. To restore network access on the port, reenable it using a non-RADIUS mechanism. This command is carried in a standard CoA-Request message that has this new vendor-specific attribute (VSA):

Cisco:Avpair="subscriber:command=disable-host-port"

Because this command is session-oriented, it must be accompanied by one or more of the session identification attributes described in the “Session Identification” section. If the session cannot be located, the switch returns a CoA-NAK message with the “Session Context Not Found” error-code attribute. If the session is located, the switch disables the hosting port and returns a CoA-ACK message.

If the switch fails before returning a CoA-ACK to the client, the process is repeated on the new active switch when the request is re-sent from the client. If the switch fails after returning a CoA-ACK message to the client but before the operation has completed, the operation is restarted on the new active switch.

Note

A Disconnect-Request failure following command re-sending could be the result of either a successful session termination before change-over (if the Disconnect-ACK was not sent) or a session termination by other means (for example, a link failure) that occurred after the original command was issued and before the standby switch became active.

CoA Request: Bounce-Port

A RADIUS server CoA bounce port sent from a RADIUS server can cause a link flap on an authentication port, which triggers DHCP renegotiation from one or more hosts connected to this port. This incident can occur when there is a VLAN change and the endpoint is a device (such as a printer) that does not have a mechanism to detect a change on this authentication port. The CoA bounce port is carried in a standard CoA-Request message that contains the following VSA:

Cisco:Avpair="subscriber:command=bounce-host-port"

Because this command is session-oriented, it must be accompanied by one or more of the session identification attributes. If the session cannot be located, the switch returns a CoA-NAK message with the “Session Context Not Found” error-code attribute. If the session is located, the switch disables the hosting port for a period of 10 seconds, re-enables it (port-bounce), and returns a CoA-ACK.

If the switch fails before returning a CoA-ACK to the client, the process is repeated on the new active switch when the request is re-sent from the client. If the switch fails after returning a CoA-ACK message to the client but before the operation has completed, the operation is re-started on the new active switch.

Stacking Guidelines for Session Termination

No special handling is required for CoA Disconnect-Request messages in a switch stack.

- Stacking Guidelines for CoA-Request Bounce-Port

- Stacking Guidelines for CoA-Request Disable-Port

Stacking Guidelines for CoA-Request Bounce-Port

Because the bounce-port command is targeted at a session, not a port, if the session is not found, the command cannot be executed.

When the Auth Manager command handler on the active switch receives a valid bounce-port command, it checkpoints the following information before returning a CoA-ACK message:

- the need for a port-bounce

- the port-id (found in the local session context)

The switch initiates a port-bounce (disables the port for 10 seconds, then re-enables it).

If the port-bounce is successful, the signal that triggered the port-bounce is removed from the standby switch.

If the active switch fails before the port-bounce completes, a port-bounce is initiated after an active switch changeover based on the original command (which is subsequently removed).

If the active switch fails before sending a CoA-ACK message, the new active switch treats the re-sent command as a new command.

Stacking Guidelines for CoA-Request Disable-Port

Because the disable-port command is targeted at a session, not a port, if the session is not found, the command cannot be executed.

When the Auth Manager command handler on the active switch receives a valid disable-port command, it verifies this information before returning a CoA-ACK message:

- the need for a port-disable

- the port-id (found in the local session context)

The switch attempts to disable the port.

If the port-disable operation is successful, the signal that triggered the port-disable is removed from the standby switch.

If the active switch fails before the port-disable operation completes, the port is disabled after an active switch changeover based on the original command (which is subsequently removed).

If the active switch fails before sending a CoA-ACK message, the new active switch treats the re-sent command as a new command.

Default RADIUS Configuration

RADIUS and AAA are disabled by default.

To prevent a lapse in security, you cannot configure RADIUS through a network management application. When enabled, RADIUS can authenticate users accessing the switch through the CLI.

RADIUS Server Host

Switch-to-RADIUS-server communication involves several components:

- Hostname or IP address

- Authentication destination port

- Accounting destination port

- Key string

- Timeout period

- Retransmission value

You identify RADIUS security servers by their hostname or IP address, hostname and specific UDP port numbers, or their IP address and specific UDP port numbers. The combination of the IP address and the UDP port number creates a unique identifier, allowing different ports to be individually defined as RADIUS hosts providing a specific AAA service. This unique identifier enables RADIUS requests to be sent to multiple UDP ports on a server at the same IP address.

If two different host entries on the same RADIUS server are configured for the same service—for example, accounting—the second host entry configured acts as a fail-over backup to the first one. Using this example, if the first host entry fails to provide accounting services, the %RADIUS-4-RADIUS_DEAD message appears, and then the switch tries the second host entry configured on the same device for accounting services. (The RADIUS host entries are tried in the order that they are configured.)

A RADIUS server and the switch use a shared secret text string to encrypt passwords and exchange responses. To configure RADIUS to use the AAA security commands, you must specify the host running the RADIUS server daemon and a secret text (key) string that it shares with the switch.

The timeout, retransmission, and encryption key values can be configured globally for all RADIUS servers, on a per-server basis, or in some combination of global and per-server settings.

RADIUS Login Authentication

To configure AAA authentication, you define a named list of authentication methods and then apply that list to various ports. The method list defines the types of authentication to be performed and the sequence in which they are performed; it must be applied to a specific port before any of the defined authentication methods are performed. The only exception is the default method list. The default method list is automatically applied to all ports except those that have a named method list explicitly defined.

A method list describes the sequence and authentication methods to be queried to authenticate a user. You can designate one or more security protocols to be used for authentication, thus ensuring a backup system for authentication in case the initial method fails. The software uses the first method listed to authenticate users; if that method fails to respond, the software selects the next authentication method in the method list. This process continues until there is successful communication with a listed authentication method or until all defined methods are exhausted. If authentication fails at any point in this cycle—meaning that the security server or local username database responds by denying the user access—the authentication process stops, and no other authentication methods are attempted.

AAA Server Groups

You can configure the switch to use AAA server groups to group existing server hosts for authentication. You select a subset of the configured server hosts and use them for a particular service. The server group is used with a global server-host list, which lists the IP addresses of the selected server hosts.

Server groups also can include multiple host entries for the same server if each entry has a unique identifier (the combination of the IP address and UDP port number), allowing different ports to be individually defined as RADIUS hosts providing a specific AAA service. This unique identifier enables RADIUS requests to be sent to different UDP ports on a server at the same IP address. If you configure two different host entries on the same RADIUS server for the same service, (for example, accounting), the second configured host entry acts as a fail-over backup to the first one. If the first host entry fails to provide accounting services, the network access server tries the second host entry configured on the same device for accounting services. (The RADIUS host entries are tried in the order in which they are configured.)

AAA Authorization

AAA authorization limits the services available to a user. When AAA authorization is enabled, the switch uses information retrieved from the user’s profile, which is in the local user database or on the security server, to configure the user’s session. The user is granted access to a requested service only if the information in the user profile allows it.

RADIUS Accounting

The AAA accounting feature tracks the services that users are using and the amount of network resources that they are consuming. When you enable AAA accounting, the switch reports user activity to the RADIUS security server in the form of accounting records. Each accounting record contains accounting attribute-value (AV) pairs and is stored on the security server. You can then analyze the data for network management, client billing, or auditing.

Vendor-Specific RADIUS Attributes

The Internet Engineering Task Force (IETF) draft standard specifies a method for communicating vendor-specific information between the switch and the RADIUS server by using the vendor-specific attribute (attribute 26). Vendor-specific attributes (VSAs) allow vendors to support their own extended attributes not suitable for general use. The Cisco RADIUS implementation supports one vendor-specific option by using the format recommended in the specification. Cisco’s vendor-ID is 9, and the supported option has vendor-type 1, which is named cisco-avpair. The value is a string with this format:

protocol : attribute sep value *

Protocol is a value of the Cisco protocol attribute for a particular type of authorization. Attribute and value are an appropriate attributevalue (AV) pair defined in the Cisco TACACS+ specification, and sep is = for mandatory attributes and is * for optional attributes. The full set of features available for TACACS+ authorization can then be used for RADIUS.

For example, the following AV pair causes Cisco’s “multiple named IP address pools” feature to be activated during IP authorization (during PPP’s Internet Protocol Control Protocol (IPCP) address assignment):

cisco-avpair= ”ip:addr-pool=first“

If you insert an “*”, the AV pair “ip:addr-pool=first” becomes optional. Note that any AV pair can be made optional:

cisco-avpair= ”ip:addr-pool*first“

The following example shows how to cause a user logging in from a network access server to have immediate access to EXEC commands:

cisco-avpair= ”shell:priv-lvl=15“

Other vendors have their own unique vendor-IDs, options, and associated VSAs. For more information about vendor-IDs and VSAs, see RFC 2138, “Remote Authentication Dial-In User Service (RADIUS).”

Attribute 26 contains the following three elements:

- Type

- Length

- String (also known as data)

- Vendor-Id

- Vendor-Type

- Vendor-Length

- Vendor-Data

The figure below shows the packet format for a VSA encapsulated “behind” attribute 26.

VSA Encapsulated Behind Attribute 26

Note

It is up to the vendor to specify the format of their VSA. The Attribute-Specific field (also known as Vendor-Data) is dependent on the vendor's definition of that attribute.

The table below describes significant fields listed in the Vendor-Specific RADIUS IETF Attributes table (second table below), which lists supported vendor-specific RADIUS attributes (IETF attribute 26).

Vendor-Specific Attributes Table Field Descriptions

Field

Description

Number

All attributes listed in the following table are extensions of IETF attribute 26.

Vendor-Specific Command Codes

A defined code used to identify a particular vendor. Code 9 defines Cisco VSAs, 311 defines Microsoft VSAs, and 529 defines Ascend VSAs.

Sub-Type Number

The attribute ID number. This number is much like the ID numbers of IETF attributes, except it is a “second layer” ID number encapsulated behind attribute 26.

Attribute

The ASCII string name of the attribute.

Description

Description of the attribute.

Vendor-Specific RADIUS IETF Attributes

Number

Vendor-Specific Company Code

Sub-Type Number

Attribute

Description

MS-CHAP Attributes

26

311

1

MSCHAP-Response

Contains the response value provided by a PPP MS-CHAP user in response to the challenge. It is only used in Access-Request packets. This attribute is identical to the PPP CHAP Identifier. ( RFC 2548

26

311

11

MSCHAP-Challenge

Contains the challenge sent by a network access server to an MS-CHAP user. It can be used in both Access-Request and Access-Challenge packets. ( RFC 2548 )

VPDN Attributes

26

9

1

l2tp-cm-local-window-size

Specifies the maximum receive window size for L2TP control messages. This value is advertised to the peer during tunnel establishment.

26

9

1

l2tp-drop-out-of-order

Respects sequence numbers on data packets by dropping those that are received out of order. This does not ensure that sequence numbers will be sent on data packets, just how to handle them if they are received.

26

9

1

l2tp-hello-interval

Specifies the number of seconds for the hello keepalive interval. Hello packets are sent when no data has been sent on a tunnel for the number of seconds configured here.

26

9

1

l2tp-hidden-avp

When enabled, sensitive AVPs in L2TP control messages are scrambled or hidden.

26

9

1

l2tp-nosession-timeout

Specifies the number of seconds that a tunnel will stay active with no sessions before timing out and shutting down.

26

9

1

tunnel-tos-reflect

Copies the IP ToS field from the IP header of each payload packet to the IP header of the tunnel packet for packets entering the tunnel at the LNS.

26

9

1

l2tp-tunnel-authen

If this attribute is set, it performs L2TP tunnel authentication.

26

9

1

l2tp-tunnel-password

Shared secret used for L2TP tunnel authentication and AVP hiding.

26

9

1

l2tp-udp-checksum

This is an authorization attribute and defines whether L2TP should perform UDP checksums for data packets. Valid values are “yes” and “no.” The default is no.

Store and Forward Fax Attributes

26

9

3

Fax-Account-Id-Origin

Indicates the account ID origin as defined by system administrator for the mmoip aaa receive-id or the mmoip aaa send-id commands.

26

9

4

Fax-Msg-Id=

Indicates a unique fax message identification number assigned by Store and Forward Fax.

26

9

5

Fax-Pages

Indicates the number of pages transmitted or received during this fax session. This page count includes cover pages.

26

9

6

Fax-Coverpage-Flag

Indicates whether or not a cover page was generated by the off-ramp gateway for this fax session. True indicates that a cover page was generated; false means that a cover page was not generated.

26

9

7

Fax-Modem-Time

Indicates the amount of time in seconds the modem sent fax data (x) and the amount of time in seconds of the total fax session (y), which includes both fax-mail and PSTN time, in the form x/y. For example, 10/15 means that the transfer time took 10 seconds, and the total fax session took 15 seconds.

26

9

8

Fax-Connect-Speed

Indicates the modem speed at which this fax-mail was initially transmitted or received. Possible values are 1200, 4800, 9600, and 14400.

26

9

9

Fax-Recipient-Count

Indicates the number of recipients for this fax transmission. Until e-mail servers support Session mode, the number should be 1.

26

9

10

Fax-Process-Abort-Flag

Indicates that the fax session was cancelled or successful. True means that the session was cancelled; false means that the session was successful.

26

9

11

Fax-Dsn-Address

Indicates the address to which DSNs will be sent.

26

9

12

Fax-Dsn-Flag

Indicates whether or not DSN has been enabled. True indicates that DSN has been enabled; false means that DSN has not been enabled.

26

9

13

Fax-Mdn-Address

Indicates the address to which MDNs will be sent.

26

9

14

Fax-Mdn-Flag

Indicates whether or not message delivery notification (MDN) has been enabled. True indicates that MDN had been enabled; false means that MDN had not been enabled.

26

9

15

Fax-Auth-Status

Indicates whether or not authentication for this fax session was successful. Possible values for this field are success, failed, bypassed, or unknown.

26

9

16

Email-Server-Address

Indicates the IP address of the e-mail server handling the on-ramp fax-mail message.

26

9

17

Email-Server-Ack-Flag

Indicates that the on-ramp gateway has received a positive acknowledgment from the e-mail server accepting the fax-mail message.

26

9

18

Gateway-Id

Indicates the name of the gateway that processed the fax session. The name appears in the following format: hostname.domain-name.

26

9

19

Call-Type

Describes the type of fax activity: fax receive or fax send.

26

9

20

Port-Used

Indicates the slot/port number of the Cisco AS5300 used to either transmit or receive this fax-mail.

26

9

21

Abort-Cause

If the fax session cancels, indicates the system component that signaled the cancel operation. Examples of system components that could trigger a cancel operation are FAP (Fax Application Process), TIFF (the TIFF reader or the TIFF writer), fax-mail client, fax-mail server, ESMTP client, or ESMTP server.

H323 Attributes

26

9

23

Remote-Gateway-ID (h323-remote-address)

Indicates the IP address of the remote gateway.

26

9

24

Connection-ID

(h323-conf-id)

Identifies the conference ID.

26

9

25

Setup-Time

(h323-setup-time)

Indicates the setup time for this connection in Coordinated Universal Time (UTC) formerly known as Greenwich Mean Time (GMT) and Zulu time.

26

9

26

Call-Origin

(h323-call-origin)

Indicates the origin of the call relative to the gateway. Possible values are originating and terminating (answer).

26

9

27

Call-Type

(h323-call-type)

Indicates call leg type. Possible values are telephony and VoIP .

26

9

28

Connect-Time

(h323-connect-time)

Indicates the connection time for this call leg in UTC.

26

9

29

Disconnect-Time

(h323-disconnect-time)

Indicates the time this call leg was disconnected in UTC.

26

9

30

Disconnect-Cause

(h323-disconnect-cause)

Specifies the reason a connection was taken offline per Q.931 specification.

26

9

31

Voice-Quality

(h323-voice-quality)

Specifies the impairment factor (ICPIF) affecting voice quality for a call.

26

9

33

Gateway-ID

(h323-gw-id)

Indicates the name of the underlying gateway.

Large Scale Dialout Attributes

26

9

1

callback-dialstring

Defines a dialing string to be used for callback.

26

9

1

data-service

No description available.

26

9

1

dial-number

Defines the number to dial.

26

9

1

force-56

Determines whether the network access server uses only the 56 K portion of a channel, even when all 64 K appear to be available.

26

9

1

map-class

Allows the user profile to reference information configured in a map class of the same name on the network access server that dials out.

26

9

1

send-auth

Defines the protocol to use (PAP or CHAP) for username-password authentication following CLID authentication.

26

9

1

send-name

PPP name authentication. To apply for PAP, do not configure the ppp pap sent-name password command on the interface. For PAP, “preauth:send-name” and “preauth:send-secret” will be used as the PAP username and PAP password for outbound authentication. For CHAP, “preauth:send-name” will be used not only for outbound authentication, but also for inbound authentication. For a CHAP inbound case, the NAS will use the name defined in “preauth:send-name” in the challenge packet to the caller box.

Note

The send-name attribute has changed over time: Initially, it performed the functions now provided by both the send-name and remote-name attributes. Because the remote-name attribute has been added, the send-name attribute is restricted to its current behavior.

26

9

1

send-secret

PPP password authentication. The vendor-specific attributes (VSAs) “preauth:send-name” and “preauth:send-secret” will be used as the PAP username and PAP password for outbound authentication. For a CHAP outbound case, both “preauth:send-name” and “preauth:send-secret” will be used in the response packet.

26

9

1

remote-name

Provides the name of the remote host for use in large-scale dial-out. Dialer checks that the large-scale dial-out remote name matches the authenticated name, to protect against accidental user RADIUS misconfiguration. (For example, dialing a valid phone number but connecting to the wrong device.)

Miscellaneous Attributes

26

9

2

Cisco-NAS-Port

Specifies additional vendor specific attribute (VSA) information for NAS-Port accounting. To specify additional NAS-Port information in the form an Attribute-Value Pair (AVPair) string, use the radius-server vsa send global configuration command.

Note

This VSA is typically used in Accounting, but may also be used in Authentication (Access-Request) packets.

26

9

1

min-links

Sets the minimum number of links for MLP.

26

9

1

proxyacl#<n>

Allows users to configure the downloadable user profiles (dynamic ACLs) by using the authentication proxy feature so that users can have the configured authorization to permit traffic going through the configured interfaces.

26

9

1

spi

Carries the authentication information needed by the home agent to authenticate a mobile node during registration. The information is in the same syntax as the ip mobile secure host <addr> configuration command. Basically it contains the rest of the configuration command that follows that string, verbatim. It provides the Security Parameter Index (SPI), key, authentication algorithm, authentication mode, and replay protection timestamp range.

Vendor-Proprietary RADIUS Server Communication

Although an IETF draft standard for RADIUS specifies a method for communicating vendor-proprietary information between the switch and the RADIUS server, some vendors have extended the RADIUS attribute set in a unique way. Cisco  IOS software supports a subset of vendor-proprietary RADIUS attributes.

As mentioned earlier, to configure RADIUS (whether vendor-proprietary or IETF draft-compliant), you must specify the host running the RADIUS server daemon and the secret text string it shares with the switch. You specify the RADIUS host and secret text string by using the radius server global configuration commands.

Identifying the RADIUS Server Host

To apply these settings globally to all RADIUS servers communicating with the Device, use the three unique global configuration commands: radius-server timeout , radius-server retransmit , and key string .

You can configure the Device to use AAA server groups to group existing server hosts for authentication. For more information, see Related Topics below.

You also need to configure some settings on the RADIUS server. These settings include the IP address of the Device and the key string to be shared by both the server and the Device. For more information, see the RADIUS server documentation.

Follow these steps to configure per-server RADIUS server communication.

Before you begin

If you configure both global and per-server functions (timeout, retransmission, and key commands) on the device, the per-server timer, retransmission, and key value commands override global timer, retransmission, and key value commands. For information on configuring these settings on all RADIUS servers, see Related Topics below.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

radius server server name

Example:

Device(config)# radius server rsim

Step 4

address {ipv4 | ipv6}ip address{ auth-port port number | acct-port port number}

Example:

Device(config-radius-server)# address ipv4 124.2.2.12 auth-port 1612

(Optional) Specifies the RADIUS server parameters.

For auth-port port-number , specify the UDP destination port for authentication requests. The default is 1645. The range is 0 to 65536.

For acct-port port-number , specify the UDP destination port for authentication requests. The default is 1646.

Step 5

key string

Example:

Device(config-radius-server)#  key rad123

(Optional) For key string , specify the authentication and encryption key used between the Device and the RADIUS daemon running on the RADIUS server.

Note

The key is a text string that must match the encryption key used on the RADIUS server. Always configure the key as the last item in the radius server command. Leading spaces are ignored, but spaces within and at the end of the key are used. If you use spaces in your key, do not enclose the key in quotation marks unless the quotation marks are part of the key.

Step 6

retransmit value

Example:

Device(config-radius-server)# retransmit 10

(Optional) Specifies the number of times a RADIUS request is resent when the server is not responding or responding slowly. The range is 1 to 100. This setting overrides the radius-server retransmit global configuration command setting.

Step 7

timeout seconds

Example:

Device(config-radius-server)# timeout 60

(Optional) Specifies the time interval that the Device waits for the RADIUS server to reply before sending a request again. The range is 1 to 1000. This setting overrides the radius-server timeout global configuration command setting.

Step 8

exit

Example:

Device(config-server-tacacs)# exit

Exits the RADIUS server mode and enters the global configuration mode.

Step 9

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 10

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 11

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Configuring RADIUS Login Authentication

Follow these steps to configure RADIUS login authentication:

Before you begin

To secure the device for HTTP access by using AAA methods, you must configure the device with the ip http authentication aaa global configuration command. Configuring AAA authentication does not secure the device for HTTP access by using AAA methods.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

aaa new-model

Example:

Device(config)# aaa new-model

Enables AAA.

Step 4

aaa authentication login {default | list-name} method1 [method2...]

Example:

Device(config)# aaa authentication login default local

Creates a login authentication method list.

- To create a default list that is used when a named list is not specified in the login authentication command, use the default keyword followed by the methods that are to be used in default situations. The default method list is automatically applied to all ports.

- For list-name , specify a character string to name the list you are creating.

- For method1... , specify the actual method the authentication algorithm tries. The additional methods of authentication are used only if the previous method returns an error, not if it fails.

Select one of these methods:

- enable —Use the enable password for authentication. Before you can use this authentication method, you must define an enable password by using the enable password global configuration command.

- group radius —Use RADIUS authentication. Before you can use this authentication method, you must configure the RADIUS server.

- line —Use the line password for authentication. Before you can use this authentication method, you must define a line password. Use the password password line configuration command.

- local —Use the local username database for authentication. You must enter username information in the database. Use the username name password global configuration command.

- local-case —Use a case-sensitive local username database for authentication. You must enter username information in the database by using the username password global configuration command.

- none —Do not use any authentication for login.

Step 5

line [console | tty | vty] line-number [ending-line-number]

Example:

Device(config)# line 1 4

Enters line configuration mode, and configure the lines to which you want to apply the authentication list.

Step 6

login authentication {default | list-name}

Example:

Device(config)# login authentication default

Applies the authentication list to a line or set of lines.

- If you specify default , use the default list created with the aaa authentication login command.

- For list-name , specify the list created with the aaa authentication login command.

Step 7

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 8

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 9

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Defining AAA Server Groups

You use the server group server configuration command to associate a particular server with a defined group server. You can either identify the server by its IP address or identify multiple host instances or entries by using the optional auth-port and acct-port keywords.

Follow these steps to define AAA server groups:

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

radius server name

Example:

Device(config)# radius server ISE

Specifies the name of the RADIUS server configuration for Protected Access Credential (PAC) provisioning and enters RADIUS server configuration mode.

The device also supports RADIUS for IPv6.

Step 4

address {ipv4 | ipv6} {ip-address | hostname} auth-port port-number acct-port port-number

Example:

Device(config-radius-server)# address ipv4 10.1.1.1 auth-port 1645 acct-port 1646

Configures the IPv4 address for the RADIUS server accounting and authentication parameters.

Step 5

key string

Example:

Device(config-radius-server)# key cisco123

Specifies the authentication and encryption key for all RADIUS communications between the device and the RADIUS server.

Step 6

end

Example:

Device(config-radius-server)# end

Exits RADIUS server configuration mode and returns to privileged EXEC mode.

Step 7

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 8

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Configuring RADIUS Authorization for User Privileged Access and Network Services

Note

Authorization is bypassed for authenticated users who log in through the CLI even if authorization has been configured.

Follow these steps to configure RADIUS authorization for user priviledged access and network services:

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

aaa authorization network radius

Example:

Device(config)# aaa authorization network radius

Configures the device for user RADIUS authorization for all network-related service requests.

Step 4

aaa authorization exec radius

Example:

Device(config)# aaa authorization exec radius

Configures the device for user RADIUS authorization if the user has privileged EXEC access.

The exec keyword might return user profile information (such as autocommand information).

Step 5

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 6

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 7

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

What to do next

You can use the aaa authorization global configuration command with the radius keyword to set parameters that restrict a user’s network access to privileged EXEC mode.

The aaa authorization exec radius local command sets these authorization parameters:

- Use RADIUS for privileged EXEC access authorization if authentication was performed by using RADIUS.

- Use the local database if authentication was not performed by using RADIUS.

Starting RADIUS Accounting

Follow these steps to start RADIUS accounting:

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

aaa accounting network start-stop radius

Example:

Device(config)# aaa accounting network start-stop radius

Enables RADIUS accounting for all network-related service requests.

Step 4

aaa accounting exec start-stop radius

Example:

Device(config)# aaa accounting exec start-stop radius

Enables RADIUS accounting to send a start-record accounting notice at the beginning of a privileged EXEC process and a stop-record at the end.

Step 5

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 6

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 7

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Configuring Settings for All RADIUS Servers

Beginning in privileged EXEC mode, follow these steps to configure settings for all RADIUS servers:

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

radius-server key string

Example:

Device(config)# radius-server key your_server_key

Device(config)# key your_server_key

Specifies the shared secret text string used between the switch and all RADIUS servers.

Note

The key is a text string that must match the encryption key used on the RADIUS server. Leading spaces are ignored, but spaces within and at the end of the key are used. If you use spaces in your key, do not enclose the key in quotation marks unless the quotation marks are part of the key.

Step 3

radius-server retransmit retries

Example:

Device(config)#  radius-server retransmit 5

Specifies the number of times the switch sends each RADIUS request to the server before giving up. The default is 3; the range 1 to 1000.

Step 4

radius-server timeout seconds

Example:

Device(config)#  radius-server timeout 3

Specifies the number of seconds a switch waits for a reply to a RADIUS request before resending the request. The default is 5 seconds; the range is 1 to 1000.

Step 5

radius-server deadtime minutes

Example:

Device(config)#  radius-server deadtime 0

When a RADIUS server is not responding to authentication requests, this command specifies a time to stop the request on that server. This avoids the wait for the request to timeout before trying the next configured server. The default is 0; the range is 1 to 1440 minutes.

Step 6

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 7

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 8

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Configuring the Device to Use Vendor-Specific RADIUS Attributes

Follow these steps to configure the device to use vendor-specific RADIUS attributes:

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

radius-server vsa send [accounting | authentication]

Example:

Device(config)# radius-server vsa send accounting

Enables the device to recognize and use VSAs as defined by RADIUS IETF attribute 26.

- (Optional) Use the accounting keyword to limit the set of recognized vendor-specific attributes to only accounting attributes.

- (Optional) Use the authentication keyword to limit the set of recognized vendor-specific attributes to only authentication attributes.

If you enter this command without keywords, both accounting and authentication vendor-specific attributes are used.

Step 4

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 5

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 6

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Configuring the Device for Vendor-Proprietary RADIUS Server Communication

Follow these steps to configure the device to use vendor-proprietary RADIUS server communication:

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

radius server server name

Example:

Device(config)#  radius server rsim

Specifies the RADIUS server.

Step 4

address { ipv4 | ipv6 } ip address

Example:

Device(config-radius-server)# address ipv4 172.24.25.10

(Optional) Specifies the IP address of the RADIUS server.

Step 5

non-standard

Example:

Device(config-radius-server)# non-standard

Identifies that the RADIUS server using a vendor-proprietary implementation of RADIUS.

Step 6

key string

Example:

Device(config-radius-server)# key rad123

Specifies the shared secret text string used between the device and the vendor-proprietary RADIUS server. The device and the RADIUS server use this text string to encrypt passwords and exchange responses.

Step 7

exit

Example:

Device(config-radius-server)# exit

Exits the RADIUS server mode and enters the global configuration mode.

Step 8

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 9

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 10

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Configuring CoA on the Device

Follow these steps to configure CoA on a device. This procedure is required.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

aaa new-model

Example:

Device(config)# aaa new-model

Enables AAA.

Step 4

aaa server radius dynamic-author

Example:

Device(config)# aaa server radius dynamic-author

Configures the device as an authentication, authorization, and accounting (AAA) server to facilitate interaction with an external policy server.

Step 5

client {ip-address | name} [vrf vrfname] [server-key string]

Enters dynamic authorization local server configuration mode and specifies a RADIUS client from which a device will accept CoA and disconnect requests.

Step 6

server-key [0 | 7] string

Example:

Device(config-sg-radius)# server-key your_server_key

Configures the RADIUS key to be shared between a device and RADIUS clients.

Step 7

port port-number

Example:

Device(config-sg-radius)# port 25

Specifies the port on which a device listens for RADIUS requests from configured RADIUS clients.

Step 8

auth-type {any | all | session-key}

Example:

Device(config-sg-radius)# auth-type any

Specifies the type of authorization the device uses for RADIUS clients.

The client must match all the configured attributes for authorization.

Step 9

ignore session-key

(Optional) Configures the device to ignore the session-key.

For more information about the ignore command, see the Cisco IOS Intelligent Services Gateway Command Reference on Cisco.com.

Step 10

ignore server-key

Example:

Device(config-sg-radius)# ignore server-key

(Optional) Configures the device to ignore the server-key.

For more information about the ignore command, see the Cisco IOS Intelligent Services Gateway Command Reference on Cisco.com.

Step 11

authentication command bounce-port ignore

Example:

Device(config-sg-radius)# authentication command bounce-port ignore

(Optional) Configures the device to ignore a CoA request to temporarily disable the port hosting a session. The purpose of temporarily disabling the port is to trigger a DHCP renegotiation from the host when a VLAN change occurs and there is no supplicant on the endpoint to detect the change.

Step 12

authentication command disable-port ignore

Example:

Device(config-sg-radius)# authentication command disable-port ignore

(Optional) Configures the device to ignore a nonstandard command requesting that the port hosting a session be administratively shut down. Shutting down the port results in termination of the session.

Use standard CLI or SNMP commands to re-enable the port.

Step 13

end

Example:

Device(config-sg-radius)# end

Returns to privileged EXEC mode.

Step 14

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 15

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Monitoring CoA Functionality

Privileged EXEC show Commands

Command

Purpose

show aaa attributes protocol radius

Displays AAA attributes of RADIUS commands.

Global Troubleshooting Commands

Command

Purpose

debug radius

Displays information for troubleshooting RADIUS.

debug aaa coa

Displays information for troubleshooting CoA processing.

debug aaa pod

Displays information for troubleshooting POD packets.

debug aaa subsys

Displays information for troubleshooting POD packets.

debug cmdhd [detail | error | events]

Displays information for troubleshooting command headers.

For detailed information about the fields in these displays, see the command reference for this release.

Chapter 5. Configuring Kerberos

- Prerequisites for Controlling Switch Access with Kerberos

- Information about Kerberos

- How to Configure Kerberos

- Monitoring the Kerberos Configuration

- Additional References

Prerequisites for Controlling Switch Access with Kerberos

The following are the prerequisites for controlling switch access with Kerberos.

- So that remote users can authenticate to network services, you must configure the hosts and the KDC in the Kerberos realm to communicate and mutually authenticate users and network services. To do this, you must identify them to each other. You add entries for the hosts to the Kerberos database on the KDC and add KEYTAB files generated by the KDC to all hosts in the Kerberos realm. You also create entries for the users in the KDC database.

- A Kerberos server can be a switch that is configured as a network security server and that can authenticate users by using the Kerberos protocol.

When you add or create entries for the hosts and users, follow these guidelines:

- The Kerberos principal name must be in all lowercase characters.

- The Kerberos instance name must be in all lowercase characters.

- The Kerberos realm name must be in all uppercase characters.

Information about Kerberos

This section provides Kerberos information.

- Kerberos and Switch Access

- Kerberos Overview

- Kerberos Operation

Kerberos and Switch Access

This section describes how to enable and configure the Kerberos security system, which authenticates requests for network resources by using a trusted third party.

Note

In the Kerberos configuration examples, the trusted third party can be any switch that supports Kerberos, that is configured as a network security server, and that can authenticate users by using the Kerberos protocol.

Kerberos Overview

Kerberos is a secret-key network authentication protocol, which was developed at the Massachusetts Institute of Technology (MIT). It uses the Data Encryption Standard (DES) cryptographic algorithm for encryption and authentication and authenticates requests for network resources. Kerberos uses the concept of a trusted third party to perform secure verification of users and services. This trusted third party is called the key distribution center (KDC).

Kerberos verifies that users are who they claim to be and the network services that they use are what the services claim to be. To do this, a KDC or trusted Kerberos server issues tickets to users. These tickets, which have a limited life span, are stored in user credential caches. The Kerberos server uses the tickets instead of user names and passwords to authenticate users and network services.

Note

A Kerberos server can be any switch that is configured as a network security server and that can authenticate users by using the Kerberos protocol.

The Kerberos credential scheme uses a process called single logon. This process authenticates a user once and then allows secure authentication (without encrypting another password) wherever that user credential is accepted.

This software release supports Kerberos 5, which allows organizations that are already using Kerberos 5 to use the same Kerberos authentication database on the KDC that they are already using on their other network hosts (such as UNIX servers and PCs).

Kerberos supports these network services:

- Telnet

- rlogin

- rsh

This table lists the common Kerberos-related terms and definitions.

Kerberos Terms

Term

Definition

Authentication

A process by which a user or service identifies itself to another service. For example, a client can authenticate to a switch or a switch can authenticate to another switch.

Authorization

A means by which the switch identifies what privileges the user has in a network or on the switch and what actions the user can perform.

Credential

A general term that refers to authentication tickets, such as TGTs[1] and service credentials. Kerberos credentials verify the identity of a user or service. If a network service decides to trust the Kerberos server that issued a ticket, it can be used in place of re-entering a username and password. Credentials have a default life span of eight hours.

Instance

An authorization level label for Kerberos principals. Most Kerberos principals are of the form user@REALM (for example, smith@EXAMPLE.COM). A Kerberos principal with a Kerberos instance has the form user/instance@REALM (for example, smith/admin@EXAMPLE.COM). The Kerberos instance can be used to specify the authorization level for the user if authentication is successful. The server of each network service might implement and enforce the authorization mappings of Kerberos instances but is not required to do so.

Note

The Kerberos principal and instance names must be in all lowercase characters.

Note

The Kerberos realm name must be in all uppercase characters.

KDC[2]

Key distribution center that consists of a Kerberos server and database program that is running on a network host.

Kerberized

A term that describes applications and services that have been modified to support the Kerberos credential infrastructure.

Kerberos realm

A domain consisting of users, hosts, and network services that are registered to a Kerberos server. The Kerberos server is trusted to verify the identity of a user or network service to another user or network service.

Note

The Kerberos realm name must be in all uppercase characters.

Kerberos server

A daemon that is running on a network host. Users and network services register their identity with the Kerberos server. Network services query the Kerberos server to authenticate to other network services.

KEYTAB[3]

A password that a network service shares with the KDC. In Kerberos 5 and later Kerberos versions, the network service authenticates an encrypted service credential by using the KEYTAB to decrypt it. In Kerberos versions earlier than Kerberos 5, KEYTAB is referred to as SRVTAB[4].

Principal

Also known as a Kerberos identity, this is who you are or what a service is according to the Kerberos server.

Note

The Kerberos principal name must be in all lowercase characters.

Service credential

A credential for a network service. When issued from the KDC, this credential is encrypted with the password shared by the network service and the KDC. The password is also shared with the user TGT.

SRVTAB

A password that a network service shares with the KDC. In Kerberos 5 or later Kerberos versions, SRVTAB is referred to as KEYTAB.

TGT

Ticket granting ticket that is a credential that the KDC issues to authenticated users. When users receive a TGT, they can authenticate to network services within the Kerberos realm represented by the KDC.

[1] ticket granting ticket

[2] key distribution center

[3] key table

[4] server table

Kerberos Operation

A Kerberos server can be a device that is configured as a network security server and that can authenticate remote users by using the Kerberos protocol. Although you can customize Kerberos in a number of ways, remote users attempting to access network services must pass through three layers of security before they can access network services.

To authenticate to network services by using a device as a Kerberos server, remote users must follow these steps:

- Authenticating to a Boundary Switch

- Obtaining a TGT from a KDC

- Authenticating to Network Services

Authenticating to a Boundary Switch

This section describes the first layer of security through which a remote user must pass. The user must first authenticate to the boundary switch. This process then occurs:

1. The user opens an un-Kerberized Telnet connection to the boundary switch.

2. The switch prompts the user for a username and password.

3. The switch requests a TGT from the KDC for this user.

4. The KDC sends an encrypted TGT that includes the user identity to the switch.

5. The switch attempts to decrypt the TGT by using the password that the user entered.

- If the decryption is successful, the user is authenticated to the switch.

- If the decryption is not successful, the user repeats Step 2 either by re-entering the username and password (noting if Caps Lock or Num Lock is on or off) or by entering a different username and password.

A remote user who initiates a un-Kerberized Telnet session and authenticates to a boundary switch is inside the firewall, but the user must still authenticate directly to the KDC before getting access to the network services. The user must authenticate to the KDC because the TGT that the KDC issues is stored on the switch and cannot be used for additional authentication until the user logs on to the switch.

Obtaining a TGT from a KDC

This section describes the second layer of security through which a remote user must pass. The user must now authenticate to a KDC and obtain a TGT from the KDC to access network services.

For instructions about how to authenticate to a KDC, see the “Obtaining a TGT from a KDC” section in the “Security Server Protocols” chapter of the Cisco IOS Security Configuration Guide, Release 12.4.

Authenticating to Network Services

This section describes the third layer of security through which a remote user must pass. The user with a TGT must now authenticate to the network services in a Kerberos realm.

For instructions about how to authenticate to a network service, see the “Authenticating to Network Services” section in the “Security Server Protocols” chapter of the Cisco IOS Security Configuration Guide, Release 12.4.

How to Configure Kerberos

To set up a Kerberos-authenticated server-client system, follow these steps:

- Configure the KDC by using Kerberos commands.

- Configure the switch to use the Kerberos protocol.

Monitoring the Kerberos Configuration

To display the Kerberos configuration, use the following commands:

- show running-config

- show kerberos creds : Lists the credentials in a current user’s credentials cache.

- clear kerberos creds : Destroys all credentials in a current user’s credentials cache, including those forwarded.

Additional References

Related Documents

Related Topic

Document Title

Kerberos Commands

Cisco IOS Security Command Reference

Error Message Decoder

Description

Link

To help you research and resolve system error messages in this release, use the Error Message Decoder tool.

https://www.cisco.com/cgi-bin/Support/Errordecoder/index.cgi

MIBs

MIB

MIBs Link

All the supported MIBs for this release.

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

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

Technical Assistance

Description

Link

The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies.

To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.

Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.

http://www.cisco.com/support

Chapter 6. MACsec Encryption

- Information About MACsec Encryption

Information About MACsec Encryption

MACsec is the IEEE 802.1AE standard for authenticating and encrypting packets between two MACsec-capable devices. These Catalyst switches support 802.1AE encryption with MACsec Key Agreement (MKA) on downlink ports for encryption between the switch and host device. The switch also supports MACsec encryption for switch-to-switch (inter-network device) security using both Cisco TrustSec Network Device Admission Control (NDAC), Security Association Protocol (SAP) and MKA-based key exchange protocol. Link layer security can include both packet authentication between switches and MACsec encryption between switches (encryption is optional).

Note

MACsec is not supported with the NPE license or the LAN Base service image.

MACsec Support on Switch Ports

Interface

Connections

MACsec support

Downlink ports

Switch-to-host

MACsec MKA encryption

Uplink ports

Switch-to-switch

MACsec MKA encryption

Cisco TrustSec NDAC MACsec

Cisco TrustSec and Cisco SAP are meant only for switch-to-switch links and are not supported on switch ports connected to end hosts, such as PCs or IP phones. MKA is supported on switch-to-host facing links (downlink) as well as switch-to-switch links (uplink). Host-facing links typically use flexible authentication ordering for handling heterogeneous devices with or without IEEE 802.1x, and can optionally use MKA-based MACsec encryption. Cisco NDAC and SAP are mutually exclusive with Network Edge Access Topology (NEAT), which is used for compact switches to extend security outside the wiring closet.

- Media Access Control Security and MACsec Key Agreement

- Information About MACsec MKA using EAP-TLS

- Information About MKA/MACsec for Port Channel

- Information About MACsec Cipher Announcment

- MACsec Connections Across Intermediate Switches

- Cisco TrustSec Overview

Media Access Control Security and MACsec Key Agreement

MACsec, defined in 802.1AE, provides MAC-layer encryption over wired networks by using out-of-band methods for encryption keying. The MACsec Key Agreement (MKA) Protocol provides the required session keys and manages the required encryption keys. MKA and MACsec are implemented after successful authentication using the 802.1x Extensible Authentication Protocol (EAP-TLS) or Pre Shared Key (PSK) framework.

A switch using MACsec accepts either MACsec or non-MACsec frames, depending on the policy associated with the MKA peer. MACsec frames are encrypted and protected with an integrity check value (ICV). When the switch receives frames from the MKA peer, it decrypts them and calculates the correct ICV by using session keys provided by MKA. The switch compares that ICV to the ICV within the frame. If they are not identical, the frame is dropped. The switch also encrypts and adds an ICV to any frames sent over the secured port (the access point used to provide the secure MAC service to a MKA peer) using the current session key.

The MKA Protocol manages the encryption keys used by the underlying MACsec protocol. The basic requirements of MKA are defined in 802.1x-REV. The MKA Protocol extends 802.1x to allow peer discovery with confirmation of mutual authentication and sharing of MACsec secret keys to protect data exchanged by the peers.

The EAP framework implements MKA as a newly defined EAP-over-LAN (EAPOL) packet. EAP authentication produces a master session key (MSK) shared by both partners in the data exchange. Entering the EAP session ID generates a secure connectivity association key name (CKN). The switch acts as the authenticator for both uplink and downlink; and acts as the key server for downlink. It generates a random secure association key (SAK), which is sent to the client partner. The client is never a key server and can only interact with a single MKA entity, the key server. After key derivation and generation, the switch sends periodic transports to the partner at a default interval of 2 seconds.

The packet body in an EAPOL Protocol Data Unit (PDU) is referred to as a MACsec Key Agreement PDU (MKPDU). MKA sessions and participants are deleted when the MKA lifetime (6 seconds) passes with no MKPDU received from a participant. For example, if a MKA peer disconnects, the participant on the switch continues to operate MKA until 6 seconds have elapsed after the last MKPDU is received from the MKA peer.

Note

Integrity check value (ICV) indicator in MKPDU is optional. ICV is not optional when the traffic is encrypted.

EAPoL Announcements indicate the use of the type of keying material. The announcements can be used to announce the capability of the supplicant as well as the authenticator. Based on the capability of each side, the largest common denominator of the keying material could be used.

Prior to Cisco IOS XE Fuji 16.8.1a, should-secure was supported for MKA and SAP. With should-secure enabled, if the peer is configured for MACsec, the data traffic is encrypted, otherwise it is sent in clear text. Starting with Cisco IOS XE Fuji 16.8.1a, must-secure support is enabled on both the ingress and the egress. Must-secure is supported for MKA and SAP. With must-secure enabled, only EAPoL traffic will not be encrypted. The rest of the traffic will be encrypted. Unencrypted packets are dropped.

Note

Must-secure mode is enabled by default.

- MKA Policies

- Virtual Ports

- MACsec and Stacking

- MACsec, MKA and 802.1x Host Modes

MKA Policies

To enable MKA on an interface, a defined MKA policy should be applied to the interface. You can configure these options:

- Policy name, not to exceed 16 ASCII characters.

- Confidentiality (encryption) offset of 0, 30, or 50 bytes for each physical interface

Virtual Ports

Use virtual ports for multiple secured connectivity associations on a single physical port. Each connectivity association (pair) represents a virtual port. In uplink, you can have only one virtual port per physical port. In downlink, you can have a maximum of two virtual ports per physical port, of which one virtual port can be part of a data VLAN; the other must externally tag its packets for the voice VLAN. You cannot simultaneously host secured and unsecured sessions in the same VLAN on the same port. Because of this limitation, 802.1x multiple authentication mode is not supported.

The exception to this limitation is in multiple-host mode when the first MACsec supplicant is successfully authenticated and connected to a hub that is connected to the switch. A non-MACsec host connected to the hub can send traffic without authentication because it is in multiple-host mode. We do not recommend using multi-host mode because after the first successful client, authentication is not required for other clients.

Virtual ports represent an arbitrary identifier for a connectivity association and have no meaning outside the MKA Protocol. A virtual port corresponds to a separate logical port ID. Valid port IDs for a virtual port are 0x0002 to 0xFFFF. Each virtual port receives a unique secure channel identifier (SCI) based on the MAC address of the physical interface concatenated with a 16-bit port ID.

MACsec and Stacking

A switch active switch running MACsec maintains the configuration files that show which ports on a member switch support MACsec. The active switch performs these functions:

- Processes secure channel and secure association creation and deletion

- Sends secure association service requests to the member switches.

- Processes packet number and replay-window information from local or remote ports and notifies the key management protocol.

- Sends MACsec initialization requests with the globally configured options to new switches that are added to the stack.

- Sends any per-port configuration to the member switches.

A member switch performs these functions:

- Processes MACsec initialization requests from the active switch.

- Processes MACsec service requests sent by the active switch.

- Sends information about local ports to the active switch.

MACsec, MKA and 802.1x Host Modes

You can use MACsec and the MKA Protocol with 802.1x single-host mode, multi-host mode, or Multi Domain Authentication (MDA) mode. Multiple authentication mode is not supported.

- Single-Host Mode

- Multiple Host Mode

- MKA Statistics

Single-Host Mode

The figure shows how a single EAP authenticated session is secured by MACsec by using MKA

MACsec in Single-Host Mode with a Secured Data Session

Multiple Host Mode

In standard (not 802.1x REV) 802.1x multiple-host mode, a port is open or closed based on a single authentication. If one user, the primary secured client services client host, is authenticated, the same level of network access is provided to any host connected to the same port. If a secondary host is a MACsec supplicant, it cannot be authenticated and traffic would not flow. A secondary host that is a non-MACsec host can send traffic to the network without authentication because it is in multiple-host mode. The figure shows MACsec in Standard Multiple-Host Unsecure Mode.

MACsec in Multiple-Host Mode - Unsecured

Note

Multi-host mode is not recommended because after the first successful client, authentication is not required for other clients, which is not secure.

In standard (not 802.1x REV) 802.1x multiple-domain mode, a port is open or closed based on a single authentication. If the primary user, a PC on data domain, is authenticated, the same level of network access is provided to any domain connected to the same port. If a secondary user is a MACsec supplicant, it cannot be authenticated and traffic would no flow. A secondary user, an IP phone on voice domain, that is a non-MACsec host, can send traffic to the network without authentication because it is in multiple-domain mode.

MKA Statistics

Some MKA counters are aggregated globally, while others are updated both globally and per session. You can also obtain information about the status of MKA sessions.

This is an example of the show mka sessions command output:

Device# show mka sessions

Total MKA Sessions....... 1
Secured Sessions... 1
Pending Sessions... 0

====================================================================================================
Interface      Local-TxSCI         Policy-Name      Inherited         Key-Server
Port-ID        Peer-RxSCI          MACsec-Peers     Status            CKN
====================================================================================================
Gi1/0/1        204c.9e85.ede4/002b p2               NO                YES
43             c800.8459.e764/002a 1                Secured           0100000000000000000000000000000000000000000000000000000000000000

Device# show mka sessions interface G1/0/1

Summary of All Currently Active MKA Sessions on Interface GigabitEthernet1/0/1...

====================================================================================================
Interface      Local-TxSCI         Policy-Name      Inherited         Key-Server
Port-ID        Peer-RxSCI          MACsec-Peers     Status            CKN
====================================================================================================
Gi1/0/1        204c.9e85.ede4/002b p2               NO                YES
43             c800.8459.e764/002a 1                Secured           0100000000000000000000000000000000000000000000000000000000000000

Device# show mka sessions interface G1/0/1 de

MKA Detailed Status for MKA Session
===================================
Status: SECURED - Secured MKA Session with MACsec

Local Tx-SCI............. 204c.9e85.ede4/002b
Interface MAC Address.... 204c.9e85.ede4
MKA Port Identifier...... 43
Interface Name........... GigabitEthernet1/0/1
Audit Session ID.........
CAK Name (CKN)........... 0100000000000000000000000000000000000000000000000000000000000000
Member Identifier (MI)... D46CBEC05D5D67594543CEAE
Message Number (MN)...... 89567
EAP Role................. NA
Key Server............... YES
MKA Cipher Suite......... AES-128-CMAC

Latest SAK Status........ Rx & Tx
Latest SAK AN............ 0
Latest SAK KI (KN)....... D46CBEC05D5D67594543CEAE00000001 (1)
Old SAK Status........... FIRST-SAK
Old SAK AN............... 0
Old SAK KI (KN).......... FIRST-SAK (0)

SAK Transmit Wait Time... 0s (Not waiting for any peers to respond)
SAK Retire Time.......... 0s (No Old SAK to retire)

MKA Policy Name.......... p2
Key Server Priority...... 2
Delay Protection......... NO
Replay Protection........ YES
Replay Window Size....... 0
Confidentiality Offset... 0
Algorithm Agility........ 80C201
Send Secure Announcement.. DISABLED
SAK Cipher Suite......... 0080C20001000001 (GCM-AES-128)
MACsec Capability........ 3 (MACsec Integrity, Confidentiality, & Offset)
MACsec Desired........... YES

# of MACsec Capable Live Peers............ 1
# of MACsec Capable Live Peers Responded.. 1

Live Peers List:
MI                        MN          Rx-SCI (Peer)        KS Priority
----------------------------------------------------------------------
38046BA37D7DA77E06D006A9  89555       c800.8459.e764/002a   10

Potential Peers List:
MI                        MN          Rx-SCI (Peer)        KS Priority
----------------------------------------------------------------------

Dormant Peers List:
MI                        MN          Rx-SCI (Peer)        KS Priority
----------------------------------------------------------------------

Device# show mka sessions detail

MKA Detailed Status for MKA Session
===================================
Status: SECURED - Secured MKA Session with MACsec

Local Tx-SCI............. 204c.9e85.ede4/002b
Interface MAC Address.... 204c.9e85.ede4
MKA Port Identifier...... 43
Interface Name........... GigabitEthernet1/0/1
Audit Session ID.........
CAK Name (CKN)........... 0100000000000000000000000000000000000000000000000000000000000000
Member Identifier (MI)... D46CBEC05D5D67594543CEAE
Message Number (MN)...... 89572
EAP Role................. NA
Key Server............... YES
MKA Cipher Suite......... AES-128-CMAC

Latest SAK Status........ Rx & Tx
Latest SAK AN............ 0
Latest SAK KI (KN)....... D46CBEC05D5D67594543CEAE00000001 (1)
Old SAK Status........... FIRST-SAK
Old SAK AN............... 0
Old SAK KI (KN).......... FIRST-SAK (0)

SAK Transmit Wait Time... 0s (Not waiting for any peers to respond)
SAK Retire Time.......... 0s (No Old SAK to retire)

MKA Policy Name.......... p2
Key Server Priority...... 2
Delay Protection......... NO
Replay Protection........ YES
Replay Window Size....... 0
Confidentiality Offset... 0
Algorithm Agility........ 80C201
SAK Cipher Suite......... 0080C20001000001 (GCM-AES-128)
MACsec Capability........ 3 (MACsec Integrity, Confidentiality, & Offset)
MACsec Desired........... YES

# of MACsec Capable Live Peers............ 1
# of MACsec Capable Live Peers Responded.. 1

Live Peers List:
MI                        MN          Rx-SCI (Peer)        KS Priority
----------------------------------------------------------------------
38046BA37D7DA77E06D006A9  89560       c800.8459.e764/002a   10

Potential Peers List:
MI                        MN          Rx-SCI (Peer)        KS Priority
----------------------------------------------------------------------

Dormant Peers List:
MI                        MN          Rx-SCI (Peer)        KS Priority
----------------------------------------------------------------------

Device# show mka policy

MKA Policy Summary...

Policy            KS       Delay   Replay  Window Conf   Cipher          Interfaces
Name              Priority Protect Protect Size   Offset Suite(s)        Applied
======================================================================================================
*DEFAULT POLICY*  0        FALSE   TRUE    0      0      GCM-AES-128

p1                1        FALSE   TRUE    0      0      GCM-AES-128

p2                2        FALSE   TRUE    0      0      GCM-AES-128     Gi1/0/1

Device# show mka policy p2 detail

MKA Policy Configuration ("p2")
========================
MKA Policy Name........ p2
Key Server Priority.... 2
Confidentiality Offset. 0
Send Secure Announcement..DISABLED
Cipher Suite(s)........ GCM-AES-128

Applied Interfaces...
GigabitEthernet1/0/1

This is an example of the show mka statistics command output:

Device# show mka statistics interface G1/0/1

MKA Statistics for Session
==========================
Reauthentication Attempts.. 0

CA Statistics
Pairwise CAKs Derived... 0
Pairwise CAK Rekeys..... 0
Group CAKs Generated.... 0
Group CAKs Received..... 0

SA Statistics
SAKs Generated.......... 1
SAKs Rekeyed............ 0
SAKs Received........... 0
SAK Responses Received.. 1

MKPDU Statistics
MKPDUs Validated & Rx... 89585
"Distributed SAK".. 0
"Distributed CAK".. 0
MKPDUs Transmitted...... 89596
"Distributed SAK".. 1
"Distributed CAK".. 0

Device# show mka summary

Total MKA Sessions....... 1
Secured Sessions... 1
Pending Sessions... 0

====================================================================================================
Interface      Local-TxSCI         Policy-Name      Inherited         Key-Server
Port-ID        Peer-RxSCI          MACsec-Peers     Status            CKN
====================================================================================================
Gi1/0/1        204c.9e85.ede4/002b p2               NO                YES
43             c800.8459.e764/002a 1                Secured           0100000000000000000000000000000000000000000000000000000000000000

MKA Global Statistics
=====================
MKA Session Totals
Secured.................... 1
Reauthentication Attempts.. 0

Deleted (Secured).......... 0
Keepalive Timeouts......... 0

CA Statistics
Pairwise CAKs Derived...... 0
Pairwise CAK Rekeys........ 0
Group CAKs Generated....... 0
Group CAKs Received........ 0

SA Statistics
SAKs Generated............. 1
SAKs Rekeyed............... 0
SAKs Received.............. 0
SAK Responses Received..... 1

MKPDU Statistics
MKPDUs Validated & Rx...... 89589
"Distributed SAK"..... 0
"Distributed CAK"..... 0
MKPDUs Transmitted......... 89600
"Distributed SAK"..... 1
"Distributed CAK"..... 0

MKA Error Counter Totals
========================
Session Failures
Bring-up Failures................ 0
Reauthentication Failures........ 0
Duplicate Auth-Mgr Handle........ 0

SAK Failures
SAK Generation................... 0
Hash Key Generation.............. 0
SAK Encryption/Wrap.............. 0
SAK Decryption/Unwrap............ 0
SAK Cipher Mismatch.............. 0

CA Failures
Group CAK Generation............. 0
Group CAK Encryption/Wrap........ 0
Group CAK Decryption/Unwrap...... 0
Pairwise CAK Derivation.......... 0
CKN Derivation................... 0
ICK Derivation................... 0
KEK Derivation................... 0
Invalid Peer MACsec Capability... 0
MACsec Failures
Rx SC Creation................... 0
Tx SC Creation................... 0
Rx SA Installation............... 0
Tx SA Installation............... 0

MKPDU Failures
MKPDU Tx......................... 0
MKPDU Rx Validation.............. 0
MKPDU Rx Bad Peer MN............. 0
MKPDU Rx Non-recent Peerlist MN.. 0

Information About MACsec MKA using EAP-TLS

MACsec MKA is supported on switch-to-switch links. Using IEE 802.1X Port-based Authentication with Extensible Authentication Protocol (EAP-TLS), you can configure MACsec MKA between device uplink ports. EAP-TLS allows mutual authentication and obtains an MSK (master session key) from which the connectivity association key (CAK) is derived for MKA operations. Device certificates are carried, using EAP-TLS, for authentication to the AAA server.

- Prerequisites for MACsec MKA using EAP-TLS

- Limitations for MACsec MKA using EAP-TLS

Prerequisites for MACsec MKA using EAP-TLS

- Ensure that you have a Certificate Authority (CA) server configured for your network.

- Generate a CA certificate.

- Ensure that you have configured Cisco Identity Services Engine (ISE) Release 2.0.

- Ensure that both the participating devices, the CA server, and Cisco Identity Services Engine (ISE) are synchronized using Network Time Protocol (NTP). If time is not synchronized on all your devices, certificates will not be validated.

- Ensure that 802.1x authentication and AAA are configured on your device.

Limitations for MACsec MKA using EAP-TLS

- MKA is not supported on port-channels.

- MKA is not supported with High Availability and local authentication.

- MKA/EAPTLS is not supported for promiscuous PVLAN Primary port.

- While configuring MACsec MKA using EAP-TLS, MACsec secure channels encrypt counters does not increment before first Rekey.

Information About MKA/MACsec for Port Channel

MKA/MACsec can be configured on the port members of a port channel. MKA/MACsec is agnostic to the port channel since the MKA session is established between the port members of a port channel.

Note

Etherchannel links that are formed as part of the port channel can either be congruent or disparate i.e. the links can either be MACsec-secured or non-MACsec-secured. MKA session between the port members is established even if a port member on one side of the port channel is not configured with MACsec.

It is recommended that you enable MKA/MACsec on all the member ports for better security of the port channel.

Information About MACsec Cipher Announcment

Cipher Announcement allows the supplicant and the authenticator to announce their respective MACsec Cipher Suite capabilities to each other. Both, the supplicant and the authenticator, calculate the largest common supported MACsec Cipher Suite and use the same as the keying material for the MKA session.

Note

Only the MACsec Cipher Suite capabilities which are configured in the MKA policy are announced from the authenticator to the supplicant.

There are two types of EAPoL Announcements :

- Unsecured Announcements (EAPoL PDUs) : Unsecured announcments are EAPoL announcements carrying MACsec Cipher Suite capabilities in an unsecured manner. These announcements are used to decide the width of the key used for MKA session prior to authentication.

- Secure Announcements (MKPDUs) : Secure announcements revalidate the MACsec Cipher Suite capabilities which were shared previously through unsecure announcements.

Once the session is authenticated, peer capabilities which were received through EAPoL announcements are revalidated with the secure announcements. If there is a mismatch in the capabilities, the MKA session tears down.

- Limitations for MACsec Cipher Announcement

Limitations for MACsec Cipher Announcement

- If MACsec Cipher Suite Capabilities get changed in an active policy at the authenticator, the updated capabilities are not take into effect until a shutdown/no shutdown is performed on the interface. If you do not disable and restart the interface, EAPoL Announcement continues to announce the older capabilities.

- The MKA session between the supplicant and the authenticator does not tear down even if the MACsec Cipher Suite Capabilities configured on both do not result in a common cipher suite.

MACsec Connections Across Intermediate Switches

Prior to Cisco IOS XE Gibraltar 16.11.1, MACsec connection between end devices which have WAN MACsec configured with the intermediate switches as the Cisco Catalyst 3650 and 3850 Series Switches was not supported. The encrypted packets were dropped if WAN MACsec was configured on the end devices with MACsec not configured on the intermediate switches. With the ClearTag feature implemented on the ASIC, the switch forwards the encrypted packet without parsing the MACsec header.

- Limitations for MACsec Connections Across Intermediate Switches

Limitations for MACsec Connections Across Intermediate Switches

- Hop-by-hop MACsec encryption with Catalyst 3650 and 3850 Series switches as intermediate switches where WAN MACsec is configured on the routers is not supported.

- WAN MACsec configured on the routers with intermediate switches as the Catalyst 3650 and 3850 Series switches is not supported on Layer 3 VPNs.

- WAN MACsec configured on the routers with intermediate switches as the Catalyst 3650 and 3850 Series switches show Cisco Discovery Protocol neighbors only in should-secure mode.

Cisco TrustSec Overview

The table below lists the TrustSec features to be eventually implemented on TrustSec-enabled Cisco switches. Successive general availability releases of TrustSec will expand the number of switches supported and the number of TrustSec features supported per switch.

Cisco TrustSec Feature

Description

802.1AE Tagging (MACsec)

Protocol for IEEE 802.1AE-based wire-rate hop-to-hop Layer 2 encryption.

Between MACsec-capable devices, packets are encrypted on egress from the transmitting device, decrypted on ingress to the receiving device, and in the clear within the devices.

This feature is only available between TrustSec hardware-capable devices.

Endpoint Admission Control (EAC)

EAC is an authentication process for an endpoint user or a device connecting to the TrustSec domain. Usually EAC takes place at the access level switch. Successful authentication and authorization in the EAC process results in Security Group Tag assignment for the user or device. Currently EAC can be 802.1X, MAC Authentication Bypass (MAB), and Web Authentication Proxy (WebAuth).

Network Device Admission Control (NDAC)

NDAC is an authentication process where each network device in the TrustSec domain can verify the credentials and trustworthiness of its peer device. NDAC utilizes an authentication framework based on IEEE 802.1X port-based authentication and uses EAP-FAST as its EAP method. Successful authentication and authorization in NDAC process results in Security Association Protocol negotiation for IEEE 802.1AE encryption.

Security Association Protocol (SAP)

After NDAC authentication, the Security Association Protocol (SAP) automatically negotiates keys and the cipher suite for subsequent MACSec link encryption between TrustSec peers. SAP is defined in IEEE 802.11i.

Security Group Tag (SGT)

An SGT is a 16-bit single label indicating the security classification of a source in the TrustSec domain. It is appended to an Ethernet frame or an IP packet.

SGT Exchange Protocol (SXP)

Security Group Tag Exchange Protocol (SXP). With SXP, devices that are not TrustSec-hardware-capable can receive SGT attributes for authenticated users and devices from the Cisco Identity Services Engine (ISE) or the Cisco Secure Access Control System (ACS). The devices can then forward a sourceIP-to-SGT binding to a TrustSec-hardware-capable device will tag the source traffic for SGACL enforcement.

When both ends of a link support 802.1AE MACsec, SAP negotiation occurs. An EAPOL-key exchange occurs between the supplicant and the authenticator to negotiate a cipher suite, exchange security parameters, and manage keys. Successful completion of these tasks results in the establishment of a security association (SA).

Depending on your software version and licensing and link hardware support, SAP negotiation can use one of these modes of operation:

- Galois Counter Mode (GCM)—authentication and encryption

- GCM authentication (GMAC)— GCM authentication, no encryption

- No Encapsulation—no encapsulation (clear text)

- Null—encapsulation, no authentication or encryption

Default MACsec MKA Configuration

MACsec is disabled. No MKA policies are configured.

Configuring an MKA Policy

Procedure

Step 1

configure terminal

Enter global configuration mode.

Step 2

mka policy policy name

Identify an MKA policy, and enter MKA policy configuration mode. The maximum policy name length is 16 characters.

Note

The default MACsec cipher suite in the MKA policy will always be "GCM-AES-128". If the device supports both "GCM-AES-128" and "GCM-AES-256" ciphers, it is highly recommended to define and use a user defined MKA policy to include both 128 and 256 bits ciphers or only 256 bits cipher, as may be required.

Step 3

send-secure-announcements

Enabled secure announcements.

Note

By default, secure announcements are disabled.

Step 4

key-server priority

Configure MKA key server options and set priority (between 0-255).

Note

When value of key server priority is set to 255, the peer can not become the key server. The key server priority value is valid only for MKA PSK; and not for MKA EAPTLS.

Step 5

include-icv-indicator

Enables the ICV indicator in MKPDU. Use the no form of this command to disable the ICV indicator — no include-icv-indicator .

Step 6

macsec-cipher-suite gcm-aes-128

Configures cipher suite for deriving SAK with 128-bit encryption.

Step 7

confidentiality-offset Offset value

Set the Confidentiality (encryption) offset for each physical interface

Note

Offset Value can be 0, 30 or 50. If you are using Anyconnect on the client, it is recommended to use Offset 0.

Step 8

end

Returns to privileged EXEC mode.

Step 9

show mka policy

Verify your entries.

Example

This example configures the MKA policy:

Switch(config)# mka policy mka_policy
Switch(config-mka-policy)# key-server priority 200
Switch(config-mka-policy)# macsec-cipher-suite gcm-aes-128
Switch(config-mka-policy)# confidentiality-offset 30
Switch(config-mka-policy)# end

Configuring Switch-to-host MACsec Encryption

Follow these steps to configure MACsec on an interface with one MACsec session for voice and one for data:

Procedure

Step 1

enable

Example:

Switch>enable

Enables privileged EXEC mode. Enter the password if prompted.

Step 2

configureterminal

Example:

Switch>configure terminal

Enters the global configuration mode.

Step 3

interface interface-id

Identify the MACsec interface, and enter interface configuration mode. The interface must be a physical interface.

Step 4

switchport access vlan vlan-id

Configure the access VLAN for the port.

Step 5

switchport mode access

Configure the interface as an access port.

Step 6

macsec

Enable 802.1ae MACsec on the interface. The macsec command enables MKA MACsec on switch-to-host links (downlink ports) only.

Step 7

authentication event linksec fail action authorize vlan vlan-id

(Optional) Specify that the switch processes authentication link-security failures resulting from unrecognized user credentials by authorizing a restricted VLAN on the port after a failed authentication attempt.

Step 8

authentication host-mode multi-domain

Configure authentication manager mode on the port to allow both a host and a voice device to be authenticated on the 802.1x-authorized port. If not configured, the default host mode is single.

Step 9

authentication linksec policy must-secure

Set the LinkSec security policy to secure the session with MACsec if the peer is available. If not set, the default is should secure.

Step 10

authentication port-control auto

Enable 802.1x authentication on the port. The port changes to the authorized or unauthorized state based on the authentication exchange between the switch and the client.

Step 11

authentication periodic

Enable or Disable Reauthentication for this port .

Step 12

authentication timer reauthenticate

Enter a value between 1 and 65535 (in seconds). Obtains re-authentication timeout value from the server. Default re-authentication time is 3600 seconds.

Step 13

authentication violation protect

Configure the port to drop unexpected incoming MAC addresses when a new device connects to a port or when a device connects to a port after the maximum number of devices are connected to that port. If not configured, the default is to shut down the port.

Step 14

mka policy policy name

Apply an existing MKA protocol policy to the interface, and enable MKA on the interface. If no MKA policy was configured (by entering the mka policy global configuration command).

Step 15

dot1x pae authenticator

Configure the port as an 802.1x port access entity (PAE) authenticator.

Step 16

spanning-tree portfast

Enable spanning tree Port Fast on the interface in all its associated VLANs. When Port Fast feature is enabled, the interface changes directly from a blocking state to a forwarding state without making the intermediate spanning-tree state changes

Step 17

end

Example:

Switch(config)#end

Returns to privileged EXEC mode.

Step 18

show authentication session interface interface-id

Verify the authorized session security status.

Step 19

show authentication session interface interface-id details

Verify the details of the security status of the authorized session.

Step 20

show macsec interface interface-id

Verify MacSec status on the interface.

Step 21

show mka sessions

Verify the established mka sessions.

Step 22

copy running-config startup-config

Example:

Switch#copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Configuring MACsec MKA using PSK

Procedure

Step 1

configure terminal

Enter global configuration mode.

Step 2

key chain key-chain-name macsec

Configures a key chain and enters the key chain configuration mode.

Step 3

key hex-string

Configures a unique identifier for each key in the keychain and enters the keychain's key configuration mode.

Note

For 128-bit encryption, use 32 hex digit key-string. For 256-bit encryption, use 64 hex digit key-string.

Step 4

cryptographic-algorithm {gcm-aes-128 | gcm-aes-256}

Set cryptographic authentication algorithm with 128-bit or 256-bit encryption.

Step 5

key-string { [0|6|7] pwd-string | pwd-string}

Sets the password for a key string. Only hex characters must be entered.

Step 6

lifetime local [start timestamp {hh::mm::ss | day | month | year}] [duration seconds | end timestamp {hh::mm::ss | day | month | year}]

Sets the lifetime of the pre shared key.

Step 7

end

Returns to privileged EXEC mode.

Example

Following is an indicative example:

Switch(config)# Key chain keychain1 macsec
Switch(config-key-chain)# key 1000
Switch(config-keychain-key)# cryptographic-algorithm gcm-aes-128
Switch(config-keychain-key)# key-string 12345678901234567890123456789012
Switch(config-keychain-key)# lifetime local 12:12:00 July 28 2016 12:19:00 July 28 2016
Switch(config-keychain-key)# end

- Configuring MACsec MKA on an Interface using PSK

Configuring MACsec MKA on an Interface using PSK

Note

To avoid traffic drop across sessions, the mka policy command must be configured before the mka pre-shared-key key-chain command.

Procedure

Step 1

configure terminal

Enters global configuration mode.

Step 2

interface interface-id

Enters interface configuration mode.

Step 3

macsec network-link

Enables MACsec on the interface.

Note

The macsec network-link command does not block MKA sessions for downlink ports. Use the macsec command instead.

Step 4

mka policy policy-name

Configures an MKA policy.

Step 5

mka pre-shared-key key-chain key-chain name

Configures an MKA pre-shared-key key-chain name.

Note

The MKA pre-shared key can be configured on either physical interface or sub-interfaces and not on both.

Step 6

macsec replay-protection window-size frame number

Sets the MACsec window size for replay protection.

Step 7

end

Returns to privileged EXEC mode.

Example

Following is an indicative example:

Switch(config)# interface GigabitEthernet 0/0/0
Switch(config-if)# mka policy mka_policy
Switch(config-if)# mka pre-shared-key key-chain key-chain-name
Switch(config-if)# macsec replay-protection window-size 10
Switch(config-if)# end

What to do next

It is not recommended to change the MKA policy on an interface with MKA PSK configured when the session is running. However, if a change is required, you must reconfigure the policy as follows:

1. Disable the existing session by removing macsec network-link configuration on each of the participating node using the no macsec network-link command

2. Configure the MKA policy on the interface on each of the participating node using the mka policy policy-name command.

3. Enable the new session on each of the participating node by using the macsec network-link command.

Configuring MACsec MKA using EAP-TLS

To configure MACsec with MKA on point-to-point links, perform these tasks:

- Configure Certificate Enrollment

- Generate Key Pairs

- Configure SCEP Enrollment

- Configure Certificates Manually

- Configure an Authentication Policy

- Configure EAP-TLS Profiles and IEEE 802.1x Credentials

- Configure MKA MACsec using EAP-TLS on Interfaces

- Generating Key Pairs

- Configuring Enrollment using SCEP

- Configuring Enrollment Manually

- Applying the 802.1x MACsec MKA Configuration on Interfaces

Generating Key Pairs

Procedure

Step 1

configure terminal

Enter global configuration mode.

Step 2

crypto key generate rsa label label-name general-keys modulus size

Generates a RSA key pair for signing and encryption.

You can also assign a label to each key pair using the label keyword. The label is referenced by the trustpoint that uses the key pair. If you do not assign a label, the key pair is automatically labeled <Default-RSA-Key>.

If you do not use additional keywords this command generates one general purpose RSA key pair. If the modulus is not specified, the default key modulus of 1024 is used. You can specify other modulus sizes with the modulus keyword.

Step 3

end

Returns to privileged EXEC mode.

Step 4

show authentication session interface interface-id

Verifies the authorized session security status.

Step 5

copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Configuring Enrollment using SCEP

Simple Certificate Enrollment Protocol (SCEP) is a Cisco-developed enrollment protocol that uses HTTP to communicate with the certificate authority (CA) or registration authority (RA). SCEP is the most commonly used method for sending and receiving requests and certificates.

Procedure

Step 1

configure terminal

Enter global configuration mode.

Step 2

crypto pki trustpoint server name

Declares the trustpoint and a given name and enters ca-trustpoint configuration mode.

Step 3

enrollment url url name pem

Specifies the URL of the CA on which your device should send certificate requests.

An IPv6 address can be added in the URL enclosed in brackets. For example: http:// [2001:DB8:1:1::1]:80.

The pem keyword adds privacy-enhanced mail (PEM) boundaries to the certificate request.

Step 4

rsakeypair label

Specifies which key pair to associate with the certificate.

Note

The rsakeypair name must match the trust-point name.

Step 5

serial-number none

The none keyword specifies that a serial number will not be included in the certificate request.

Step 6

ip-address none

The none keyword specifies that no IP address should be included in the certificate request.

Step 7

revocation-check crl

Specifies CRL as the method to ensure that the certificate of a peer has not been revoked.

Step 8

auto-enroll percent regenerate

Enables auto-enrollment, allowing the client to automatically request a rollover certificate from the CA.

If auto-enrollment is not enabled, the client must be manually re-enrolled in your PKI upon certificate expiration.

By default, only the Domain Name System (DNS) name of the device is included in the certificate.

Use the percent argument to specify that a new certificate will be requested after the percentage of the lifetime of the current certificate is reached.

Use the regenerate keyword to generate a new key for the certificate even if a named key already exists.

If the key pair being rolled over is exportable, the new key pair will also be exportable. The following comment will appear in the trustpoint configuration to indicate whether the key pair is exportable: “! RSA key pair associated with trustpoint is exportable.”

It is recommended that a new key pair be generated for security reasons.

Step 9

crypto pki authenticate name

Retrieves the CA certificate and authenticates it.

Step 10

exit

Exits global configuration mode.

Step 11

show crypto pki certificate trustpoint name

Displays information about the certificate for the trust point.

Configuring Enrollment Manually

If your CA does not support SCEP or if a network connection between the router and CA is not possible. Perform the following task to set up manual certificate enrollment:

Procedure

Step 1

configure terminal

Enter global configuration mode.

Step 2

crypto pki trustpoint server name

Declares the trustpoint and a given name and enters ca-trustpoint configuration mode.

Step 3

enrollment url url name pem

Specifies the URL of the CA on which your device should send certificate requests.

An IPv6 address can be added in the URL enclosed in brackets. For example: http:// [2001:DB8:1:1::1]:80.

The pem keyword adds privacy-enhanced mail (PEM) boundaries to the certificate request.

Step 4

rsakeypair label

Specifies which key pair to associate with the certificate.

Step 5

serial-number none

The none keyword specifies that a serial number will not be included in the certificate request.

Step 6

ip-address none

The none keyword specifies that no IP address should be included in the certificate request.

Step 7

revocation-check crl

Specifies CRL as the method to ensure that the certificate of a peer has not been revoked.

Step 8

exit

Exits Global Configuration mode.

Step 9

crypto pki authenticate name

Retrieves the CA certificate and authenticates it.

Step 10

crypto pki enroll name

Generates certificate request and displays the request for copying and pasting into the certificate server.

Enter enrollment information when you are prompted. For example, specify whether to include the device FQDN and IP address in the certificate request.

You are also given the choice about displaying the certificate request to the console terminal.

The base-64 encoded certificate with or without PEM headers as requested is displayed.

Step 11

crypto pki import name certificate

Imports a certificate via TFTP at the console terminal, which retrieves the granted certificate.

The device attempts to retrieve the granted certificate via TFTP using the same filename used to send the request, except the extension is changed from “.req” to “.crt”. For usage key certificates, the extensions “-sign.crt” and “-encr.crt” are used.

The device parses the received files, verifies the certificates, and inserts the certificates into the internal certificate database on the switch.

Note

Some CAs ignore the usage key information in the certificate request and issue general purpose usage certificates. If your CA ignores the usage key information in the certificate request, only import the general purpose certificate. The router will not use one of the two key pairs generated.

Step 12

exit

Exits global configuration mode.

Step 13

show crypto pki certificate trustpoint name

Displays information about the certificate for the trust point.

Step 14

copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Applying the 802.1x MACsec MKA Configuration on Interfaces

To apply MACsec MKA using EAP-TLS to interfaces, perform the following task:

Procedure

Step 1

configure terminal

Enters global configuration mode.

Step 2

interface interface-id

Identifies the MACsec interface, and enter interface configuration mode. The interface must be a physical interface.

Step 3

macsec network-link

Enables MACsec on the interface.

Step 4

authentication periodic

Enables reauthentication for this port.

Step 5

authentication timer reauthenticate interval

Sets the reauthentication interval.

Step 6

access-session host-mode multi-domain

Allows hosts to gain access to the interface.

Step 7

access-session closed

Prevents preauthentication access on the interface.

Step 8

access-session port-control auto

Sets the authorization state of a port.

Step 9

dot1x pae both

Configures the port as an 802.1X port access entity (PAE) supplicant and authenticator.

Step 10

dot1x credentials profile

Assigns a 802.1x credentials profile to the interface.

Step 11

dot1x supplicant eap profile name

Assigns the EAP-TLS profile to the interface.

Step 12

service-policy type control subscriber control-policy name

Applies a subscriber control policy to the interface.

Step 13

exit

Returns to privileged EXEC mode.

Step 14

show macsec interface

Displays MACsec details for the interface.

Step 15

copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Configuring Cisco TrustSec MACsec

- Configuring Cisco TrustSec Switch-to-Switch Link Security in Manual Mode

Configuring Cisco TrustSec Switch-to-Switch Link Security in Manual Mode

Before you begin

When manually configuring Cisco TrustSec on an interface, consider these usage guidelines and restrictions:

- If no SAP parameters are defined, Cisco TrustSec encapsulation or encryption is not performed.

- If you select GCM as the SAP operating mode, you must have a MACsec Encryption software license from Cisco. If you select GCM without the required license, the interface is forced to a link-down state.

- These protection levels are supported when you configure SAP pairwise master key (sap pmk):

- SAP is not configured—no protection.

- sap mode-list gcm-encrypt gmac no-encap —protection desirable but not mandatory.

- sap mode-list gcm-encrypt gmac —confidentiality preferred and integrity required. The protection is selected by the supplicant according to supplicant preference.

- sap mode-list gmac —integrity only.

- sap mode-list gcm-encrypt —confidentiality required.

- sap mode-list gmac gcm-encrypt —integrity required and preferred, confidentiality optional.

- Before changing the configuration from MKA to Cisco TrustSec SAP and vice versa, we recommend that you remove the interface configuration.

Beginning in privileged EXEC mode, follow these steps to manually configure Cisco TrustSec on an interface to another Cisco TrustSec device:

Procedure

Step 1

configure terminal

Example:

Switch# configure terminal

Enters global configuration mode.

Step 2

interface interface-id

Example:

Switch(config)# interface tengigabitethernet 1/1/2

Note

Enters interface configuration mode.

Step 3

cts manual

Example:

Switch(config-if)# cts manual

Enters Cisco TrustSec manual configuration mode.

Step 4

sap pmk key [ mode-list mode1 [ mode2 [ mode3 [ mode4] ] ] ]

Example:

Switch(config-if-cts-manual)# sap pmk 1234abcdef mode-list gcm-encrypt null no-encap

(Optional) Configures the SAP pairwise master key (PMK) and operation mode. SAP is disabled by default in Cisco TrustSec manual mode.

- key —A hexadecimal value with an even number of characters and a maximum length of 32 characters.

The SAP operation mode options:

- gcm-encrypt —Authentication and encryption

Note

Select this mode for MACsec authentication and encryption if your software license supports MACsec encryption.

- gmac —Authentication, no encryption

- no-encap —No encapsulation

- null —Encapsulation, no authentication or encryption

Note

If the interface is not capable of data link encryption, no-encap is the default and the only available SAP operating mode. SGT is not supported.

Step 5

no propagate sgt

Example:

Switch(config-if-cts-manual)# no propagate sgt

Use the no form of this command when the peer is incapable of processing a SGT. The no propagate sgt command prevents the interface from transmitting the SGT to the peer.

Step 6

exit

Example:

Switch(config-if-cts-manual)# exit

Exits Cisco TrustSec 802.1x interface configuration mode.

Step 7

end

Example:

Switch(config-if)# end

Returns to privileged EXEC mode.

Step 8

show cts interface [ interface-id | brief | summary]

(Optional) Verify the configuration by displaying TrustSec-related interface characteristics.

Example

This example shows how to configure Cisco TrustSec authentication in manual mode on an interface:

Switch# configure terminal
Switch(config)# interface tengigabitethernet 1/1/2
Switch(config-if)# cts manual
Switch(config-if-cts-manual)# sap pmk 1234abcdef mode-list gcm-encrypt null no-encap
Switch(config-if-cts-manual)# no propagate sgt
Switch(config-if-cts-manual)# exit
Switch(config-if)# end

Configuring MKA/MACsec for Port Channel

- Configuring MKA/MACsec for Port Channel using PSK

- Configuring Port Channel Logical Interfaces for Layer 2 EtherChannels

- Configuring Port Channel Logical Interfaces for Layer 3 EtherChannels

Configuring MKA/MACsec for Port Channel using PSK

Procedure

Step 1

configure terminal

Enters global configuration mode.

Step 2

interface interface-id

Enters interface configuration mode.

Step 3

macsec network-link

Enables MACsec on the interface. Supports layer 2 and layer 3 port channels.

Step 4

mka policy policy-name

Configures an MKA policy.

Step 5

mka pre-shared-key key-chain key-chain-name

Configures an MKA pre-shared-key key-chain name.

Note

The MKA pre-shared key can be configured on either physical interface or sub-interfaces and not on both.

Step 6

channel-group channel-group-number mode {auto | desirable} | {active | passive} | {on}

Configures the port in a channel group and sets the mode. The channel-number range is from 1 to 4096. The port channel associated with this channel group is automatically created if the port channel does not already exist.For mode, select one of the following keywords:

- auto — Enables PAgP only if a PAgP device is detected. This places the port into a passive negotiating state, in which the port responds to PAgP packets it receives but does not start PAgP packet negotiation.

Note

The auto keyword is not supported when EtherChannel members are from different switches in the switch stack.

- desirable — Unconditionally enables PAgP. This places the port into an active negotiating state, in which the port starts negotiations with other ports by sending PAgP packets.

Note

The desirable keyword is not supported when EtherChannel members are from different switches in the switch stack.

- on — Forces the port to channel without PAgP or LACP. In the on mode, an EtherChannel exists only when a port group in the on mode is connected to another port group in the on mode.

- active — Enables LACP only if a LACP device is detected. It places the port into an active negotiating state in which the port starts negotiations with other ports by sending LACP packets.

- passive — Enables LACP on the port and places it into a passive negotiating state in which the port responds to LACP packets that it receives, but does not start LACP packet negotiation.

Step 7

end

Returns to privileged EXEC mode.

Configuring Port Channel Logical Interfaces for Layer 2 EtherChannels

To create a port channel interface for a Layer 2 EtherChannel, perform this task:

Procedure

Step 1

configure terminal

Enters global configuration mode.

Step 2

[no] interface port-channel channel-group-number

Creates the port channel interface.

Note

Use the no form of this command to delete the port channel interface.

Step 3

switchport

Switches an interface that is in Layer 3 mode into Layer 2 mode for Layer 2 configuration.

Step 4

switchport mode {access | trunk}

Assigns all ports as static-access ports in the same VLAN, or configure them as trunks.

Step 5

end

Returns to privileged EXEC mode.

Configuring Port Channel Logical Interfaces for Layer 3 EtherChannels

To create a port channel interface for a Layer 3 EtherChannel, perform this task:

Procedure

Step 1

configure terminal

Enters global configuration mode.

Step 2

interface interface-id

Enters interface configuration mode.

Step 3

no switchport

Switches an interface that is in Layer 2 mode into Layer 3 mode for Layer 3 configuration.

Step 4

ip address ip-address subnet_mask

Assigns an IP address and subnet mask to the EtherChannel.

Step 5

end

Returns to privileged EXEC mode.

Configuring MACsec Cipher Announcement

- Configuring an MKA Policy for Secure Announcement

- Configuring Secure Announcement Globally (Across all the MKA Policies)

- Configuring EAPoL Announcements on an interface

Configuring an MKA Policy for Secure Announcement

Procedure

Step 1

configure terminal

Enter global configuration mode.

Step 2

mka policy policy-name

Identify an MKA policy, and enter MKA policy configuration mode. The maximum policy name length is 16 characters.

Note

The default MACsec cipher suite in the MKA policy will always be "GCM-AES-128". If the device supports both "GCM-AES-128" and "GCM-AES-256" ciphers, it is highly recommended to define and use a user defined MKA policy to include both 128 and 256 bits ciphers or only 256 bits cipher, as may be required.

Step 3

key-server priority

Configure MKA key server options and set priority (between 0-255).

Note

When value of key server priority is set to 255, the peer can not become the key server. The key server priority value is valid only for MKA PSK; and not for MKA EAPTLS.

Step 4

[no] send-secure-announcements

Enables sending of secure announcements. Use the no form of the command to disable sending of secure announcements. By default, secure announcements are disabled.

Step 5

macsec-cipher-suite {gcm-aes-128 | gcm-aes-256}

Configures cipher suite for deriving SAK with 128-bit or 256-bit encryption.

Step 6

end

Returns to privileged EXEC mode.

Step 7

show mka policy

Verify your entries.

Configuring Secure Announcement Globally (Across all the MKA Policies)

Procedure

Step 1

configure terminal

Enter global configuration mode.

Step 2

[no] mka defaults policy send-secure-announcements

Enables sending of secure announcements in MKPDUs across MKA policies. By default, secure announcements are disabled.

Step 3

end

Returns to privileged EXEC mode.

Configuring EAPoL Announcements on an interface

Procedure

Step 1

configure terminal

Enter global configuration mode.

Step 2

interface interface-id

Identifies the MACsec interface, and enter interface configuration mode. The interface must be a physical interface.

Step 3

[no] eapol annoucement

Enable EAPoL announcements. Use the no form of the command to disable EAPoL announcements. By default,EAPoL announcements are disabled.

Step 4

end

Returns to privileged EXEC mode.

Configuring Switch-to-host MACsec Encryption

Follow these steps to configure MACsec on an interface with one MACsec session for voice and one for data:

Procedure

Step 1

enable

Example:

Switch>enable

Enables privileged EXEC mode. Enter the password if prompted.

Step 2

configureterminal

Example:

Switch>configure terminal

Enters the global configuration mode.

Step 3

interface interface-id

Identify the MACsec interface, and enter interface configuration mode. The interface must be a physical interface.

Step 4

switchport access vlan vlan-id

Configure the access VLAN for the port.

Step 5

switchport mode access

Configure the interface as an access port.

Step 6

macsec

Enable 802.1ae MACsec on the interface. The macsec command enables MKA MACsec on switch-to-host links (downlink ports) only.

Step 7

authentication event linksec fail action authorize vlan vlan-id

(Optional) Specify that the switch processes authentication link-security failures resulting from unrecognized user credentials by authorizing a restricted VLAN on the port after a failed authentication attempt.

Step 8

authentication host-mode multi-domain

Configure authentication manager mode on the port to allow both a host and a voice device to be authenticated on the 802.1x-authorized port. If not configured, the default host mode is single.

Step 9

authentication linksec policy must-secure

Set the LinkSec security policy to secure the session with MACsec if the peer is available. If not set, the default is should secure.

Step 10

authentication port-control auto

Enable 802.1x authentication on the port. The port changes to the authorized or unauthorized state based on the authentication exchange between the switch and the client.

Step 11

authentication periodic

Enable or Disable Reauthentication for this port .

Step 12

authentication timer reauthenticate

Enter a value between 1 and 65535 (in seconds). Obtains re-authentication timeout value from the server. Default re-authentication time is 3600 seconds.

Step 13

authentication violation protect

Configure the port to drop unexpected incoming MAC addresses when a new device connects to a port or when a device connects to a port after the maximum number of devices are connected to that port. If not configured, the default is to shut down the port.

Step 14

mka policy policy name

Apply an existing MKA protocol policy to the interface, and enable MKA on the interface. If no MKA policy was configured (by entering the mka policy global configuration command).

Step 15

dot1x pae authenticator

Configure the port as an 802.1x port access entity (PAE) authenticator.

Step 16

spanning-tree portfast

Enable spanning tree Port Fast on the interface in all its associated VLANs. When Port Fast feature is enabled, the interface changes directly from a blocking state to a forwarding state without making the intermediate spanning-tree state changes

Step 17

end

Example:

Switch(config)#end

Returns to privileged EXEC mode.

Step 18

show authentication session interface interface-id

Verify the authorized session security status.

Step 19

show authentication session interface interface-id details

Verify the details of the security status of the authorized session.

Step 20

show macsec interface interface-id

Verify MacSec status on the interface.

Step 21

show mka sessions

Verify the established mka sessions.

Step 22

copy running-config startup-config

Example:

Switch#copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Example: Configuring MACsec MKA for Port Channel using PSK

Etherchannel Mode — Static/On

The following is a sample configuration on Device 1 and Device 2 with EtherChannel Mode on.

key chain KC macsec
key 1000
cryptographic-algorithm aes-128-cmac
key-string FC8F5B10557C192F03F60198413D7D45
end

mka policy POLICY
key-server priority 0
macsec-cipher-suite gcm-aes-128
confidentiality-offset 0
end

interface Te1/0/1
channel-group 2 mode on
macsec network-link
mka policy POLICY
mka pre-shared-key key-chain KC
end

interface Te1/0/2
channel-group 2 mode on
macsec network-link
mka policy POLICY
mka pre-shared-key key-chain KC
end

Layer 2 EtherChannel Configuration

Device 1

interface port-channel 2
switchport
switchport mode trunk
no shutdown
end

Device 2

interface port-channel 2
switchport
switchport mode trunk
no shutdown
end

The following shows a sample output of show etherchannel summary command.

Flags:  D - down        P - bundled in port-channel
I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3      S - Layer2
U - in use      f - failed to allocate aggregator

M - not in use, minimum links not met
u - unsuitable for bundling
w - waiting to be aggregated
d - default port

A - formed by Auto LAG

Number of channel-groups in use: 1
Number of aggregators:           1

Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------------------------
2      Po2(RU)          -        Te1/0/1(P)  Te1/0/2(P)

Layer 3 EtherChannel Configuration

Device 1

interface port-channel 2
no switchport
ip address 10.25.25.3 255.255.255.0
no shutdown
end

Device 2

interface port-channel 2
no switchport
ip address 10.25.25.4 255.255.255.0
no shutdown
end

The following shows a sample output of show etherchannel summary command.

Flags:  D - down        P - bundled in port-channel
I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3      S - Layer2
U - in use      f - failed to allocate aggregator

M - not in use, minimum links not met
u - unsuitable for bundling
w - waiting to be aggregated
d - default port

A - formed by Auto LAG

Number of channel-groups in use: 1
Number of aggregators:           1

Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------------------------
2      Po2(RU)          -        Te1/0/1(P)  Te1/0/2(P)

Etherchannel Mode — LACP

The following is a sample configuration on Device 1 and Device 2 with EtherChannel Mode as LACP.

key chain KC macsec
key 1000
cryptographic-algorithm aes-128-cmac
key-string FC8F5B10557C192F03F60198413D7D45
end

mka policy POLICY
key-server priority 0
macsec-cipher-suite gcm-aes-128
confidentiality-offset 0
end

interface Te1/0/1
channel-group 2 mode active
macsec network-link
mka policy POLICY
mka pre-shared-key key-chain KC
end

interface Te1/0/2
channel-group 2 mode active
macsec network-link
mka policy POLICY
mka pre-shared-key key-chain KC
end

Layer 2 EtherChannel Configuration

Device 1

interface port-channel 2
switchport
switchport mode trunk
no shutdown
end

Device 2

interface port-channel 2
switchport
switchport mode trunk
no shutdown
end

The following shows a sample output of show etherchannel summary command.

Flags:  D - down        P - bundled in port-channel
I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3      S - Layer2
U - in use      f - failed to allocate aggregator

M - not in use, minimum links not met
u - unsuitable for bundling
w - waiting to be aggregated
d - default port

A - formed by Auto LAG

Number of channel-groups in use: 1
Number of aggregators:           1

------+-------------+-----------+-----------------------------------------------
2      Po2(SU)         LACP      Te1/1/1(P)  Te1/1/2(P)

Layer 3 EtherChannel Configuration

Device 1

interface port-channel 2
no switchport
ip address 10.25.25.3 255.255.255.0
no shutdown
end

Device 2

interface port-channel 2
no switchport
ip address 10.25.25.4 255.255.255.0
no shut

The following shows a sample output of show etherchannel summary command.

Flags:  D - down        P - bundled in port-channel
I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3      S - Layer2
U - in use      f - failed to allocate aggregator

M - not in use, minimum links not met
u - unsuitable for bundling
w - waiting to be aggregated
d - default port

A - formed by Auto LAG

Number of channel-groups in use: 1
Number of aggregators:           1

Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------------------------
2      Po2(RU)         LACP      Te1/1/1(P)  Te1/1/2(P)

Etherchannel Mode — PAgP

The following is a sample configuration on Device 1 and Device 2 with EtherChannel Mode as PAgP.

key chain KC macsec
key 1000
cryptographic-algorithm aes-128-cmac
key-string FC8F5B10557C192F03F60198413D7D45
end

mka policy POLICY
key-server priority 0
macsec-cipher-suite gcm-aes-128
confidentiality-offset 0
end

interface Te1/0/1
channel-group 2 mode desirable
macsec network-link
mka policy POLICY
mka pre-shared-key key-chain KC
end

interface Te1/0/2
channel-group 2 mode desirable
macsec network-link
mka policy POLICY
mka pre-shared-key key-chain KC
end

Layer 2 EtherChannel Configuration

Device 1

interface port-channel 2
switchport
switchport mode trunk
no shutdown
end

Device 2

interface port-channel 2
switchport
switchport mode trunk
no shutdown
end

The following shows a sample output of show etherchannel summary command.

Flags:  D - down        P - bundled in port-channel
I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3      S - Layer2
U - in use      f - failed to allocate aggregator

M - not in use, minimum links not met
u - unsuitable for bundling
w - waiting to be aggregated
d - default port

A - formed by Auto LAG

Number of channel-groups in use: 1
Number of aggregators:           1

------+-------------+-----------+-----------------------------------------------
2      Po2(SU)         PAgP      Te1/1/1(P)  Te1/1/2(P)

Layer 3 EtherChannel Configuration

Device 1

interface port-channel 2
no switchport
ip address 10.25.25.3 255.255.255.0
no shutdown
end

Device 2

interface port-channel 2
no switchport
ip address 10.25.25.4 255.255.255.0
no shutdown
end

The following shows a sample output of show etherchannel summary command.

Flags:  D - down        P - bundled in port-channel
I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3      S - Layer2
U - in use      f - failed to allocate aggregator

M - not in use, minimum links not met
u - unsuitable for bundling
w - waiting to be aggregated
d - default port

A - formed by Auto LAG

Number of channel-groups in use: 1
Number of aggregators:           1

Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------------------------
2      Po2(RU)         PAgP      Te1/1/1(P)  Te1/1/2(P)

Displaying Active MKA Sessions

The following shows all the active MKA sessions.

Device# show mka sessions interface Te1/0/1
====================================================================================================
Interface      Local-TxSCI         Policy-Name      Inherited         Key-Server
Port-ID        Peer-RxSCI          MACsec-Peers     Status            CKN
====================================================================================================
Te1/0/1        00a3.d144.3364/0025 POLICY           NO                NO
37             701f.539b.b0c6/0032 1                Secured           1000

Examples: Configuring MACsec Cipher Announcement

This example shows how to configure MKA policy for Secure Announcement:

Device# configure terminal
Device(config)# mka policy mka_policy
Device(config-mka-policy)# key-server 2
Device(config-mka-policy)# send-secure-announcements
Device(config-mka-policy)#macsec-cipher-suite gcm-aes-128confidentiality-offset 0
Device(config-mka-policy)# end

This example shows how to configure Secure Announcement globally:

Device# configure terminal
Device(config)# mka defaults policy send-secure-announcements
Device(config)# end

This example shows how to configure EAPoL Announcements on an interface:

Device# configure terminal
Device(config)# interface GigabitEthernet 1/0/1
Device(config-if)# eapol announcement
Device(config-if)# end

The following is a sample output for show running-config interface interface-name command with EAPoL announcement enabled.

Device# show running-config interface GigabitEthernet 1/0/1
switchport mode access
macsec
access-session host-mode multi-host
access-session closed
access-session port-control auto
dot1x pae authenticator
dot1x timeout quiet-period 10
dot1x timeout tx-period 5
dot1x timeout supp-timeout 10
dot1x supplicant eap profile peap
eapol announcement
spanning-tree portfast
service-policy type control subscriber Dot1X

The following is a sample output of the show mka sessions interface interface-name detail command with secure announcement disabled.

Device# show mka sessions interface GigabitEthernet 1/0/1 detail

MKA Detailed Status for MKA Session
===================================
Status: SECURED - Secured MKA Session with MACsec

Local Tx-SCI............. 204c.9e85.ede4/002b
Interface MAC Address.... 204c.9e85.ede4
MKA Port Identifier...... 43
Interface Name........... GigabitEthernet1/0/1
Audit Session ID.........
CAK Name (CKN)........... 0100000000000000000000000000000000000000000000000000000000000000
Member Identifier (MI)... D46CBEC05D5D67594543CEAE
Message Number (MN)...... 89567
EAP Role................. NA
Key Server............... YES
MKA Cipher Suite......... AES-128-CMAC

Latest SAK Status........ Rx & Tx
Latest SAK AN............ 0
Latest SAK KI (KN)....... D46CBEC05D5D67594543CEAE00000001 (1)
Old SAK Status........... FIRST-SAK
Old SAK AN............... 0
Old SAK KI (KN).......... FIRST-SAK (0)

SAK Transmit Wait Time... 0s (Not waiting for any peers to respond)
SAK Retire Time.......... 0s (No Old SAK to retire)

MKA Policy Name.......... p2
Key Server Priority...... 2
Delay Protection......... NO
Replay Protection........ YES
Replay Window Size....... 0
Confidentiality Offset... 0
Algorithm Agility........ 80C201
Send Secure Announcement.. DISABLED
SAK Cipher Suite......... 0080C20001000001 (GCM-AES-128)
MACsec Capability........ 3 (MACsec Integrity, Confidentiality, & Offset)
MACsec Desired........... YES

# of MACsec Capable Live Peers............ 1
# of MACsec Capable Live Peers Responded.. 1

Live Peers List:
MI                        MN          Rx-SCI (Peer)        KS Priority
----------------------------------------------------------------------
38046BA37D7DA77E06D006A9  89555       c800.8459.e764/002a   10

Potential Peers List:
MI                        MN          Rx-SCI (Peer)        KS Priority
----------------------------------------------------------------------

Dormant Peers List:
MI                        MN          Rx-SCI (Peer)        KS Priority
----------------------------------------------------------------------

The following is a sample output of the show mka sessions details command with secure announcement disabled.

Device# show mka sessions details
MKA Detailed Status for MKA Session
===================================
Status: SECURED - Secured MKA Session with MACsec

Local Tx-SCI............. 204c.9e85.ede4/002b
Interface MAC Address.... 204c.9e85.ede4
MKA Port Identifier...... 43
Interface Name........... GigabitEthernet1/0/1
Audit Session ID.........
CAK Name (CKN)........... 0100000000000000000000000000000000000000000000000000000000000000
Member Identifier (MI)... D46CBEC05D5D67594543CEAE
Message Number (MN)...... 89572
EAP Role................. NA
Key Server............... YES
MKA Cipher Suite......... AES-128-CMAC

Latest SAK Status........ Rx & Tx
Latest SAK AN............ 0
Latest SAK KI (KN)....... D46CBEC05D5D67594543CEAE00000001 (1)
Old SAK Status........... FIRST-SAK
Old SAK AN............... 0
Old SAK KI (KN).......... FIRST-SAK (0)

SAK Transmit Wait Time... 0s (Not waiting for any peers to respond)
SAK Retire Time.......... 0s (No Old SAK to retire)

MKA Policy Name.......... p2
Key Server Priority...... 2
Delay Protection......... NO
Replay Protection........ YES
Replay Window Size....... 0
Confidentiality Offset... 0
Algorithm Agility........ 80C201
Send Secure Announcement.. DISABLED
SAK Cipher Suite......... 0080C20001000001 (GCM-AES-128)
MACsec Capability........ 3 (MACsec Integrity, Confidentiality, & Offset)
MACsec Desired........... YES

# of MACsec Capable Live Peers............ 1
# of MACsec Capable Live Peers Responded.. 1

Live Peers List:
MI                        MN          Rx-SCI (Peer)        KS Priority
----------------------------------------------------------------------
38046BA37D7DA77E06D006A9  89560       c800.8459.e764/002a   10

Potential Peers List:
MI                        MN          Rx-SCI (Peer)        KS Priority
----------------------------------------------------------------------

Dormant Peers List:
MI                        MN          Rx-SCI (Peer)        KS Priority
----------------------------------------------------------------------

The following is a sample output of the show mka policy policy-name detail command with secure announcement disabled.

Device# show mka policy p2 detail
MKA Policy Configuration ("p2")
========================
MKA Policy Name........ p2
Key Server Priority.... 2
Confidentiality Offset. 0
Send Secure Announcement..DISABLED
Cipher Suite(s)........ GCM-AES-128

Applied Interfaces...
GigabitEthernet1/0/1

Example: Cisco TrustSec Switch-to-Switch Link Security Configuration

This example shows the configuration necessary for a seed and non-seed device for Cisco TrustSec switch-to-switch security. You must configure the AAA and RADIUS for link security. In this example, ACS-1 through ACS-3 can be any server names and cts-radius is the Cisco TrustSec server.

Seed Device Configuration:

Switch(config)#aaa new-model
Switch(config)#radius server ACS-1
Switch(config-radius-server)#address ipv4 10.5.120.12 auth-port 1812 acct-port 1813
Switch(config-radius-server)#pac key cisco123
Switch(config-radius-server)#exit
Switch(config)#radius server ACS-2
Switch(config-radius-server)#address ipv4 10.5.120.14 auth-port 1812 acct-port 1813
Switch(config-radius-server)#pac key cisco123
Switch(config-radius-server)#exit
Switch(config)#radius server ACS-3
Switch(config-radius-server)#address ipv4 10.5.120.15 auth-port 1812 acct-port 1813
Switch(config-radius-server)#pac key cisco123
Switch(config-radius-server)#exit
Switch(config)#aaa group server radius cts-radius
Switch(config-sg-radius)#server name ACS-1
Switch(config-sg-radius)#server name ACS-2
Switch(config-sg-radius)#server name ACS-3
Switch(config-sg-radius)#exit
Switch(config)#aaa authentication login default none
Switch(config)#aaa authentication dot1x default group cts-radius
Switch(config)#aaa authorization network cts-radius group cts-radius
Switch(config)#aaa session-id common
Switch(config)#cts authorization list cts-radius
Switch(config)#dot1x system-auth-control

Switch(config)#interface gi1/1/2
Switch(config-if)#switchport mode trunk
Switch(config-if)#cts manual
Switch(config-if-cts-manual)#sap pmk 0 abcd mode-list gcm-encrypt gmac

Switch(config-if-cts-manual)#exit
Switch(config-if)#exit

Switch(config)#interface gi1/1/4
Switch(config-if)#switchport mode trunk
Switch(config-if)#cts manual
Switch(config-if-cts-manual)#sap pmk 033445AABBCCDDEEFF mode-list gcm-encrypt gmac
Switch(config-if-cts-manual)#no propagate sgt
Switch(config-if-cts-manual)#exit
Switch(config-if)#exit

Switch(config)#radius-server vsa send authentication
Switch(config)#end
Switch#cts credentials id cts-36 password trustsec123

Non-Seed Device:

Switch(config)#aaa new-model
Switch(config)#aaa session-id common
Switch(config)#dot1x system-auth-control

Switch(config)#interface gi1/1/2
Switch(config-if)#switchport mode trunk
Switch(config-if)#shutdown
Switch(config-if)#cts manual
Switch(config-if-cts-manual)#sap pmk 0 abcd mode-list gcm-encrypt gmac
Switch(config-if-cts-manual)#exit
Switch(config-if)#exit

Switch(config)#interface gi1/1/4
Switch(config-if)#switchport mode trunk
Switch(config-if)#shutdown
Switch(config-if)#cts manual
Switch(config-if-cts-manual)#sap pmk 033445AABBCCDDEEFF mode-list gcm-encrypt gmac
Switch(config-if-cts-manual)#no propagate sgt
Switch(config-if-cts-manual)#exit
Switch(config-if)#exit

Switch(config)#radius-server vsa send authentication
Switch(config)#cts credentials id cts-72 password trustsec123
Switch(config)#end

Chapter 7. Configuring Local Authentication and Authorization

- Monitoring Local Authentication and Authorization

- Additional References

Configuring the Switch for Local Authentication and Authorization

You can configure AAA to operate without a server by setting the switch to implement AAA in local mode. The switch then handles authentication and authorization. No accounting is available in this configuration.

Note

To secure the switch for HTTP access by using AAA methods, you must configure the switch with the ip http authentication aaa global configuration command. Configuring AAA authentication does not secure the switch for HTTP access by using AAA methods.

Follow these steps to configure AAA to operate without a server by setting the switch to implement AAA in local mode:

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

aaa new-model

Example:

Device(config)# aaa new-model

Enables AAA.

Step 4

aaa authentication login default local

Example:

Device(config)# aaa authentication login default local

Sets the login authentication to use the local username database. The default keyword applies the local user database authentication to all ports.

Step 5

aaa authorization exec default local

Example:

Device(config)# aaa authorization exec default local

Configures user AAA authorization, check the local database, and allow the user to run an EXEC shell.

Step 6

aaa authorization network default local

Example:

Device(config)# aaa authorization network default local

Configures user AAA authorization for all network-related service requests.

Step 7

username name [privilege level] {password encryption-type password}

Example:

Device(config)# username your_user_name privilege 1 password 7 secret567

Enters the local database, and establishes a username-based authentication system.

Repeat this command for each user.

- For name , specify the user ID as one word. Spaces and quotation marks are not allowed.

- (Optional) For level , specify the privilege level the user has after gaining access. The range is 0 to 15. Level 15 gives privileged EXEC mode access. Level 0 gives user EXEC mode access.

- For encryption-type , enter 0 to specify that an unencrypted password follows. Enter 7 to specify that a hidden password follows.

- For password , specify the password the user must enter to gain access to the switch. The password must be from 1 to 25 characters, can contain embedded spaces, and must be the last option specified in the username command.

Step 8

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 9

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 10

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Monitoring Local Authentication and Authorization

To display Local Authentication and Authorization configuration, use the show running-config privileged EXEC command.

Additional References

Error Message Decoder

Description

Link

To help you research and resolve system error messages in this release, use the Error Message Decoder tool.

https://www.cisco.com/cgi-bin/Support/Errordecoder/index.cgi

MIBs

MIB

MIBs Link

All the supported MIBs for this release.

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

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

Technical Assistance

Description

Link

The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies.

To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.

Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.

http://www.cisco.com/support

Chapter 8. Configuring Secure Shell

- Prerequisites for Configuring Secure Shell

- Restrictions for Configuring Secure Shell

- Information About Configuring Secure Shell

- Monitoring the SSH Configuration and Status

Prerequisites for Configuring Secure Shell

The following are the prerequisites for configuring the switch for secure shell (SSH):

- For SSH to work, the switch needs an Rivest, Shamir, and Adleman (RSA) public/private key pair. This is the same with Secure Copy Protocol (SCP), which relies on SSH for its secure transport.

- Before enabling SCP, you must correctly configure SSH, authentication, and authorization on the switch.

- Because SCP relies on SSH for its secure transport, the router must have an Rivest, Shamir, and Adelman (RSA) key pair.

- SCP relies on SSH for security.

- SCP requires that authentication, authorization, and accounting (AAA) authorization be configured so the router can determine whether the user has the correct privilege level.

- A user must have appropriate authorization to use SCP.

- A user who has appropriate authorization can use SCP to copy any file in the Cisco IOS File System (IFS) to and from a switch by using the copy command. An authorized administrator can also do this from a workstation.

- The Secure Shell (SSH) server requires an IPsec (Data Encryption Standard [DES] or 3DES) encryption software image; the SSH client requires an IPsec (DES or 3DES) encryption software image.)

- Configure a hostname and host domain for your device by using the hostname and ip domain name commands in global configuration mode.

Restrictions for Configuring Secure Shell

The following are restrictions for configuring the device for secure shell.

- The switch supports Rivest, Shamir, and Adelman (RSA) authentication.

- SSH supports only the execution-shell application.

- The SSH server and the SSH client are supported only on Data Encryption Standard (DES) (56-bit) and 3DES (168-bit) data encryption software. In DES software images, DES is the only encryption algorithm available. In 3DES software images, both DES and 3DES encryption algorithms are available.

- The device supports the Advanced Encryption Standard (AES) encryption algorithm with a 128-bit key, 192-bit key, or 256-bit key. However, symmetric cipher AES to encrypt the keys is not supported.

- When using SCP, you cannot enter the password into the copy command. You must enter the password when prompted.

- The login banner is not supported in Secure Shell Version 1. It is supported in Secure Shell Version 2.

- The -l keyword and userid :{number} {ip-address} delimiter and arguments are mandatory when configuring the alternative method of Reverse SSH for console access.

- To authenticate clients with freeradius over RADSEC, you should generate an RSA key longer than 1024 bit. Use the crypto key generate rsa general-keys exportable label label-name command to achieve this.

Information About Configuring Secure Shell

Secure Shell (SSH) is a protocol that provides a secure, remote connection to a device. SSH provides more security for remote connections than Telnet does by providing strong encryption when a device is authenticated. This software release supports SSH Version 2 (SSHv2).

- SSH And Switch Access

- SSH Servers, Integrated Clients, and Supported Versions

- SSH Configuration Guidelines

- Secure Copy Protocol Overview

- Secure Copy Protocol

SSH And Switch Access

Secure Shell (SSH) is a protocol that provides a secure, remote connection to a device. SSH provides more security for remote connections than Telnet does by providing strong encryption when a device is authenticated. This software release supports SSH Version 2 (SSHv2).

SSH functions the same in IPv6 as in IPv4. For IPv6, SSH supports IPv6 addresses and enables secure, encrypted connections with remote IPv6 nodes over an IPv6 transport.

SSH Servers, Integrated Clients, and Supported Versions

The Secure Shell (SSH) Integrated Client feature is an application that runs over the SSH protocol to provide device authentication and encryption. The SSH client enables a Cisco device to make a secure, encrypted connection to another Cisco device or to any other device running the SSH server. This connection provides functionality similar to that of an outbound Telnet connection except that the connection is encrypted. With authentication and encryption, the SSH client allows for secure communication over an unsecured network.

The SSH server and SSH integrated client are applications that run on the switch. The SSH server works with the SSH client supported in this release and with non-Cisco SSH clients. The SSH client works with publicly and commercially available SSH servers. The SSH client supports the ciphers of Data Encryption Standard (DES), 3DES, and password authentication.

Note

The SSH client functionality is available only when the SSH server is enabled.

User authentication is performed like that in the Telnet session to the device. SSH also supports the following user authentication methods:

- TACACS+

- RADIUS

- Local authentication and authorization

SSH Configuration Guidelines

Follow these guidelines when configuring the switch as an SSH server or SSH client:

- An RSA key pair generated by a SSHv1 server can be used by an SSHv2 server, and the reverse.

- If the SSH server is running on an active switch and the active switch fails, the new active switch uses the RSA key pair generated by the previous active switch.

- If you get CLI error messages after entering the crypto key generate rsa global configuration command, an RSA key pair has not been generated. Reconfigure the hostname and domain, and then enter the crypto key generate rsa command.

- When generating the RSA key pair, the message No host name specified might appear. If it does, you must configure a hostname by using the hostname command in global configuration mode.

- When generating the RSA key pair, the message No domain specified might appear. If it does, you must configure an IP domain name by using the ip domain name command in global configuration mode.

- When configuring the local authentication and authorization authentication method, make sure that AAA is disabled on the console.

Secure Copy Protocol Overview

The Secure Copy Protocol (SCP) feature provides a secure and authenticated method for copying switch configurations or switch image files. SCP relies on Secure Shell (SSH), an application and a protocol that provides a secure replacement for the Berkeley r-tools.

For SSH to work, the switch needs an RSA public/private key pair. This is the same with SCP, which relies on SSH for its secure transport.

Because SSH also relies on AAA authentication, and SCP relies further on AAA authorization, correct configuration is necessary.

- Before enabling SCP, you must correctly configure SSH, authentication, and authorization on the switch.

- Because SCP relies on SSH for its secure transport, the router must have an Rivest, Shamir, and Adelman (RSA) key pair.

Note

When using SCP, you cannot enter the password into the copy command. You must enter the password when prompted.

Secure Copy Protocol

The Secure Copy Protocol (SCP) feature provides a secure and authenticated method for copying device configurations or switch image files. The behavior of SCP is similar to that of remote copy (rcp), which comes from the Berkeley r-tools suite, except that SCP relies on SSH for security. SCP also requires that authentication, authorization, and accounting (AAA) authorization be configured so the device can determine whether the user has the correct privilege level. To configure the Secure Copy feature, you should understand the SCP concepts.

Setting Up the Device to Run SSH

Follow the procedure given below to set up your Device to run SSH:

Before you begin

Configure user authentication for local or remote access. This step is required. For more information, see Related Topics below.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

hostname hostname

Example:

Device(config)# hostname your_hostname

Configures a hostname and IP domain name for your Device.

Note

Follow this procedure only if you are configuring the Device as an SSH server.

Step 4

ip domain name domain_name

Example:

Device(config)# ip domain name your_domain

Configures a host domain for your Device.

Step 5

crypto key generate rsa

Example:

Device(config)# crypto key generate rsa

Enables the SSH server for local and remote authentication on the Device and generates an RSA key pair. Generating an RSA key pair for the Device automatically enables SSH.

We recommend that a minimum modulus size of 1024 bits.

When you generate RSA keys, you are prompted to enter a modulus length. A longer modulus length might be more secure, but it takes longer to generate and to use.

Note

Follow this procedure only if you are configuring the Device as an SSH server.

Step 6

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 7

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 8

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Configuring the SSH Server

Follow these steps to configure the SSH server:

Note

This procedure is only required if you are configuring the Device as an SSH server.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ip ssh version [2]

Example:

Device(config)# ip ssh version 2

(Optional) Configures the Device to run SSH Version 2.

If you do not enter this command or do not specify a keyword, the SSH server selects the latest SSH version supported by the SSH client.

Step 4

ip ssh {timeout seconds | authentication-retries number}

Example:

Device(config)# ip ssh timeout 90 authentication-retries 2

Configures the SSH control parameters:

- Specify the time-out value in seconds; the default is 120 seconds. The range is 0 to 120 seconds. This parameter applies to the SSH negotiation phase. After the connection is established, the Device uses the default time-out values of the CLI-based sessions.

By default, up to five simultaneous, encrypted SSH connections for multiple CLI-based sessions over the network are available (session 0 to session 4). After the execution shell starts, the CLI-based session time-out value returns to the default of 10 minutes.

- Specify the number of times that a client can re-authenticate to the server. The default is 3; the range is 0 to 5.

Repeat this step when configuring both parameters.

Step 5

Use one or both of the following:

- line vty line_number [ending_line_number]

- transport input ssh

Example:

Device(config)# line vty 1 10

or

Device(config-line)# transport input ssh

(Optional) Configures the virtual terminal line settings.

- Enters line configuration mode to configure the virtual terminal line settings. For the line_number and ending_line_number arguments, the range is from 0 to 15.

- Specifies that the Device prevents non-SSH Telnet connections, limiting the device to only SSH connections.

Step 6

end

Example:

Device(config-line)# end

Exits line configuration mode and returns to privileged EXEC mode.

Step 7

Use one of the following:

- show ip ssh

- show ssh

Example:

Device# show ip ssh

or

Device# show ssh

- Shows the version and configuration information for your SSH server.

- Shows the status of the SSH server connections on the Device.

Step 8

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 9

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Monitoring the SSH Configuration and Status

This table displays the SSH server configuration and status.

Commands for Displaying the SSH Server Configuration and Status

Command

Purpose

show ip ssh

Shows the version and configuration information for the SSH server.

show ssh

Shows the status of the SSH server.

Chapter 9. Configuring SSH File Transfer Protocol

Secure Shell (SSH) includes support for SSH File Transfer Protocol (SFTP), which is a new standard file transfer protocol introduced in SSHv2. This feature provides a secure and authenticated method for copying device configuration or device image files.

- Prerequisites for SSH File Transfer Protocol

- Restrictions for SSH File Transfer Protocol

- Information About SSH File Transfer Protocol

- How to Configure SSH File Transfer Protocol

- Example: Configuring SSH File Transfer Protocol

- Additional References

- Feature Information for SSH File Transfer Protocol

Prerequisites for SSH File Transfer Protocol

- SSH must be enabled.

- The ip ssh source-interface interface-type interface-number command must be configured.

Restrictions for SSH File Transfer Protocol

- The SFTP server is not supported.

- SFTP boot is not supported.

- The sftp option in the install add command is not supported.

Information About SSH File Transfer Protocol

The SFTP client functionality is provided as part of the SSH component and is always enabled on the corresponding device. Therefore, any SFTP server user with the appropriate permission can copy files to and from the device.

An SFTP client is VRF-aware; you can configure the secure FTP client to use the virtual routing and forwarding (VRF) associated with a particular source interface during connection attempts.

How to Configure SSH File Transfer Protocol

The following sections provide information about the various tasks that comprise an SFTP configuration.

- Configuring SFTP

- Perform an SFTP Copy Operation

Configuring SFTP

Perform the following steps:

Before you begin

To configure a Cisco device for SFTP client-side functionality, the ip ssh source-interface interface-type interface-number command must be configured first.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode. Enter your password, if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ip ssh source-interface interface-type interface-number

Example:

Device(config)# ip ssh source-interface GigabitEthernet 1/0/1

Defines the source IP for the SSH session.

Step 4

exit

Example:

Device(config)# exit

Exits global configuration mode and returns to privileged EXEC mode.

Step 5

show running-config

Example:

Device# show running-config

(Optional) Displays the SFTP client-side functionality.

Step 6

debug ip sftp

Example:

Device# debug ip sftp

(Optional) Enables SFTP debugging.

Perform an SFTP Copy Operation

SFTP copy takes the IP or hostname of the corresponding server if Domain Name System (DNS) is configured. To perform SFTP copy operations, use the following commands in privileged EXEC mode:

Command

Purpose

Device# copy ios-file-system:file sftp://user:pwd@server-ip//filepath

Or

Device# copy ios-file-system: sftp:

Copies a file from the local Cisco IOS file system to the server.

Specify the username, password, IP address, and filepath of the server.

Device# copy sftp://user:pwd@server-ip //filepath ios-file-system:file

Or

Device# copy sftp: ios-file-system:

Copies the file from the server to the local Cisco IOS file system.

Specify the username, password, IP address, and filepath of the server.

Example: Configuring SSH File Transfer Protocol

The following example shows how to configure the client-side functionality of SFTP:

Device> enable
Device# configure terminal
Device(config)# ip ssh source-interface gigabitethernet 1/0/1
Device(config)# exit

Additional References

Related Documents

Related Topic

Document Title

Cisco IOS commands

Cisco IOS Master Command List, All Releases

Secure Shell Version 1 and 2 Support

Configuring Secure Shell

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

http://www.cisco.com/cisco/web/support/index.html

Feature Information for SSH File Transfer Protocol

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

Feature Information for SFTP

Feature Name

Releases

Feature Information

SSH File Transfer Protocol (SFTP)

Cisco IOS XE Gibraltar 16.11.1

SSH includes support for SFTP, a new standard file transfer protocol introduced in SSHv2.

Chapter 10. X.509v3 Certificates for SSH Authentication

- X.509v3 Certificates for SSH Authentication

- Information About X.509v3 Certificates for SSH Authentication

- How to Configure X.509v3 Certificates for SSH Authentication

- Configuration Examples for X.509v3 Certificates for SSH Authentication

- Additional References for X.509v3 Certificates for SSH Authentication

- Feature Information for X.509v3 Certificates for SSH Authentication

X.509v3 Certificates for SSH Authentication

The X.509v3 Certificates for secure shell (SSH) Authentication feature uses the X.509v3 digital certificates in server and user authentication at the SSH server side.

- Prerequisites for Digital Certificates for SSH Authentication

- Restrictions for X.509v3 Certificates for SSH Authentication

Prerequisites for Digital Certificates for SSH Authentication

The Digital Certificates for SSH Authentication feature introduces the ip ssh server algorithm authentication command to replace the ip ssh server authenticate user command. If you use the ip ssh server authenticate user command, the following deprecation message is displayed.

Warning: SSH command accepted but this CLI will be deprecated soon. Please move to new CLI “ip ssh server algorithm authentication”. Please configure “default ip ssh server authenticate user” to make CLI ineffective.

Use the default ip ssh server authenticate user command to remove the ip ssh server authenticate user command from effect. The IOS secure shell (SSH) server then starts using the ip ssh server algorithm authentication command.

Restrictions for X.509v3 Certificates for SSH Authentication

The following restrictions are applicable for X.509v3 Certificate for SSH Authentication:

- The X.509v3 Certificates for SSH Authentication feature implementation is applicable only on the IOS secure shell (SSH) server side.

- IOS SSH server supports only the x509v3-ssh-rsa algorithm based certificate for server and user authentication on the IOS SSH server side.

The X.509v3 Certificate for SSH Authentication fails in the following conditions:

- When root certification authority is configured as a trustpoint on the device.

- When a client passes a certificate chain that leads to a self-signed root certificate authority that includes a client certificate, sub-ca certificate, and self-signed root certificate authority.

- When a sub-ca certification is configured as a trustpoint on the device but not included as a trustpoint on the user certificate.

Information About X.509v3 Certificates for SSH Authentication

The following section provides information about digital certificates, and server and user authentication.

- Digital Certificates

- Server and User Authentication using X.509v3

Digital Certificates

The validity of the authentication depends upon the strength of the linkage between the public signing key and the identity of the signer. Digital certificates in the X.509v3 format (RFC5280) are used to provide identity management. A chain of signatures by a trusted root certification authority and its intermediate certificate authorities binds a given public signing key to a given digital identity.

Public key infrastructure (PKI) trustpoint helps manage the digital certificates. The association between the certificate and the trustpoint helps track the certificate. The trustpoint contains information about the certificate authority (CA), different identity parameters, and the digital certificate. Multiple trustpoints can be created to associate with different certificates.

Server and User Authentication using X.509v3

For server authentication, the IOS secure shell (SSH) server sends its own certificate to the SSH client for verification. This server certificate is associated with the trustpoint configured in the server certificate profile (ssh-server-cert-profile-server configuration mode).

For user authentication, the SSH client sends the user's certificate to the IOS SSH server for verification. The SSH server validates the incoming user certificate using public key infrastructure (PKI) trustpoints configured in the server certificate profile (ssh-server-cert-profile-user configuration mode).

By default, certificate-based authentication is enabled for server and user at the IOS SSH server end.

How to Configure X.509v3 Certificates for SSH Authentication

The following section provides information about how to configure X.509v3 Certificates for SSH Authentication.

- Configuring IOS SSH Server to Use Digital Certificates for Sever Authentication

- Configuring IOS SSH Server to Verify User's Digital Certificate for User Authentication

- Verifying Configuration for Server and User Authentication Using Digital Certificates

Configuring IOS SSH Server to Use Digital Certificates for Sever Authentication

The following section provides information about Configuring IOS SSH Server to Use Digital Certificates for Sever Authentication.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ip ssh server algorithm hostkey {x509v3-ssh-rsa [ssh-rsa] | ssh-rsa [x509v3-ssh-rsa]}

Example:

Device(config)# ip ssh server algorithm hostkey x509v3-ssh-rsa

Defines the order of host key algorithms. Only the configured algorithm is negotiated with the secure shell (SSH) client.

Note

The IOS SSH server must have at least one configured host key algorithm:

- ssh-rsa – public key based authentication

- x509v3-ssh-rsa – certificate-based authentication

Step 4

ip ssh server certificate profile

Example:

Device(config)# ip ssh server certificate profile

Configures server certificate profile and user certificate profile and enters SSH certificate profile configuration mode.

Step 5

server

Example:

Device(ssh-server-cert-profile)# server

Configures server certificate profile and enters SSH server certificate profile server configuration mode.

Step 6

trustpoint sign PKI-trustpoint-name

Example:

Device(ssh-server-cert-profile-server)# trustpoint sign trust1

Attaches the public key infrastructure (PKI) trustpoint to the server certificate profile. The SSH server uses the certificate associated with this PKI trustpoint for server authentication.

Step 7

ocsp-response include

Example:

Device(ssh-server-cert-profile-server)# ocsp-response include

(Optional) Sends the Online Certificate Status Protocol (OCSP) response or OCSP stapling along with the server certificate.

Note

By default the “no” form of this command is configured and no OCSP response is sent along with the server certificate.

Step 8

end

Example:

Device(ssh-server-cert-profile-server)# end

Exits SSH server certificate profile server configuration mode and enters privileged EXEC mode.

Configuring IOS SSH Server to Verify User's Digital Certificate for User Authentication

The following section provides information about configuring IOS SSH Server to Verify User's Digital Certificate for User Authentication.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ip ssh server algorithm authentication {publickey | keyboard | password}

Example:

Device(config)# ip ssh server algorithm authentication publickey

Defines the order of user authentication algorithms. Only the configured algorithm is negotiated with the secure shell (SSH) client.

Note

- The IOS SSH server must have at least one configured user authentication algorithm.

- To use the certificate method for user authentication, the publickey keyword must be configured.

- The ip ssh server algorithm authentication command replaces the ip ssh server authenticate user command.

Step 4

ip ssh server algorithm publickey {x509v3-ssh-rsa [ssh-rsa] | ssh-rsa [x509v3-ssh-rsa]}

Example:

Device(config)# ip ssh server algorithm publickey x509v3-ssh-rsa

Defines the order of public key algorithms. Only the configured algorithm is accepted by the SSH client for user authentication.

Note

The IOS SSH client must have at least one configured public key algorithm:

- ssh-rsa – public-key-based authentication

- x509v3-ssh-rsa – certificate-based authentication

Step 5

ip ssh server certificate profile

Example:

Device(config)#ip ssh server certificate profile

Configures server certificate profile and user certificate profile and enters SSH certificate profile configuration mode.

Step 6

user

Example:

Device(ssh-server-cert-profile)# user

Configures user certificate profile and enters SSH server certificate profile user configuration mode.

Step 7

trustpoint verify PKI-trustpoint-name

Example:

Device(ssh-server-cert-profile-user)#trustpoint verify trust2

Configures the public key infrastructure (PKI) trustpoint that is used to verify the incoming user certificate.

Note

Configure multiple trustpoints by executing the same command multiple times. A maximum of 10 trustpoints can be configured.

Step 8

ocsp-response required

Example:

Device(ssh-server-cert-profile-user)# ocsp-response required

(Optional) Mandates the presence of the Online Certificate Status Protocol (OCSP) response with the incoming user certificate.

Note

By default the “no” form of this command is configured and the user certificate is accepted without an OCSP response.

Step 9

end

Example:

Device(ssh-server-cert-profile-user)#end

Exits SSH server certificate profile user configuration mode and enters privileged EXEC mode.

Verifying Configuration for Server and User Authentication Using Digital Certificates

The following section provides information about verifying configuration for Server and User Authentication Using Digital Certificates.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

show ip ssh

Example:

Device# show ip ssh

SSH Enabled - version 1.99
Authentication methods:publickey,keyboard-interactive,password
Authentication Publickey Algorithms:x509v3-ssh-rsa,ssh-rsa
Hostkey Algorithms:x509v3-ssh-rsa,ssh-rsa
Authentication timeout: 120 secs; Authentication retries: 3
Minimum expected Diffie Hellman key size : 1024 bits

Displays the currently configured authentication methods. To confirm the use of certificate-based authentication, ensure that the x509v3-ssh-rsa algorithm is the configured host key algorithm.

Configuration Examples for X.509v3 Certificates for SSH Authentication

The following section provides examples for user and server authentication using digital certificates.

- Example: Configuring IOS SSH Server to Use Digital Certificates for Server Authentication

- Example: Configuring IOS SSH Server to Verify User's Digital Certificate for User Authentication

Example: Configuring IOS SSH Server to Use Digital Certificates for Server Authentication

This example shows how to configure IOS SSH Server to Use Digital Certificates for Server Authentication.

Device> enable
Device# configure terminal
Device(config)# ip ssh server algorithm hostkey x509v3-ssh-rsa
Device(config)# ip ssh server certificate profile
Device(ssh-server-cert-profile)# server
Device(ssh-server-cert-profile-server)# trustpoint sign trust1
Device(ssh-server-cert-profile-server)# exit

Example: Configuring IOS SSH Server to Verify User's Digital Certificate for User Authentication

This example shows how to configure IOS SSH Server to Verify User's Digital Certificate for User Authentication.

Device> enable
Device# configure terminal
Device(config)# ip ssh server algorithm authentication publickey
Device(config)# ip ssh server algorithm publickey x509v3-ssh-rsa
Device(config)# ip ssh server certificate profile
Device(ssh-server-cert-profile)# user
Device(ssh-server-cert-profile-user)# trustpoint verify trust2
Device(ssh-server-cert-profile-user)# end

Additional References for X.509v3 Certificates for SSH Authentication

Related Documents

Related Topic

Document Title

Security commands

- Cisco IOS Security Command Reference: Commands A to C

- Cisco IOS Security Command Reference: Commands D to L

- Cisco IOS Security Command Reference: Commands M to R

- Cisco IOS Security Command Reference: Commands S to Z

SSH authentication

“Secure Shell-Configuring User Authentication Methods” chapter in Secure Shell Configuration Guide

Public key infrastructure (PKI) trustpoint

“Configuring and Managing a Cisco IOS Certificate Server for PKI Deployment” chapter in Public Key Infrastructure Configuration Guide

Technical Assistance

Description

Link

The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies.

To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.

Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.

http://www.cisco.com/cisco/web/support/index.html

Feature Information for X.509v3 Certificates for SSH Authentication

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

Feature Information for X.509v3 Certificates for SSH Authentication

Feature Information

Release

Modification

X.509v3 Certificates for SSH Authentication

Cisco IOS XE Denali 16.1.x

The X.509v3 Certificates for SSH Authentication feature uses the X.509v3 digital certificates in server and user authentication at the secure shell (SSH) server side

Chapter 11. Configuring Secure Socket Layer HTTP

- Monitoring Secure HTTP Server and Client Status

- Additional References for Secure Socket Layer HTTP

Secure HTTP Servers and Clients Overview

On a secure HTTP connection, data to and from an HTTP server is encrypted before being sent over the Internet. HTTP with SSL encryption provides a secure connection to allow such functions as configuring a switch from a Web browser. Cisco's implementation of the secure HTTP server and secure HTTP client uses an implementation of SSL Version 3.0 with application-layer encryption. HTTP over SSL is abbreviated as HTTPS; the URL of a secure connection begins with https:// instead of http://.

Note

SSL evolved into Transport Layer Security (TLS) in 1999, but is still used in this particular context.

The primary role of the HTTP secure server (the switch) is to listen for HTTPS requests on a designated port (the default HTTPS port is 443) and pass the request to the HTTP 1.1 Web server. The HTTP 1.1 server processes requests and passes responses (pages) back to the HTTP secure server, which, in turn, responds to the original request.

The primary role of the HTTP secure client (the web browser) is to respond to Cisco IOS application requests for HTTPS User Agent services, perform HTTPS User Agent services for the application, and pass the response back to the application.

Note

Beginning with Cisco IOS XE Denali 16.3.1, support for attaching IPv6 ACL to the HTTP server has been enabled. Prior to Cisco IOS XE Denali 16.3.1, only IPv4 ACL support was available for configuring the secure HTTP server. You can attach the preconfigured IPv6 and IPv4 ACLs to the HTTP server using the configuration CLI for the secure HTTP server.

Certificate Authority Trustpoints

Certificate authorities (CAs) manage certificate requests and issue certificates to participating network devices. These services provide centralized security key and certificate management for the participating devices. Specific CA servers are referred to as trustpoints.

When a connection attempt is made, the HTTPS server provides a secure connection by issuing a certified X.509v3 certificate, obtained from a specified CA trustpoint, to the client. The client (usually a Web browser), in turn, has a public key that allows it to authenticate the certificate.

For secure HTTP connections, we highly recommend that you configure a CA trustpoint. If a CA trustpoint is not configured for the device running the HTTPS server, the server certifies itself and generates the needed RSA key pair. Because a self-certified (self-signed) certificate does not provide adequate security, the connecting client generates a notification that the certificate is self-certified, and the user has the opportunity to accept or reject the connection. This option is useful for internal network topologies (such as testing).

If you do not configure a CA trustpoint, when you enable a secure HTTP connection, either a temporary or a persistent self-signed certificate for the secure HTTP server (or client) is automatically generated.

- If the switch is not configured with a hostname and a domain name, a temporary self-signed certificate is generated. If the switch reboots, any temporary self-signed certificate is lost, and a new temporary new self-signed certificate is assigned.

- If the switch has been configured with a host and domain name, a persistent self-signed certificate is generated. This certificate remains active if you reboot the switch or if you disable the secure HTTP server so that it will be there the next time you re-enable a secure HTTP connection.

Note

The certificate authorities and trustpoints must be configured on each device individually. Copying them from other devices makes them invalid on the switch.

When a new certificate is enrolled, the new configuration change is not applied to the HTTPS server until the server is restarted. You can restart the server using either the CLI or by physical reboot. On restarting the server, the switch starts using the new certificate.

If a self-signed certificate has been generated, this information is included in the output of the show running-config privileged EXEC command. This is a partial sample output from that command displaying a self-signed certificate.

Device# show running-config
Building configuration...

<output truncated>

crypto pki trustpoint TP-self-signed-3080755072
enrollment selfsigned
subject-name cn=IOS-Self-Signed-Certificate-3080755072
revocation-check none
rsakeypair TP-self-signed-3080755072
!
!
crypto ca certificate chain TP-self-signed-3080755072
certificate self-signed 01
3082029F 30820208 A0030201 02020101 300D0609 2A864886 F70D0101 04050030
59312F30 2D060355 04031326 494F532D 53656C66 2D536967 6E65642D 43657274
69666963 6174652D 33303830 37353530 37323126 30240609 2A864886 F70D0109
02161743 45322D33 3535302D 31332E73 756D6D30 342D3335 3530301E 170D3933
30333031 30303030 35395A17 0D323030 31303130 30303030 305A3059 312F302D

<output truncated>

You can remove this self-signed certificate by disabling the secure HTTP server and entering the no crypto pki trustpoint TP-self-signed-30890755072 global configuration command. If you later re-enable a secure HTTP server, a new self-signed certificate is generated.

Note

The values that follow TP self-signed depend on the serial number of the device.

You can use an optional command (ip http secure-client-auth ) to allow the HTTPS server to request an X.509v3 certificate from the client. Authenticating the client provides more security than server authentication by itself.

CipherSuites

A CipherSuite specifies the encryption algorithm and the digest algorithm to use on a SSL connection. When connecting to the HTTPS server, the client Web browser offers a list of supported CipherSuites, and the client and server negotiate the best encryption algorithm to use from those on the list that are supported by both. For example, Netscape Communicator 4.76 supports U.S. security with RSA Public Key Cryptography, MD2, MD5, RC2-CBC, RC4, DES-CBC, and DES-EDE3-CBC.

For the best possible encryption, you should use a client browser that supports 128-bit encryption, such as Microsoft Internet Explorer Version 5.5 (or later) or Netscape Communicator Version 4.76 (or later). The SSL_RSA_WITH_DES_CBC_SHA CipherSuite provides less security than the other CipherSuites, as it does not offer 128-bit encryption.

The more secure and more complex CipherSuites require slightly more processing time. This list defines the CipherSuites supported by the switch and ranks them from fastest to slowest in terms of router processing load (speed):

1. SSL_RSA_WITH_DES_CBC_SHA—RSA key exchange (RSA Public Key Cryptography) with DES-CBC for message encryption and SHA for message digest

2. SSL_RSA_WITH_NULL_SHA key exchange with NULL for message encryption and SHA for message digest (only for SSL 3.0).

3. SSL_RSA_WITH_NULL_MD5 key exchange with NULL for message encryption and MD5 for message digest (only for SSL 3.0).

4. SSL_RSA_WITH_RC4_128_MD5—RSA key exchange with RC4 128-bit encryption and MD5 for message digest

5. SSL_RSA_WITH_RC4_128_SHA—RSA key exchange with RC4 128-bit encryption and SHA for message digest

6. SSL_RSA_WITH_3DES_EDE_CBC_SHA—RSA key exchange with 3DES and DES-EDE3-CBC for message encryption and SHA for message digest

7. SSL_RSA_WITH_AES_128_CBC_SHA—RSA key exchange with AES 128-bit encryption and SHA for message digest (only for SSL 3.0).

8. SSL_RSA_WITH_AES_256_CBC_SHA—RSA key exchange with AES 256-bit encryption and SHA for message digest (only for SSL 3.0).

9. SSL_RSA_WITH_DHE_AES_128_CBC_SHA—RSA key exchange with AES 128-bit encryption and SHA for message digest (only for SSL 3.0).

10. SSL_RSA_WITH_DHE_AES_256_CBC_SHA—RSA key exchange with AES 256-bit encryption and SHA for message digest (only for SSL 3.0).

Note

The latest versions of Chrome do not support the four original cipher suites, thus disallowing access to both web GUI and guest portals.

RSA (in conjunction with the specified encryption and digest algorithm combinations) is used for both key generation and authentication on SSL connections. This usage is independent of whether or not a CA trustpoint is configured.

Default SSL Configuration

The standard HTTP server is enabled.

SSL is enabled.

No CA trustpoints are configured.

No self-signed certificates are generated.

SSL Configuration Guidelines

When SSL is used in a switch cluster, the SSL session terminates at the cluster commander. Cluster member switches must run standard HTTP.

Before you configure a CA trustpoint, you should ensure that the system clock is set. If the clock is not set, the certificate is rejected due to an incorrect date.

In a switch stack, the SSL session terminates at the active switch.

Configuring a CA Trustpoint

For secure HTTP connections, we recommend that you configure an official CA trustpoint. A CA trustpoint is more secure than a self-signed certificate.

Beginning in privileged EXEC mode, follow these steps to configure a CA Trustpoint:

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

hostname hostname

Example:

Device(config)# hostname your_hostname

Specifies the hostname of the switch (required only if you have not previously configured a hostname). The hostname is required for security keys and certificates.

Step 3

ip domain-name domain-name

Example:

Device(config)# ip domain-name your_domain

Specifies the IP domain name of the switch (required only if you have not previously configured an IP domain name). The domain name is required for security keys and certificates.

Step 4

crypto key generate rsa

Example:

Device(config)# crypto key generate rsa

(Optional) Generates an RSA key pair. RSA key pairs are required before you can obtain a certificate for the switch. RSA key pairs are generated automatically. You can use this command to regenerate the keys, if needed.

Step 5

crypto ca trustpoint name

Example:

Device(config)# crypto ca trustpoint your_trustpoint

Specifies a local configuration name for the CA trustpoint and enter CA trustpoint configuration mode.

Step 6

enrollment url url

Example:

Device(ca-trustpoint)# enrollment url http://your_server:80

Specifies the URL to which the switch should send certificate requests.

Step 7

enrollment http-proxy host-name port-number

Example:

Device(ca-trustpoint)# enrollment http-proxy your_host 49

(Optional) Configures the switch to obtain certificates from the CA through an HTTP proxy server.

- For host-name , specify the proxy server used to get the CA.

- For port-number, specify the port number used to access the CA.

Step 8

crl query url

Example:

Device(ca-trustpoint)# crl query ldap://your_host:49

Configures the switch to request a certificate revocation list (CRL) to ensure that the certificate of the peer has not been revoked.

Step 9

primary name

Example:

Device(ca-trustpoint)# primary your_trustpoint

(Optional) Specifies that the trustpoint should be used as the primary (default) trustpoint for CA requests.

- For name, specify the trustpoint that you just configured.

Step 10

exit

Example:

Device(ca-trustpoint)# exit

Exits CA trustpoint configuration mode and return to global configuration mode.

Step 11

crypto ca authentication name

Example:

Device(config)# crypto ca authentication your_trustpoint

Authenticates the CA by getting the public key of the CA. Use the same name used in Step 5.

Step 12

crypto ca enroll name

Example:

Device(config)# crypto ca enroll your_trustpoint

Obtains the certificate from the specified CA trustpoint. This command requests a signed certificate for each RSA key pair.

Step 13

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Configuring the Secure HTTP Server

Beginning in privileged EXEC mode, follow these steps to configure a secure HTTP server:

Before you begin

If you are using a certificate authority for certification, you should use the previous procedure to configure the CA trustpoint on the switch before enabling the HTTP server. If you have not configured a CA trustpoint, a self-signed certificate is generated the first time that you enable the secure HTTP server. After you have configured the server, you can configure options (path, access list to apply, maximum number of connections, or timeout policy) that apply to both standard and secure HTTP servers.

To verify the secure HTTP connection by using a Web browser, enter https://URL, where the URL is the IP address or hostname of the server switch. If you configure a port other than the default port, you must also specify the port number after the URL. For example:

Note

AES256_SHA2 is not supported.

https://209.165.129:1026

or

https://host.domain.com:1026

The existing ip http access-class access-list-number command for specifying the access-list(Only IPv4 ACLs) is going to be deprecated. You can still use this command to specify an access list to allow access to the HTTP server. Two new commands have been introduced to enable support for specifying IPv4 and IPv6 ACLs. These are ip http access-class ipv4 access-list-name | access-list-number for specifying IPv4 ACLs and ip http access-class ipv6 access-list-name for specifying IPv6 ACLs. We recommend using the new CLI to avoid receiving warning messages.

Note the following considerations for specifying access-lists:

- If you specify an access-list that does not exist, the configuration takes place but you receive the below warning message:

ACL being attached does not exist, please configure it

- If you use the ip http access-class command for specifying an access-list for the HTTP server, the below warning message appears:

This CLI will be deprecated soon, Please use new CLI ip http access-class ipv4/ipv6 <access-list-name>| <access-list-number>

- If you use ip http access-class ipv4 access-list-name | access-list-number or ip http access-class ipv6 access-list-name , and an access-list was already configured using ip http access-class , the below warning message appears:

Removing ip http access-class <access-list-number>

ip http access-class access-list-number and ip http access-class ipv4 access-list-name | access-list-number share the same functionality. Each command overrides the configuration of the previous command. The following combinations between the configuration of the two commands explain the effect on the running configuration:

- If ip http access-class access-list-number is already configured and you try to configure using ip http access-class ipv4 access-list-number command, the configuration of ip http access-class access-list-number will be removed and the configuration of ip http access-class ipv4 access-list-number will be added to the running configuration.

- If ip http access-class access-list-number is already configured and you try to configure using ip http access-class ipv4 access-list-name command, the configuration of ip http access-class access-list-number will be removed and the configuration of ip http access-class ipv4 access-list-name will be added to the running configuration.

- If ip http access-class ipv4 access-list-number is already configured and you try to configure using ip http access-class access-list-name , the configuration of ip http access-class ipv4 access-list-number will be removed from configuration and the configuration of ip http access-class access-list-name will be added to the running configuration.

- If ip http access-class ipv4 access-list-name is already configured and you try to configure using ip http access-class access-list-number , the configuration of ip http access-class ipv4 access-list-name will be removed from the configuration and the configuration of ip http access-class access-list-number will be added to the running configuration.

Procedure

Step 1

show ip http server status

Example:

Device# show ip http server status

(Optional) Displays the status of the HTTP server to determine if the secure HTTP server feature is supported in the software. You should see one of these lines in the output:

HTTP secure server capability: Present

or

HTTP secure server capability: Not present

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ip http secure-server

Example:

Device(config)# ip http secure-server

Enables the HTTPS server if it has been disabled. The HTTPS server is enabled by default.

Step 4

ip http secure-port port-number

Example:

Device(config)# ip http secure-port 443

(Optional) Specifies the port number to be used for the HTTPS server. The default port number is 443. Valid options are 443 or any number in the range 1025 to 65535.

Step 5

ip http secure-ciphersuite {[3des-ede-cbc-sha] [rc4-128-md5] [rc4-128-sha] [des-cbc-sha]}

Example:

Device(config)# ip http secure-ciphersuite rc4-128-md5

(Optional) Specifies the CipherSuites (encryption algorithms) to be used for encryption over the HTTPS connection. If you do not have a reason to specify a particularly CipherSuite, you should allow the server and client to negotiate a CipherSuite that they both support. This is the default.

Step 6

ip http secure-client-auth

Example:

Device(config)# ip http secure-client-auth

(Optional) Configures the HTTP server to request an X.509v3 certificate from the client for authentication during the connection process. The default is for the client to request a certificate from the server, but the server does not attempt to authenticate the client.

Step 7

ip http secure-trustpoint name

Example:

Device(config)# ip http secure-trustpoint your_trustpoint

Specifies the CA trustpoint to use to get an X.509v3 security certificate and to authenticate the client certificate connection.

Note

Use of this command assumes you have already configured a CA trustpoint according to the previous procedure.

Step 8

ip http path path-name

Example:

Device(config)# ip http path /your_server:80

(Optional) Sets a base HTTP path for HTML files. The path specifies the location of the HTTP server files on the local system (usually located in system flash memory).

Step 9

ip http access-class access-list-number

Example:

Device(config)# ip http access-class 2

(Optional) Specifies an access list to use to allow access to the HTTP server.

Step 10

ip http access-class { ipv4 {access-list-number | access-list-name} | ipv6 {access-list-name} }

Example:

Device(config)# ip http access-class ipv4 4

(Optional)Specifies an access list to use to allow access to the HTTP server.

Step 11

ip http max-connections value

Example:

Device(config)# ip http max-connections 4

(Optional) Sets the maximum number of concurrent connections that are allowed to the HTTP server. We recommend that the value be at least 10 and not less. This is required for the UI to function as expected.

Step 12

ip http timeout-policy idle seconds life seconds requests value

Example:

Device(config)# ip http timeout-policy idle 120 life 240 requests 1

(Optional) Specifies how long a connection to the HTTP server can remain open under the defined circumstances:

- idle —the maximum time period when no data is received or response data cannot be sent. The range is 1 to 600 seconds. The default is 180 seconds (3 minutes).

- life —the maximum time period from the time that the connection is established. The range is 1 to 86400 seconds (24 hours). The default is 180 seconds.

- requests —the maximum number of requests processed on a persistent connection. The maximum value is 86400. The default is 1.

Step 13

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Configuring the Secure HTTP Client

Beginning in privileged EXEC mode, follow these steps to configure a secure HTTP client:

Before you begin

The standard HTTP client and secure HTTP client are always enabled. A certificate authority is required for secure HTTP client certification. This procedure assumes that you have previously configured a CA trustpoint on the switch. If a CA trustpoint is not configured and the remote HTTPS server requires client authentication, connections to the secure HTTP client fail.

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

ip http client secure-trustpoint name

Example:

Device(config)# ip http client secure-trustpoint your_trustpoint

(Optional) Specifies the CA trustpoint to be used if the remote HTTP server requests client authentication. Using this command assumes that you have already configured a CA trustpoint by using the previous procedure. The command is optional if client authentication is not needed or if a primary trustpoint has been configured.

Step 3

ip http client secure-ciphersuite {[3des-ede-cbc-sha] [rc4-128-md5] [rc4-128-sha] [des-cbc-sha]}

Example:

Device(config)# ip http client secure-ciphersuite rc4-128-md5

(Optional) Specifies the CipherSuites (encryption algorithms) to be used for encryption over the HTTPS connection. If you do not have a reason to specify a particular CipherSuite, you should allow the server and client to negotiate a CipherSuite that they both support. This is the default.

Step 4

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Monitoring Secure HTTP Server and Client Status

To monitor the SSL secure server and client status, use the privileged EXEC commands in the following table.

Commands for Displaying the SSL Secure Server and Client Status

Command

Purpose

show ip http client secure status

Shows the HTTP secure client configuration.

show ip http server secure status

Shows the HTTP secure server configuration.

show running-config

Shows the generated self-signed certificate for secure HTTP connections.

Additional References for Secure Socket Layer HTTP

Related Documents

Related Topic

Document Title

Certification Authority

Configuring Certification Authority Interoperability

MIBs

MIB

MIBs Link

All the supported MIBs for this release.

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

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

Technical Assistance

Description

Link

The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies.

To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.

Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.

http://www.cisco.com/support

Chapter 12. IPv4 ACLs

- Restrictions for Configuring IPv4 Access Control Lists

- Information about Network Security with ACLs

- How to Configure ACLs

- Monitoring IPv4 ACLs

- Configuration Examples for ACLs

Restrictions for Configuring IPv4 Access Control Lists

General Network Security

The following are restrictions for configuring network security with ACLs:

- Not all commands that accept a numbered ACL accept a named ACL. ACLs for packet filters and route filters on interfaces can use a name. VLAN maps also accept a name.

- A standard ACL and an extended ACL cannot have the same name.

- Though visible in the command-line help strings, appletalk is not supported as a matching condition for the deny and permit MAC access-list configuration mode commands.

- ACL wildcard is not supported in downstream client policy.

IPv4 ACL Network Interfaces

The following restrictions apply to IPv4 ACLs to network interfaces:

- When controlling access to an interface, you can use a named or numbered ACL.

- If you apply an ACL to a Layer 2 interface that is a member of a VLAN, the Layer 2 (port) ACL takes precedence over an input Layer 3 ACL applied to the VLAN interface or a VLAN map applied to the VLAN.

- If you apply an ACL to a Layer 3 interface and routing is not enabled on the switch, the ACL only filters packets that are intended for the CPU, such as SNMP, Telnet, or web traffic.

- If the preauth_ipv4_acl ACL is configured to filter packets, the ACL is removed after authentication.

- You do not have to enable routing to apply ACLs to Layer 2 interfaces.

MAC ACLs on a Layer 2 Interface

After you create a MAC ACL, you can apply it to a Layer 2 interface to filter non-IP traffic coming in that interface. When you apply the MAC ACL, consider these guidelines:

- You can apply no more than one IP access list and one MAC access list to the same Layer 2 interface. The IP access list filters only IP packets, and the MAC access list filters non-IP packets.

- A Layer 2 interface can have only one MAC access list. If you apply a MAC access list to a Layer 2 interface that has a MAC ACL configured, the new ACL replaces the previously configured one.

Note

The mac access-group interface configuration command is only valid when applied to a physical Layer 2 interface. You cannot use the command on EtherChannel port channels.

IP Access List Entry Sequence Numbering

- This feature does not support dynamic, reflexive, or firewall access lists.

Information about Network Security with ACLs

This chapter describes how to configure network security on the switch by using access control lists (ACLs), which in commands and tables are also referred to as access lists.

- ACL Overview

- Supported ACLs

- ACEs and Fragmented and Unfragmented Traffic

- ACLs and Switch Stacks

- Standard and Extended IPv4 ACLs

- Hardware and Software Treatment of IP ACLs

- VLAN Map Configuration Guidelines

- VLAN Maps with Router ACLs

- Time Ranges for ACLs

- IPv4 ACL Interface Considerations

ACL Overview

Packet filtering can help limit network traffic and restrict network use by certain users or devices. ACLs filter traffic as it passes through a router or switch and permit or deny packets crossing specified interfaces or VLANs. An ACL is a sequential collection of permit and deny conditions that apply to packets. When a packet is received on an interface, the switch compares the fields in the packet against any applied ACLs to verify that the packet has the required permissions to be forwarded, based on the criteria specified in the access lists. One by one, it tests packets against the conditions in an access list. The first match decides whether the switch accepts or rejects the packets. Because the switch stops testing after the first match, the order of conditions in the list is critical. If no conditions match, the switch rejects the packet. If there are no restrictions, the switch forwards the packet; otherwise, the switch drops the packet. The switch can use ACLs on all packets it forwards, including packets bridged within a VLAN.

You configure access lists on a router or Layer 3 switch to provide basic security for your network. If you do not configure ACLs, all packets passing through the switch could be allowed onto all parts of the network. You can use ACLs to control which hosts can access different parts of a network or to decide which types of traffic are forwarded or blocked at router interfaces. For example, you can allow e-mail traffic to be forwarded but not Telnet traffic. ACLs can be configured to block inbound traffic, outbound traffic, or both.

- Access Control Entries

- ACL Supported Types

- Hitless TCAM Update

Access Control Entries

An ACL contains an ordered list of access control entries (ACEs). Each ACE specifies permit or deny and a set of conditions the packet must satisfy in order to match the ACE. The meaning of permit or deny depends on the context in which the ACL is used.

ACL Supported Types

The switch supports IP ACLs and Ethernet (MAC) ACLs:

- IP ACLs filter IPv4 traffic, including TCP, User Datagram Protocol (UDP), Internet Group Management Protocol (IGMP), and Internet Control Message Protocol (ICMP).

- Ethernet ACLs filter non-IP traffic.

This switch also supports quality of service (QoS) classification ACLs.

Hitless TCAM Update

The Hitless TCAM update for IPv4 and IPv6 provides the capability to apply existing features to the incoming traffic while updating new features in the TCAM. Any change in IPv4 and IPv6 ACL on a given interface would trigger a reprogramming of TCAM.

Starting with Cisco IOS XE Fuji 16.8.1a, Hitless TCAM update is enabled.

This feature is always enabled. You cannot disable this feature.

The Hitless TCAM update follows the below ACL change rules:

- If there are value compare unit (VCU) registers in use from ACEs with layer 4 operators, there could be a few packet drops during the change.

- If there are not enough VCU bits remaining to add a second set of access control entries and if there is not enough space in TCAM to expand these entries, the old ACL change method will apply; which will drop all packets, delete the old ACL, add the new ACL entries into TCAM, and then remove the entry that is causing the packets to drop.

- If there is not enough space in TCAM to add the modified entries, the old ACL change method will automatically be applied.

Note

- To perform Hitless ACL update for an IPv4 ACL which has X number of ACEs, TCAM should have a free space for accommodating X+1 entries.

- To perform Hitless ACL update for an IPv6 ACL which has X number of ACEs, TCAM should have a free space for accommodating 2X+2 entries.

Supported ACLs

The switch supports three types of ACLs to filter traffic:

- Port ACLs access-control traffic entering a Layer 2 interface. You can apply port ACLs to a Layer 2 interface in each direction to each access list type — IPv4 and MAC.

- Router ACLs access-control routed traffic between VLANs and are applied to Layer 3 interfaces in a specific direction (inbound or outbound).

- VLAN ACLs or VLAN maps access-control all packets (bridged and routed). You can use VLAN maps to filter traffic between devices in the same VLAN. VLAN maps are configured to provide access control based on Layer 3 addresses for IPv4. Unsupported protocols are access-controlled through MAC addresses using Ethernet ACEs. After a VLAN map is applied to a VLAN, all packets (routed or bridged) entering the VLAN are checked against the VLAN map. Packets can either enter the VLAN through a switch port or through a routed port after being routed.

- ACL Precedence

- Port ACLs

- Router ACLs

- VLAN Maps

ACL Precedence

When VLAN maps, Port ACLs, and router ACLs are configured on the same switch, the filtering precedence, from greatest to least for ingress traffic is port ACL, VLAN map, and then router ACL. For egress traffic, the filtering precedence is router ACL, VLAN map, and then port ACL.

The following examples describe simple use cases:

- When both an input port ACL and a VLAN map are applied, incoming packets received on ports with a port ACL applied are filtered by the port ACL. Other packets are filtered by the VLAN map

- When an input router ACL and input port ACL exist in a switch virtual interface (SVI), incoming packets received on ports to which a port ACL is applied are filtered by the port ACL. Incoming routed IP packets received on other ports are filtered by the router ACL. Other packets are not filtered.

- When an output router ACL and input port ACL exist in an SVI, incoming packets received on the ports to which a port ACL is applied are filtered by the port ACL. Outgoing routed IP packets are filtered by the router ACL. Other packets are not filtered.

- When a VLAN map, input router ACL, and input port ACL exist in an SVI, incoming packets received on the ports to which a port ACL is applied are only filtered by the port ACL. Incoming routed IP packets received on other ports are filtered by both the VLAN map and the router ACL. Other packets are filtered only by the VLAN map.

- When a VLAN map, output router ACL, and input port ACL exist in an SVI, incoming packets received on the ports to which a port ACL is applied are only filtered by the port ACL. Outgoing routed IP packets are filtered by both the VLAN map and the router ACL. Other packets are filtered only by the VLAN map.

Port ACLs

Port ACLs are ACLs that are applied to Layer 2 interfaces on a switch. Port ACLs are supported only on physical interfaces and not on EtherChannel interfaces. Port ACLs can be applied to the interface in outbound and inbound direction. The following access lists are supported:

- Standard IP access lists using source addresses

- Extended IP access lists using source and destination addresses and optional protocol type information

- MAC extended access lists using source and destination MAC addresses and optional protocol type information

The switch examines ACLs on an interface and permits or denies packet forwarding based on how the packet matches the entries in the ACL. In this way, ACLs control access to a network or to part of a network.

Using ACLs to Control Traffic in a Network

When you apply a port ACL to a trunk port, the ACL filters traffic on all VLANs present on the trunk port. When you apply a port ACL to a port with voice VLAN, the ACL filters traffic on both data and voice VLANs.

With port ACLs, you can filter IP traffic by using IP access lists and non-IP traffic by using MAC addresses. You can filter both IP and non-IP traffic on the same Layer 2 interface by applying both an IP access list and a MAC access list to the interface.

Note

You cannot apply more than one IP access list and one MAC access list to a Layer 2 interface. If an IP access list or MAC access list is already configured on a Layer 2 interface and you apply a new IP access list or MAC access list to the interface, the new ACL replaces the previously configured one.

Router ACLs

You can apply router ACLs on switch virtual interfaces (SVIs), which are Layer 3 interfaces to VLANs; on physical Layer 3 interfaces; and on Layer 3 EtherChannel interfaces. You apply router ACLs on interfaces for specific directions (inbound or outbound). You can apply one router ACL in each direction on an interface.

The switch supports these access lists for IPv4 traffic:

- Standard IP access lists use source addresses for matching operations.

- Extended IP access lists use source and destination addresses and optional protocol type information for matching operations.

As with port ACLs, the switch examines ACLs associated with features configured on a given interface. As packets enter the switch on an interface, ACLs associated with all inbound features configured on that interface are examined. After packets are routed and before they are forwarded to the next hop, all ACLs associated with outbound features configured on the egress interface are examined.

ACLs permit or deny packet forwarding based on how the packet matches the entries in the ACL, and can be used to control access to a network or to part of a network.

VLAN Maps

VLAN ACLs or VLAN maps are used to control network traffic within a VLAN. You can apply VLAN maps to all packets that are bridged within a VLAN in the switch or switch stack. VACLs are strictly for security packet filtering and for redirecting traffic to specific physical interfaces. VACLs are not defined by direction (ingress or egress).

All non-IP protocols are access-controlled through MAC addresses and Ethertype using MAC VLAN maps. (IP traffic is not access controlled by MAC VLAN maps.) You can enforce VLAN maps only on packets going through the switch; you cannot enforce VLAN maps on traffic between hosts on a hub or on another switch connected to this switch.

With VLAN maps, forwarding of packets is permitted or denied, based on the action specified in the map.

Using VLAN Maps to Control Traffic

ACEs and Fragmented and Unfragmented Traffic

IP packets can be fragmented as they cross the network. When this happens, only the fragment containing the beginning of the packet contains the Layer 4 information, such as TCP or UDP port numbers, ICMP type and code, and so on. All other fragments are missing this information.

Some access control entries (ACEs) do not check Layer 4 information and therefore can be applied to all packet fragments. ACEs that do test Layer 4 information cannot be applied in the standard manner to most of the fragments in a fragmented IP packet. When the fragment contains no Layer 4 information and the ACE tests some Layer 4 information, the matching rules are modified:

- Permit ACEs that check the Layer 3 information in the fragment (including protocol type, such as TCP, UDP, and so on) are considered to match the fragment regardless of what the missing Layer 4 information might have been.

Note

For TCP ACEs with L4 Ops, the fragmented packets will be dropped per RFC 1858.

- Deny ACEs that check Layer 4 information never match a fragment unless the fragment contains Layer 4 information.

- ACEs and Fragmented and Unfragmented Traffic Examples

ACEs and Fragmented and Unfragmented Traffic Examples

Consider access list 102, configured with these commands, applied to three fragmented packets:

Device(config)# access-list 102 permit tcp any host 10.1.1.1 eq smtp
Device(config)# access-list 102 deny tcp any host 10.1.1.2 eq telnet
Device(config)# access-list 102 permit tcp any host 10.1.1.2
Device(config)# access-list 102 deny tcp any any

Note

In the first and second ACEs in the examples, the eq keyword after the destination address means to test for the TCP-destination-port well-known numbers equaling Simple Mail Transfer Protocol (SMTP) and Telnet, respectively.

- Packet A is a TCP packet from host 10.2.2.2., port 65000, going to host 10.1.1.1 on the SMTP port. If this packet is fragmented, the first fragment matches the first ACE (a permit) as if it were a complete packet because all Layer 4 information is present. The remaining fragments also match the first ACE, even though they do not contain the SMTP port information, because the first ACE only checks Layer 3 information when applied to fragments. The information in this example is that the packet is TCP and that the destination is 10.1.1.1.

- Packet B is from host 10.2.2.2, port 65001, going to host 10.1.1.2 on the Telnet port. If this packet is fragmented, the first fragment matches the second ACE (a deny) because all Layer 3 and Layer 4 information is present. The remaining fragments in the packet do not match the second ACE because they are missing Layer 4 information. Instead, they match the third ACE (a permit).

Because the first fragment was denied, host 10.1.1.2 cannot reassemble a complete packet, so packet B is effectively denied. However, the later fragments that are permitted will consume bandwidth on the network and resources of host 10.1.1.2 as it tries to reassemble the packet.

- Fragmented packet C is from host 10.2.2.2, port 65001, going to host 10.1.1.3, port ftp. If this packet is fragmented, the first fragment matches the fourth ACE (a deny). All other fragments also match the fourth ACE because that ACE does not check any Layer 4 information and because Layer 3 information in all fragments shows that they are being sent to host 10.1.1.3, and the earlier permit ACEs were checking different hosts.

ACLs and Switch Stacks

ACL support is the same for a switch stack as for a standalone switch. ACL configuration information is propagated to all switches in the stack. All switches in the stack, including the active switch, process the information and program their hardware.

- Active Switch and ACL Functions

- Stack Member and ACL Functions

- Active Switch Failure and ACLs

Active Switch and ACL Functions

The active switch performs these ACL functions:

- It processes the ACL configuration and propagates the information to all stack members.

- It distributes the ACL information to any switch that joins the stack.

- If packets must be forwarded by software for any reason (for example, not enough hardware resources), the active switch forwards the packets only after applying ACLs on the packets.

- It programs its hardware with the ACL information it processes.

Stack Member and ACL Functions

Stack members perform these ACL functions:

- They receive the ACL information from the active switch and program their hardware.

- A stack member configured as a standby switch, performs the functions of the active switch in the event the active switch fails.

Active Switch Failure and ACLs

Both the active and standby switches have the ACL information. When the active switch fails, the standby takes over. The new active switch distributes the ACL information to all stack members.

Standard and Extended IPv4 ACLs

This section describes IP ACLs.

An ACL is a sequential collection of permit and deny conditions. One by one, the switch tests packets against the conditions in an access list. The first match determines whether the switch accepts or rejects the packet. Because the switch stops testing after the first match, the order of the conditions is critical. If no conditions match, the switch denies the packet.

The software supports these types of ACLs or access lists for IPv4:

- Standard IP access lists use source addresses for matching operations.

- Extended IP access lists use source and destination addresses for matching operations and optional protocol-type information for finer granularity of control.

- IPv4 ACL Switch Unsupported Features

- Access List Numbers

- Numbered Standard IPv4 ACLs

- Numbered Extended IPv4 ACLs

- Named IPv4 ACLs

- ACL Logging

IPv4 ACL Switch Unsupported Features

Configuring IPv4 ACLs on the switch is the same as configuring IPv4 ACLs on other Cisco switches and routers.

The following ACL-related features are not supported:

- Non-IP protocol ACLs

- IP accounting

- Reflexive ACLs and dynamic ACLs are not supported.

Access List Numbers

The number you use to denote your ACL shows the type of access list that you are creating.

This lists the access-list number and corresponding access list type and shows whether or not they are supported in the switch. The switch supports IPv4 standard and extended access lists, numbers 1 to 199 and 1300 to 2699.

Access List Numbers

Access List Number

Type

Supported

1–99

IP standard access list

Yes

100–199

IP extended access list

Yes

200–299

Protocol type-code access list

No

300–399

DECnet access list

No

400–499

XNS standard access list

No

500–599

XNS extended access list

No

600–699

AppleTalk access list

No

700–799

48-bit MAC address access list

No

800–899

IPX standard access list

No

900–999

IPX extended access list

No

1000–1099

IPX SAP access list

No

1100–1199

Extended 48-bit MAC address access list

No

1200–1299

IPX summary address access list

No

1300–1999

IP standard access list (expanded range)

Yes

2000–2699

IP extended access list (expanded range)

Yes

In addition to numbered standard and extended ACLs, you can also create standard and extended named IP ACLs by using the supported numbers. That is, the name of a standard IP ACL can be 1 to 99; the name of an extended IP ACL can be 100 to 199. The advantage of using named ACLs instead of numbered lists is that you can delete individual entries from a named list.

Numbered Standard IPv4 ACLs

When creating an ACL, remember that, by default, the end of the ACL contains an implicit deny statement for all packets that it did not find a match for before reaching the end. With standard access lists, if you omit the mask from an associated IP host address ACL specification, 0.0.0.0 is assumed to be the mask.

The switch always rewrites the order of standard access lists so that entries with host matches and entries with matches having a don’t care mask of 0.0.0.0 are moved to the top of the list, above any entries with non-zero don’t care masks. Therefore, in show command output and in the configuration file, the ACEs do not necessarily appear in the order in which they were entered.

After creating a numbered standard IPv4 ACL, you can apply it to VLANs, to terminal lines, or to interfaces.

Numbered Extended IPv4 ACLs

Although standard ACLs use only source addresses for matching, you can use extended ACL source and destination addresses for matching operations and optional protocol type information for finer granularity of control. When you are creating ACEs in numbered extended access lists, remember that after you create the ACL, any additions are placed at the end of the list. You cannot reorder the list or selectively add or remove ACEs from a numbered list.

The switch does not support dynamic or reflexive access lists. It also does not support filtering based on the type of service (ToS) minimize-monetary-cost bit.

Some protocols also have specific parameters and keywords that apply to that protocol.

You can define an extended TCP, UDP, ICMP, IGMP, or other IP ACL. The switch also supports these IP protocols:

Note

ICMP echo-reply cannot be filtered. All other ICMP codes or types can be filtered.

These IP protocols are supported:

- Authentication Header Protocol (ahp )

- Encapsulation Security Payload (esp )

- Enhanced Interior Gateway Routing Protocol (eigrp )

- generic routing encapsulation (gre )

- Internet Control Message Protocol (icmp )

- Internet Group Management Protocol (igmp )

- any Interior Protocol (ip )

- IP in IP tunneling (ipinip )

- KA9Q NOS-compatible IP over IP tunneling (nos )

- Open Shortest Path First routing (ospf )

- Payload Compression Protocol (pcp )

- Protocol-Independent Multicast (pim )

- Transmission Control Protocol (tcp )

- User Datagram Protocol (udp )

Named IPv4 ACLs

You can identify IPv4 ACLs with an alphanumeric string (a name) rather than a number. You can use named ACLs to configure more IPv4 access lists in a router than if you were to use numbered access lists. If you identify your access list with a name rather than a number, the mode and command syntax are slightly different. However, not all commands that use IP access lists accept a named access list.

Note

The name you give to a standard or extended ACL can also be a number in the supported range of access list numbers. That is, the name of a standard IP ACL can be 1 to 99 and . The advantage of using named ACLs instead of numbered lists is that you can delete individual entries from a named list.

Consider these guidelines before configuring named ACLs:

- Numbered ACLs are also available.

- A standard ACL and an extended ACL cannot have the same name.

ACL Logging

The switch software can provide logging messages about packets permitted or denied by a standard IP access list. That is, any packet that matches the ACL causes an informational logging message about the packet to be sent to the console. The level of messages logged to the console is controlled by the logging console commands controlling the syslog messages.

Note

ACL logging is only supported for RACL.

Note

Because routing is done in hardware and logging is done in software, if a large number of packets match a permit or deny ACE containing a log keyword, the software might not be able to match the hardware processing rate, and not all packets will be logged.

The first packet that triggers the ACL causes a logging message right away, and subsequent packets are collected over 5-minute intervals before they appear or logged. The logging message includes the access list number, whether the packet was permitted or denied, the source IP address of the packet, and the number of packets from that source permitted or denied in the prior 5-minute interval.

Note

The logging facility might drop some logging message packets if there are too many to be handled or if there is more than one logging message to be handled in 1 second. This behavior prevents the router from crashing due to too many logging packets. Therefore, the logging facility should not be used as a billing tool or an accurate source of the number of matches to an access list.

Hardware and Software Treatment of IP ACLs

ACL processing is performed in hardware. If the hardware reaches its capacity to store ACL configurations, all packets on that interface are dropped.

Note

If an ACL configuration cannot be implemented in hardware due to an out-of-resource condition on a device or stack member, then only the traffic in that VLAN arriving on that device is affected.

For router ACLs, other factors can cause packets to be sent to the CPU:

- Using the log keyword

- Generating ICMP unreachable messages

When you enter the show ip access-lists privileged EXEC command, the match count displayed does not account for packets that are access controlled in hardware. Use the show platform software fed switch { switch_num | active | standby } acl counters hardware privileged EXEC command to obtain some basic hardware ACL statistics for switched and routed packets.

Router ACLs function as follows:

- The hardware controls permit and deny actions of standard and extended ACLs (input and output) for security access control.

- If log has not been specified, the flows that match a deny statement in a security ACL are dropped by the hardware if ip unreachables is disabled. The flows matching a permit statement are switched in hardware.

- Adding the log keyword to an ACE in a router ACL causes a copy of the packet to be sent to the CPU for logging only. If the ACE is a permit statement, the packet is still switched and routed in hardware.

VLAN Map Configuration Guidelines

VLAN maps are the only way to control filtering within a VLAN. VLAN maps have no direction. To filter traffic in a specific direction by using a VLAN map, you need to include an ACL with specific source or destination addresses. If there is a match clause for that type of packet (IP or MAC) in the VLAN map, the default action is to drop the packet if the packet does not match any of the entries within the map. If there is no match clause for that type of packet, the default is to forward the packet.

The following are the VLAN map configuration guidelines:

- If there is no ACL configured to deny traffic on an interface and no VLAN map is configured, all traffic is permitted.

- Each VLAN map consists of a series of entries. The order of entries in an VLAN map is important. A packet that comes into the switch is tested against the first entry in the VLAN map. If it matches, the action specified for that part of the VLAN map is taken. If there is no match, the packet is tested against the next entry in the map.

- If the VLAN map has at least one match clause for the type of packet (IP or MAC) and the packet does not match any of these match clauses, the default is to drop the packet. If there is no match clause for that type of packet in the VLAN map, the default is to forward the packet.

- Logging is not supported for VLAN maps.

- When a switch has an IP access list or MAC access list applied to a Layer 2 interface, and you apply a VLAN map to a VLAN that the port belongs to, the port ACL takes precedence over the VLAN map.

- If a VLAN map configuration cannot be applied in hardware, all packets in that VLAN are dropped.

VLAN Maps with Router ACLs

To access control both bridged and routed traffic, you can use VLAN maps only or a combination of router ACLs and VLAN maps. You can define router ACLs on both input and output routed VLAN interfaces, and you can define a VLAN map to access control the bridged traffic.

If a packet flow matches a VLAN-map deny clause in the ACL, regardless of the router ACL configuration, the packet flow is denied.

Note

When you use router ACLs with VLAN maps, packets that require logging on the router ACLs are not logged if they are denied by a VLAN map.

If the VLAN map has a match clause for the type of packet (IP or MAC) and the packet does not match the type, the default is to drop the packet. If there is no match clause in the VLAN map, and no action specified, the packet is forwarded if it does not match any VLAN map entry.

- VLAN Maps and Router ACL Configuration Guidelines

VLAN Maps and Router ACL Configuration Guidelines

These guidelines are for configurations where you need to have an router ACL and a VLAN map on the same VLAN. These guidelines do not apply to configurations where you are mapping router ACLs and VLAN maps on different VLANs.

If you must configure a router ACL and a VLAN map on the same VLAN, use these guidelines for both router ACL and VLAN map configuration:

- You can configure only one VLAN map and one router ACL in each direction (input/output) on a VLAN interface.

- Whenever possible, try to write the ACL with all entries having a single action except for the final, default action of the other type. That is, write the ACL using one of these two forms:

permit...
permit...
permit...
deny ip any any

or

deny...
deny...
deny...
permit ip any any

- To define multiple actions in an ACL (permit, deny), group each action type together to reduce the number of entries.

- Avoid including Layer 4 information in an ACL; adding this information complicates the merging process. The best merge results are obtained if the ACLs are filtered based on IP addresses (source and destination) and not on the full flow (source IP address, destination IP address, protocol, and protocol ports). It is also helpful to use don’t care bits in the IP address, whenever possible.

If you need to specify the full-flow mode and the ACL contains both IP ACEs and TCP/UDP/ICMP ACEs with Layer 4 information, put the Layer 4 ACEs at the end of the list. This gives priority to the filtering of traffic based on IP addresses.

Time Ranges for ACLs

You can selectively apply extended ACLs based on the time of day and the week by using the time-range global configuration command. First, define a time-range name and set the times and the dates or the days of the week in the time range. Then enter the time-range name when applying an ACL to set restrictions to the access list. You can use the time range to define when the permit or deny statements in the ACL are in effect, for example, during a specified time period or on specified days of the week. The time-range keyword and argument are referenced in the named and numbered extended ACL task tables.

These are some benefits of using time ranges:

- You have more control over permitting or denying a user access to resources, such as an application (identified by an IP address/mask pair and a port number).

- You can control logging messages. ACL entries can be set to log traffic only at certain times of the day. Therefore, you can simply deny access without needing to analyze many logs generated during peak hours.

Time-based access lists trigger CPU activity because the new configuration of the access list must be merged with other features and the combined configuration loaded into the hardware memory. For this reason, you should be careful not to have several access lists configured to take affect in close succession (within a small number of minutes of each other.)

Note

The time range relies on the switch system clock; therefore, you need a reliable clock source. We recommend that you use Network Time Protocol (NTP) to synchronize the switch clock.

IPv4 ACL Interface Considerations

When you apply the ip access-group interface configuration command to a Layer 3 interface (an SVI, a Layer 3 EtherChannel, or a routed port), the interface must have been configured with an IP address. Layer 3 access groups filter packets that are routed or are received by Layer 3 processes on the CPU. They do not affect packets bridged within a VLAN.

For inbound ACLs, after receiving a packet, the switch checks the packet against the ACL. If the ACL permits the packet, the switch continues to process the packet. If the ACL rejects the packet, the switch discards the packet.

For outbound ACLs, after receiving and routing a packet to a controlled interface, the switch checks the packet against the ACL. If the ACL permits the packet, the switch sends the packet. If the ACL rejects the packet, the switch discards the packet.

By default, the input interface sends ICMP Unreachable messages whenever a packet is discarded, regardless of whether the packet was discarded because of an ACL on the input interface or because of an ACL on the output interface. ICMP Unreachables are normally limited to no more than one every one-half second per input interface, but this can be changed by using the ip icmp rate-limit unreachable global configuration command.

When you apply an undefined ACL to an interface, the switch acts as if the ACL has not been applied to the interface and permits all packets. Remember this behavior if you use undefined ACLs for network security.

How to Configure ACLs

- Configuring IPv4 ACLs

- Creating a Numbered Standard ACL (CLI)

- Creating a Numbered Extended ACL (CLI)

- Creating Named Standard ACLs

- Creating Extended Named ACLs

- Configuring Time Ranges for ACLs

- Applying an IPv4 ACL to a Terminal Line

- Applying an IPv4 ACL to an Interface (CLI)

- Creating Named MAC Extended ACLs

- Applying a MAC ACL to a Layer 2 Interface

- Configuring VLAN Maps

- Creating a VLAN Map

- Applying a VLAN Map to a VLAN

Configuring IPv4 ACLs

Follow the procedure given below to use IP ACLs on the switch:

Procedure

Step 1

Create an ACL by specifying an access list number or name and the access conditions.

Step 2

Apply the ACL to interfaces or terminal lines. You can also apply standard and extended IP ACLs to VLAN maps.

Creating a Numbered Standard ACL (CLI)

Follow the procedure given below to create a numbered standard ACL:

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode. Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

access-list access-list-number {deny | permit} source source-wildcard ]

Example:

Device(config)# access-list 2 deny your_host

Defines a standard IPv4 access list by using a source address and wildcard.

The access-list-number is a decimal number from 1 to 99 or 1300 to 1999.

Enter deny or permit to specify whether to deny or permit access if conditions are matched.

The source is the source address of the network or host from which the packet is being sent specified as:

- The 32-bit quantity in dotted-decimal format.

- The keyword any as an abbreviation for source and source-wildcard of 0.0.0.0 255.255.255.255. You do not need to enter a source-wildcard.

- The keyword host as an abbreviation for source and source-wildcard of source 0.0.0.0.

(Optional) The source-wildcard applies wildcard bits to the source.

Note

Logging is supported only on ACLs attached to Layer 3 interfaces.

Step 4

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 5

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 6

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Creating a Numbered Extended ACL (CLI)

Follow the procedure given below to create a numbered extended ACL:

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

access-list access-list-number
{deny | permit} protocol
source source-wildcard
destination destination-wildcard [precedence precedence] [tos tos] [fragments] [log [log-input] [time-range time-range-name] [dscp dscp]

Example:

Device(config)# access-list 101 permit ip host 10.1.1.2 any precedence 0 tos 0 log

Defines an extended IPv4 access list and the access conditions.

The access-list-number is a decimal number from 100 to 199 or 2000 to 2699.

Enter deny or permit to specify whether to deny or permit the packet if conditions are matched.

For protocol , enter the name or number of an P protocol: ahp , eigrp , esp , gre , icmp , igmp , igrp , ip , ipinip , nos , ospf , pcp , pim , tcp , or udp , or an integer in the range 0 to 255 representing an IP protocol number. To match any Internet protocol (including ICMP, TCP, and UDP), use the keyword ip .

Note

This step includes options for most IP protocols. For additional specific parameters for TCP, UDP, ICMP, and IGMP, see the following steps.

The source is the number of the network or host from which the packet is sent.

The source-wildcard applies wildcard bits to the source.

The destination is the network or host number to which the packet is sent.

The destination-wildcard applies wildcard bits to the destination.

Source, source-wildcard, destination, and destination-wildcard can be specified as:

- The 32-bit quantity in dotted-decimal format.

- The keyword any for 0.0.0.0 255.255.255.255 (any host).

- The keyword host for a single host 0.0.0.0.

The other keywords are optional and have these meanings:

- precedence —Enter to match packets with a precedence level specified as a number from 0 to 7 or by name: routine (0), priority (1), immediate (2), flash (3), flash-override (4), critical (5), internet (6), network (7).

- fragments —Enter to check non-initial fragments.

- tos —Enter to match by type of service level, specified by a number from 0 to 15 or a name: normal (0), max-reliability (2), max-throughput (4), min-delay (8).

- log —Enter to create an informational logging message to be sent to the console about the packet that matches the entry or log-input to include the input interface in the log entry.

- time-range —Specify the time-range name.

- dscp —Enter to match packets with the DSCP value specified by a number from 0 to 63, or use the question mark (?) to see a list of available values.

Note

If you enter a dscp value, you cannot enter tos or precedence . You can enter both a tos and a precedence value with no dscp .

Step 3

access-list access-list-number {deny | permit} tcp source source-wildcard [operator port] destination destination-wildcard [operator port] [established] [precedence precedence] [tos tos] [fragments] [log [log-input] [time-range time-range-name] [dscp dscp] [flag]

Example:

Device(config)# access-list 101 permit tcp any any eq 500

Defines an extended TCP access list and the access conditions.

The parameters are the same as those described for an extended IPv4 ACL, with these exceptions:

(Optional) Enter an operator and port to compare source (if positioned after source source-wildcard ) or destination (if positioned after destination destination-wildcard ) port. Possible operators include eq (equal), gt (greater than), lt (less than), neq (not equal), and range (inclusive range). Operators require a port number (range requires two port numbers separated by a space).

Enter the port number as a decimal number (from 0 to 65535) or the name of a TCP port. Use only TCP port numbers or names when filtering TCP.

The other optional keywords have these meanings:

- established —Enter to match an established connection. This has the same function as matching on the ack or rst flag.

- flag —Enter one of these flags to match by the specified TCP header bits: ack (acknowledge), fin (finish), psh (push), rst (reset), syn (synchronize), or urg (urgent).

Step 4

access-list access-list-number
{deny | permit} udp
source source-wildcard [operator port] destination destination-wildcard [operator port] [precedence precedence] [tos tos] [fragments] [log [log-input] [time-range time-range-name] [dscp dscp]

Example:

Device(config)# access-list 101 permit udp any any eq 100

(Optional) Defines an extended UDP access list and the access conditions.

The UDP parameters are the same as those described for TCP except that the [operator [port]] port number or name must be a UDP port number or name, and the flag and established keywords are not valid for UDP.

Step 5

access-list access-list-number
{deny | permit} icmp source source-wildcard destination destination-wildcard [icmp-type | [[icmp-type icmp-code] | [icmp-message]] [precedence precedence] [tos tos] [fragments] [time-range time-range-name] [dscp dscp]

Example:

Device(config)# access-list 101 permit icmp any any 200

Defines an extended ICMP access list and the access conditions.

The ICMP parameters are the same as those described for most IP protocols in an extended IPv4 ACL, with the addition of the ICMP message type and code parameters. These optional keywords have these meanings:

- icmp-type—Enter to filter by ICMP message type, a number from 0 to 255.

- icmp-code—Enter to filter ICMP packets that are filtered by the ICMP message code type, a number from 0 to 255.

- icmp-message—Enter to filter ICMP packets by the ICMP message type name or the ICMP message type and code name.

Step 6

access-list access-list-number
{deny | permit} igmp source source-wildcard destination destination-wildcard [igmp-type] [precedence precedence] [tos tos] [fragments] [log [log-input] [time-range time-range-name] [dscp dscp]

Example:

Device(config)# access-list 101 permit igmp any any 14

(Optional) Defines an extended IGMP access list and the access conditions.

The IGMP parameters are the same as those described for most IP protocols in an extended IPv4 ACL, with this optional parameter.

igmp-type—To match IGMP message type, enter a number from 0 to 15, or enter the message name: dvmrp , host-query , host-report , pim , or trace .

Step 7

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Creating Named Standard ACLs

Follow the procedure given below to create a standard ACL using names:

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode. Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ip access-list standard name

Example:

Device(config)# ip access-list standard 20

Defines a standard IPv4 access list using a name, and enter access-list configuration mode.

The name can be a number from 1 to 99.

Step 4

Use one of the following:

- deny {source [source-wildcard] | host source | any} [log]

- permit {source [source-wildcard] | host source | any} [log]

Example:

Device(config-std-nacl)# deny 192.168.0.0 0.0.255.255 255.255.0.0 0.0.255.255

or

Device(config-std-nacl)# permit 10.108.0.0 0.0.0.0 255.255.255.0 0.0.0.0

In access-list configuration mode, specify one or more conditions denied or permitted to decide if the packet is forwarded or dropped.

- host source —A source and source wildcard of source 0.0.0.0.

- any —A source and source wildcard of 0.0.0.0 255.255.255.255.

Step 5

end

Example:

Device(config-std-nacl)# end

Returns to privileged EXEC mode.

Step 6

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 7

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Creating Extended Named ACLs

Follow the procedure given below to create an extended ACL using names:

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode. Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ip access-list extended name

Example:

Device(config)# ip access-list extended 150

Defines an extended IPv4 access list using a name, and enter access-list configuration mode.

The name can be a number from 100 to 199.

Step 4

{deny | permit} protocol {source [source-wildcard] | host source | any} {destination [destination-wildcard] | host destination | any} [precedence precedence] [tos tos] [established] [log] [time-range time-range-name]

Example:

Device(config-ext-nacl)# permit 0 any any

In access-list configuration mode, specify the conditions allowed or denied. Use the log keyword to get access list logging messages, including violations.

- host source —A source and source wildcard of source 0.0.0.0.

- host destintation —A destination and destination wildcard of destination 0.0.0.0.

- any—A source and source wildcard or destination and destination wildcard of 0.0.0.0 255.255.255.255.

Step 5

end

Example:

Device(config-ext-nacl)# end

Returns to privileged EXEC mode.

Step 6

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 7

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

When you are creating extended ACLs, remember that, by default, the end of the ACL contains an implicit deny statement for everything if it did not find a match before reaching the end. For standard ACLs, if you omit the mask from an associated IP host address access list specification, 0.0.0.0 is assumed to be the mask.

After you create an ACL, any additions are placed at the end of the list. You cannot selectively add ACL entries to a specific ACL. However, you can use no permit and no deny access-list configuration mode commands to remove entries from a named ACL.

Being able to selectively remove lines from a named ACL is one reason you might use named ACLs instead of numbered ACLs.

What to do next

After creating a named ACL, you can apply it to interfaces or to VLANs .

Configuring Time Ranges for ACLs

Follow these steps to configure a time-range parameter for an ACL:

Procedure

Step 1

enable

Example:

Device(config)# enable

Enables privileged EXEC mode. Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

time-range time-range-name

Example:

Device(config)# time-range workhours

Assigns a meaningful name (for example, workhours) to the time range to be created, and enter time-range configuration mode. The name cannot contain a space or quotation mark and must begin with a letter.

Step 4

Use one of the following:

- absolute [start time date]
[end time date]

- periodic day-of-the-week hh:mm to [day-of-the-week] hh:mm

- periodic {weekdays | weekend | daily} hh:mm to hh:mm

Example:

Device(config-time-range)# absolute start 00:00 1 Jan 2006 end 23:59 1 Jan 2006

or

Device(config-time-range)# periodic weekdays 8:00 to 12:00

Specifies when the function it will be applied to is operational.

- You can use only one absolute statement in the time range. If you configure more than one absolute statement, only the one configured last is executed.

- You can enter multiple periodic statements. For example, you could configure different hours for weekdays and weekends.

See the example configurations.

Step 5

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 6

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 7

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

What to do next

Repeat the steps if you have multiple items that you want in effect at different times.

Applying an IPv4 ACL to a Terminal Line

You can use numbered ACLs to control access to one or more terminal lines. You cannot apply named ACLs to lines. You must set identical restrictions on all the virtual terminal lines because a user can attempt to connect to any of them.

Follow these steps to restrict incoming and outgoing connections between a virtual terminal line and the addresses in an ACL:

Procedure

Step 1

enable

Example:

Device(config)# enable

Enables privileged EXEC mode. Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

line [console | vty] line-number

Example:

Device(config)# line console 0

Identifies a specific line to configure, and enter in-line configuration mode.

- console—Specifies the console terminal line. The console port is DCE.

- vty—Specifies a virtual terminal for remote console access.

The line-number is the first line number in a contiguous group that you want to configure when the line type is specified. The range is from 0 to 16.

Step 4

access-class access-list-number {in | out }

Example:

Device(config-line)# access-class 10 in

Restricts incoming and outgoing connections between a particular virtual terminal line (into a device) and the addresses in an access list.

Step 5

end

Example:

Device(config-line)# end

Returns to privileged EXEC mode.

Step 6

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 7

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Applying an IPv4 ACL to an Interface (CLI)

This section describes how to apply IPv4 ACLs to network interfaces.

Beginning in privileged EXEC mode, follow the procedure given below to control access to an interface:

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

interface interface-id

Example:

Device(config)# interface gigabitethernet1/0/1

Identifies a specific interface for configuration, and enter interface configuration mode.

The interface can be a Layer 2 interface (port ACL), or a Layer 3 interface (router ACL).

Step 3

ip access-group {access-list-number | name} {in | out}

Example:

Device(config-if)# ip access-group 2 in

Controls access to the specified interface.

Step 4

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Step 5

show running-config

Example:

Device# show running-config

Displays the access list configuration.

Step 6

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Creating Named MAC Extended ACLs

You can filter non-IPv4 traffic on a VLAN or on a Layer 2 interface by using MAC addresses and named MAC extended ACLs. The procedure is similar to that of configuring other extended named ACLs.

Follow these steps to create a named MAC extended ACL:

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode. Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

mac access-list extended name

Example:

Device(config)# mac access-list extended mac1

Defines an extended MAC access list using a name.

Step 4

{deny | permit} {any | host source MAC address | source MAC address mask} {any | host destination MAC address | destination MAC address mask} [type mask | lsap lsap mask | aarp | amber | dec-spanning | decnet-iv | diagnostic | dsm | etype-6000 | etype-8042 | lat | lavc-sca | mop-console | mop-dump | msdos | mumps | netbios | vines-echo | vines-ip | xns-idp | 0-65535] [cos cos]

Example:

Device(config-ext-macl)# deny any any decnet-iv

or

Device(config-ext-macl)# permit any any

In extended MAC access-list configuration mode, specifies to permit or deny any source MAC address, a source MAC address with a mask, or a specific host source MAC address and any destination MAC address, destination MAC address with a mask, or a specific destination MAC address.

(Optional) You can also enter these options:

- type mask —An arbitrary EtherType number of a packet with Ethernet II or SNAP encapsulation in decimal, hexadecimal, or octal with optional mask of don’t care bits applied to the EtherType before testing for a match.

- lsap lsap mask —An LSAP number of a packet with IEEE 802.2 encapsulation in decimal, hexadecimal, or octal with optional mask of don’t care bits.

- aarp | amber | dec-spanning | decnet-iv | diagnostic | dsm | etype-6000 | etype-8042 | lat | lavc-sca | mop-console | mop-dump | msdos | mumps | netbios | vines-echo | vines-ip | xns-idp —A non-IP protocol.

- cos cos —An IEEE 802.1Q cost of service number from 0 to 7 used to set priority.

Step 5

end

Example:

Device(config-ext-macl)# end

Returns to privileged EXEC mode.

Step 6

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 7

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Applying a MAC ACL to a Layer 2 Interface

Follow these steps to apply a MAC access list to control access to a Layer 2 interface:

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface interface-id

Example:

Device(config)# interface gigabitethernet1/0/2

Identifies a specific interface, and enter interface configuration mode. The interface must be a physical Layer 2 interface (port ACL).

Step 4

mac access-group {name} {in | out }

Example:

Device(config-if)# mac access-group mac1 in

Controls access to the specified interface by using the MAC access list.

Port ACLs are supported in the outbound and inbound directions .

Step 5

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Step 6

show mac access-group [interface interface-id]

Example:

Device# show mac access-group interface gigabitethernet1/0/2

Displays the MAC access list applied to the interface or all Layer 2 interfaces.

Step 7

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 8

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

After receiving a packet, the switch checks it against the inbound ACL. If the ACL permits it, the switch continues to process the packet. If the ACL rejects the packet, the switch discards it. When you apply an undefined ACL to an interface, the switch acts as if the ACL has not been applied and permits all packets. Remember this behavior if you use undefined ACLs for network security.

Configuring VLAN Maps

Follow the procedure given below to create a VLAN map and apply it to one or more VLANs:

Before you begin

Create the standard or extended IPv4 ACLs or named MAC extended ACLs that you want to apply to the VLAN.

Procedure

Step 1

vlan access-map name [number]

Example:

Device(config)# vlan access-map map_1 20

Creates a VLAN map, and give it a name and (optionally) a number. The number is the sequence number of the entry within the map.

When you create VLAN maps with the same name, numbers are assigned sequentially in increments of 10. When modifying or deleting maps, you can enter the number of the map entry that you want to modify or delete.

VLAN maps do not use the specific permit or deny keywords. To deny a packet by using VLAN maps, create an ACL that would match the packet, and set the action to drop. A permit in the ACL counts as a match. A deny in the ACL means no match.

Entering this command changes to access-map configuration mode.

Step 2

match {ip | mac} address {name | number} [name | number]

Example:

Device(config-access-map)# match ip address ip2

Match the packet (using either the IP or MAC address) against one or more standard or extended access lists. Note that packets are only matched against access lists of the correct protocol type. IP packets are matched against standard or extended IP access lists. Non-IP packets are only matched against named MAC extended access lists.

Note

If the VLAN map is configured with a match clause for a type of packet (IP or MAC) and the map action is drop, all packets that match the type are dropped. If the VLAN map has no match clause, and the configured action is drop, all IP and Layer 2 packets are dropped.

Step 3

Enter one of the following commands to specify an IP packet or a non-IP packet (with only a known MAC address) and to match the packet against one or more ACLs (standard or extended):

- action { forward}

Device(config-access-map)# action forward

- action { drop}

Device(config-access-map)# action drop

Sets the action for the map entry.

Step 4

vlan filter mapname vlan-list list

Example:

Device(config)# vlan filter map 1 vlan-list 20-22

Applies the VLAN map to one or more VLAN IDs.

The list can be a single VLAN ID (22), a consecutive list (10-22), or a string of VLAN IDs (12, 22, 30). Spaces around the comma and hyphen are optional.

Creating a VLAN Map

Each VLAN map consists of an ordered series of entries. Beginning in privileged EXEC mode, follow these steps to create, add to, or delete a VLAN map entry:

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

vlan access-map name [number]

Example:

Device(config)# vlan access-map map_1 20

Creates a VLAN map, and give it a name and (optionally) a number. The number is the sequence number of the entry within the map.

When you create VLAN maps with the same name, numbers are assigned sequentially in increments of 10. When modifying or deleting maps, you can enter the number of the map entry that you want to modify or delete.

VLAN maps do not use the specific permit or deny keywords. To deny a packet by using VLAN maps, create an ACL that would match the packet, and set the action to drop. A permit in the ACL counts as a match. A deny in the ACL means no match.

Entering this command changes to access-map configuration mode.

Step 3

match {ip | mac} address {name | number} [name | number]

Example:

Device(config-access-map)# match ip address ip2

Match the packet (using either the IP or MAC address) against one or more standard or extended access lists. Note that packets are only matched against access lists of the correct protocol type. IP packets are matched against standard or extended IP access lists. Non-IP packets are only matched against named MAC extended access lists.

Step 4

action {drop | forward}

Example:

Device(config-access-map)# action forward

(Optional) Sets the action for the map entry. The default is to forward.

Step 5

end

Example:

Device(config-access-map)# end

Returns to global configuration mode.

Step 6

show running-config

Example:

Device# show running-config

Displays the access list configuration.

Step 7

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Applying a VLAN Map to a VLAN

To apply a VLAN map to one or more VLANs, perform these steps.

Procedure

Step 1

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

vlan filter mapname vlan-list list

Example:

Device(config)# vlan filter map 1 vlan-list 20-22

Applies the VLAN map to one or more VLAN IDs.

The list can be a single VLAN ID (22), a consecutive list (10-22), or a string of VLAN IDs (12, 22, 30). Spaces around the comma and hyphen are optional.

Step 4

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 5

show running-config

Example:

Device# show running-config

Displays the access list configuration.

Step 6

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Monitoring IPv4 ACLs

You can monitor IPv4 ACLs by displaying the ACLs that are configured on the switch, and displaying the ACLs that have been applied to interfaces and VLANs.

When you use the ip access-group interface configuration command to apply ACLs to a Layer 2 or 3 interface, you can display the access groups on the interface. You can also display the MAC ACLs applied to a Layer 2 interface. You can use the privileged EXEC commands as described in this table to display this information.

Commands for Displaying Access Lists and Access Groups

Command

Purpose

show access-lists [number | name]

Displays the contents of one or all current IP and MAC address access lists or a specific access list (numbered or named).

show ip access-lists [number | name]

Displays the contents of all current IP access lists or a specific IP access list (numbered or named).

show ip interface interface-id

Displays detailed configuration and status of an interface. If IP is enabled on the interface and ACLs have been applied by using the ip access-group interface configuration command, the access groups are included in the display.

show running-config [interface interface-id]

Displays the contents of the configuration file for the switch or the specified interface, including all configured MAC and IP access lists and which access groups are applied to an interface.

show mac access-group [interface interface-id]

Displays MAC access lists applied to all Layer 2 interfaces or the specified

Layer 2 interface.

Configuration Examples for ACLs

- Examples: Using Time Ranges with ACLs

- Examples: Including Comments in ACLs

- IPv4 ACL Configuration Examples

- Configuration Examples for ACLs and VLAN Maps

- Configuration Examples for Using VLAN Maps in Your Network

- Configuration Examples of Router ACLs and VLAN Maps Applied to VLANs

Examples: Using Time Ranges with ACLs

This example shows how to verify after you configure time ranges for workhours and to configure January 1, 2006, as a company holiday.

Device# show time-range
time-range entry: new_year_day_2003 (inactive)
absolute start 00:00 01 January 2006 end 23:59 01 January 2006
time-range entry: workhours (inactive)
periodic weekdays 8:00 to 12:00
periodic weekdays 13:00 to 17:00

To apply a time range, enter the time-range name in an extended ACL that can implement time ranges. This example shows how to create and verify extended access list 188 that denies TCP traffic from any source to any destination during the defined holiday times and permits all TCP traffic during work hours.

Device(config)# access-list 188 deny tcp any any time-range new_year_day_2006
Device(config)# access-list 188 permit tcp any any time-range workhours
Device(config)# end
Device# show access-lists
Extended IP access list 188
10 deny tcp any any time-range new_year_day_2006 (inactive)
20 permit tcp any any time-range workhours (inactive)

This example uses named ACLs to permit and deny the same traffic.

Device(config)# ip access-list extended deny_access
Device(config-ext-nacl)# deny tcp any any time-range new_year_day_2006
Device(config-ext-nacl)# exit
Device(config)# ip access-list extended may_access
Device(config-ext-nacl)# permit tcp any any time-range workhours
Device(config-ext-nacl)# end
Device# show ip access-lists
Extended IP access list lpip_default
10 permit ip any any
Extended IP access list deny_access
10 deny tcp any any time-range new_year_day_2006 (inactive)
Extended IP access list may_access
10 permit tcp any any time-range workhours (inactive)

Examples: Including Comments in ACLs

You can use the remark keyword to include comments (remarks) about entries in any IP standard or extended ACL. The remarks make the ACL easier for you to understand and scan. Each remark line is limited to 100 characters.

The remark can go before or after a permit or deny statement. You should be consistent about where you put the remark so that it is clear which remark describes which permit or deny statement. For example, it would be confusing to have some remarks before the associated permit or deny statements and some remarks after the associated statements.

To include a comment for IP numbered standard or extended ACLs, use the access-list access-list number remark remark global configuration command. To remove the remark, use the no form of this command.

In this example, the workstation that belongs to Jones is allowed access, and the workstation that belongs to Smith is not allowed access:

Device(config)# access-list 1 remark Permit only Jones workstation through
Device(config)# access-list 1 permit 171.69.2.88
Device(config)# access-list 1 remark Do not allow Smith through
Device(config)# access-list 1 deny 171.69.3.13

For an entry in a named IP ACL, use the remark access-list configuration command. To remove the remark, use the no form of this command.

In this example, the Jones subnet is not allowed to use outbound Telnet:

Device(config)# ip access-list extended telnetting
Device(config-ext-nacl)# remark Do not allow Jones subnet to telnet out
Device(config-ext-nacl)# deny tcp host 171.69.2.88 any eq telnet

IPv4 ACL Configuration Examples

This section provides examples of configuring and applying IPv4 ACLs. For detailed information about compiling ACLs, see the Cisco IOS Security Configuration Guide, Release 12.4 and to the Configuring IP Services” section in the “IP Addressing and Services” chapter of the Cisco IOS IP Configuration Guide, Release 12.4.

- ACLs in a Small Networked Office

- Examples: ACLs in a Small Networked Office

- Example: Numbered ACLs

- Examples: Extended ACLs

- Examples: Named ACLs

- Examples: Time Range Applied to an IP ACL

- Examples: Configuring Commented IP ACL Entries

- Examples: ACL Logging

ACLs in a Small Networked Office

Using Router ACLs to Control Traffic

Use router ACLs to do this in one of two ways:

- Create a standard ACL, and filter traffic coming to the server from Port 1.

- Create an extended ACL, and filter traffic coming from the server into Port 1.

Examples: ACLs in a Small Networked Office

This example uses a standard ACL to filter traffic coming into Server B from a port, permitting traffic only from Accounting’s source addresses 172.20.128.64 to 172.20.128.95. The ACL is applied to traffic coming out of routed Port 1 from the specified source address.

Device(config)# access-list 6 permit 172.20.128.64 0.0.0.31
Device(config)# end
Device# how access-lists
Standard IP access list 6
10 permit 172.20.128.64, wildcard bits 0.0.0.31
Device(config)# interface gigabitethernet1/0/1
Device(config-if)# ip access-group 6 out

This example uses an extended ACL to filter traffic coming from Server B into a port, permitting traffic from any source address (in this case Server B) to only the Accounting destination addresses 172.20.128.64 to 172.20.128.95. The ACL is applied to traffic going into routed Port 1, permitting it to go only to the specified destination addresses. Note that with extended ACLs, you must enter the protocol (IP) before the source and destination information.

Device(config)# access-list 106 permit ip any 172.20.128.64 0.0.0.31
Device(config)# end
Device# show access-lists
Extended IP access list 106
10 permit ip any 172.20.128.64 0.0.0.31
Device(config)# interface gigabitethernet1/0/1
Device(config-if)# ip access-group 106 in

Example: Numbered ACLs

In this example, network 10.0.0.0 is a Class A network whose second octet specifies a subnet; that is, its subnet mask is 255.255.0.0. The third and fourth octets of a network 10.0.0.0 address specify a particular host. Using access list 2, the switch accepts one address on subnet 48 and reject all others on that subnet. The last line of the list shows that the switch accepts addresses on all other network 10.0.0.0 subnets. The ACL is applied to packets entering a port.

Device(config)# access-list 2 permit 10.48.0.3
Device(config)# access-list 2 deny 10.48.0.0 0.0.255.255
Device(config)# access-list 2 permit 10.0.0.0 0.255.255.255
Device(config)# interface gigabitethernet2/0/1
Device(config-if)# ip access-group 2 in

Examples: Extended ACLs

In this example, the first line permits any incoming TCP connections with destination ports greater than 1023. The second line permits incoming TCP connections to the Simple Mail Transfer Protocol (SMTP) port of host 128.88.1.2. The third line permits incoming ICMP messages for error feedback.

Device(config)# access-list 102 permit tcp any 128.88.0.0 0.0.255.255 gt 1023
Device(config)# access-list 102 permit tcp any host 128.88.1.2 eq 25
Device(config)# access-list 102 permit icmp any any
Device(config)# interface gigabitethernet2/0/1
Device(config-if)# ip access-group 102 in

In this example, suppose that you have a network connected to the Internet, and you want any host on the network to be able to form TCP connections to any host on the Internet. However, you do not want IP hosts to be able to form TCP connections to hosts on your network, except to the mail (SMTP) port of a dedicated mail host.

SMTP uses TCP port 25 on one end of the connection and a random port number on the other end. The same port numbers are used throughout the life of the connection. Mail packets coming in from the Internet have a destination port of 25. Outbound packets have the port numbers reversed. Because the secure system of the network always accepts mail connections on port 25, the incoming and outgoing services are separately controlled. The ACL must be configured as an input ACL on the outbound interface and an output ACL on the inbound interface.

Device(config)# access-list 102 permit tcp any 128.88.0.0 0.0.255.255 eq 23
Device(config)# access-list 102 permit tcp any 128.88.0.0 0.0.255.255 eq 25
Device(config)# interface gigabitethernet1/0/1
Device(config-if)# ip access-group 102 in

In this example, the network is a Class B network with the address 128.88.0.0, and the mail host address is 128.88.1.2. The established keyword is used only for the TCP to show an established connection. A match occurs if the TCP datagram has the ACK or RST bits set, which show that the packet belongs to an existing connection. Gigabit Ethernet interface 1 on stack member 1 is the interface that connects the router to the Internet.

Device(config)# access-list 102 permit tcp any 128.88.0.0 0.0.255.255 established
Device(config)# access-list 102 permit tcp any host 128.88.1.2 eq 25
Device(config)# interface gigabitethernet1/0/1
Device(config-if)# ip access-group 102 in

Examples: Named ACLs

Creating named standard and extended ACLs

This example creates a standard ACL named internet_filter and an extended ACL named marketing_group. The internet_filter ACL allows all traffic from the source address 1.2.3.4.

Device(config)# ip access-list standard Internet_filter
Device(config-ext-nacl)# permit 1.2.3.4
Device(config-ext-nacl)# exit

The marketing_group ACL allows any TCP Telnet traffic to the destination address and wildcard 171.69.0.0 0.0.255.255 and denies any other TCP traffic. It permits ICMP traffic, denies UDP traffic from any source to the destination address range 171.69.0.0 through 179.69.255.255 with a destination port less than 1024, denies any other IP traffic, and provides a log of the result.

Device(config)# ip access-list extended marketing_group
Device(config-ext-nacl)# permit tcp any 171.69.0.0 0.0.255.255 eq telnet
Device(config-ext-nacl)# deny tcp any any
Device(config-ext-nacl)# permit icmp any any
Device(config-ext-nacl)# deny udp any 171.69.0.0 0.0.255.255 lt 1024
Device(config-ext-nacl)# deny ip any any log
Device(config-ext-nacl)# exit

The Internet_filter ACL is applied to outgoing traffic and the marketing_group ACL is applied to incoming traffic on a Layer 3 port.

Device(config)# interface gigabitethernet3/0/1
Device(config-if)# no switchport
Device(config-if)# ip address 2.0.5.1 255.255.255.0
Device(config-if)# ip access-group Internet_filter out
Device(config-if)# ip access-group marketing_group in

Deleting individual ACEs from named ACLs

This example shows how you can delete individual ACEs from the named access list border-list:

Device(config)# ip access-list extended border-list
Device(config-ext-nacl)# no permit ip host 10.1.1.3 any

Examples: Time Range Applied to an IP ACL

This example denies HTTP traffic on IP on Monday through Friday between the hours of 8:00 a.m. and 6:00 p.m (18:00). The example allows UDP traffic only on Saturday and Sunday from noon to 8:00 p.m. (20:00).

Device(config)# time-range no-http
Device(config)# periodic weekdays 8:00 to 18:00
!
Device(config)# time-range udp-yes
Device(config)# periodic weekend 12:00 to 20:00
!
Device(config)# ip access-list extended strict
Device(config-ext-nacl)# deny tcp any any eq www time-range no-http
Device(config-ext-nacl)# permit udp any any time-range udp-yes
!
Device(config-ext-nacl)# exit
Device(config)# interface gigabitethernet2/0/1
Device(config-if)# ip access-group strict in

Examples: Configuring Commented IP ACL Entries

In this example of a numbered ACL, the workstation that belongs to Jones is allowed access, and the workstation that belongs to Smith is not allowed access:

Device(config)# access-list 1 remark Permit only Jones workstation through
Device(config)# access-list 1 permit 171.69.2.88
Device(config)# access-list 1 remark Do not allow Smith workstation through
Device(config)# access-list 1 deny 171.69.3.13

In this example of a numbered ACL, the Winter and Smith workstations are not allowed to browse the web:

Device(config)# access-list 100 remark Do not allow Winter to browse the web
Device(config)# access-list 100 deny host 171.69.3.85 any eq www
Device(config)# access-list 100 remark Do not allow Smith to browse the web
Device(config)# access-list 100 deny host 171.69.3.13 any eq www

In this example of a named ACL, the Jones subnet is not allowed access:

Device(config)# ip access-list standard prevention
Device(config-std-nacl)# remark Do not allow Jones subnet through
Device(config-std-nacl)# deny 171.69.0.0 0.0.255.255

In this example of a named ACL, the Jones subnet is not allowed to use outbound Telnet:

Device(config)# ip access-list extended telnetting
Device(config-ext-nacl)# remark Do not allow Jones subnet to telnet out
Device(config-ext-nacl)# deny tcp 171.69.0.0 0.0.255.255 any eq telnet

Examples: ACL Logging

Two variations of logging are supported on ACLs. The log keyword sends an informational logging message to the console about the packet that matches the entry; the log-input keyword includes the input interface in the log entry.

In this example, standard named access list stan1 denies traffic from 10.1.1.0 0.0.0.255, allows traffic from all other sources, and includes the log keyword.

Device(config)# ip access-list standard stan1
Device(config-std-nacl)# deny 10.1.1.0 0.0.0.255 log
Device(config-std-nacl)# permit any log
Device(config-std-nacl)# exit
Device(config)# interface gigabitethernet1/0/1
Device(config-if)# ip access-group stan1 in
Device(config-if)# end
Device# show logging
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
Console logging: level debugging, 37 messages logged
Monitor logging: level debugging, 0 messages logged
Buffer logging: level debugging, 37 messages logged
File logging: disabled
Trap logging: level debugging, 39 message lines logged

Log Buffer (4096 bytes):

00:00:48: NTP: authentication delay calculation problems

<output truncated>

00:09:34:%SEC-6-IPACCESSLOGS:list stan1 permitted 0.0.0.0 1 packet
00:09:59:%SEC-6-IPACCESSLOGS:list stan1 denied 10.1.1.15 1 packet
00:10:11:%SEC-6-IPACCESSLOGS:list stan1 permitted 0.0.0.0 1 packet

This example is a named extended access list ext1 that permits ICMP packets from any source to 10.1.1.0 0.0.0.255 and denies all UDP packets.

Device(config)# ip access-list extended ext1
Device(config-ext-nacl)# permit icmp any 10.1.1.0 0.0.0.255 log
Device(config-ext-nacl)# deny udp any any log
Device(config-std-nacl)# exit
Device(config)# interface gigabitethernet1/0/2
Device(config-if)# ip access-group ext1 in

This is a an example of a log for an extended ACL:

01:24:23:%SEC-6-IPACCESSLOGDP:list ext1 permitted icmp 10.1.1.15 -> 10.1.1.61 (0/0), 1 packet
01:25:14:%SEC-6-IPACCESSLOGDP:list ext1 permitted icmp 10.1.1.15 -> 10.1.1.61 (0/0), 7 packets
01:26:12:%SEC-6-IPACCESSLOGP:list ext1 denied udp 0.0.0.0(0) -> 255.255.255.255(0), 1 packet
01:31:33:%SEC-6-IPACCESSLOGP:list ext1 denied udp 0.0.0.0(0) -> 255.255.255.255(0), 8 packets

Note that all logging entries for IP ACLs start with %SEC-6-IPACCESSLOG with minor variations in format depending on the kind of ACL and the access entry that has been matched.

This is an example of an output message when the log-input keyword is entered:

00:04:21:%SEC-6-IPACCESSLOGDP:list inputlog permitted icmp 10.1.1.10 (Vlan1 0001.42ef.a400) ->
10.1.1.61 (0/0), 1 packet

A log message for the same sort of packet using the log keyword does not include the input interface information:

00:05:47:%SEC-6-IPACCESSLOGDP:list inputlog permitted icmp 10.1.1.10 -> 10.1.1.61 (0/0), 1 packet

Configuration Examples for ACLs and VLAN Maps

- Example: Creating an ACL and a VLAN Map to Deny a Packet

- Example: Creating an ACL and a VLAN Map to Permit a Packet

- Example: Default Action of Dropping IP Packets and Forwarding MAC Packets

- Example: Default Action of Dropping MAC Packets and Forwarding IP Packets

- Example: Default Action of Dropping All Packets

Example: Creating an ACL and a VLAN Map to Deny a Packet

This example shows how to create an ACL and a VLAN map to deny a packet. In the first map, any packets that match the ip1 ACL (TCP packets) would be dropped. You first create the ip1 ACL to permit any TCP packet and no other packets. Because there is a match clause for IP packets in the VLAN map, the default action is to drop any IP packet that does not match any of the match clauses.

Device(config)# ip access-list extended ip1
Device(config-ext-nacl)# permit tcp any any
Device(config-ext-nacl)# exit
Device(config)# vlan access-map map_1 10
Device(config-access-map)# match ip address ip1
Device(config-access-map)# action drop

Example: Creating an ACL and a VLAN Map to Permit a Packet

This example shows how to create a VLAN map to permit a packet. ACL ip2 permits UDP packets and any packets that match the ip2 ACL are forwarded. In this map, any IP packets that did not match any of the previous ACLs (that is, packets that are not TCP packets or UDP packets) would get dropped.

Device(config)# ip access-list extended ip2
Device(config-ext-nacl)# permit udp any any
Device(config-ext-nacl)# exit
Device(config)# vlan access-map map_1 20
Device(config-access-map)# match ip address ip2
Device(config-access-map)# action forward

Example: Default Action of Dropping IP Packets and Forwarding MAC Packets

In this example, the VLAN map has a default action of drop for IP packets and a default action of forward for MAC packets. Used with standard ACL 101 and extended named access lists igmp-match and tcp-match , the map will have the following results:

- Forward all UDP packets

- Drop all IGMP packets

- Forward all TCP packets

- Drop all other IP packets

- Forward all non-IP packets

Device(config)# access-list 101 permit udp any any
Device(config)# ip access-list extended igmp-match
Device(config-ext-nacl)# permit igmp any any

Device(config-ext-nacl)# permit tcp any any
Device(config-ext-nacl)# exit
Device(config)# vlan access-map drop-ip-default 10
Device(config-access-map)# match ip address 101
Device(config-access-map)# action forward
Device(config-access-map)# exit
Device(config)# vlan access-map drop-ip-default 20
Device(config-access-map)# match ip address igmp-match
Device(config-access-map)# action drop
Device(config-access-map)# exit
Device(config)# vlan access-map drop-ip-default 30
Device(config-access-map)# match ip address tcp-match
Device(config-access-map)# action forward

Example: Default Action of Dropping MAC Packets and Forwarding IP Packets

In this example, the VLAN map has a default action of drop for MAC packets and a default action of forward for IP packets. Used with MAC extended access lists good-hosts and good-protocols , the map will have the following results:

- Forward MAC packets from hosts 0000.0c00.0111 and 0000.0c00.0211

- Forward MAC packets with decnet-iv or vines-ip protocols

- Drop all other non-IP packets

- Forward all IP packets

Example: Default Action of Dropping All Packets

In this example, the VLAN map has a default action of drop for all packets (IP and non-IP). Used with access lists tcp-match and good-hosts from Examples 2 and 3, the map will have the following results:

- Forward all TCP packets

- Forward MAC packets from hosts 0000.0c00.0111 and 0000.0c00.0211

- Drop all other IP packets

- Drop all other MAC packets

Device(config)# vlan access-map drop-all-default 10
Device(config-access-map)# match ip address tcp-match
Device(config-access-map)# action forward
Device(config-access-map)# exit
Device(config)# vlan access-map drop-all-default 20
Device(config-access-map)# match mac address good-hosts
Device(config-access-map)# action forward

Configuration Examples for Using VLAN Maps in Your Network

- Example: Wiring Closet Configuration

- Example: Restricting Access to a Server on Another VLAN

- Example: Denying Access to a Server on Another VLAN

Example: Wiring Closet Configuration

Wiring Closet Configuration

If you do not want HTTP traffic switched from Host X to Host Y, you can configure a VLAN map on Switch A to drop all HTTP traffic from Host X (IP address 10.1.1.32) to Host Y (IP address 10.1.1.34) at Switch A and not bridge it to Switch B.

First, define the IP access list http that permits (matches) any TCP traffic on the HTTP port.

Device(config)# ip access-list extended http
Device(config-ext-nacl)# permit tcp host 10.1.1.32 host 10.1.1.34 eq www
Device(config-ext-nacl)# exit

Next, create VLAN access map map2 so that traffic that matches the http access list is dropped and all other IP traffic is forwarded.

Device(config)# vlan access-map map2 10
Device(config-access-map)# match ip address http
Device(config-access-map)# action drop
Device(config-access-map)# exit
Device(config)# ip access-list extended match_all
Device(config-ext-nacl)# permit ip any any
Device(config-ext-nacl)# exit
Device(config)# vlan access-map map2 20
Device(config-access-map)# match ip address match_all
Device(config-access-map)# action forward

Then, apply VLAN access map map2 to VLAN 1.

Device(config)# vlan filter map2 vlan 1

Example: Restricting Access to a Server on Another VLAN

Restricting Access to a Server on Another VLAN

Example: Denying Access to a Server on Another VLAN

This example shows how to deny access to a server on another VLAN by creating the VLAN map SERVER 1 that denies access to hosts in subnet 10.1.2.0.8, host 10.1.1.4, and host 10.1.1.8 and permits other IP traffic. The final step is to apply the map SERVER1 to VLAN 10.

Define the IP ACL that will match the correct packets.

Device(config)# ip access-list extended SERVER1_ACL
Device(config-ext-nacl))# permit ip 10.1.2.0 0.0.0.255 host 10.1.1.100
Device(config-ext-nacl))# permit ip host 10.1.1.4 host 10.1.1.100
Device(config-ext-nacl))# permit ip host 10.1.1.8 host 10.1.1.100
Device(config-ext-nacl))# exit

Define a VLAN map using this ACL that will drop IP packets that match SERVER1_ACL and forward IP packets that do not match the ACL.

Device(config)# vlan access-map SERVER1_MAP
Device(config-access-map)# match ip address SERVER1_ACL
Device(config-access-map)# action drop
Device(config)# vlan access-map SERVER1_MAP 20
Device(config-access-map)# action forward
Device(config-access-map)# exit

Apply the VLAN map to VLAN 10.

Device(config)# vlan filter SERVER1_MAP vlan-list 10

Configuration Examples of Router ACLs and VLAN Maps Applied to VLANs

This section gives examples of applying router ACLs and VLAN maps to a VLAN for switched, bridged, routed, and multicast packets. Although the following illustrations show packets being forwarded to their destination, each time the packet’s path crosses a line indicating a VLAN map or an ACL, it is also possible that the packet might be dropped, rather than forwarded.

- Example: ACLs and Switched Packets

- Example: ACLs and Bridged Packets

- Example: ACLs and Routed Packets

- Example: ACLs and Multicast Packets

Example: ACLs and Switched Packets

Applying ACLs on Switched Packets

Example: ACLs and Bridged Packets

Applying ACLs on Bridged Packets

Example: ACLs and Routed Packets

Applying ACLs on Routed Packets

Example: ACLs and Multicast Packets

Applying ACLs on Multicast Packets

Chapter 13. IPv6 ACLs

- Restrictions for IPv6 ACLs

- IPv6 ACLs Overview

- Default Configuration for IPv6 ACLs

- Configuring IPv6 ACLs

- Attaching an IPv6 ACL to an Interface

- Configuring a VLAN Map

- Applying a VLAN Map to a VLAN

- Monitoring IPv6 ACLs

- Additional References

- Feature Information for IPv6 ACLs

Restrictions for IPv6 ACLs

With IPv4, you can configure standard and extended numbered IP ACLs, named IP ACLs, and MAC ACLs. IPv6 supports only named ACLs.

The switch supports most Cisco IOS-supported IPv6 ACLs with some exceptions:

- The switch does not support matching on these keywords: routing header, and undetermined-transport.

- The switch does not support reflexive ACLs (the reflect keyword).

- This release supports port ACLs, router ACLs and VLAN ACLs (VLAN maps) for IPv6.

- The switch does not apply MAC-based ACLs on IPv6 frames.

- When configuring an ACL, there is no restriction on keywords entered in the ACL, regardless of whether or not they are supported on the platform. When you apply the ACL to an interface that requires hardware forwarding (physical ports or SVIs), the switch checks to determine whether or not the ACL can be supported on the interface. If not, attaching the ACL is rejected.

- If an ACL is applied to an interface and you attempt to add an access control entry (ACE) with an unsupported keyword, the switch does not allow the ACE to be added to the ACL that is currently attached to the interface.

IPv6 ACLs on the switch have these characteristics:

- Fragmented frames (the fragments keyword as in IPv4) are supported

- The same statistics supported in IPv4 are supported for IPv6 ACLs.

- If the switch runs out of hardware space, the packets associated with the ACL are dropped on the interface.

- Logging is supported for router ACLs, but not for port ACLs.

- The switch supports IPv6 address-matching for a full range of prefix-lengths.

IPv6 ACLs Overview

You can filter IP Version 6 (IPv6) traffic by creating IPv6 access control lists (ACLs) and applying them to interfaces similar to how you create and apply IP Version 4 (IPv4) named ACLs. You can also create and apply input router ACLs to filter Layer 3 management traffic when the switch is running IP base and LAN base feature sets.

A switch supports three types of IPv6 ACLs:

- IPv6 router ACLs are supported on outbound or inbound traffic on Layer 3 interfaces, which can be routed ports, switch virtual interfaces (SVIs), or Layer 3 EtherChannels. IPv6 router ACLs apply only to IPv6 packets that are routed.

- IPv6 port ACLs are supported on outbound and inbound Layer 2 interfaces. IPv6 port ACLs are applied to all IPv6 packets entering the interface.

- VLAN ACLs or VLAN maps access-control all packets in a VLAN. You can use VLAN maps to filter traffic between devices in the same VLAN. ACL VLAN maps are applied on L2 VLANs. VLAN maps are configured to provide access control based on Layer 3 addresses for IPv6. Unsupported protocols are access-controlled through MAC addresses using Ethernet ACEs. After a VLAN map is applied to a VLAN, all packets entering the VLAN are checked against the VLAN map.

The switch supports VLAN ACLs (VLAN maps) for IPv6 traffic.

You can apply both IPv4 and IPv6 ACLs to an interface. As with IPv4 ACLs, IPv6 port ACLs take precedence over router ACLs.

- Understanding IPv6 ACLs

- Switch Stacks and IPv6 ACLs

- ACL Precedence

- VLAN Maps

- Hitless TCAM Update

- Interactions with Other Features and Switches

Understanding IPv6 ACLs

A switch supports two types of IPv6 ACLs:

- IPv6 router ACLs are supported on outbound or inbound traffic on Layer 3 interfaces, which can be routed ports, switch virtual interfaces (SVIs), or Layer 3 EtherChannels. IPv6 router ACLs apply only to IPv6 packets that are routed.

- IPv6 port ACLs are supported on inbound traffic on Layer 2 interfaces only. IPv6 port ACLs are applied to all IPv6 packets entering the interface.

A switch running the IP base feature set supports only input router IPv6 ACLs. It does not support port ACLs or output IPv6 router ACLs.

Note

If you configure unsupported IPv6 ACLs, an error message appears and the configuration does not take affect.

The switch does not support VLAN ACLs (VLAN maps) for IPv6 traffic.

You can apply both IPv4 and IPv6 ACLs to an interface. As with IPv4 ACLs, IPv6 port ACLs take precedence over router ACLs:

- When an input router ACL and input port ACL exist in an SVI, packets received on ports to which a port ACL is applied are filtered by the port ACL. Routed IP packets received on other ports are filtered by the router ACL. Other packets are not filtered.

- When an output router ACL and input port ACL exist in an SVI, packets received on the ports to

which a port ACL is applied are filtered by the port ACL. Outgoing routed IPv6 packets are filtered by the router ACL. Other packets are not filtered.

Note

If any port ACL (IPv4, IPv6, or MAC) is applied to an interface, that port ACL is used to filter packets, and any router ACLs attached to the SVI of the port VLAN are ignored.

Per User IPv6 ACL

For the per-user ACL, the full access control entries (ACE) as the text strings are configured on the Cisco Secure Access Control Server (Cisco Secure ACS).

Filter ID IPv6 ACL

For the filter-Id ACL, the full ACEs and the acl name(filter-id) is configured on the device and only the filter-id is configured on the Cisco Secure ACS.

Downloadable IPv6 ACL

For the downloadable ACL (dACL), all the full ACEs and the dacl name are configured only on the Cisco Secure ACS.

The Cisco Secure ACS sends the dacl name to the device in its ACCESS-Accept attribute, which takes the dacl name and sends the dACL name back to the Cisco Secure ACS for the ACEs, using the ACCESS-request attribute.

Switch Stacks and IPv6 ACLs

The active switch supports IPv6 ACLs in hardware and distributes the IPv6 ACLs to the stack members.

If a standby switch takes over as the active switch, it distributes the ACL configuration to all stack members. The member switches sync up the configuration distributed by the new active switch and flush out entries that are not required.

When an ACL is modified, attached to, or detached from an interface, the active switch distributes the change to all stack members.

ACL Precedence

When VLAN maps, Port ACLs, and router ACLs are configured on the same switch, the filtering precedence, from greatest to least for ingress traffic is port ACL, VLAN map, and then router ACL. For egress traffic, the filtering precedence is router ACL, VLAN map, and then port ACL.

The following examples describe simple use cases:

- When both an input port ACL and a VLAN map are applied, incoming packets received on ports with a port ACL applied are filtered by the port ACL. Other packets are filtered by the VLAN map

- When an input router ACL and input port ACL exist in a switch virtual interface (SVI), incoming packets received on ports to which a port ACL is applied are filtered by the port ACL. Incoming routed IP packets received on other ports are filtered by the router ACL. Other packets are not filtered.

- When an output router ACL and input port ACL exist in an SVI, incoming packets received on the ports to which a port ACL is applied are filtered by the port ACL. Outgoing routed IP packets are filtered by the router ACL. Other packets are not filtered.

- When a VLAN map, input router ACL, and input port ACL exist in an SVI, incoming packets received on the ports to which a port ACL is applied are only filtered by the port ACL. Incoming routed IP packets received on other ports are filtered by both the VLAN map and the router ACL. Other packets are filtered only by the VLAN map.

- When a VLAN map, output router ACL, and input port ACL exist in an SVI, incoming packets received on the ports to which a port ACL is applied are only filtered by the port ACL. Outgoing routed IP packets are filtered by both the VLAN map and the router ACL. Other packets are filtered only by the VLAN map.

VLAN Maps

VLAN ACLs or VLAN maps are used to control network traffic within a VLAN. You can apply VLAN maps to all packets that are bridged within a VLAN in the switch or switch stack. VACLs are strictly for security packet filtering and for redirecting traffic to specific physical interfaces. VACLs are not defined by direction (ingress or egress).

All non-IP protocols are access-controlled through MAC addresses and Ethertype using MAC VLAN maps. (IP traffic is not access controlled by MAC VLAN maps.) You can enforce VLAN maps only on packets going through the switch; you cannot enforce VLAN maps on traffic between hosts on a hub or on another switch connected to this switch.

With VLAN maps, forwarding of packets is permitted or denied, based on the action specified in the map.

Using VLAN Maps to Control Traffic

Hitless TCAM Update

The Hitless TCAM update for IPv4 and IPv6 provides the capability to apply existing features to the incoming traffic while updating new features in the TCAM. Any change in IPv4 and IPv6 ACL on a given interface would trigger a reprogramming of TCAM.

Starting with Cisco IOS XE Fuji 16.8.1a, Hitless TCAM update is enabled.

This feature is always enabled. You cannot disable this feature.

The Hitless TCAM update follows the below ACL change rules:

- If there are value compare unit (VCU) registers in use from ACEs with layer 4 operators, there could be a few packet drops during the change.

- If there are not enough VCU bits remaining to add a second set of access control entries and if there is not enough space in TCAM to expand these entries, the old ACL change method will apply; which will drop all packets, delete the old ACL, add the new ACL entries into TCAM, and then remove the entry that is causing the packets to drop.

- If there is not enough space in TCAM to add the modified entries, the old ACL change method will automatically be applied.

Note

- To perform Hitless ACL update for an IPv4 ACL which has X number of ACEs, TCAM should have a free space for accommodating X+1 entries.

- To perform Hitless ACL update for an IPv6 ACL which has X number of ACEs, TCAM should have a free space for accommodating 2X+2 entries.

Interactions with Other Features and Switches

- If an IPv6 router ACL is configured to deny a packet, the packet is not routed. A copy of the packet is sent to the Internet Control Message Protocol (ICMP) queue to generate an ICMP unreachable message for the frame.

- If a bridged frame is to be dropped due to a port ACL, the frame is not bridged.

- You can create both IPv4 and IPv6 ACLs on a switch or switch stack, and you can apply both IPv4 and IPv6 ACLs to the same interface. Each ACL must have a unique name; an error message appears if you try to use a name that is already configured.

You use different commands to create IPv4 and IPv6 ACLs and to attach IPv4 or IPv6 ACLs to the same Layer 2 or Layer 3 interface. If you use the wrong command to attach an ACL (for example, an IPv4 command to attach an IPv6 ACL), you receive an error message.

- You cannot use MAC ACLs to filter IPv6 frames. MAC ACLs can only filter non-IP frames.

- If the hardware memory is full, packets are dropped on the interface and an unload error message is logged.

Default Configuration for IPv6 ACLs

The default IPv6 ACL configuration is as follows:

Switch# show access-lists preauth_ipv6_acl
IPv6 access list preauth_ipv6_acl (per-user)
permit udp any any eq domain sequence 10
permit tcp any any eq domain sequence 20
permit icmp any any nd-ns sequence 30
permit icmp any any nd-na sequence 40
permit icmp any any router-solicitation sequence 50
permit icmp any any router-advertisement sequence 60
permit icmp any any redirect sequence 70
permit udp any eq 547 any eq 546 sequence 80
permit udp any eq 546 any eq 547 sequence 90
deny ipv6 any any sequence 100

Configuring IPv6 ACLs

To filter IPv6 traffic, perform this procedure:

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

[no]{ipv6 access-list list-name| client permit-control-packets| log-update threshold| role-based list-name}

Example:

Device(config)# ipv6 access-list example_acl_list

Defines an IPv6 ACL name, and enters IPv6 access list configuration mode.

Step 4

[no]{deny | permit} protocol {source-ipv6-prefix/ |prefix-length |any threshold| host source-ipv6-address} [ operator [ port-number ]] { destination-ipv6-prefix/ prefix-length | any | host destination-ipv6-address} [operator [port-number]][dscp value] [fragments] [log] [log-input] [routing] [sequence value] [time-range name]

Enter deny or permit to specify whether to deny or permit the packet if conditions are matched. These are the conditions:

- For protocol, enter the name or number of an IP: ahp , esp , icmp , ipv6 , pcp , stcp , tcp , or udp , or an integer in the range 0 to 255 representing an IPv6 protocol number.

- The source-ipv6-prefix/prefix-length or destination-ipv6-prefix/ prefix-length is the source or destination IPv6 network or class of networks for which to set deny or permit conditions, specified in hexadecimal and using 16-bit values between colons (see RFC 2373).

- Enter any as an abbreviation for the IPv6 prefix ::/0.

- For host source-ipv6-address or destination-ipv6-address , enter the source or destination IPv6 host address for which to set deny or permit conditions, specified in hexadecimal using 16-bit values between colons.

- (Optional) For operator, specify an operand that compares the source or destination ports of the specified protocol. Operands are lt (less than), gt (greater than), eq (equal), neq (not equal), and range .

If the operator follows the source-ipv6-prefix/prefix-length argument, it must match the source port. If the operator follows the destination-ipv6- prefix/prefix-length argument, it must match the destination port.

- (Optional) The port-number is a decimal number from 0 to 65535 or the name of a TCP or UDP port. You can use TCP port names only when filtering TCP. You can use UDP port names only when filtering UDP.

- (Optional) Enter dscp value to match a differentiated services code point value against the traffic class value in the Traffic Class field of each IPv6 packet header. The acceptable range is from 0 to 63.

- (Optional) Enter fragments to check noninitial fragments. This keyword is visible only if the protocol is ipv6.

- (Optional) Enter log to cause an logging message to be sent to the console about the packet that matches the entry. Enter log-input to include the input interface in the log entry. Logging is supported only for router ACLs.

- (Optional) Enter routing to specify that IPv6 packets be routed.

- (Optional) Enter sequence value to specify the sequence number for the access list statement. The acceptable range is from 1 to 4,294,967,295.

- (Optional) Enter time-range name to specify the time range that applies to the deny or permit statement.

Step 5

{deny | permit} tcp {source-ipv6-prefix/prefix-length | any | host source-ipv6-address} [operator [port-number]] {destination-ipv6- prefix/prefix-length | any | host destination-ipv6-address} [operator [port-number]] [ack] [dscp value] [established] [fin] [log] [log-input] [neq {port | protocol}] [psh] [range {port | protocol}] [rst] [routing] [sequence value] [syn] [time-range name] [urg]

(Optional) Define a TCP access list and the access conditions.

Enter tcp for Transmission Control Protocol. The parameters are the same as those described in Step 3a, with these additional optional parameters:

- ack : Acknowledgment bit set.

- established : An established connection. A match occurs if the TCP datagram has the ACK or RST bits set.

- fin : Finished bit set; no more data from sender.

- neq { port |protocol} : Matches only packets that are not on a given port number.

- psh —Push function bit set.

- range { port |protocol} : Matches only packets in the port number range.

- rst : Reset bit set.

- syn : Synchronize bit set.

- urg : Urgent pointer bit set.

Step 6

{deny | permit} udp {source-ipv6-prefix/prefix-length | any | host source-ipv6-address} [operator [port-number]] {destination-ipv6-prefix/prefix-length | any | host destination-ipv6-address} [operator [port-number]] [dscp value] [log] [log-input] [neq {port | protocol}] [range {port | protocol}] [routing] [sequence value] [time-range name]]

(Optional) Define a UDP access list and the access conditions.

Enter udp for the User Datagram Protocol. The UDP parameters are the same as those described for TCP, except that the [operator [port]] port number or name must be a UDP port number or name, and the established parameter is not valid for UDP.

Step 7

{deny | permit} icmp {source-ipv6-prefix/prefix-length | any | host source-ipv6-address} [operator [port-number]] {destination-ipv6-prefix/prefix-length | any | host destination-ipv6-address} [operator [port-number]] [icmp-type [icmp-code] | icmp-message] [dscp value] [log] [log-input] [routing] [sequence value] [time-range name]

(Optional) Define an ICMP access list and the access conditions.

Enter icmp for Internet Control Message Protocol. The ICMP parameters are the same as those described for most IP protocols in Step 1, with the addition of the ICMP message type and code parameters. These optional keywords have these meanings:

- icmp-type : Enter to filter by ICMP message type, a number from 0 to 255.

- icmp-code : Enter to filter ICMP packets that are filtered by the ICMP message code type, a number from 0 to 255.

- icmp-message : Enter to filter ICMP packets by the ICMP message type name or the ICMP message type and code name. To see a list of ICMP message type names and code names, use the ? key or see command reference for this release.

Step 8

end

Return to privileged EXEC mode.

Step 9

show ipv6 access-list

Verify the access list configuration.

Step 10

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 11

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Attaching an IPv6 ACL to an Interface

You can apply an ACL to outbound or inbound traffic on Layer 3 interfaces, or to inbound traffic on Layer 2 interfaces. You can also apply ACLs only to inbound management traffic on Layer 3 interfaces.

Follow these steps to control access to an interface.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface interface-id

Identify a Layer 2 interface (for port ACLs) or Layer 3 interface (for router ACLs) on which to apply an access list, and enter interface configuration mode.

Step 4

no switchport

If applying a router ACL, this changes the interface from Layer 2 mode (the default) to Layer 3 mode.

Step 5

ipv6 address ipv6-address

Configure an IPv6 address on a Layer 3 interface (for router ACLs).

Step 6

ipv6 traffic-filter access-list-name {in | out}

Apply the access list to incoming or outgoing traffic on the interface.

Step 7

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 8

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 9

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Configuring a VLAN Map

To create a VLAN map and apply it to one or more VLANs, perform these steps:

Before you begin

Create the IPv6 ACL that you want to apply to the VLAN.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

vlan access-map name [number]

Example:

Device(config)# vlan access-map map_1 20

Creates a VLAN map, and give it a name and (optionally) a number. The number is the sequence number of the entry within the map.

When you create VLAN maps with the same name, numbers are assigned sequentially in increments of 10. When modifying or deleting maps, you can enter the number of the map entry that you want to modify or delete.

VLAN maps do not use the specific permit or deny keywords. To deny a packet by using VLAN maps, create an ACL that would match the packet, and set the action to drop. A permit in the ACL counts as a match. A deny in the ACL means no match.

Entering this command changes to access-map configuration mode.

Step 4

match {ip | ipv6 | mac} address {name | number} [name | number]

Example:

Device(config-access-map)# match ipv6 address ip_net

Match the packet against one or more access lists. Note that packets are only matched against access lists of the correct protocol type. IP packets are matched against IP access lists. Non-IP packets are only matched against named MAC access lists.

Note

If the VLAN map is configured with a match clause for a type of packet (IP or MAC) and the map action is drop, all packets that match the type are dropped. If the VLAN map has no match clause, and the configured action is drop, all IP and Layer 2 packets are dropped.

Step 5

Enter one of the following commands to specify an IP packet or a non-IP packet (with only a known MAC address) and to match the packet against one or more ACLs:

- action { forward}

Device(config-access-map)# action forward

- action { drop}

Device(config-access-map)# action drop

Sets the action for the map entry.

Step 6

vlan filter mapname vlan-list list

Example:

Device(config)# vlan filter map 1 vlan-list 20-22

Applies the VLAN map to one or more VLAN IDs.

The list can be a single VLAN ID (22), a consecutive list (10-22), or a string of VLAN IDs (12, 22, 30). Spaces around the comma and hyphen are optional.

Applying a VLAN Map to a VLAN

To apply a VLAN map to one or more VLANs, perform these steps.

Procedure

Step 1

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

vlan filter mapname vlan-list list

Example:

Device(config)# vlan filter map 1 vlan-list 20-22

Applies the VLAN map to one or more VLAN IDs.

The list can be a single VLAN ID (22), a consecutive list (10-22), or a string of VLAN IDs (12, 22, 30). Spaces around the comma and hyphen are optional.

Step 4

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 5

show running-config

Example:

Device# show running-config

Displays the access list configuration.

Step 6

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Monitoring IPv6 ACLs

You can display information about all configured access lists, all IPv6 access lists, or a specific access list by using one or more of the privileged EXEC commands shown in the table below:

show ACL commands

Command

Purpose

show access-lists

Displays all access lists configured on the switch.

show ipv6 access-list [access-list-name]

Displays all configured IPv6 access lists or the access list specified by name.

show vlan access-map [map-name]

Displays VLAN access map configuration.

show vlan filter [access-map access-map | vlan vlan-id]

Displays the mapping between VACLs and VLANs.

This is an example of the output from the show access-lists privileged EXEC command. The output shows all access lists that are configured on the switch or switch stack.

Switch # show access-lists
Extended IP access list hello
10 permit ip any any
IPv6 access list ipv6
permit ipv6 any any sequence 10

This is an example of the output from the show ipv6 access-list privileged EXEC command. The output shows only IPv6 access lists configured on the switch or switch stack

Switch# show ipv6 access-list
IPv6 access list inbound
permit tcp any any eq bgp (8 matches) sequence 10
permit tcp any any eq telnet (15 matches) sequence 20
permit udp any any sequence 30
IPv6 access list outbound
deny udp any any sequence 10
deny tcp any any eq telnet sequence 20

This is an example of the output from the show vlan access-map privileged EXEC command. The output shows VLAN access map information.

Switch# show vlan access-map
Vlan access-map "m1"  10
Match clauses:
ipv6 address: ip2
Action: drop

Example: Creating an IPv6 ACL

This example configures the IPv6 access list named CISCO. The first deny entry in the list denies all packets that have a destination TCP port number greater than 5000. The second deny entry denies packets that have a source UDP port number less than 5000. The second deny also logs all matches to the console. The first permit entry in the list permits all ICMP packets. The second permit entry in the list permits all other traffic. The second permit entry is necessary because an implicit deny -all condition is at the end of each IPv6 access list.

Note

Logging is supported only on Layer 3 interfaces.

Device(config)# ipv6 access-list CISCO
Device(config-ipv6-acl)# deny tcp any any gt 5000
Device (config-ipv6-acl)# deny ::/0 lt 5000 ::/0 log
Device(config-ipv6-acl)# permit icmp any any
Device(config-ipv6-acl)# permit any any

Example: Applying IPv6 ACLs

This example shows how to apply the access list Cisco to outbound traffic on a Layer 3 interface.

Device(config-if)# no switchport
Device(config-if)# ipv6 address 2001::/64 eui-64
Device(config-if)# ipv6 traffic-filter CISCO out

Example: Displaying IPv6 ACLs

This is an example of the output from the show access-lists privileged EXEC command. The output shows all access lists that are configured on the switch or switch stack.

Device #show access-lists
Extended IP access list hello
10 permit ip any any
IPv6 access list ipv6
permit ipv6 any any sequence 10

This is an example of the output from the show ipv6 access-lists privileged EXEC command. The output shows only IPv6 access lists configured on the switch or switch stack.

Device# show ipv6 access-list
IPv6 access list inbound
permit tcp any any eq bgp (8 matches) sequence 10
permit tcp any any eq telnet (15 matches) sequence 20
permit udp any any sequence 30

IPv6 access list outbound
deny udp any any sequence 10
deny tcp any any eq telnet sequence 20

Configuring RA Guard Policy

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ipv6 nd raguard policy policy name

Example:

Device(config)# ipv6 nd raguard policy MyPolicy

Step 4

trusted-port

Example:

Device(config-nd-raguard)# trusted-port

Configures the trusted port for the policy created above.

Step 5

device-role router

Example:

Device(config-nd-raguard)# device-role [host|monitor|router|switch]
Device(config-nd-raguard)# device-role router
d

Defines the trusted device that can send RAs to the trusted port created above.

Step 6

interface interface-id

Example:

Device(config)# interface tenGigabitEthernet 1/0/1

Configures the interface to the trusted device.

Step 7

ipv6 nd raguard attach-policy policy name

Example:

Device(config-if)# ipv6 nd raguard attach-policy Mypolicy

Configures and attaches the policy to trust the RA's received from the port.

Step 8

vlan vlan-id

Example:

Device(config)# vlan configuration 19-21,23

Configures the wireless client vlans.

Step 9

ipv6 nd suppress

Example:

Device(config-vlan-config)# ipv6 nd suppress

Suppresses the ND messages over wireless.

Step 10

ipv6 snooping

Example:

Device(config-vlan-config)# ipv6 snooping

Captures IPv6 traffic.

Step 11

ipv6 nd raguard attach-policy policy name

Example:

Device(config-vlan-config)# ipv6 nd raguard attach-policy Mypolicy

Attaches the RA Guard policy to the wireless client vlans.

Step 12

ipv6 nd ra-throttler attach-policy policy name

Example:

Device(config-vlan-config)# ipv6 nd ra-throttler attach-policy Mythrottle

Attaches the RA throttling policy to the wireless client vlans.

Configuring IPv6 Neighbor Binding

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ipv6 neighbor binding [vlan] 19 2001:db8::25:4 interface tenGigabitEthernet 1/0/3 aaa.bbb.ccc

Example:

Device(config)# ipv6 neighbor binding vlan 19 2001:db8::25:4 interface tenGigabitEthernet 1/0/3 aaa.bbb.ccc

Sets and validates the neighbor 2001:db8::25: 4 only valid when transmitting on VLAN 19 through interface te1/0/3 with the source mac-address as aaa.bbb.ccc.

Additional References

Related Documents

Error Message Decoder

Description

Link

To help you research and resolve system error messages in this release, use the Error Message Decoder tool.

https://www.cisco.com/cgi-bin/Support/Errordecoder/index.cgi

MIBs

MIB

MIBs Link

All the supported MIBs for this release.

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

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

Technical Assistance

Description

Link

The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies.

To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.

Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.

http://www.cisco.com/support

Feature Information for IPv6 ACLs

This table lists the features in this module and provides links to specific configuration information:

Feature

Release

Modification

IPv6 ACL Functionality

Cisco IOS XE 3.3SECisco IOS XE 3.3SE

This feature was introduced.

Downloadable IPv6 ACL

Cisco IOS XE Gibraltar 16.11.1

This feature was introduced.

Chapter 14. Configuring DHCP

DHCP Server

The DHCP server assigns IP addresses from specified address pools on a switch or router to DHCP clients and manages them. If the DHCP server cannot give the DHCP client the requested configuration parameters from its database, it forwards the request to one or more secondary DHCP servers defined by the network administrator. The switch can act as a DHCP server.

DHCP Relay Agent

A DHCP relay agent is a Layer 3 device that forwards DHCP packets between clients and servers. Relay agents forward requests and replies between clients and servers when they are not on the same physical subnet. Relay agent forwarding is different from the normal Layer 2 forwarding, in which IP datagrams are switched transparently between networks. Relay agents receive DHCP messages and generate new DHCP messages to send on output interfaces.

DHCP Snooping

DHCP snooping is a DHCP security feature that provides network security by filtering untrusted DHCP messages and by building and maintaining a DHCP snooping binding database, also referred to as a DHCP snooping binding table.

DHCP snooping acts like a firewall between untrusted hosts and DHCP servers. You use DHCP snooping to differentiate between untrusted interfaces connected to the end user and trusted interfaces connected to the DHCP server or another switch.

Note

For DHCP snooping to function properly, all DHCP servers must be connected to the switch through trusted interfaces.

An untrusted DHCP message is a message that is received through an untrusted interface. By default, the switch considers all interfaces untrusted. So, the switch must be configured to trust some interfaces to use DHCP Snooping. When you use DHCP snooping in a service-provider environment, an untrusted message is sent from a device that is not in the service-provider network, such as a customer’s switch. Messages from unknown devices are untrusted because they can be sources of traffic attacks.

The DHCP snooping binding database has the MAC address, the IP address, the lease time, the binding type, the VLAN number, and the interface information that corresponds to the local untrusted interfaces of a switch. It does not have information regarding hosts interconnected with a trusted interface.

In a service-provider network, an example of an interface you might configure as trusted is one connected to a port on a device in the same network. An example of an untrusted interface is one that is connected to an untrusted interface in the network or to an interface on a device that is not in the network.

When a switch receives a packet on an untrusted interface and the interface belongs to a VLAN in which DHCP snooping is enabled, the switch compares the source MAC address and the DHCP client hardware address. If the addresses match (the default), the switch forwards the packet. If the addresses do not match, the switch drops the packet.

The switch drops a DHCP packet when one of these situations occurs:

- A packet from a DHCP server, such as a DHCPOFFER, DHCPACK, DHCPNAK, or DHCPLEASEQUERY packet, is received from outside the network or firewall.

- A packet is received on an untrusted interface, and the source MAC address and the DHCP client hardware address do not match.

- The switch receives a DHCPRELEASE or DHCPDECLINE broadcast message that has a MAC address in the DHCP snooping binding database, but the interface information in the binding database does not match the interface on which the message was received.

- A DHCP relay agent forwards a DHCP packet that includes a relay-agent IP address that is not 0.0.0.0, or the relay agent forwards a packet that includes option-82 information to an untrusted port.

- The maximum snooping queue size of 1000 is exceeded when DHCP snooping is enabled.

Note

This is applicable from Cisco IOS XE Denali 16.1.x release onwards.

If the switch is an aggregation switch supporting DHCP snooping and is connected to an edge switch that is inserting DHCP option-82 information, the switch drops packets with option-82 information when packets are received on an untrusted interface. If DHCP snooping is enabled and packets are received on a trusted port, the aggregation switch does not learn the DHCP snooping bindings for connected devices and cannot build a complete DHCP snooping binding database.

When an aggregation switch can be connected to an edge switch through an untrusted interface and you enter the ip dhcp snooping information option allow-untrusted global configuration command, the aggregation switch accepts packets with option-82 information from the edge switch. The aggregation switch learns the bindings for hosts connected through an untrusted switch interface. The DHCP security features, such as dynamic ARP inspection or IP source guard, can still be enabled on the aggregation switch while the switch receives packets with option-82 information on untrusted input interfaces to which hosts are connected. The port on the edge switch that connects to the aggregation switch must be configured as a trusted interface.

Option-82 Data Insertion

In residential, metropolitan Ethernet-access environments, DHCP can centrally manage the IP address assignments for a large number of subscribers. When the DHCP option-82 feature is enabled on the switch, a subscriber device is identified by the switch port through which it connects to the network (in addition to its MAC address). Multiple hosts on the subscriber LAN can be connected to the same port on the access switch and are uniquely identified.

Note

The DHCP option-82 feature is supported only when DHCP snooping is globally enabled on the VLANs to which subscriber devices using option-82 are assigned.

The following illustration shows a metropolitan Ethernet network in which a centralized DHCP server assigns IP addresses to subscribers connected to the switch at the access layer. Because the DHCP clients and their associated DHCP server do not reside on the same IP network or subnet, a DHCP relay agent (the Catalyst switch) is configured with a helper address to enable broadcast forwarding and to transfer DHCP messages between the clients and the server.

DHCP Relay Agent in a Metropolitan Ethernet Network

When you enable the DHCP snooping information option 82 on the switch, the following sequence of events occurs:

- The host (DHCP client) generates a DHCP request and broadcasts it on the network.

- When the switch receives the DHCP request, it adds the option-82 information in the packet. By default, the remote-ID suboption is the switch MAC address, and the circuit-ID suboption is the port identifier, vlan-mod-port , from which the packet is received.You can configure the remote ID and circuit ID.

- If the IP address of the relay agent is configured, the switch adds this IP address in the DHCP packet.

- The switch forwards the DHCP request that includes the option-82 field to the DHCP server.

- The DHCP server receives the packet. If the server is option-82-capable, it can use the remote ID, the circuit ID, or both to assign IP addresses and implement policies, such as restricting the number of IP addresses that can be assigned to a single remote ID or circuit ID. Then the DHCP server echoes the option-82 field in the DHCP reply.

- The DHCP server unicasts the reply to the switch if the request was relayed to the server by the switch. The switch verifies that it originally inserted the option-82 data by inspecting the remote ID and possibly the circuit ID fields. The switch removes the option-82 field and forwards the packet to the switch port that connects to the DHCP client that sent the DHCP request.

In the default suboption configuration, when the described sequence of events occurs, the values in these fields do not change (see the illustration,Suboption Packet Formats):

- 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 remote-ID type

In the port field of the circuit ID suboption, the port numbers start at 3. For example, on a switch with 24 10/100/1000 ports and four small form-factor pluggable (SFP) module slots, port 3 is the Gigabit Ethernet 1/0/1 port, port 4 is the Gigabit Ethernet 1/0/2 port, and so forth. Port 27 is the SFP module slot Gigabit Ethernet1/0/25, and so forth.

The illustration, Suboption Packet Formats. shows the packet formats for the remote-ID suboption and the circuit-ID suboption when the default suboption configuration is used. For the circuit-ID suboption, the module number corresponds to the switch number in the stack. The switch uses the packet formats when you globally enable DHCP snooping and enter the ip dhcp snooping information option global configuration command.

Suboption Packet Formats

The illustration, User-Configured Suboption Packet Formats, shows the packet formats for user-configured remote-ID and circuit-ID suboptions The switch uses these packet formats when DHCP snooping is globally enabled and when the ip dhcp snooping information option format remote-id global configuration command and theip dhcp snooping vlan information option format-type circuit-id string interface configuration command are entered.

The values for these fields in the packets change from the default values when you configure the remote-ID and circuit-ID suboptions:

- Circuit-ID suboption fields

- The circuit-ID type is 1.

- The length values are variable, depending on the length of the string that you configure.

- Remote-ID suboption fields

- The remote-ID type is 1.

- The length values are variable, depending on the length of the string that you configure.

User-Configured Suboption Packet Formats

Cisco IOS DHCP Server Database

During the DHCP-based autoconfiguration process, the designated DHCP server uses the Cisco IOS DHCP server database. It has IP addresses, address bindings, and configuration parameters, such as the boot file.

An address binding is a mapping between an IP address and a MAC address of a host in the Cisco IOS DHCP server database. You can manually assign the client IP address, or the DHCP server can allocate an IP address from a DHCP address pool. For more information about manual and automatic address bindings, see the “Configuring DHCP” chapter of the Cisco IOS IP Configuration Guide,
Release 12.4.

For procedures to enable and configure the Cisco IOS DHCP server database, see the “DHCP Configuration Task List” section in the “Configuring DHCP” chapter of the Cisco IOS IP Configuration Guide, Release 12.4.

DHCP Snooping Binding Database

When DHCP snooping is enabled, the switch uses the DHCP snooping binding database to store information about untrusted interfaces. The database can have up to 64,000 bindings.

Each database entry (binding) has an IP address, an associated MAC address, the lease time (in hexadecimal format), the interface to which the binding applies, and the VLAN to which the interface belongs. The database agent stores the bindings in a file at a configured location. At the end of each entry is a checksum that accounts for all the bytes from the start of the file through all the bytes associated with the entry. Each entry is 72 bytes, followed by a space and then the checksum value.

To keep the bindings when the switch reloads, you must use the DHCP snooping database agent. If the agent is disabled, dynamic ARP inspection or IP source guard is enabled, and the DHCP snooping binding database has dynamic bindings, the switch loses its connectivity. If the agent is disabled and only DHCP snooping is enabled, the switch does not lose its connectivity, but DHCP snooping might not prevent DHCP spoofing attacks.

When reloading, the switch reads the binding file to build the DHCP snooping binding database. The switch updates the file when the database changes.

When a switch learns of new bindings or when it loses bindings, the switch immediately updates the entries in the database. The switch also updates the entries in the binding file. The frequency at which the file is updated is based on a configurable delay, and the updates are batched. If the file is not updated in a specified time (set by the write-delay and cancel-timeout values), the update stops.

This is the format of the file with bindings:

<initial-checksum>
TYPE DHCP-SNOOPING
VERSION 1
BEGIN
<entry-1> <checksum-1>
<entry-2> <checksum-1-2>
...
...
<entry-n> <checksum-1-2-..-n>
END

Each entry in the file is tagged with a checksum value that the switch uses to verify the entries when it reads the file. The initial-checksum entry on the first line distinguishes entries associated with the latest file update from entries associated with a previous file update.

This is an example of a binding file:

2bb4c2a1
TYPE DHCP-SNOOPING
VERSION 1
BEGIN
192.1.168.1 3 0003.47d8.c91f 2BB6488E Gi1/0/4 21ae5fbb
192.1.168.3 3 0003.44d6.c52f 2BB648EB Gi1/0/4 1bdb223f
192.1.168.2 3 0003.47d9.c8f1 2BB648AB Gi1/0/4 584a38f0
END

When the switch starts and the calculated checksum value equals the stored checksum value, the switch reads entries from the binding file and adds the bindings to its DHCP snooping binding database. The switch ignores an entry when one of these situations occurs:

- The switch reads the entry and the calculated checksum value does not equal the stored checksum value. The entry and the ones following it are ignored.

- An entry has an expired lease time (the switch might not remove a binding entry when the lease time expires).

- The interface in the entry no longer exists on the system.

- The interface is a routed interface or a DHCP snooping-trusted interface.

DHCP Snooping and Switch Stacks

DHCP snooping is managed on the active switch. When a new switch joins the stack, the switch receives the DHCP snooping configuration from the active switch. When a member switch leaves the stack, all DHCP snooping address bindings associated with the switch age out.

All snooping statistics are generated on the active switch. If a new active switch is elected, the statistics counters reset.

When a stack merge occurs, all DHCP snooping bindings in the active switch are lost if it is no longer the active switch. With a stack partition, the existing active switch is unchanged, and the bindings belonging to the partitioned switches age out. The new active switch of the partitioned stack begins processing the new incoming DHCP packets.

Default DHCP Snooping Configuration

Default DHCP Configuration

Feature

Default Setting

DHCP server

Enabled in Cisco IOS software, requires configuration[1]

DHCP relay agent

Enabled[2]

DHCP packet forwarding address

None configured

Checking the relay agent information

Enabled (invalid messages are dropped)

DHCP relay agent forwarding policy

Replace the existing relay agent information

DHCP snooping enabled globally

Disabled

DHCP snooping information option

Enabled

DHCP snooping option to accept packets on untrusted input interfaces[3]

Disabled

DHCP snooping limit rate

None configured

DHCP snooping trust

Untrusted

DHCP snooping VLAN

Disabled

DHCP snooping MAC address verification

Enabled

Cisco IOS DHCP server binding database

Enabled in Cisco IOS software, requires configuration.

Note

The switch gets network addresses and configuration parameters only from a device configured as a DHCP server.

DHCP snooping binding database agent

Enabled in Cisco IOS software, requires configuration. This feature is operational only when a destination is configured.

[1] The switch responds to DHCP requests only if it is configured as a DHCP server.

[2] The switch relays DHCP packets only if the IP address of the DHCP server is configured on the SVI of the DHCP client.

[3] Use this feature when the switch is an aggregation switch that receives packets with option-82 information from an edge switch.

DHCP Snooping Configuration Guidelines

- If a switch port is connected to a DHCP server, configure a port as trusted by entering the ip dhcp snooping trust interface configuration command.

- If a switch port is connected to a DHCP client, configure a port as untrusted by entering the no ip dhcp snooping trust interface configuration command.

- You can display DHCP snooping statistics by entering the show ip dhcp snooping statistics user EXEC command, and you can clear the snooping statistics counters by entering the clear ip dhcp snooping statistics privileged EXEC command.

Configuring the DHCP Server

The switch can act as a DHCP server. If IOS based DHCP server for DHCP clients with management ports are used, both DHCP pool and the corresponding interface must be configured using the Management VRF.

For procedures to configure the switch as a DHCP server, see the “Configuring DHCP” section of the “IP addressing and Services” section of the Cisco IOS IP Configuration Guide, Release 12.4.

DHCP Server and Switch Stacks

The DHCP binding database is managed on the stack master. When a new stack master is assigned, the new master downloads the saved binding database from the TFTP server. When a switchover happens, the new active stack master will use its database file that has been synced from the old active stack master using the SSO function. The IP addresses associated with the lost bindings are released. You should configure an automatic backup by using the ip dhcp database url [timeout seconds | write-delay seconds] global configuration command.

Configuring the DHCP Relay Agent

Follow these steps to enable the DHCP relay agent on the switch:

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

service dhcp

Example:

Device(config)# service dhcp

Enables the DHCP server and relay agent on your switch. By default, this feature is enabled.

Step 4

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 5

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 6

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

What to do next

- Checking (validating) the relay agent information

- Configuring the relay agent forwarding policy

Specifying the Packet Forwarding Address

If the DHCP server and the DHCP clients are on different networks or subnets, you must configure the switch with the ip helper-address address interface configuration command. The general rule is to configure the command on the Layer 3 interface closest to the client. The address used in the ip helper-address command can be a specific DHCP server IP address, or it can be the network address if other DHCP servers are on the destination network segment. Using the network address enables any DHCP server to respond to requests.

Beginning in privileged EXEC mode, follow these steps to specify the packet forwarding address:

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface vlan vlan-id

Example:

Device(config)# interface vlan 1

Creates a switch virtual interface by entering a VLAN ID, and enter interface configuration mode.

Step 4

ip address ip-address subnet-mask

Example:

Device(config-if)# ip address 192.108.1.27 255.255.255.0

Configures the interface with an IP address and an IP subnet.

Step 5

ip helper-address address

Example:

Device(config-if)# ip helper-address 172.16.1.2

Specifies the DHCP packet forwarding address.

The helper address can be a specific DHCP server address, or it can be the network address if other DHCP servers are on the destination network segment. Using the network address enables other servers to respond to DHCP requests.

If you have multiple servers, you can configure one helper address for each server.

Step 6

end

Example:

Device(config-if)# end

Returns to global configuration mode.

Step 7

Use one of the following:

- interface range port-range

- interface interface-id

Example:

Device(config)# interface gigabitethernet1/0/2

Configures multiple physical ports that are connected to the DHCP clients, and enter interface range configuration mode.

or

Configures a single physical port that is connected to the DHCP client, and enter interface configuration mode.

Step 8

switchport mode access

Example:

Device(config-if)# switchport mode access

Defines the VLAN membership mode for the port.

Step 9

switchport access vlan vlan-id

Example:

Device(config-if)# switchport access vlan 1

Assigns the ports to the same VLAN as configured in Step 2.

Step 10

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Step 11

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 12

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Prerequisites for Configuring DHCP Snooping and Option 82

The prerequisites for DHCP Snooping and Option 82 are as follows:

- You must globally enable DHCP snooping on the switch.

- Before globally enabling DHCP snooping on the switch, make sure that the devices acting as the DHCP server and the DHCP relay agent are configured and enabled.

- If you want the switch to respond to DHCP requests, it must be configured as a DHCP server.

- Before configuring the DHCP snooping information option on your switch, be sure to configure the device that is acting as the DHCP server. You must specify the IP addresses that the DHCP server can assign or exclude, or you must configure DHCP options for these devices.

- For DHCP snooping to function properly, all DHCP servers must be connected to the switch through trusted interfaces. In a service-provider network, a trusted interface is connected to a port on a device in the same network.

- You must configure the switch to use the Cisco IOS DHCP server binding database to use it for DHCP snooping.

- To use the DHCP snooping option of accepting packets on untrusted inputs, the switch must be an aggregation switch that receives packets with option-82 information from an edge switch.

- The following prerequisites apply to DHCP snooping binding database configuration:

- You must configure a destination on the DHCP snooping binding database to use the switch for DHCP snooping.

- Because both NVRAM and the flash memory have limited storage capacity, we recommend that you store the binding file on a TFTP server.

- For network-based URLs (such as TFTP and FTP), you must create an empty file at the configured URL before the switch can write bindings to the binding file at that URL. See the documentation for your TFTP server to determine whether you must first create an empty file on the server; some TFTP servers cannot be configured this way.

- To ensure that the lease time in the database is accurate, we recommend that you enable and configure Network Time Protocol (NTP).

- If NTP is configured, the switch writes binding changes to the binding file only when the switch system clock is synchronized with NTP.

- Before configuring the DHCP relay agent on your switch, make sure to configure the device that is acting as the DHCP server. You must specify the IP addresses that the DHCP server can assign or exclude, configure DHCP options for devices, or set up the DHCP database agent.

- If you want the switch to relay DHCP packets, the IP address of the DHCP server must be configured on the switch virtual interface (SVI) of the DHCP client.

- If a switch port is connected to a DHCP server, configure a port as trusted by entering the ip dhcp snooping trust interface configuration command.

- If a switch port is connected to a DHCP client, configure a port as untrusted by entering the no ip dhcp snooping trust interface configuration command.

Enabling the Cisco IOS DHCP Server Database

For procedures to enable and configure the Cisco IOS DHCP server database, see the “DHCP Configuration Task List” section in the “Configuring DHCP” chapter of the Cisco IOS IP Configuration Guide, Release 12.4

Monitoring DHCP Snooping Information

Commands for Displaying DHCP Information

show ip dhcp snooping

Displays the DHCP snooping configuration for a switch

show ip dhcp snooping binding

Displays only the dynamically configured bindings in the DHCP snooping binding database, also referred to as a binding table.

show ip dhcp snooping database

Displays the DHCP snooping binding database status and statistics.

show ip dhcp snooping statistics

Displays the DHCP snooping statistics in summary or detail form.

show ip source binding

Display the dynamically and statically configured bindings.

Note

If DHCP snooping is enabled and an interface changes to the down state, the switch does not delete the statically configured bindings.

Information About Configuring DHCP Server Port-Based Address Allocation

DHCP server port-based address allocation is a feature that enables DHCP to maintain the same IP address on an Ethernet switch port regardless of the attached device client identifier or client hardware address.

When Ethernet switches are deployed in the network, they offer connectivity to the directly connected devices. In some environments, such as on a factory floor, if a device fails, the replacement device must be working immediately in the existing network. With the current DHCP implementation, there is no guarantee that DHCP would offer the same IP address to the replacement device. Control, monitoring, and other software expect a stable IP address associated with each device. If a device is replaced, the address assignment should remain stable even though the DHCP client has changed.

When configured, the DHCP server port-based address allocation feature ensures that the same IP address is always offered to the same connected port even as the client identifier or client hardware address changes in the DHCP messages received on that port. The DHCP protocol recognizes DHCP clients by the client identifier option in the DHCP packet. Clients that do not include the client identifier option are identified by the client hardware address. When you configure this feature, the port name of the interface overrides the client identifier or hardware address and the actual point of connection, the switch port, becomes the client identifier.

In all cases, by connecting the Ethernet cable to the same port, the same IP address is allocated through DHCP to the attached device.

The DHCP server port-based address allocation feature is only supported on a Cisco IOS DHCP server and not a third-party server.

Default Port-Based Address Allocation Configuration

By default, DHCP server port-based address allocation is disabled.

Port-Based Address Allocation Configuration Guidelines

- By default, DHCP server port-based address allocation is disabled.

- To restrict assignments from the DHCP pool to preconfigured reservations (unreserved addresses are not offered to the client and other clients are not served by the pool), you can enter the reserved-only DHCP pool configuration command.

Enabling the DHCP Snooping Binding Database Agent

Beginning in privileged EXEC mode, follow these steps to enable and configure the DHCP snooping binding database agent on the switch:

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ip dhcp snooping database {flash[number]: /filename | ftp://user:password@host/filename | http://[[username:password]@]{hostname | host-ip}[ /directory]
/image-name.tar | rcp://user@host/filename}| tftp://host/filename

Example:

Device(config)# ip dhcp snooping database tftp://10.90.90.90/snooping-rp2

Specifies the URL for the database agent or the binding file by using one of these forms:

- flash[number]:/filename

(Optional) Use the number parameter to specify the stack member number of the active switch. The range for number is 1 to 9.

- ftp://user:password@host/filename

- http://[[username:password]@]{hostname | host-ip}[ /directory]
/image-name.tar

- rcp://user@host/filename

- tftp://host/filename

Step 4

ip dhcp snooping database timeout seconds

Example:

Device(config)# ip dhcp snooping database timeout 300

Specifies (in seconds) how long to wait for the database transfer process to finish before stopping the process.

The default is 300 seconds. The range is 0 to 86400. Use 0 to define an infinite duration, which means to continue trying the transfer indefinitely.

Step 5

ip dhcp snooping database write-delay seconds

Example:

Device(config)# ip dhcp snooping database write-delay 15

Specifies the duration for which the transfer should be delayed after the binding database changes. The range is from 15 to 86400 seconds. The default is 300 seconds (5 minutes).

Step 6

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 7

ip dhcp snooping binding mac-address vlan vlan-id ip-address interface interface-id expiry seconds

Example:

Device# ip dhcp snooping binding 0001.1234.1234 vlan 1 172.20.50.5 interface gi1/1 expiry 1000

(Optional) Adds binding entries to the DHCP snooping binding database. The vlan-id range is from 1 to 4904. The seconds range is from 1 to 4294967295.

Enter this command for each entry that you add.

Use this command when you are testing or debugging the switch.

Step 8

show ip dhcp snooping database [detail]

Example:

Device# show ip dhcp snooping database detail

Displays the status and statistics of the DHCP snooping binding database agent.

Step 9

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 10

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Enabling DHCP Server Port-Based Address Allocation

Follow these steps to globally enable port-based address allocation and to automatically generate a subscriber identifier on an interface.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ip dhcp use subscriber-id client-id

Example:

Device(config)# ip dhcp use subscriber-id client-id

Configures the DHCP server to globally use the subscriber identifier as the client identifier on all incoming DHCP messages.

Step 4

ip dhcp subscriber-id interface-name

Example:

Device(config)# ip dhcp subscriber-id interface-name

Automatically generates a subscriber identifier based on the short name of the interface.

A subscriber identifier configured on a specific interface takes precedence over this command.

Step 5

interface interface-id

Example:

Device(config)# interface gigabitethernet1/0/1

Specifies the interface to be configured, and enter interface configuration mode.

Step 6

ip dhcp server use subscriber-id client-id

Example:

Device(config-if)# ip dhcp server use subscriber-id client-id

Configures the DHCP server to use the subscriber identifier as the client identifier on all incoming DHCP messages on the interface.

Step 7

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 8

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 9

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

What to do next

After enabling DHCP port-based address allocation on the switch, use the ip dhcp pool global configuration command to preassign IP addresses and to associate them to clients.

Monitoring DHCP Server Port-Based Address Allocation

Commands for Displaying DHCP Port-Based Address Allocation Information

Command

Purpose

show interface interface id

Displays the status and configuration of a specific interface.

show ip dhcp pool

Displays the DHCP address pools.

show ip dhcp binding

Displays address bindings on the Cisco IOS DHCP server.

Chapter 15. CAPWAP Access Controller DHCPv6 Option

The Control And Provisioning of Wireless Access Points (CAPWAP) protocol allows lightweight access points to use DHCPv6 to discover a wireless controller to which it can connect. CAPWAP is a standard, interoperable protocol that enables a controller to manage a collection of wireless access points.

Wireless access points use the DHCPv6 option 52 (RFC 5417) to supply the IPv6 management interface addresses of the primary, secondary, and tertiary wireless controllers.

Both stateless and stateful DHCPv6 addressing modes are supported. In stateless mode, access points obtain IPv6 address using the Stateless Address AutoConfiguration (SLAAC), while additional network information (not obtained from router advertisements) is obtained from a DHCPv6 server. In stateful mode, access points obtain both IPv6 addressing and additional network information exclusively from the DHCPv6 server. In both modes, a DHCPv6 server is required to provide option 52 if Wireless Controller discovery using DHCPv6 is required.

When the MAX_PACKET_SIZE exceeds 15, and option 52 is configured, the DHCPv6 server does not send DHCP packets.

- Verifying DHCPv6 Options Support

- Feature Information for DHCPv6 Options Support

DNS Search List Option

DNS Search List (DNSSL) is a list of Domain Name System (DNS) suffix domain names used by IPv6 hosts when they perform DNS query searches for short, unqualified domain names. The DNSSL option contains one or more domain names. All domain names share the same lifetime value, which is the maximum time in seconds over which this DNSSL may be used. If different lifetime values are required, multiple DNSSL options can be used. There can bea maximum of 5 DNSSLs.

Note

If DNS information is available from multiple Router Advertisements (RAs) and/or from DHCP, the host must maintain an ordered list of this DNS information.

RFC 6106 specifies IPv6 Router Advertisement (RA) options to allow IPv6 routers to advertise a DNS Search List (DNSSL) to IPv6 hosts for an enhanced DNS configuration.

The DNS lifetime range should be between the maximum RA interval and twice the maximum RA interval, as displayed in the following example:

(max ra interval) <= dns lifetime <= (2*(max ra interval))

The maximum RA interval can have a value between 4 and 1800 seconds (the default is 240 seconds). The following example shows an out-of-range lifetime:

Device(config-if)# ipv6 nd ra dns search list sss.com 3600
! Lifetime configured out of range for the interface that has the  default maximum RA interval.!

DHCPv6 Client Link-Layer Address Option

Cisco IOS XE Fuji 16.8.1a supports DHCPv6 Client Link-Layer Address Option (RFC 6939). It defines an optional mechanism and the related DHCPv6 option to allow first-hop DHCPv6 relay agents (relay agents that are connected to the same link as the client) to provide the client's link-layer address in DHCPv6 messages that are sent towards the server.

The Client Link-Layer Address option is only exchanged between relay agents and servers. DHCPv6 clients are not aware of the use of the Client Link-Layer Address option. The DHCPv6 client must not send the Client Link-Layer Address option, and must ignore the Client Link-Layer Address option if received.

Each DHCPv6 client and server is identified by a DHCP unique identifier (DUID). The DUID is carried in the client identifier and server identifier options. The DUID is unique across all DHCP clients and servers, and it is stable for any specific client or server. DHCPv6 uses DUIDs based on link-layer addresses for both the client and server identifier. The device uses the MAC address from the lowest-numbered interface to form the DUID. The network interface is assumed to be permanently attached to the device.

DHCPv6 Relay Agent

A DHCPv6 relay agent, which may reside on a client link, is used to relay messages between the client and the server. The DHCPv6 relay agent operation is transparent to the client. The DHCPv6 client locates a DHCPv6 server using a reserved, link-scoped multicast address. For direct communication between the DHCPv6 client and the DHCPv6 server, both of them must be attached to the same link. However, in some situations where ease of management, economy, or scalability is a concern, it is desirable to allow a DHCPv6 client to send messages to a DHCPv6 server that is not connected to the same link. IPv6 enable is required for IPv6 DHCP relay, even if the IPv6 address is configured.

Configuring CAPWAP Access Points

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ipv6 dhcp pool poolname

Example:

Device(config)# ipv6 dhcp pool pool1

Configures a DHCPv6 server configuration information pool and enters DHCPv6 pool configuration mode.

Step 4

capwap-ac address ipv6-address

Example:

Device(config-dhcpv6)# capwap-ac address 2001:DB8::1

Configures CAPWAP access controller address.

Step 5

end

Example:

Device(config-dhcpv6)# end

Exits DHCPv6 pool configuration mode and returns to privileged EXEC mode.

Configuring DNS Search List Using IPv6 Router Advertisement Options

Note

The domain name configuration should follow RFC 1035. If not, the configuration will be rejected. For example, the following domain name configuration will result in an error:

Device(config-if)# ipv6 nd ra dns search list .example.example.com infinite-lifetime

Use the no ipv6 nd ra dns search list name command to delete a single DNS search list under an interface. Use the no ipv6 nd ra dns search list command to delete all DNS search lists under an interface.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface interface-type interface-number

Example:

Device(config)# interface GigabitEthernet 0/2/0

Configures an interface and enters interface configuration mode.

Step 4

ipv6 nd prefix ipv6-prefix/prefix-length

Example:

Device(config-if)# ipv6 nd prefix 2001:DB8::1/64 1111 222

Configures IPv6 prefixes that are included in IPv6 Neighbor Discovery (ND) router advertisements,

Step 5

ipv6 nd ra lifetime seconds

Example:

Device(config-if)# ipv6 nd ra lifetime 9000

Configures the device lifetime value in IPv6 router advertisements on an interface.

Step 6

ipv6 nd ra dns search list list-name [infinite-lifetime]

Example:

Device(config-if)# ipv6 nd ra dns search list example.example.com infinite-lifetime

Configures the DNS search list. You can specify the life time of the search list.

Step 7

end

Example:

Device(config-if)# end

Exits interface configuration mode and returns to privileged EXEC mode.

What to do next

Use the show ipv6 nd idb interface command to verify the DNS search list configuration based on IPv6 RA options:

Device# show ipv6 nd idb interface gigabitEthernet 0/2/0/0 detail location 0/2/CPU0

Mon Jul 4 14:28:53.422 IST

ifname: Gi0/2/0/0, ifh: 0x01000300, iftype: 15, VI-type: 0, Pseudo IDB: FALSE
vrf-id: 0x60000000, table-id: 0xe0800000
Mac Addr: 02d1.1e2b.0baf, size: 6, VLan tag set: FALSE

Media Name: ether, Media Encap: 0x1 (ARPA)
Mac Length: 6, Media Header Len: 14, Media Proto: 0xdd86
Current Encap: 0x1 (ARPA), Mcast Encap : 0x1 (ARPA)

IPV6 Interface: Enabled, IPV6: Enabled, MPLS: Disabled
Link local address: 2001::d1:1eff:fe2b:baf, Global Addr count: 1
Global Addresses:1::1(0x2),
Default Prefix Address: ::, Prefix Addr Count: 3,
Prefix addresses: 1::(0x401), 2001:db8:e8:1011::(0x4), 2001:db8:e8:1011::(0x4)

RA Specific Route Count: 1,
RA Specific Route : Address 3:: Prefix Length 116 Lifetime 1112 Preference Low

RA DNS Search List Count: 3,
RA DNS Search List : Name example.example.com Lifetime 240
RA DNS Search List : Name example1.example1.com Lifetime 240
RA DNS Search List : Name example2.example2.com Lifetime 4294967295

Example: Configuring CAPWAP Access Points

The following example shows how to configure a CAPWAP access point:

Device> enable
Device# configure terminal
Device(config)# ipv6 dhcp pool pool1
Device(config-dhcpv6)# capwap-ac address 2001:DB8::1
Device(config-dhcpv6)# end
Device#

Verifying DHCPv6 Options Support

Verifying Option 52 Support

The following sample output from the show ipv6 dhcp pool command displays the DHCPv6 configuration pool information:

Device# show ipv6 dhcp pool

DHCPv6 pool: svr-p1
Static bindings:
Binding for client 000300010002FCA5C01C
IA PD: IA ID 00040002,
Prefix: 2001:db8::3/72
preferred lifetime 604800, valid lifetime 2592000
IA PD: IA ID not specified; being used by 00040001
Prefix: 2001:db8::1/72
preferred lifetime 240, valid lifetime 54321
Prefix: 2001:db8::2/72
preferred lifetime 300, valid lifetime 54333
Prefix: 2001:db8::3/72
preferred lifetime 280, valid lifetime 51111
Prefix from pool: local-p1, Valid lifetime 12345, Preferred lifetime 180
DNS server: 1001::1
DNS server: 1001::2
CAPWAP-AC Controller address: 2001:DB8::1
Domain name: example1.com
Domain name: example2.com
Domain name: example3.com
Active clients: 2

The following example shows how to enable debugging for DHCPv6:

Device# debug ipv6 dhcp detail

IPv6 DHCP debugging is on (detailed)

Troubleshooting DNS Search Lists

Recursive DNS servers and DNS search lists are sent as part of RA messages. Run the IPv6 ND traces to debug any particular issue related to a DNS servers and DNS search lists:

Device# show ipv6 nd trace location 0/2/CPU0

Jun 30 20:07:03.508 nd/fevent 0/2/CPU0 t26702 Sending RA to ff02::1 on GigabitEthernet0/2/0/0 (0x1000300)
Jun 30 20:07:03.508 nd/fevent 0/2/CPU0 t26702 hoplimit 64 lifetime 9000 reachable 0 retrans 0
Jun 30 20:07:03.509 nd/fevent 0/2/CPU0 t26702 1::/64 Onlink Auto
Jun 30 20:07:03.509 nd/fevent 0/2/CPU0 t26702 valid 2592000 pref 604800
Jun 30 20:07:03.509 nd/fevent 0/2/CPU0 t26702 2002:4898:e8:1011::/64 Onlink Auto
Jun 30 20:07:03.509 nd/fevent 0/2/CPU0 t26702 valid 1111 pref 222
Jun 30 20:07:03.509 nd/fevent 0/2/CPU0 t26702 2002:4899:e8:1011::/64 Onlink Auto
Jun 30 20:07:03.509 nd/fevent 0/2/CPU0 t26702 valid 1111 pref 222
Jun 30 20:07:03.509 nd/fevent 0/2/CPU0 t26702 ra specific route address 3:: lifetime 1112 preference Low
Jun 30 20:07:03.509 nd/fevent 0/2/CPU0 t26702 ra dns server address 5::6 lifetime 240 first
Jun 30 20:07:03.509 nd/fevent 0/2/CPU0 t26702 ra dns server address 5::5 lifetime 240 part of same ra dns server option
Jun 30 20:07:03.509 nd/fevent 0/2/CPU0 t26702 ra dns server address 4::4 lifetime 4294967295 first
Jun 30 20:07:03.509 nd/fevent 0/2/CPU0 t26702 ra dns search list name example.example.com lifetime 240 first
Jun 30 20:07:03.509 nd/fevent 0/2/CPU0 t26702 ra dns search list name example1.example1.com lifetime 240 part of
same ra dns search list option
Jun 30 20:07:03.509 nd/fevent 0/2/CPU0 t26702 ra dns search list name example2.example2.com lifetime 4294967295 first
Jun 30 20:07:03.509 nd/fevent 0/2/CPU0 t26702 nd_send_ra: sending RA paksize=320, plen=280
Jun 30 20:07:03.509 nd/fevent 0/2/CPU0 t26702 nd_pak_send: size=320, ifh GigabitEthernet0/2/0/0 (0x1000300) ,
priority=2 to ipv6-io
Jun 30 20:07:03.509 nd/fevent 0/2/CPU0 t26702 nd_pak_send: sending pak=0x60c07d8b with NO FVS set, size=320,
ifh GigabitEthernet0/2/0/0 (0x1000300) to ipv6-io

Feature Information for DHCPv6 Options Support

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

Feature Information for DHCPv6 Options Support

Feature Name

Release

Feature Information

CAPWAP Access Controller DHCPv6 Option-52

Cisco IOS XE Fuji 16.8.1a

The CAPWAP protocol allows lightweight access points to use DHCPv6 to discover a Wireless Controller to which it can connect. CAPWAP is a standard, interoperable protocol that enables a controller to manage a collection of wireless access points.

DHCPv6 Client Link-Layer Address Option

Cisco IOS XE Fuji 16.8.1a

The DHCPv6 Client Link-Layer Address Option (RFC 6939) defines an optional mechanism and the related DHCPv6 option to allow first-hop DHCPv6 relay agents (relay agents that are connected to the same link as the client) to provide the client's link-layer address in the DHCPv6 messages being sent towards the server.

DNS Search List

Cisco IOS XE Fuji 16.8.1a

DNS Search List (DNSSL) is a list of Domain Name System (DNS) suffix domain names used by IPv6 hosts when they perform DNS query searches for short, unqualified domain names. The DNSSL option contains one or more domain names.

Chapter 16. Configuring IP Source Guard

- Monitoring IP Source Guard

- Additional References

IP Source Guard

You can use IP source guard to prevent traffic attacks if a host tries to use the IP address of its neighbor and you can enable IP source guard when DHCP snooping is enabled on an untrusted interface.

After IPSG is enabled on an interface, the switch blocks all IP traffic received on the interface except for DHCP packets allowed by DHCP snooping.

The switch uses a source IP lookup table in hardware to bind IP addresses to ports. For IP and MAC filtering, a combination of source IP and source MAC lookups are used. IP traffic with a source IP address in the binding table is allowed, all other traffic is denied.

The IP source binding table has bindings that are learned by DHCP snooping or are manually configured (static IP source bindings). An entry in this table has an IP address, its associated MAC address, and its associated VLAN number. The switch uses the IP source binding table only when IP source guard is enabled.

IPSG is supported only on Layer 2 ports, including access and trunk ports. You can configure IPSG with source IP address filtering or with source IP and MAC address filtering.

IP Source Guard for Static Hosts

Note

Do not use IPSG (IP source guard) for static hosts on uplink ports or trunk ports.

IPSG for static hosts extends the IPSG capability to non-DHCP and static environments. The previous IPSG used the entries created by DHCP snooping to validate the hosts connected to a switch. Any traffic received from a host without a valid DHCP binding entry is dropped. This security feature restricts IP traffic on nonrouted Layer 2 interfaces. It filters traffic based on the DHCP snooping binding database and on manually configured IP source bindings. The previous version of IPSG required a DHCP environment for IPSG to work.

IPSG for static hosts allows IPSG to work without DHCP. IPSG for static hosts relies on IP device tracking-table entries to install port ACLs. The switch creates static entries based on ARP requests or other IP packets to maintain the list of valid hosts for a given port. You can also specify the number of hosts allowed to send traffic to a given port. This is equivalent to port security at Layer 3.

IPSG for static hosts also supports dynamic hosts. If a dynamic host receives a DHCP-assigned IP address that is available in the IP DHCP snooping table, the same entry is learned by the IP device tracking table. In a stacked environment, when the active switch failover occurs, the IP source guard entries for static hosts attached to member ports are retained. When you enter the show device-tracking database EXEC command, the IP device tracking table displays the entries as ACTIVE.

Note

Some IP hosts with multiple network interfaces can inject some invalid packets into a network interface. The invalid packets contain the IP or MAC address for another network interface of the host as the source address. The invalid packets can cause IPSG for static hosts to connect to the host, to learn the invalid IP or MAC address bindings, and to reject the valid bindings. Consult the vender of the corresponding operating system and the network interface to prevent the host from injecting invalid packets.

IPSG for static hosts initially learns IP or MAC bindings dynamically through an ACL-based snooping mechanism. IP or MAC bindings are learned from static hosts by ARP and IP packets. They are stored in the device tracking database. When the number of IP addresses that have been dynamically learned or statically configured on a given port reaches a maximum, the hardware drops any packet with a new IP address. To resolve hosts that have moved or gone away for any reason, IPSG for static hosts leverages IP device tracking to age out dynamically learned IP address bindings. This feature can be used with DHCP snooping. Multiple bindings are established on a port that is connected to both DHCP and static hosts. For example, bindings are stored in both the device tracking database as well as in the DHCP snooping binding database.

IP Source Guard Configuration Guidelines

- You can configure static IP bindings only on nonrouted ports. If you enter the ip source binding mac-address vlan vlan-id ip-address interface interface-id global configuration command on a routed interface, this error message appears:

Static IP source binding can only be configured on switch port.

- When IP source guard with source IP filtering is enabled on an interface, DHCP snooping must be enabled on the access VLAN for that interface.

- If you are enabling IP source guard on a trunk interface with multiple VLANs and DHCP snooping is enabled on all the VLANs, the source IP address filter is applied on all the VLANs.

Note

If IP source guard is enabled and you enable or disable DHCP snooping on a VLAN on the trunk interface, the switch might not properly filter traffic.

- You can enable this feature when 802.1x port-based authentication is enabled.

Enabling IP Source Guard

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface interface-id

Example:

Device(config)# interface gigabitethernet 1/0/1

Specifies the interface to be configured, and enters interface configuration mode.

Step 4

ip verify source [mac-check ]

Example:

Device(config-if)# ip verify source

Enables IP source guard with source IP address filtering.

(Optional) mac-check—Enables IP Source Guard with source IP address and MAC address filtering.

Step 5

exit

Example:

Device(config-if)# exit

Returns to global configuration mode.

Step 6

ip source binding mac-address vlan vlan-id ip-address interface interface-id

Example:

Device(config)# ip source binding 0100.0230.0002 vlan 11 10.0.0.4 interface gigabitethernet1/0/1

Adds a static IP source binding.

Enter this command for each static binding.

Step 7

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 8

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 9

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Configuring IP Source Guard for Static Hosts on a Layer 2 Access Port

You must configure the ip device tracking maximum limit-number interface configuration command globally for IPSG for static hosts to work. If you only configure this command on a port without enabling IP device tracking globally or by setting an IP device tracking maximum on that interface, IPSG with static hosts rejects all the IP traffic from that interface.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ip device tracking

Example:

Device(config)# ip device tracking

Turns on the IP host table, and globally enables IP device tracking.

Step 4

interface interface-id

Example:

Device(config)# interface gigabitethernet 1/0/1

Enters interface configuration mode.

Step 5

switchport mode access

Example:

Device(config-if)# switchport mode access

Configures a port as access.

Step 6

switchport access vlan vlan-id

Example:

Device(config-if)# switchport access vlan 10

Configures the VLAN for this port.

Step 7

ip verify source[tracking] [mac-check ]

Example:

Device(config-if)# ip verify source tracking mac-check

Enables IP source guard with source IP address filtering.

(Optional) tracking—Enables IP source guard for static hosts.

(Optional) mac-check—Enables MAC address filtering.

The command ip verify source tracking mac-checkenables IP source guard for static hosts with MAC address filtering.

Step 8

ip device tracking maximum number

Example:

Device(config-if)# ip device tracking maximum 8

Establishes a maximum limit for the number of static IPs that the IP device tracking table allows on the port. The range is 1to 10. The maximum number is 10.

Note

You must configure the ip device tracking maximum limit-number interface configuration command.

Step 9

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Monitoring IP Source Guard

Privileged EXEC show Commands

Command

Purpose

show ip verify source [ interface interface-id ]

Displays the IP source guard configuration on the switch or on a specific interface.

show ip device tracking { all | interface interface-id | ip ip-address | mac mac-address}

Displays information about the entries in the IP device tracking table.

Interface Configuration Commands

Command

Purpose

ip verify source tracking

Verifies the data source.

For detailed information about the fields in these displays, see the command reference for this release.

Additional References

Error Message Decoder

Description

Link

To help you research and resolve system error messages in this release, use the Error Message Decoder tool.

https://www.cisco.com/cgi-bin/Support/Errordecoder/index.cgi

MIBs

MIB

MIBs Link

All the supported MIBs for this release.

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

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

Technical Assistance

Description

Link

The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies.

To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.

Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.

http://www.cisco.com/support

Chapter 17. Configuring Dynamic ARP Inspection

- Restrictions for Dynamic ARP Inspection

- Understanding Dynamic ARP Inspection

- Default Dynamic ARP Inspection Configuration

- Relative Priority of ARP ACLs and DHCP Snooping Entries

- Configuring ARP ACLs for Non-DHCP Environments

- Configuring Dynamic ARP Inspection in DHCP Environments

- Limiting the Rate of Incoming ARP Packets

- Performing Dynamic ARP Inspection Validation Checks

- Monitoring DAI

- Verifying the DAI Configuration

- Additional References

Restrictions for Dynamic ARP Inspection

This section lists the restrictions and guidelines for configuring Dynamic ARP Inspection on the switch.

- Dynamic ARP inspection is an ingress security feature; it does not perform any egress checking.

- Dynamic ARP inspection is not effective for hosts connected to switches that do not support dynamic ARP inspection or that do not have this feature enabled. Because man-in-the-middle attacks are limited to a single Layer 2 broadcast domain, separate the domain with dynamic ARP inspection checks from the one with no checking. This action secures the ARP caches of hosts in the domain enabled for dynamic ARP inspection.

- Dynamic ARP inspection depends on the entries in the DHCP snooping binding database to verify IP-to-MAC address bindings in incoming ARP requests and ARP responses. Make sure to enable DHCP snooping to permit ARP packets that have dynamically assigned IP addresses.

When DHCP snooping is disabled or in non-DHCP environments, use ARP ACLs to permit or to deny packets.

- Dynamic ARP inspection is supported on access ports, trunk ports, and EtherChannel ports.

Note

Do not enable Dynamic ARP inspection on RSPAN VLANs. If Dynamic ARP inspection is enabled on RSPAN VLANs, Dynamic ARP inspection packets might not reach the RSPAN destination port.

- A physical port can join an EtherChannel port channel only when the trust state of the physical port and the channel port match. Otherwise, the physical port remains suspended in the port channel. A port channel inherits its trust state from the first physical port that joins the channel. Consequently, the trust state of the first physical port need not match the trust state of the channel.

Conversely, when you change the trust state on the port channel, the switch configures a new trust state on all the physical ports that comprise the channel.

- The rate limit is calculated separately on each switch in a switch stack. For a cross-stack EtherChannel, this means that the actual rate limit might be higher than the configured value. For example, if you set the rate limit to 30 pps on an EtherChannel that has one port on switch 1 and one port on switch 2, each port can receive packets at 29 pps without causing the EtherChannel to become error-disabled.

- The operating rate for the port channel is cumulative across all the physical ports within the channel. For example, if you configure the port channel with an ARP rate-limit of 400 pps, all the interfaces combined on the channel receive an aggregate 400 pps. The rate of incoming ARP packets on EtherChannel ports is equal to the sum of the incoming rate of packets from all the channel members. Configure the rate limit for EtherChannel ports only after examining the rate of incoming ARP packets on the channel-port members.

The rate of incoming packets on a physical port is checked against the port-channel configuration rather than the physical-ports configuration. The rate-limit configuration on a port channel is independent of the configuration on its physical ports.

If the EtherChannel receives more ARP packets than the configured rate, the channel (including all physical ports) is placed in the error-disabled state.

- Make sure to limit the rate of ARP packets on incoming trunk ports. Configure trunk ports with higher rates to reflect their aggregation and to handle packets across multiple dynamic ARP inspection-enabled VLANs. You also can use the ip arp inspection limit none interface configuration command to make the rate unlimited. A high rate-limit on one VLAN can cause a denial-of-service attack to other VLANs when the software places the port in the error-disabled state.

- When you enable dynamic ARP inspection on the switch, policers that were configured to police ARP traffic are no longer effective. The result is that all ARP traffic is sent to the CPU.

Understanding Dynamic ARP Inspection

ARP provides IP communication within a Layer 2 broadcast domain by mapping an IP address to a MAC address. For example, Host B wants to send information to Host A but does not have the MAC address of Host A in its ARP cache. Host B generates a broadcast message for all hosts within the broadcast domain to obtain the MAC address associated with the IP address of Host A. All hosts within the broadcast domain receive the ARP request, and Host A responds with its MAC address. However,because ARP allows a gratuitous reply from a host even if an ARP request was not received, an ARP spoofing attack and the poisoning of ARP caches can occur. After the attack, all traffic from the device under attack flows through the attacker’s computer and then to the router, switch, or host.

A malicious user can attack hosts, switches, and routers connected to your Layer 2 network by poisoning the ARP caches of systems connected to the subnet and by intercepting traffic intended for other hosts on the subnet. Figure 26-1 shows an example of ARP cache poisoning.

ARP Cache Poisoning

Hosts A, B, and C are connected to the switch 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 MAC address MA. When Host A needs to communicate to Host B at the IP layer, it broadcasts an ARP request for the MAC address associated with IP address IB. When the switch and Host B receive the ARP request, they populate their ARP caches with an ARP binding for a host with the IP address IA and a MAC address MA; for example, IP address IA is bound to MAC address MA. When Host B responds, the switch and Host A populate their ARP caches with a binding for a host with the IP address IB and the MAC address MB.

Host C can poison the ARP caches of the switch, Host A, and Host B by broadcasting forged ARP responses with bindings for a host with an IP address of IA (or IB) and a MAC address of MC. Hosts with poisoned ARP caches use the MAC address MC as the destination MAC address for traffic intended for IA or IB. This means that Host C intercepts that traffic. Because Host C knows the true MAC addresses associated with IA and IB, it can forward the intercepted traffic to those hosts by using the correct MAC address as the destination. Host C has inserted itself into the traffic stream from Host A to Host B, the classic man-in-the middleattack.

Dynamic ARP inspection is a security feature that validates ARP packets in a network. It intercepts, logs,and discards ARP packets with invalid IP-to-MAC address bindings. This capability protects the network from certain man-in-the-middle attacks.

Dynamic ARP inspection ensures that only valid ARP requests and responses are relayed. The switch 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 updating the local ARP cache or before forwarding the packet to the appropriate destination

- Drops invalid ARP packets

Dynamic ARP inspection determines the validity of an ARP packet based on valid IP-to-MAC address bindings stored in a trusted database, the DHCP snooping binding database. This database is built by DHCP snooping if DHCP snooping is enabled on the VLANs and on the switch. If the ARP packet is received on a trusted interface, the switch forwards the packet without any checks. On untrusted interfaces, the switch forwards the packet only if it is valid.

You enable dynamic ARP inspection on a per-VLAN basis by using the ip arp inspection vlan vlan-range global configuration command.

In non-DHCP environments, dynamic ARP inspection can validate ARP packets against user-configured ARP access control lists (ACLs) for hosts with statically configured IP addresses. You define an ARP ACL by using the arp access-list acl-name global configuration command.

You can configure dynamic ARP inspection to drop ARP packets when the IP addresses in the packets are invalid or when the MAC addresses in the body of the ARP packets do not match the addresses specified in the Ethernet header. Use the ip arp inspection validate {[src-mac] [dst-mac] [ip]} global configuration command.

- Interface Trust States and Network Security

- Rate Limiting of ARP Packets

- Relative Priority of ARP ACLs and DHCP Snooping Entries

- Logging of Dropped Packets

Interface Trust States and Network Security

Dynamic ARP inspection associates a trust state with each interface on the switch. Packets arriving on trusted interfaces bypass all dynamic ARP inspection validation checks, and those arriving on untrusted interfaces undergo the dynamic ARP inspection validation process.

In a typical network configuration, you configure all switch ports connected to host ports as untrusted and configure all switch ports connected to switches as trusted. With this configuration, all ARP packets entering the network from a given switch bypass the security check. No other validation is needed at any other place in the VLAN or in the network. You configure the trust setting by using theip arp inspection trust interface configuration command.

Caution

Use the trust state configuration carefully. Configuring interfaces as untrusted when they should betrusted can result in a loss of connectivity.

In the following figure, assume that both Switch A and Switch B are running dynamic ARP inspection on the VLAN that includes Host 1 and Host 2. If Host 1 and Host 2 acquire their IP addresses from the DHCP server connected to Switch A, only Switch A binds the IP-to-MAC address of Host 1. Therefore, if the interface between Switch A and Switch B is untrusted, the ARP packets from Host 1 are dropped by Switch B. Connectivity between Host 1 and Host 2 is lost.

ARP Packet Validation on a VLAN Enabled for Dynamic ARP Inspection

Configuring interfaces to be trusted when they are actually untrusted leaves a security hole in the network. If Switch A is not running dynamic ARP inspection, Host 1 can easily poison the ARP cache of Switch B (and Host 2, if the link between the switches is configured as trusted). This condition can occur even though Switch B is running dynamic ARP inspection.

Dynamic ARP inspection ensures that hosts (on untrusted interfaces) connected to a switch running dynamic ARP inspection do not poison the ARP caches of other hosts in the network. However, dynamic ARP inspection does not prevent hosts in other portions of the network from poisoning the caches of the hosts that are connected to a switch running dynamic ARP inspection.

In cases in which some switches in a VLAN run dynamic ARP inspection and other switches do not, configure the interfaces connecting such switches as untrusted. However, to validate the bindings of packets from nondynamic ARP inspection switches, configure the switch running dynamic ARP inspection with ARP ACLs. When you cannot determine such bindings, at Layer 3, isolate switches running dynamic ARP inspection from switches not running dynamic ARP inspection switches.

Note

Depending on the setup of the DHCP server and the network, it might not be possible to validate a given ARP packet on all switches in the VLAN.

Rate Limiting of ARP Packets

The switch CPU performs dynamic ARP inspection validation checks; therefore, the number of incoming ARP packets is rate-limited to prevent a denial-of-service attack. By default, the rate for untrusted interfaces is 15 packets per second (pps). Trusted interfaces are not rate-limited. You can change this setting by using the ip arp inspection limit interface configuration command.

When the rate of incoming ARP packets exceeds the configured limit, the switch places the port in the error-disabled state. The port remains in that state until you intervene. You can use the errdisable recovery global configuration command to enable error disable recovery so that ports automatically emerge from this state after a specified timeout period.

Note

The rate limit for an EtherChannel is applied separately to each switch in a stack. For example, if a limit of 20 pps is configured on the EtherChannel, each switch with ports in the EtherChannel can carry up to 20 pps. If any switch exceeds the limit, the entire EtherChannel is placed into the error-disabled state.

Relative Priority of ARP ACLs and DHCP Snooping Entries

Dynamic ARP inspection uses the DHCP snooping binding database for the list of valid IP-to-MAC address bindings.

ARP ACLs take precedence over entries in the DHCP snooping binding database. The switch uses ACLs only if you configure them by using the ip arp inspection filter vlan global configuration command. The switch first compares ARP packets to user-configured ARP ACLs. If the ARP ACL denies the ARP packet, the switch also denies the packet even if a valid binding exists in the database populated by DHCP snooping.

Logging of Dropped Packets

When the switch drops a packet, it places an entry in the log buffer and then generates system messages on a rate-controlled basis. After the message is generated, the switch clears the entry from the log buffer. Each log entry contains flow information, such as the receiving VLAN, the port number, the source and destination IP addresses, and the source and destination MAC addresses.

You use the ip arp inspection log-buffer global configuration command to configure the number of entries in the buffer and the number of entries needed in the specified interval to generate system messages. You specify the type of packets that are logged by using the ip arp inspection vlan logging global configuration command.

Default Dynamic ARP Inspection Configuration

Feature

Default Settings

Dynamic ARP inspection

Disabled on all VLANs.

Interface trust state

All interfaces are untrusted.

Rate limit of incoming ARP packets

The rate is 15 pps on untrusted interfaces, assuming that the network is a switched network with a host connecting to as many as 15 new hosts per second.
The rate is unlimited on all trusted interfaces.

The burst interval is 1 second.

ARP ACLs for non-DHCP environments

No ARP ACLs are defined.

Validation checks

No checks are performed.

Log buffer

When dynamic ARP inspection is enabled, all denied or dropped ARP packets are logged.

The number of entries in the log is 32.

The number of system messages is limited to 5 per second.

The logging-rate interval is 1 second.

Per-VLAN logging

All denied or dropped ARP packets are logged.

Relative Priority of ARP ACLs and DHCP Snooping Entries

Dynamic ARP inspection uses the DHCP snooping binding database for the list of valid IP-to-MAC address bindings.

ARP ACLs take precedence over entries in the DHCP snooping binding database. The switch uses ACLs only if you configure them by using the ip arp inspection filter vlan global configuration command. The switch first compares ARP packets to user-configured ARP ACLs. If the ARP ACL denies the ARP packet, the switch also denies the packet even if a valid binding exists in the database populated by DHCP snooping.

Configuring ARP ACLs for Non-DHCP Environments

This procedure shows how to configure dynamic ARP inspection when Switch B shown in Figure 2 does not support dynamic ARP inspection or DHCP snooping.

If you configure port 1 on Switch A as trusted, a security hole is created because both Switch A and Host 1 could be attacked by either Switch B or Host 2. To prevent this possibility, you must configure port 1 on Switch A as untrusted. To permit ARP packets from Host 2, you must set up an ARP ACL and apply it to VLAN 1. If the IP address of Host 2 is not static (it is impossible to apply the ACL configuration on Switch A) you must separate Switch A from Switch B at Layer 3 and use a router to route packets between them.

Follow these steps to configure an ARP ACL on Switch A. This procedure is required in non-DHCP environments.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

arp access-list acl-name

Defines an ARP ACL, and enters ARP access-list configuration mode. By default, no ARP access lists are defined.

Note

At the end of the ARP access list, there is an implicit deny ip any mac any command.

Step 4

permit ip host sender-ip mac host sender-mac

Permits ARP packets from the specified host (Host 2).

- Forsender-ip, enter the IP address of Host 2.

- For sender-mac, enter the MAC address of Host 2.

Step 5

exit

Returns to global configuration mode.

Step 6

ip arp inspection filter arp-acl-name vlan vlan-range [static]

Applies ARP ACL to the VLAN. By default, no defined ARP ACLs are applied to any VLAN.

- For arp-acl-name, specify the name of the ACL created in Step 2.

- For vlan-range, specify the VLAN that the switches and hosts are in. You can specify a single VLAN identified by VLAN ID number, a range of VLANs separated by a hyphen, or a series of VLANs separated by a comma. The range is 1 to 4094.

- (Optional) Specify static to treat implicit denies in the ARP ACL as explicit denies and to drop packets that do not match any previous clauses in the ACL. DHCP bindings are not used.

If you do not specify this keyword, it means that there is no explicit deny in the ACL that denies the packet, and DHCP bindings determine whether a packet is permitted or denied if the packet does not match any clauses in the ACL.

ARP packets containing only IP-to-MAC address bindings are compared against the ACL. Packets are permitted only if the access list permits them.

Step 7

interface interface-id

Specifies Switch A interface that is connected to Switch B, and enters the interface configuration mode.

Step 8

no ip arp inspection trust

Configures Switch A interface that is connected to Switch B as untrusted.

By default, all interfaces are untrusted.

For untrusted interfaces, the switch intercepts all ARP requests and responses. It verifies that the intercepted packets have valid IP-to-MAC address bindings before updating the local cache and before forwarding the packet to the appropriate destination. The switch drops invalid packets and logs them in the log buffer according to the logging configuration specified with the ip arp inspection vlan logging global configuration command.

Step 9

end

Returns to privileged EXEC mode.

Step 10

Use the following show commands:

- show arp access-list acl-name

- show ip arp inspection vlan vlan-range

- show ip arp inspection interfaces

Verifies your entries.

Step 11

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 12

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Configuring Dynamic ARP Inspection in DHCP Environments

Before you begin

This procedure shows how to configure dynamic ARP inspection when two switches support this feature. Host 1 is connected to Switch A, and Host 2 is connected to Switch B. Both switches are running dynamic ARP inspection on VLAN 1 where the hosts are located. A DHCP server is connected to Switch A. Both hosts acquire their IP addresses from the same DHCP server. Therefore, Switch A has the bindings for Host 1 and Host 2, and Switch B has the binding for Host 2.

Note

Dynamic ARP inspection depends on the entries in the DHCP snooping binding database to verify IP-to-MAC address bindings in incoming ARP requests and ARP responses. Make sure to enable DHCP snooping to permit ARP packets that have dynamically assigned IP addresses.

Follow these steps to configure dynamic ARP inspection. You must perform this procedure on both switches. This procedure is required.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

show cdp neighbors

Verify the connection between the switches.

Example:

Device(config-if)#show cdp neighbors

Step 3

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 4

ip arp inspection vlan vlan-range

Example:

Device(config)# ip arp inspection vlan 1

Enable dynamic ARP inspection on a per-VLAN basis. By default, dynamic ARP inspection is disabled on all VLANs. For vlan-range, specify a single VLAN identified by VLAN ID number, a range of VLANs separated by a hyphen, or a series of VLANs separated by a comma. The range is 1 to 4094. Specify the same VLAN ID for both switches.

Step 5

Interfaceinterface-id

Example:

Device(config)# interface gigabitethernet1/0/1

Specifies the interface connected to the other switch, and enter interface configuration mode.

Step 6

ip arp inspection trust

Example:

Device(config-if)#ip arp inspection trust

Configures the connection between the switches as trusted. By default, all interfaces are untrusted.

The switch does not check ARP packets that it receives from the other switch on the trusted interface. It simply forwards the packets.

For untrusted interfaces, the switch intercepts all ARP requests and responses. It verifies that the intercepted packets have valid IP-to-MAC address bindings before updating the local cache and before forwarding the packet to the appropriate destination. The switch drops invalid packets and logs them in the log buffer according to the logging configuration specified with the ip arp inspection vlan logging global configuration command.

Step 7

end

Example:

Device(config-if)#end

Returns to privileged EXEC mode.

Step 8

show ip arp inspection interfaces

Example:

Verifies the dynamic ARP inspection configuration on interfaces.

Step 9

show ip arp inspection vlan vlan-range

Verifies the dynamic ARP inspection configuration on VLAN.

Example:

Device(config-if)#show ip arp inspection vlan 1

Step 10

show ip dhcp snooping binding

Example:

Device(config-if)#show ip dhcp snooping binding

Verifies the DHCP bindings.

Step 11

show ip arp inspection statistics vlan vlan-range

Example:

Device(config-if)#show ip arp inspection statistics vlan 1

Checks the dynamic ARP inspection statistics on VLAN.

Step 12

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 13

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Limiting the Rate of Incoming ARP Packets

The switch CPU performs dynamic ARP inspection validation checks; therefore, the number of incoming ARP packets is rate-limited to prevent a denial- of-service attack.

When the rate of incoming ARP packets exceeds the configured limit, the switch places the port in the error-disabled state. The port remains in that state until you enable error-disabled recovery so that ports automatically emerge from this state after a specified timeout period.

Note

Unless you configure a rate limit on an interface, changing the trust state of the interface also changes its rate limit to the default value for that trust state. After you configure the rate limit, the interface retains the rate limit even when its trust state is changed. If you enter the no ip arp inspection limit interface configuration command, the interface reverts to its default rate limit.

Follow these steps to limit the rate of incoming ARP packets. This procedure is optional.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface interface-id

Specifies the interface to be rate-limited, and enter interface configuration mode.

Step 4

ip arp inspection limit {rate pps [burst interval seconds] | none}

Limits the rate of incoming ARP requests and responses on the interface. The default rate is 15 pps on untrusted interfaces and unlimited on trusted interfaces. The burst interval is 1 second.

The keywords have these meanings:

- For ratepps , specify an upper limit for the number of incoming packets processed per second. The range is 0 to 2048 pps.

- (Optional) For burst intervalseconds , specify the consecutive interval in seconds, over which the interface is monitored for a high rate of ARP packets. The range is 1 to 15.

- For rate none , specify no upper limit for the rate of incoming ARP packets that can be processed.

Step 5

exit

Returns to global configuration mode.

Step 6

Use the following commands:

- errdisable detect cause arp-inspection

- errdisable recovery cause arp-inspection

- errdisable recovery interval interval

(Optional) Enables error recovery from the dynamic ARP inspection error-disabled state, and configure the dynamic ARP inspection recover mechanism variables.

By default, recovery is disabled, and the recovery interval is 300 seconds.

For interval interval , specify the time in seconds to recover from the error-disabled state. The range is 30 to 86400.

Step 7

exit

Returns to privileged EXEC mode.

Step 8

Use the following show commands:

- show ip arp inspection interfaces

- show errdisable recovery

Verifies your settings.

Step 9

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 10

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Performing Dynamic ARP Inspection Validation Checks

Dynamic ARP inspection intercepts, logs, and discards ARP packets with invalid IP-to-MAC address bindings. You can configure the switch to perform additional checks on the destination MAC address, the sender and target IP addresses, and the source MAC address.

Follow these steps to perform specific checks on incoming ARP packets. This procedure is optional.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ip arp inspection validate {[src-mac] [dst-mac] [ip]}

Performs a specific check on incoming ARP packets. By default, no checks are performed.

The keywords have these meanings:

- For src-mac , check the source MAC address in the Ethernet header against the sender MAC address in the ARP body. This check is performed on both ARP requests and responses. When enabled, packets with different MAC addresses are classified as invalid and are dropped.

- For dst-mac , check the destination MAC address in the Ethernet header against the target MAC address in ARP body. This check is performed for ARP responses. When enabled, packets with different MAC addresses are classified as invalid and are dropped.

- For ip , check the ARP body for invalid and unexpected IP addresses. Addresses include 0.0.0.0, 255.255.255.255, and all IP multicast addresses. Sender IP addresses are checked in all ARP requests and responses, and target IP addresses are checked only in ARP responses.

You must specify at least one of the keywords. Each command overrides the configuration of the previous command; that is, if a command enables src and dst mac validations, and a second command enables IP validation only, the src and dst mac validations are disabled as a result of the second command.

Step 4

exit

Returns to privileged EXEC mode.

Step 5

show ip arp inspection vlan vlan-range

Verifies your settings.

Step 6

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 7

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Monitoring DAI

To monitor DAI, use the following commands:

Command

Description

clear ip arp inspection statistics

Clears dynamic ARP inspection statistics.

show ip arp inspection statistics [vlan vlan-range]

Displays statistics for forwarded, dropped, MAC validation failure, IP validation failure, ACL permitted and denied, and DHCP permitted and denied packets for the specified VLAN. If no VLANs are specified or if a range is specified, displays information only for VLANs with dynamic ARP inspection enabled (active).

clear ip arp inspection log

Clears the dynamic ARP inspection log buffer.

show ip arp inspection log

Displays the configuration and contents of the dynamic ARP inspection log buffer.

For the show ip arp inspection statistics command, the switch increments the number of forwarded packets for each ARP request and response packet on a trusted dynamic ARP inspection port. The switch increments the number of ACL or DHCP permitted packets for each packet that is denied by source MAC, destination MAC, or IP validation checks, and the switch increments the appropriate.

Verifying the DAI Configuration

To display and verify the DAI configuration, use the following commands:

Command

Description

show arp access-list [acl-name]

Displays detailed information about ARP ACLs.

show ip arp inspection interfaces [interface-id]

Displays the trust state and the rate limit of ARP packets for the specified interface or all interfaces.

show ip arp inspection vlan vlan-range

Displays the configuration and the operating state of dynamic ARP inspection for the specified VLAN. If no VLANs are specified or if a range is specified, displays information only for VLANs with dynamic ARP inspection enabled (active).

Additional References

Error Message Decoder

Description

Link

To help you research and resolve system error messages in this release, use the Error Message Decoder tool.

https://www.cisco.com/cgi-bin/Support/Errordecoder/index.cgi

MIBs

MIB

MIBs Link

All the supported MIBs for this release.

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

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

Technical Assistance

Description

Link

The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies.

To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.

Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.

http://www.cisco.com/support

Chapter 18. Configuring IPv6 First Hop Security

- Prerequisites for First Hop Security in IPv6

- Restrictions for First Hop Security in IPv6

- Information about First Hop Security in IPv6

- How to Configure an IPv6 Snooping Policy

- How to Attach an IPv6 Snooping Policy to an Interface

- How to Attach an IPv6 Snooping Policy to a Layer 2 EtherChannel Interface

- How to Attach an IPv6 Snooping Policy to VLANs Globally

- How to Configure the IPv6 Binding Table Content

- How to Configure an IPv6 Neighbor Discovery Inspection Policy

- How to Configure an IPv6 Router Advertisement Guard Policy

- How to Configure an IPv6 DHCP Guard Policy

- How to Configure IPv6 Source Guard

- How to Configure IPv6 Prefix Guard

- Configuration Examples for IPv6 First Hop Security

Prerequisites for First Hop Security in IPv6

- You have configured the necessary IPv6 enabled SDM template.

- You should be familiar with the IPv6 neighbor discovery feature.

Restrictions for First Hop Security in IPv6

- The following restrictions apply when applying FHS policies to EtherChannel interfaces (Port Channels):

- A physical port with an FHS policy attached cannot join an EtherChannel group.

- An FHS policy cannot be attached to an physical port when it is a member of an EtherChannel group.

- By default, a snooping policy has a security-level of guard. When such a snooping policy is configured on an access switch, external IPv6 Router Advertisement (RA) or Dynamic Host Configuration Protocol for IPv6 (DHCPv6) server packets are blocked, even though the uplink port facing the router or DHCP server/relay is configured as a trusted port. To allow IPv6 RA or DHCPv6 server messages, do the following:

- Apply an IPv6 RA-guard policy (for RA) or IPv6 DHCP-guard policy (for DHCP server messages ) on the uplink port.

- Configure a snooping policy with a lower security-level, for example glean or inspect. However; configuring a lower security level is not recommended with such a snooping policy, because benefits of First Hop security features are not effective.

Information about First Hop Security in IPv6

First Hop Security in IPv6 (FHS IPv6) is a set of IPv6 security features, the policies of which can be attached to a physical interface, an EtherChannel interface, or a VLAN. An IPv6 software policy database service stores and accesses these policies. When a policy is configured or modified, the attributes of the policy are stored or updated in the software policy database, then applied as was specified. The following IPv6 policies are currently supported:

- IPv6 Snooping Policy—IPv6 Snooping Policy acts as a container policy that enables most of the features available with FHS in IPv6.

- IPv6 FHS Binding Table Content—A database table of IPv6 neighbors connected to the switch is created from information sources such as Neighbor Discovery (ND) protocol snooping. This database, or binding, table is used by various IPv6 guard features (such as IPv6 ND Inspection) to validate the link-layer address (LLA), the IPv4 or IPv6 address, and prefix binding of the neighbors to prevent spoofing and redirect attacks.

- IPv6 Neighbor Discovery Inspection—IPv6 ND inspection learns and secures bindings for stateless autoconfiguration addresses in Layer 2 neighbor tables. IPv6 ND inspection analyzes neighbor discovery messages in order to build a trusted binding table database and IPv6 neighbor discovery messages that do not conform are dropped. An ND message is considered trustworthy if its IPv6-to-Media Access Control (MAC) mapping is verifiable.
This feature mitigates some of the inherent vulnerabilities of the ND mechanism, such as attacks on DAD, address resolution, router discovery, and the neighbor cache.

Note

Effective Cisco IOS XE Release 16.3.1, ND Inspection functionality, IPv6 Snooping Policy, and IPv6 FHS Binding Table Content are supported through Switch Integrated Security Feature (SISF)-based Device Tracking. For more information, see Configuring SISF based device tracking section of the Software Configuration Guide.

- IPv6 Router Advertisement Guard—The IPv6 Router Advertisement (RA) guard feature enables the network administrator to block or reject unwanted or rogue RA guard messages that arrive at the network switch platform. RAs are used by routers to announce themselves on the link. The RA Guard feature analyzes the RAs and filters out bogus RAs sent by unauthorized routers. In host mode, all router advertisement and router redirect messages are disallowed on the port. The RA guard feature compares configuration information on the Layer 2 device with the information found in the received RA frame. Once the Layer 2 device has validated the content of the RA frame and router redirect frame against the configuration, it forwards the RA to its unicast or multicast destination. If the RA frame content is not validated, the RA is dropped.

- IPv6 DHCP Guard—The IPv6 DHCP Guard feature blocks reply and advertisement messages that come from unauthorized DHCPv6 servers and relay agents. IPv6 DHCP guard can prevent forged messages from being entered in the binding table and block DHCPv6 server messages when they are received on ports that are not explicitly configured as facing a DHCPv6 server or DHCP relay. To use this feature, configure a policy and attach it to an interface or a VLAN. To debug DHCP guard packets, use the debug ipv6 snooping dhcp-guard privileged EXEC command.

- IPv6 Prefix Guard—The IPv6 prefix guard feature works within the IPv6 source guard feature, to enable the device to deny traffic originated from non-topologically correct addresses. IPv6 prefix guard is often used when IPv6 prefixes are delegated to devices (for example, home gateways) using DHCP prefix delegation. The feature discovers ranges of addresses assigned to the link and blocks any traffic sourced with an address outside this range.

For more information on IPv6 Prefix Guard, see the IPv6 Prefix Guard chapter of the Cisco IOS IPv6 Configuration Guide Library on Cisco.com.

- IPv6 Destination Guard—The IPv6 destination guard feature works with IPv6 neighbor discovery to ensure that the device performs address resolution only for those addresses that are known to be active on the link. It relies on the address glean functionality to populate all destinations active on the link into the binding table and then blocks resolutions before they happen when the destination is not found in the binding table.

Note

IPv6 Destination Guard is recommended to apply on Layer 2 VLAN with an SVI configured

For more information about IPv6 Destination Guard, see the IPv6 Destination Guard chapter of the Cisco IOS IPv6 Configuration Guide Library on Cisco.com.

How to Configure an IPv6 Snooping Policy

The IPv6 Snooping Policy feature is deprecated starting from Cisco IOS XE Denali 16.3.1. Although the commands are visible on the CLI and you can configure them, we recommend that you use the Switch Integrated Security Feature (SISF)-based Device Tracking feature instead.

Beginning in privileged EXEC mode, follow these steps to configure IPv6 Snooping Policy :

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters the global configuration mode.

Step 2

ipv6 snooping policy policy-name

Example:

Device(config)# ipv6 snooping policy example_policy

Creates a snooping policy and enters IPv6 Snooping Policy Configuration mode.

Step 3

{[default ] | [device-role {node | switch}] | [limit address-count value] | [no] | [protocol {dhcp | ndp} ] | [security-level {glean | guard | inspect} ] | [tracking {disable [stale-lifetime [seconds | infinite] | enable [reachable-lifetime [seconds | infinite] } ] | [trusted-port ] }

Example:

Device(config-ipv6-snooping)# security-level inspect

Example:

Device(config-ipv6-snooping)# trusted-port

Enables data address gleaning, validates messages against various criteria, specifies the security level for messages.

- (Optional) default—Sets all to default options.

- (Optional) device-role{node] | switch}—Specifies the role of the device attached to the port. Default is node.

- (Optional) limit address-count value—Limits the number of addresses allowed per target.

- (Optional) no—Negates a command or sets it to defaults.

- (Optional) protocol{dhcp | ndp}—Specifies which protocol should be redirected to the snooping feature for analysis. The default, is dhcp and ndp. To change the default, use the no protocol command.

- (Optional) security-level{glean|guard|inspect}—Specifies the level of security enforced by the feature. Default is guard.

- glean—Gleans addresses from messages and populates the binding table without any verification.

- guard—Gleans addresses and inspects messages. In addition, it rejects RA and DHCP server messages. This is the default option.

- inspect—Gleans addresses, validates messages for consistency and conformance, and enforces address ownership.

- (Optional) tracking {disable | enable}—Overrides the default tracking behavior and specifies a tracking option.

- (Optional) trusted-port—Sets up a trusted port. It disables the guard on applicable targets. Bindings learned through a trusted port have preference over bindings learned through any other port. A trusted port is given preference in case of a collision while making an entry in the table.

Step 4

end

Example:

Device(config-ipv6-snooping)# exit

Exits configuration modes to Privileged EXEC mode.

Step 5

show ipv6 snooping policy policy-name

Example:

Device#show ipv6 snooping policy example_policy

Displays the snooping policy configuration.

What to do next

Attach an IPv6 Snooping policy to interfaces or VLANs.

How to Attach an IPv6 Snooping Policy to an Interface

Beginning in privileged EXEC mode, follow these steps to attach an IPv6 Snooping policy on an interface or VLAN:

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters the global configuration mode.

Step 2

interface Interface_type stack/module/port

Example:

Device(config)#  interface gigabitethernet 1/1/4

Specifies an interface type and identifier; enters the interface configuration mode.

Step 3

switchport

Example:

Device(config-if)# switchport

Enters the Switchport mode.

Note

To configure Layer 2 parameters, if the interface is in Layer 3 mode, you must enter the switchport interface configuration command without any parameters to put the interface into Layer 2 mode. This shuts down the interface and then re-enables it, which might generate messages on the device to which the interface is connected. When you put an interface that is in Layer 3 mode into Layer 2 mode, the previous configuration information related to the affected interface might be lost, and the interface is returned to its default configuration. The command prompt displays as (config-if)# in Switchport configuration mode.

Step 4

ipv6 snooping [attach-policy policy_name [ vlan {vlan_id | add vlan_ids | exceptvlan_ids | none | remove vlan_ids}] | vlan {vlan_id | add vlan_ids | exceptvlan_ids | none | remove vlan_ids | all} ]

Example:

Device(config-if)# ipv6 snooping

or

Device(config-if)# ipv6 snooping attach-policy example_policy

or
Device(config-if)# ipv6 snooping vlan 111,112

or

Device(config-if)# ipv6 snooping attach-policy example_policy vlan 111,112

Attaches a custom ipv6 snooping policy to the interface or the specified VLANs on the interface. To attach the default policy to the interface, use the ipv6 snooping command without the attach-policy keyword. To attach the default policy to VLANs on the interface, use the ipv6 snooping vlan command. The default policy is, security-level guard, device-role node, protocol ndp and dhcp.

Step 5

do show running-config

Example:

Device#(config-if)#  do show running-config

Verifies that the policy is attached to the specified interface without exiting the interface configuration mode.

How to Attach an IPv6 Snooping Policy to a Layer 2 EtherChannel Interface

Beginning in privileged EXEC mode, follow these steps to attach an IPv6 Snooping policy on an EtherChannel interface or VLAN:

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters the global configuration mode.

Step 2

interface range Interface_name

Example:

Device(config)#  interface range Po11

Specify the port-channel interface name assigned when the EtherChannel was created. Enters the interface range configuration mode.

Tip

Enter the do show interfaces summary command for quick reference to interface names and types.

Step 3

ipv6 snooping [attach-policy policy_name [ vlan {vlan_ids | add vlan_ids | except vlan_ids | none | remove vlan_ids | all} ] | vlan [ {vlan_ids | add vlan_ids | exceptvlan_ids | none | remove vlan_ids | all} ]

Example:

Device(config-if-range)# ipv6 snooping attach-policy example_policy

or

Device(config-if-range)# ipv6 snooping attach-policy example_policy vlan 222,223,224

or

Device(config-if-range)#ipv6 snooping vlan 222, 223,224

Attaches the IPv6 Snooping policy to the interface or the specified VLANs on that interface. The default policy is attached if the attach-policy option is not used.

Step 4

do show running-config interfaceportchannel_interface_name

Example:

Device#(config-if-range)#  do show running-config int po11

Confirms that the policy is attached to the specified interface without exiting the configuration mode.

How to Attach an IPv6 Snooping Policy to VLANs Globally

Beginning in privileged EXEC mode, follow these steps to attach an IPv6 Snooping Policy to VLANs across multiple interfaces:

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters the global configuration mode.

Step 2

vlan configuration vlan_list

Example:

Device(config)#  vlan configuration 333

Specifies the VLANs to which the IPv6 Snooping policy will be attached ; enters the VLAN interface configuration mode.

Step 3

ipv6 snooping [attach-policy policy_name]

Example:

Device(config-vlan-config)#ipv6 snooping attach-policy example_policy

Attaches the IPv6 Snooping policy to the specified VLANs across all switch and stack interfaces. The default policy is attached if the attach-policy option is not used. The default policy is, security-level guard, device-role node, protocol ndp and dhcp.

Step 4

do show running-config

Example:

Device#(config-if)#  do show running-config

Verifies that the policy is attached to the specified VLANs without exiting the interface configuration mode.

How to Configure the IPv6 Binding Table Content

Beginning in privileged EXEC mode, follow these steps to configure IPv6 Binding Table Content :

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters the global configuration mode.

Step 2

[no] ipv6 neighbor binding [vlan vlan-id {ipv6-address interface interface_type stack/module/port hw_address [reachable-lifetimevalue [seconds | default | infinite] | [tracking{ [default | disable] [ reachable-lifetimevalue [seconds | default | infinite] | [enable [reachable-lifetimevalue [seconds | default | infinite] | [retry-interval {seconds| default [reachable-lifetimevalue [seconds | default | infinite] } ]

Example:

Device(config)#  ipv6 neighbor binding

Adds a static entry to the binding table database.

Step 3

[no] ipv6 neighbor binding max-entries number [mac-limit number | port-limit number [mac-limit number] | vlan-limit number [ [mac-limit number] | [port-limit number [mac-limitnumber] ] ] ]

Example:

Device(config)#  ipv6 neighbor binding max-entries 30000

Specifies the maximum number of entries that are allowed to be inserted in the binding table cache.

Step 4

ipv6 neighbor binding logging

Example:

Device(config)# ipv6 neighbor binding logging

Enables the logging of binding table main events.

Step 5

exit

Example:

Device(config)# exit

Exits global configuration mode, and places the router in privileged EXEC mode.

Step 6

show ipv6 neighbor binding

Example:

Device#  show ipv6 neighbor binding

Displays contents of a binding table.

How to Configure an IPv6 Neighbor Discovery Inspection Policy

Beginning in privileged EXEC mode, follow these steps to configure an IPv6 ND Inspection Policy:

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters the global configuration mode.

Step 2

[no]ipv6 nd inspection policy policy-name

Example:

Device(config)# ipv6 nd inspection policy example_policy

Specifies the ND inspection policy name and enters ND Inspection Policy configuration mode.

Step 3

device-role {host | switch}

Example:

Device(config-nd-inspection)# device-role switch

Specifies the role of the device attached to the port. The default is host.

Step 4

limit address-count value

Example:

Device(config-nd-inspection)# limit address-count 1000

Enter 1–10,000.

Step 5

tracking {enable [reachable-lifetime {value | infinite}] | disable [stale-lifetime {value | infinite}]}

Example:

Device(config-nd-inspection)# tracking disable stale-lifetime infinite

Overrides the default tracking policy on a port.

Step 6

trusted-port

Example:

Device(config-nd-inspection)# trusted-port

Configures a port to become a trusted port.

Step 7

validate source-mac

Example:

Device(config-nd-inspection)# validate source-mac

Checks the source media access control (MAC) address against the link-layer address.

Step 8

no {device-role | limit address-count | tracking | trusted-port | validate source-mac}

Example:

Device(config-nd-inspection)# no validate source-mac

Remove the current configuration of a parameter with the no form of the command.

Step 9

default {device-role | limit address-count | tracking | trusted-port | validate source-mac}

Example:

Device(config-nd-inspection)# default limit address-count

Restores configuration to the default values.

Step 10

do show ipv6 nd inspection policy policy_name

Example:

Device(config-nd-inspection)# do show ipv6 nd inspection policy example_policy

Verifies the ND Inspection Configuration without exiting ND inspection configuration mode.

- How to Attach an IPv6 Neighbor Discovery Inspection Policy to an Interface

- How to Attach an IPv6 Neighbor Discovery Inspection Policy to a Layer 2 EtherChannel Interface

- How to Attach an IPv6 Neighbor Discovery Inspection Policy to VLANs Globally

How to Attach an IPv6 Neighbor Discovery Inspection Policy to an Interface

Beginning in privileged EXEC mode, follow these steps to attach an IPv6 ND Inspection policy to an interface or VLANs on an interface :

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters the global configuration mode.

Step 2

interface Interface_type stack/module/port

Example:

Device(config)#  interface gigabitethernet 1/1/4

Specifies an interface type and identifier; enters the interface configuration mode.

Step 3

ipv6 nd inspection [attach-policy policy_name [ vlan {vlan_ids | add vlan_ids | except vlan_ids | none | remove vlan_ids | all} ] | vlan [ {vlan_ids | add vlan_ids | exceptvlan_ids | none | remove vlan_ids | all} ]

Example:

Device(config-if)# ipv6 nd inspection attach-policy example_policy

or

Device(config-if)# ipv6 nd inspection attach-policy example_policy vlan 222,223,224

or

Device(config-if)# ipv6 nd inspection vlan 222, 223,224

Attaches the Neighbor Discovery Inspection policy to the interface or the specified VLANs on that interface. The default policy is attached if the attach-policy option is not used.

Step 4

do show running-config

Example:

Device#(config-if)#  do show running-config

Verifies that the policy is attached to the specified interface without exiting the interface configuration mode.

How to Attach an IPv6 Neighbor Discovery Inspection Policy to a Layer 2 EtherChannel Interface

Beginning in privileged EXEC mode, follow these steps to attach an IPv6 Neighbor Discovery Inspection policy on an EtherChannel interface or VLAN:

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters the global configuration mode.

Step 2

interface range Interface_name

Example:

Device(config)#  interface Po11

Specify the port-channel interface name assigned when the EtherChannel was created. Enters the interface range configuration mode.

Tip

Enter the do show interfaces summary command for quick reference to interface names and types.

Step 3

ipv6 nd inspection [attach-policy policy_name [ vlan {vlan_ids | add vlan_ids | except vlan_ids | none | remove vlan_ids | all} ] | vlan [ {vlan_ids | add vlan_ids | exceptvlan_ids | none | remove vlan_ids | all} ]

Example:

Device(config-if-range)# ipv6 nd inspection attach-policy example_policy

or

Device(config-if-range)# ipv6 nd inspection attach-policy example_policy vlan 222,223,224

or

Device(config-if-range)#ipv6 nd inspection vlan 222, 223,224

Attaches the ND Inspection policy to the interface or the specified VLANs on that interface. The default policy is attached if the attach-policy option is not used.

Step 4

do show running-config interfaceportchannel_interface_name

Example:

Device#(config-if-range)#  do show running-config int po11

Confirms that the policy is attached to the specified interface without exiting the configuration mode.

How to Attach an IPv6 Neighbor Discovery Inspection Policy to VLANs Globally

Beginning in privileged EXEC mode, follow these steps to attach an IPv6 ND Inspection policy to VLANs across multiple interfaces:

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters the global configuration mode.

Step 2

vlan configuration vlan_list

Example:

Device(config)# vlan configuration 334

Specifies the VLANs to which the IPv6 Snooping policy will be attached ; enters the VLAN interface configuration mode.

Step 3

ipv6 nd inspection [attach-policy policy_name]

Example:

Device(config-vlan-config)#ipv6 nd inspection attach-policy example_policy

Attaches the IPv6 Neighbor Discovery policy to the specified VLANs across all switch and stack interfaces. The default policy is attached if the attach-policy option is not used.

The default policy is, device-role host, no drop-unsecure, limit address-count disabled, sec-level minimum is disabled, tracking is disabled, no trusted-port, no validate source-mac.

Step 4

do show running-config

Example:

Device#(config-if)#  do show running-config

Confirms that the policy is attached to the specified VLANs without exiting the configuration mode.

How to Configure an IPv6 Router Advertisement Guard Policy

Beginning in privileged EXEC mode, follow these steps to configure an IPv6 Router Advertisement policy :

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters the global configuration mode.

Step 2

[no]ipv6 nd raguard policy policy-name

Example:

Device(config)# ipv6 nd raguard policy example_policy

Specifies the RA Guard policy name and enters RA Guard Policy configuration mode.

Step 3

[no]device-role {host | monitor | router | switch}

Example:

Device(config-nd-raguard)# device-role switch

Specifies the role of the device attached to the port. The default is host.

Note

For a network with both host-facing ports and router-facing ports, along with a RA guard policy configured with device-role host on host-facing ports or vlan, it is mandatory to configure a RA guard policy with device-role router on router-facing ports to allow the RA Guard feature to work properly.

Step 4

[no]hop-limit {maximum | minimum} value

Example:

Device(config-nd-raguard)# hop-limit maximum 33

(1–255) Range for Maximum and Minimum Hop Limit values.

Enables filtering of Router Advertisement messages by the Hop Limit value. A rogue RA message may have a low Hop Limit value (equivalent to the IPv4 Time to Live) that when accepted by the host, prevents the host from generating traffic to destinations beyond the rogue RA message generator. An RA message with an unspecified Hop Limit value is blocked.

If not configured, this filter is disabled. Configure minimum to block RA messages with Hop Limit values lower than the value you specify. Configure maximumto block RA messages with Hop Limit values greater than the value you specify.

Step 5

[no]managed-config-flag {off | on}

Example:

Device(config-nd-raguard)# managed-config-flag on

Enables filtering of Router Advertisement messages by the Managed Address Configuration, or "M" flag field. A rouge RA message with an M field of 1 can cause a host to use a rogue DHCPv6 server. If not configured, this filter is disabled.

On—Accepts and forwards RA messages with an M value of 1, blocks those with 0.

Off—Accepts and forwards RA messages with an M value of 0, blocks those with 1.

Step 6

[no]match {ipv6 access-list list | ra prefix-list list}

Example:

Device(config-nd-raguard)# match ipv6 access-list example_list

Matches a specified prefix list or access list.

Step 7

[no]other-config-flag {on | off}

Example:

Device(config-nd-raguard)# other-config-flag on

Enables filtering of Router Advertisement messages by the Other Configuration, or "O" flag field. A rouge RA message with an O field of 1 can cause a host to use a rogue DHCPv6 server. If not configured, this filter is disabled.

On—Accepts and forwards RA messages with an O value of 1, blocks those with 0.

Off—Accepts and forwards RA messages with an O value of 0, blocks those with 1.

Step 8

[no]router-preference maximum {high | medium | low}

Example:

Device(config-nd-raguard)# router-preference maximum high

Enables filtering of Router Advertisement messages by the Router Preference flag. If not configured, this filter is disabled.

- high—Accepts RA messages with the Router Preference set to high, medium, or low.

- medium—Blocks RA messages with the Router Preference set to high.

- low—Blocks RA messages with the Router Preference set to medium and high.

Step 9

[no]trusted-port

Example:

Device(config-nd-raguard)# trusted-port

When configured as a trusted port, all attached devices are trusted, and no further message verification is performed.

Step 10

default {device-role | hop-limit {maximum | minimum} | managed-config-flag | match {ipv6 access-list | ra prefix-list } | other-config-flag | router-preference maximum| trusted-port}

Example:

Device(config-nd-raguard)# default hop-limit

Restores a command to its default value.

Step 11

do show ipv6 nd raguard policy policy_name

Example:

Device(config-nd-raguard)# do show ipv6 nd raguard policy example_policy

(Optional)—Displays the ND Guard Policy configuration without exiting the RA Guard policy configuration mode.

- How to Attach an IPv6 Router Advertisement Guard Policy to an Interface

- How to Attach an IPv6 Router Advertisement Guard Policy to a Layer 2 EtherChannel Interface

- How to Attach an IPv6 Router Advertisement Guard Policy to VLANs Globally

How to Attach an IPv6 Router Advertisement Guard Policy to an Interface

Beginning in privileged EXEC mode, follow these steps to attach an IPv6 Router Advertisement policy to an interface or to VLANs on the interface :

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters the global configuration mode.

Step 2

interface Interface_type stack/module/port

Example:

Device(config)#  interface gigabitethernet 1/1/4

Specifies an interface type and identifier; enters the interface configuration mode.

Step 3

ipv6 nd raguard [attach-policy policy_name [ vlan {vlan_ids | add vlan_ids | except vlan_ids | none | remove vlan_ids | all} ] | vlan [ {vlan_ids | add vlan_ids | exceptvlan_ids | none | remove vlan_ids | all} ]

Example:

Device(config-if)# ipv6 nd raguard attach-policy example_policy

or

Device(config-if)# ipv6 nd raguard attach-policy example_policy vlan 222,223,224

or

Device(config-if)# ipv6 nd raguard vlan 222, 223,224

Attaches the Neighbor Discovery Inspection policy to the interface or the specified VLANs on that interface. The default policy is attached if the attach-policy option is not used.

Step 4

do show running-config

Example:

Device#(config-if)#  do show running-config

Confirms that the policy is attached to the specified interface without exiting the configuration mode.

How to Attach an IPv6 Router Advertisement Guard Policy to a Layer 2 EtherChannel Interface

Beginning in privileged EXEC mode, follow these steps to attach an IPv6 Router Advertisement Guard Policy on an EtherChannel interface or VLAN:

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters the global configuration mode.

Step 2

interface range Interface_name

Example:

Device(config)#  interface Po11

Specify the port-channel interface name assigned when the EtherChannel was created. Enters the interface range configuration mode.

Tip

Enter the do show interfaces summary command for quick reference to interface names and types.

Step 3

ipv6 nd raguard [attach-policy policy_name [ vlan {vlan_ids | add vlan_ids | except vlan_ids | none | remove vlan_ids | all} ] | vlan [ {vlan_ids | add vlan_ids | exceptvlan_ids | none | remove vlan_ids | all} ]

Example:

Device(config-if-range)# ipv6 nd raguard attach-policy example_policy

or

Device(config-if-range)# ipv6 nd raguard attach-policy example_policy vlan 222,223,224

or

Device(config-if-range)#ipv6 nd raguard vlan 222, 223,224

Attaches the RA Guard policy to the interface or the specified VLANs on that interface. The default policy is attached if the attach-policy option is not used.

Step 4

do show running-config interfaceportchannel_interface_name

Example:

Device#(config-if-range)#  do show running-config int po11

Confirms that the policy is attached to the specified interface without exiting the configuration mode.

How to Attach an IPv6 Router Advertisement Guard Policy to VLANs Globally

Beginning in privileged EXEC mode, follow these steps to attach an IPv6 Router Advertisement policy to VLANs regardless of interface:

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

vlan configuration vlan_list

Example:

Device(config)# vlan configuration 335

Specifies the VLANs to which the IPv6 RA Guard policy will be attached ; enters the VLAN interface configuration mode.

Step 3

ipv6 dhcp guard [attach-policy policy_name]

Example:

Device(config-vlan-config)#ipv6 nd raguard attach-policy example_policy

Attaches the IPv6 RA Guard policy to the specified VLANs across all switch and stack interfaces. The default policy is attached if the attach-policy option is not used.

Step 4

do show running-config

Example:

Device#(config-if)#  do show running-config

Confirms that the policy is attached to the specified VLANs without exiting the configuration mode.

How to Configure an IPv6 DHCP Guard Policy

Beginning in privileged EXEC mode, follow these steps to configure an IPv6 DHCP (DHCPv6) Guard policy:

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters the global configuration mode.

Step 2

[no]ipv6 dhcp guard policy policy-name

Example:

Device(config)# ipv6 dhcp guard policy example_policy

Specifies the DHCPv6 Guard policy name and enters DHCPv6 Guard Policy configuration mode.

Step 3

[no]device-role {client | server}

Example:

Device(config-dhcp-guard)# device-role server

(Optional) Filters out DHCPv6 replies and DHCPv6 advertisements on the port that are not from a device of the specified role. Default is client.

- client—Default value, specifies that the attached device is a client. Server messages are dropped on this port.

- server—Specifies that the attached device is a DHCPv6 server. Server messages are allowed on this port.

Step 4

[no] match server access-list ipv6-access-list-name

Example:

;;Assume a preconfigured IPv6 Access List as follows:
Device(config)# ipv6 access-list my_acls
Device(config-ipv6-acl)# permit host FE80::A8BB:CCFF:FE01:F700 any

;;configure DCHPv6 Guard to match approved access list.
Device(config-dhcp-guard)#  match server access-list my_acls

(Optional). Enables verification that the advertised DHCPv6 server or relay address is from an authorized server access list (The destination address in the access list is 'any'). If not configured, this check will be bypassed. An empty access list is treated as a permit all.

Step 5

[no] match reply prefix-list ipv6-prefix-list-name

Example:

;;Assume a preconfigured IPv6 prefix list as follows:
Device(config)# ipv6 prefix-list my_prefix permit 2001:0DB8::/64 le 128

;; Configure DCHPv6 Guard to match prefix
Device(config-dhcp-guard)#  match reply prefix-list my_prefix

(Optional) Enables verification of the advertised prefixes in DHCPv6 reply messages from the configured authorized prefix list. If not configured, this check will be bypassed. An empty prefix list is treated as a permit.

Step 6

[no]preference{ max limit | min limit }

Example:

Device(config-dhcp-guard)# preference max 250
Device(config-dhcp-guard)#preference min 150

Configure max and min when device-role is serverto filter DCHPv6 server advertisements by the server preference value. The defaults permit all advertisements.

max limit—(0 to 255) (Optional) Enables verification that the advertised preference (in preference option) is less than the specified limit. Default is 255. If not specified, this check will be bypassed.

min limit—(0 to 255) (Optional) Enables verification that the advertised preference (in preference option) is greater than the specified limit. Default is 0. If not specified, this check will be bypassed.

Step 7

[no] trusted-port

Example:

Device(config-dhcp-guard)# trusted-port

(Optional) trusted-port—Sets the port to a trusted mode. No further policing takes place on the port.

Note

If you configure a trusted port then the device-role option is not available.

Step 8

default {device-role | trusted-port}

Example:

Device(config-dhcp-guard)# default device-role

(Optional) default—Sets a command to its defaults.

Step 9

do show ipv6 dhcp guard policy policy_name

Example:

Device(config-dhcp-guard)# do show ipv6 dhcp guard policy example_policy

(Optional) Displays the configuration of the IPv6 DHCP guard policy without leaving the configuration submode. Omitting the policy_name variable displays all DHCPv6 policies.

Example of DHCPv6 Guard Configuration

enable
configure terminal
ipv6 access-list acl1
permit host FE80::A8BB:CCFF:FE01:F700 any
ipv6 prefix-list abc permit 2001:0DB8::/64 le 128
ipv6 dhcp guard policy pol1
device-role server
match server access-list acl1
match reply prefix-list abc
preference min 0
preference max 255
trusted-port
interface GigabitEthernet 0/2/0
switchport
ipv6 dhcp guard attach-policy pol1 vlan add 1
vlan 1
ipv6 dhcp guard attach-policy pol1
show ipv6 dhcp guard policy pol1

- How to Attach an IPv6 DHCP Guard Policy to an Interface or a VLAN on an Interface

- How to Attach an IPv6 DHCP Guard Policy to a Layer 2 EtherChannel Interface

- How to Attach an IPv6 DHCP Guard Policy to VLANs Globally

How to Attach an IPv6 DHCP Guard Policy to an Interface or a VLAN on an Interface

Beginning in privileged EXEC mode, follow these steps to configure IPv6 Binding Table Content :

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters the global configuration mode.

Step 2

interface Interface_type stack/module/port

Example:

Device(config)#  interface gigabitethernet 1/1/4

Specifies an interface type and identifier; enters the interface configuration mode.

Step 3

ipv6 dhcp guard [attach-policy policy_name [ vlan {vlan_ids | add vlan_ids | except vlan_ids | none | remove vlan_ids | all} ] | vlan [ {vlan_ids | add vlan_ids | exceptvlan_ids | none | remove vlan_ids | all} ]

Example:

Device(config-if)# ipv6 dhcp guard attach-policy example_policy

or

Device(config-if)# ipv6 dhcp guard attach-policy example_policy vlan 222,223,224

or

Device(config-if)# ipv6 dhcp guard vlan 222, 223,224

Attaches the DHCP Guard policy to the interface or the specified VLANs on that interface. The default policy is attached if the attach-policy option is not used.

Step 4

do show running-config interface Interface_type stack/module/port

Example:

Device#(config-if)#  do show running-config gig 1/1/4

Confirms that the policy is attached to the specified interface without exiting the configuration mode.

How to Attach an IPv6 DHCP Guard Policy to a Layer 2 EtherChannel Interface

Beginning in privileged EXEC mode, follow these steps to attach an IPv6 DHCP Guard policy on an EtherChannel interface or VLAN:

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters the global configuration mode.

Step 2

interface range Interface_name

Example:

Device(config)#  interface Po11

Specify the port-channel interface name assigned when the EtherChannel was created. Enters the interface range configuration mode.

Tip

Enter the do show interfaces summary command for quick reference to interface names and types.

Step 3

ipv6 dhcp guard [attach-policy policy_name [ vlan {vlan_ids | add vlan_ids | except vlan_ids | none | remove vlan_ids | all} ] | vlan [ {vlan_ids | add vlan_ids | exceptvlan_ids | none | remove vlan_ids | all} ]

Example:

Device(config-if-range)# ipv6 dhcp guard attach-policy example_policy

or

Device(config-if-range)# ipv6 dhcp guard attach-policy example_policy vlan 222,223,224

or

Device(config-if-range)#ipv6 dhcp guard vlan 222, 223,224

Attaches the DHCP Guard policy to the interface or the specified VLANs on that interface. The default policy is attached if the attach-policy option is not used.

Step 4

do show running-config interfaceportchannel_interface_name

Example:

Device#(config-if-range)#  do show running-config int po11

Confirms that the policy is attached to the specified interface without exiting the configuration mode.

How to Attach an IPv6 DHCP Guard Policy to VLANs Globally

Beginning in privileged EXEC mode, follow these steps to attach an IPv6 DHCP Guard policy to VLANs across multiple interfaces:

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters the global configuration mode.

Step 2

vlan configuration vlan_list

Example:

Device(config)# vlan configuration 334

Specifies the VLANs to which the IPv6 Snooping policy will be attached ; enters the VLAN interface configuration mode.

Step 3

ipv6 dhcp guard [attach-policy policy_name]

Example:

Device(config-vlan-config)#ipv6 dhcp guard attach-policy example_policy

Attaches the IPv6 Neighbor Discovery policy to the specified VLANs across all switch and stack interfaces. The default policy is attached if the attach-policy option is not used. The default policy is, device-role client, no trusted-port.

Step 4

do show running-config

Example:

Device#(config-if)#  do show running-config

Confirms that the policy is attached to the specified VLANs without exiting the configuration mode.

How to Configure IPv6 Source Guard

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters the global configuration mode.

Step 3

[no] ipv6 source-guard policy policy_name

Example:

Device(config)#  ipv6 source-guard policy example_policy

Specifies the IPv6 Source Guard policy name and enters IPv6 Source Guard policy configuration mode.

Step 4

[deny global-autoconf] [permit link-local] [default{. . . }] [exit] [no{. . . }]

Example:

Device(config-sisf-sourceguard)#  deny global-autoconf

(Optional) Defines the IPv6 Source Guard policy.

- deny global-autoconf—Denies data traffic from auto-configured global addresses. This is useful when all global addresses on a link are DHCP-assigned and the administrator wants to block hosts with self-configured addresses to send traffic.

- permit link-local—Allows all data traffic that is sourced by a link-local address.

Note

Trusted option under source guard policy is not supported.

Step 5

end

Example:

Device(config-sisf-sourceguard)# end

Exits out of IPv6 Source Guard policy configuration mode.

Step 6

show ipv6 source-guard policy policy_name

Example:

Device# show ipv6 source-guard policy example_policy

Shows the policy configuration and all the interfaces where the policy is applied.

What to do next

Apply the IPv6 Source Guard policy to an interface.

- How to Attach an IPv6 Source Guard Policy to an Interface

- How to attach an IPv6 Source Guard Policy to a Layer 2 EtherChannel Interface

How to Attach an IPv6 Source Guard Policy to an Interface

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters the global configuration mode.

Step 3

interface Interface_type stack/module/port

Example:

Device(config)#  interface gigabitethernet 1/1/4

Specifies an interface type and identifier; enters the interface configuration mode.

Step 4

ipv6 source-guard [ attach-policy <policy_name> ]

Example:

Device(config-if)# ipv6 source-guard attach-policy example_policy

Attaches the IPv6 Source Guard policy to the interface. The default policy is attached if the attach-policy option is not used.

Step 5

show ipv6 source-guard policy policy_name

Example:

Device#(config-if)# show ipv6 source-guard policy example_policy

Shows the policy configuration and all the interfaces where the policy is applied.

How to attach an IPv6 Source Guard Policy to a Layer 2 EtherChannel Interface

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters the global configuration mode.

Step 3

interface port-channel port-channel-number

Example:

Device (config)# interface Po4

Specifies an interface type and port number and places the switch in the port channel configuration mode.

Step 4

ipv6 source-guard [ attach-policy <policy_name> ]

Example:

Device(config-if) # ipv6 source-guard attach-policy example_policy

Attaches the IPv6 Source Guard policy to the interface. The default policy is attached if the attach-policy option is not used.

Step 5

show ipv6 source-guard policy policy_name

Example:

Device(config-if) #show ipv6 source-guard policy example_policy

Shows the policy configuration and all the interfaces where the policy is applied.

How to Configure IPv6 Prefix Guard

Note

To allow routing protocol control packets sourced by a link-local address when prefix guard is applied, enable the permit link-local command in the source-guard policy configuration mode.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

[ no] ipv6 source-guard policy source-guard-policy

Example:

Device (config)# ipv6 source-guard policy my_snooping_policy

Defines an IPv6 source-guard policy name and enters switch integrated security features source-guard policy configuration mode.

Step 4

[ no ] validate address

Example:

Device (config-sisf-sourceguard)# no validate address

Disables the validate address feature and enables the IPv6 prefix guard feature to be configured.

Step 5

validate prefix

Example:

Device (config-sisf-sourceguard)# validate prefix

Enables IPv6 source guard to perform the IPv6 prefix-guard operation.

Step 6

exit

Example:

Device (config-sisf-sourceguard)# exit

Exits switch integrated security features source-guard policy configuration mode and returns to privileged EXEC mode.

Step 7

show ipv6 source-guard policy [ source-guard-policy]

Example:

Device # show ipv6 source-guard policy policy1

Displays the IPv6 source-guard policy configuration.

- How to Attach an IPv6 Prefix Guard Policy to an Interface

- How to attach an IPv6 Prefix Guard Policy to a Layer 2 EtherChannel Interface

How to Attach an IPv6 Prefix Guard Policy to an Interface

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters the global configuration mode.

Step 3

interface Interface_type stack/module/port

Example:

Device(config)#  interface gigabitethernet 1/1/4

Specifies an interface type and identifier; enters the interface configuration mode.

Step 4

ipv6 source-guard attach-policy policy_name

Example:

Device(config-if)# ipv6 source-guard attach-policy example_policy

Attaches the IPv6 Source Guard policy to the interface. The default policy is attached if the attach-policy option is not used.

Step 5

show ipv6 source-guard policy policy_name

Example:

Device(config-if)# show ipv6 source-guard policy example_policy

Shows the policy configuration and all the interfaces where the policy is applied.

How to attach an IPv6 Prefix Guard Policy to a Layer 2 EtherChannel Interface

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters the global configuration mode.

Step 3

interface port-channel port-channel-number

Example:

Device (config)# interface Po4

Specifies an interface type and port number and places the switch in the port channel configuration mode.

Step 4

ipv6 source-guard [ attach-policy <policy_name> ]

Example:

Device(config-if)# ipv6 source-guard attach-policy example_policy

Attaches the IPv6 Source Guard policy to the interface. The default policy is attached if the attach-policy option is not used.

Step 5

show ipv6 source-guard policy policy_name

Example:

Device(config-if)# show ipv6 source-guard policy example_policy

Shows the policy configuration and all the interfaces where the policy is applied.

Configuration Examples for IPv6 First Hop Security

- Examples: How to attach an IPv6 Source Guard Policy to a Layer 2 EtherChannel Interface

- Examples: How to attach an IPv6 Prefix Guard Policy to a Layer 2 EtherChannel Interface

Examples: How to attach an IPv6 Source Guard Policy to a Layer 2 EtherChannel Interface

The following example shows how to attach an IPv6 Source Guard Policy to a Layer 2 EtherChannel Interface:

Switch# configure terminal
Switch(config)# ipv6 source-guard policy POL
Switch(config-sisf-sourceguard) # validate address
switch(config-sisf-sourceguard)# exit
Switch(config)# interface Po4
Switch(config)# ipv6 snooping
Switch(config-if)# ipv6 source-guard attach-policy POL
Switch(config-if)# exit
switch(config)#

Examples: How to attach an IPv6 Prefix Guard Policy to a Layer 2 EtherChannel Interface

The following example shows how to attach an IPv6 Prefix Guard Policy to a Layer 2 EtherChannel Interface:

Switch# configure terminal
Switch(config)# ipv6 source-guard policy POL
Switch (config-sisf-sourceguard)# no validate address
Switch((config-sisf-sourceguard)# validate prefix
Switch(config)# interface Po4
Switch(config-if)# ipv6 snooping
Switch(config-if)# ipv6 source-guard attach-policy POL

Chapter 19. Configuring SISF-Based Device Tracking

- Information About SISF-Based Device Tracking

- How to Configure SISF-Based Device Tracking

- Configuration Examples for SISF-Based Device Tracking

- Feature History and Information for SISF-Based Device Tracking

Information About SISF-Based Device Tracking

- Overview of SISF-Based Device Tracking

- Options to Enable SISF-Based Device Tracking

- Migrating from Legacy Commands to SISF-Based Device-Tracking Commands

Overview of SISF-Based Device Tracking

The Switch Integrated Security Features based (SISF-based) device tracking feature is part of the suite of first-hop security features.

The main role of the feature is to track the presence, location, and movement of end-nodes in the network. SISF snoops traffic received by the switch, extracts device identity (MAC and IP address), and stores them in a binding table. Many features, such as, IEEE 802.1X, web authentication, Cisco TrustSec and LISP etc., depend on the accuracy of this information to operate properly.

SISF-based device tracking supports both IPv4 and IPv6.

Even with the introduction of SISF-based device tracking, the legacy device tracking CLI (IP Device Tracking (IPDT) and IPv6 Snooping CLI) continues to be available. When you bootup the switch, the set of commands that is available depends on existing configuration, and only one of the following is available:

- SISF-based device tracking CLI, or

- IPDT and IPv6 Snooping CLI

Note

The IPDT and IPv6 Snooping commands are deprecated, but continue to be available. We recommend that you upgrade to SISF-based device tracking.

If you are using the IPDT and IPv6 Snooping CLI and want to migrate to SISF-based device tracking, see Migrating from legacy IPDT and IPv6 Snooping to SISF-Based Device Tracking, for more information.

SISF-based device tracking can be enabled manually (by using device-tracking commands), or programmatically (which is the case when providing device tracking services to other features).

Options to Enable SISF-Based Device Tracking

SISF-Based device tracking is disabled by default.

You can enable it by defining a device tracking policy and attaching the policy to a specific target.

Note

The target could be an interface or a VLAN.

Manually Enabling SISF-Based Device Tracking

- Option 1: Apply the default device tracking policy to a target.

Enter the device-tracking command in the interface configuration mode or in the VLAN configuration mode. The system then attaches the default policy it to the interface or VLAN.

Note

The default policy is a built-in policy with default settings; you cannot change any of the attributes of the default policy. In order to be able to configure device tracking policy attributes you must create a custom policy. See Option 2: Create a custom policy with custom settings.

- Option 2: Create a custom policy with custom settings.

Enter the device-tracking policy command in global configuration mode and enter a custom policy name. The system creates a policy with the name you specify. You can then configure the available settings, in the device tracking configuration mode (config-device-tracking), and attach the policy to a specified target.

Programmatically Enabling SISF-Based Device Tracking

Some features rely on device tracking and utilize the trusted database of binding entries that SISF-based device tracking builds and maintains. These features, also called device tracking clients, enable device tracking programmatically (create and attach the device tracking policy).

Note

The exceptions here are IEEE 802.1X, web authentication, Cisco TrustSec, and IP Source Guard (IPSG) - they also rely on device tracking, but they do not enable it. For these device tracking clients, you must enter the ip dhcp snooping vlan vlan command, to programmatically enable device tracking on a particular target.

Note the following about programmatically enabling SISF-based device tracking:

- A device tracking client requires device tracking to be enabled.

There are several device tracking clients, therefore, multiple programmatic policies could be created. The settings of each policy differ depending on the device tracking client that creates the policy.

- The policy that is created, and its settings, are system-defined.

Configurable policy attributes are available in the device tracking configuration mode (config-device-tracking) and vary from one release to another. If you try to modify an attribute that is not configurable, the configuration change is rejected and an error message is displayed.

For release-specific information about programmatically created policies, see Programmatically Enabling SISF-Based Device Tracking in Cisco IOS XE <release name> <release number> in the required version of the document.

Migrating from Legacy Commands to SISF-Based Device-Tracking Commands

- Migrating from Legacy IPDT and IPv6 Snooping to SISF-Based Device Tracking

- IPDT, IPv6 Snooping, and SISF-Based Device Tracking CLI Compatibility

Migrating from Legacy IPDT and IPv6 Snooping to SISF-Based Device Tracking

Starting with Cisco IOS XE Denali 16.1.1, the existing IPv6 snooping and IP Device Tracking (IPDT) commands have corresponding SISF-based device-tracking commands that allow you to apply your configuration to both IPv4 and IPv6 address families.

After you have upgraded from a Cisco IOS XE 3.x.x release to a Cisco IOS XE 16.x.x release, enter the device-tracking upgrade-cli to convert legacy IPDT and IPv6 Snooping commands to SISF-based device tracking commands. After you run the command, only the new device-tracking commands are available on your device and the legacy commands are not supported.

Based on the legacy configuration that exists on your device, the device-tracking upgrade-cli command upgrades your CLI differently. Consider the following configuration scenarios and the corresponding migration results before you migrate your existing configuration.

Note

You cannot configure a mix of the old IPDT and IPv6 snooping CLI with the new SISF-based device-tracking CLI.

Only IPDT Configuration Exists

If your device has only IPDT configuration, running the device-tracking upgrade-cli command converts the configuration to use the new SISF policy that is created and attached to the interface. You can then update this SISF policy.

If you continue to use the legacy commands, this restricts you to operate in a legacy mode where only the legacy IPDT and IPv6 snooping commands are available on the device.

Only IPv6 Snooping Configuration Exists

On a device with existing IPv6 snooping configuration, the old IPv6 Snooping commands are available for further configuration. The following options are available:

- (Recommended) Use the device-tracking upgrade-cli command to convert all your legacy configuration to the new SISF-based device tracking commands. After conversion, only the new device tracking commands will work on your device.

- Use the legacy IPv6 Snooping commands for your future configuration and do not run the device-tracking upgrade-cli command. With this option, only the legacy IPv6 Snooping commands are available on your device, and you cannot use the new SISF-based device tracking CLI commands.

Both IPDT and IPv6 Snooping Configuration Exist

On a device that has both legacy IPDT configuration and IPv6 snooping configuration, you can convert legacy commands to the SISF-based device tracking CLI commands. However, note that only one snooping policy can be attached to an interface, and the IPv6 snooping policy parameters override the IPDT settings.

Note

If you do not migrate to the new SISF-based commands and continue to use the legacy IPv6 snooping or IPDT commands, your IPv4 device tracking configuration information may be displayed in the IPv6 snooping commands, as the SISF-based device tracking feature handles both IPv4 and IPv6 configuration. To avoid this, we recommend that you convert your legacy configuration to SISF-based device tracking commands.

No IPDT or IPv6 Snooping Configuration Exists

If your device has no legacy IP Device Tracking or IPv6 Snooping configurations, you can use only the new SISF-based device tracking commands for all your future configuration. The legacy IPDT commands and IPv6 snooping commands are not available.

Note

Starting from Cisco IOS XE Denali 16.3.1, the ip dhcp snooping vlan vlan command creates a device tracking policy programmatically, to support the IEEE 802.1X, web authentication, Cisco TrustSec and IPSG features. The programmatically created policy tracks both IPv4 and IPv6 clients. Ensure that this command is configured, if you are using any of the aforementioned features.

IPDT, IPv6 Snooping, and SISF-Based Device Tracking CLI Compatibility

Table Table 1 displays legacy IPDT and then the IPv6 snooping commands they are converted to - if the device-tracking upgrade-cli command (global configuration mode) is NOT executed.

Table Table 2 displays legacy IPDT and then the SISF-based device-tracking commands that the system converts them to, if you have executed the device-tracking upgrade-cli command.

IPDT → IPv6 Snooping Commands

Legacy IP Device Tracking (IPDT)

IPv6 Snooping Command

(Starting from Cisco IOS XE Denali 16.3.7 and all later Cisco IOS XE 16.x.x releases).

ip device tracking probe count

Set to the default value, and cannot be changed.

ip device tracking probe delay

Set to the default value, and cannot be changed[1].

ip device tracking probe interval

ipv6 neighbor binding reachable-lifetime [2]

ip device tracking probe use-svi

Set to the default behavior, and cannot be changed.

ip device tracking probe auto-source [ fallback host-ip-address subnet-mask] [ override]

ipv6 neighbor tracking auto-source[ fallback host-ip-address subnet-mask] [ override]

ip device tracking trace-buffer

Not supported

ip device tracking maximum n

ipv6 snooping policy IPDT_MAX_n[ limit address-count]

ip device tracking maximum 0

Not supported

clear ip device tracking all

Not supported

[1] Until Cisco IOS XE Denali 16.3.6 and in Cisco IOS XE Everest 16.5.1a, the system incorrectly converts the ip device tracking probe delay command to ipv6 neighbor binding reachable-lifetime . Starting from Cisco IOS XE Denali 16.3.7 (except in Cisco IOS XE Everest 16.5.x), this is set to the default value and cannot be changed.

[2] Until Cisco IOS XE Denali 16.3.6 and in Cisco IOS XE Everest 16.5.1a, the system incorrectly converts the ip device tracking probe interval command to ipv6 snooping tracking retry-interval . Starting from Cisco IOS XE Denali 16.3.7 (except in Cisco IOS XE Everest 16.5.x), this is correctly converted to ipv6 neighbor binding reachable-lifetime .

IPDT → SISF Commands

Legacy IP Device Tracking (IPDT)

SISF-Based Device-Tracking After SISF Conversion

(Starting from Cisco IOS XE Denali 16.3.7 and all later Cisco IOS XE 16.x.x releases).

ip device tracking probe count

Set to the default value, and cannot be changed.

ip device tracking probe delay

Set to the default value, and cannot be changed[3].

ip device tracking probe interval

device-tracking binding reachable-lifetime [4]

ip device tracking probe use-svi

Set to the default behaviour and cannot be changed.

ip device tracking probe auto-source[ fallback host-ip-address subnet-mask] [ override]

device-tracking tracking auto-source[ fallback host-ip-address subnet-mask] [ override]

ip device tracking trace-buffer

Not supported.

ip device tracking maximum n

device-tracking snooping policy IPDT_MAX_n[ limit address-count]

ip device tracking maximum 0

Not supported.

clear ip device tracking all

Not supported.

[3] Until Cisco IOS XE Denali 16.3.6 and in Cisco IOS XE Everest 16.5.1a, the system incorrectly converts the ip device tracking probe delay command to device-tracking binding reachable-lifetime . Starting from Cisco IOS XE Denali 16.3.7 (except in Cisco IOS XE Everest 16.5.x), this is set to the default value, and cannot be changed.

[4] Until Cisco IOS XE Denali 16.3.6 and in Cisco IOS XE Everest 16.5.1a, the system incorrectly converts the ip device tracking probe interval command to device-tracking tracking retry-interval . Starting from Cisco IOS XE Denali 16.3.7 (except in Cisco IOS XE Everest 16.5.1a), this is correctly converted to device-tracking binding reachable-lifetime .

How to Configure SISF-Based Device Tracking

- Manually Enabling SISF-Based Device Tracking

- Programmatically Enabling SISF-Based Device Tracking in Cisco IOS XE Fuji 16.9.x and Later Releases

- Configuring a Multi-Switch Network to Stop Creating Binding Entries from a Trunk Port

Manually Enabling SISF-Based Device Tracking

- Applying the Default Device Tracking Policy to a Target

- Creating a Custom Device Tracking Policy with Custom Settings

- Attaching a Device Tracking Policy to an Interface

- Attaching a Device Tracking Policy to a VLAN

Applying the Default Device Tracking Policy to a Target

Beginning in privileged EXEC mode, follow these steps to apply the default device tracking policy to an interface or VLAN:

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters the global configuration mode.

Step 2

Specify an interface or a VLAN

- interface interface

- vlan configuration vlan_list

Example:

Device(config)# interface gigabitethernet 1/1/4
OR
Device(config)# vlan configuration 333

interface type number —Specifies the interface and enters the interface configuration mode. The device tracking policy will be attached to the specified interface.

vlan configuration vlan_list —Specifies the VLANs and enters the VLAN feature configuration mode. The device tracking policy will be attached to the specified VLAN.

Step 3

device-tracking

Example:

Device(config-if)# device-tracking
OR
Device(config-vlan-config)# device-tracking

Enables SISF-based device tracking and attaches the default policy it to the interface or VLAN.

The default policy is a built-in policy with default settings; none of the attributes of the default policy can be changed.

Step 4

exit

Example:

Device(config-if)# exit
OR
Device(config-vlan-config)# exit

Exits configuration mode.

Step 5

show device-tracking policy policy-name

Example:

Device# show device-tracking policy default

Displays device-tracking policy configuration, and all the targets it is applied to.

Creating a Custom Device Tracking Policy with Custom Settings

Beginning in privileged EXEC mode, follow these steps to create and configure a device tracking policy:

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters the global configuration mode.

Step 2

[no] device-tracking policy policy-name

Example:

Device(config)# device-tracking policy example_policy

Creates the policy and enters the device-tracking configuration mode.

Step 3

[ data-glean | default | destination-glean | device-role | distribution-switch | exit | limit | no | prefix-glean | protocol | security-level | tracking | trusted-port | vpc]

Example:

Device (config-device-tracking)# destination-glean log-only

Enter the question mark (?) at the system prompt to obtain a list of available options in this mode. You can configure the following for both IPv4 and IPv6:

- (Optional) data-glean —Enables learning of addresses from a data packet snooped from a source inside the network and populates the binding table with the data traffic source address. Enter one of these options:

- log-only —Generates a syslog message upon data packet notification

- recovery —Uses a protocol to enable binding table recovery. Enter NDP or DHCP .

- (Optional) default —Sets the policy attribute to its default value. You can set these policy attributes to their default values: data-glean , destination-glean , device-role , limit , prefix-glean , protocol , security-level , tracking , trusted-port .

- (Optional) destination-glean —Populates the binding table by gleaning data traffic destination address. Enter one of these options:

- log-only —Generates a syslog message upon data packet notification

- recovery —Uses a protocol to enable binding table recovery. Enter DHCP .

- (Optional) device-role —Sets the role of the device attached to the port. It can be a node or a switch. Enter one of these options:

- node —Configures the attached device as a node. This is the default option.

- switch —Configures the attached device as a switch.

- (Optional) distribution-switch —Although visible on the CLI, this option is not supported. Any configuration settings you make will not take effect.

- exit —Exits the device-tracking policy configuration mode.

- limit address-count —Specifies an address count limit per port. The range is 1 to 32000.

- no —Negates the command or sets it to defaults.

- (Optional) prefix-glean —Enables learning of prefixes from either IPv6 Router Advertisements or from DHCP-PD. You have the following option:

- (Optional) only —Gleans only prefixes and not host addresses.

- (Optional) protocol —Sets the protocol to glean; by default, all are gleaned. Enter one of these options:

- arp [ prefix-list name] —Gleans addresses in ARP packets. Optionally, enter the name of prefix-list that is to be matched.

- dhcp4 [ prefix-list name] —Glean addresses in DHCPv4 packets. Optionally, enter the name of prefix-list that is to be matched.

- dhcp6 [ prefix-list name] —Glean addresses in DHCPv6 packets. Optionally, enter the name of prefix-list that is to be matched.

- ndp [ prefix-list name] —Glean addresses in NDP packets. Optionally, enter the name of prefix-list that is to be matched.

- udp [ prefix-list name] —Although visible on the CLI, this option is not supported. Any configuration settings you make will not take effect.

- (Optional) security-level —Specifies the level of security enforced by the feature. Enter one of these options:

- glean —Gleans addresses passively.

- guard —Inspects and drops un-authorized messages. This is the default.

- inspect —Gleans and validates messages.

- (Optional) tracking —Specfies a tracking option. Enter one of these options:

- disable [ stale-lifetime [ 1-86400-seconds| infinite] ] —Turns of device-tracking.

Optionally, you can enter the duration for which the entry is kept inactive before deletion, or keep it permanently inactive.

- enable [ reachable-lifetime [ 1-86400-seconds| infinite] ] —Turns on device-tracking.

Optionally, you can enter the duration for which the entry is kept reachable, or keep it permanently reachable.

- (Optional) trusted-port —Sets up a trusted port. Disables the guard on applicable targets. Bindings learned through a trusted port have preference over bindings learned through any other port. A trusted port is given preference in case of a collision while making an entry in the table.

- (Optional) vpc —Although visible on the CLI, this option is not supported. Any configuration settings you make will not take effect.

Step 4

end

Example:

Device(config-device-tracking)# exit

Exits configuration mode.

Step 5

show device-tracking policy policy-name

Example:

Device# show device-tracking policy example_policy

Displays the device-tracking policy configuration.

What to do next

Attach the policy to an interface or VLAN.

Attaching a Device Tracking Policy to an Interface

Beginning in privileged EXEC mode, follow these steps to attach a device tracking policy to an interface:

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters the global configuration mode.

Step 2

interface interface

Example:

Device(config)# interface gigabitethernet 1/1/4

Specifies an interface and enters the interface configuration mode.

Step 3

[ no] device-tracking attach-policy policy name

Example:

Device(config-if)# device-tracking attach-policy example_policy

Attaches the device tracking policy to the interface.

Note

SISF based device-tracking policies can be disabled only if they are custom policies. Programmatically created policies can be removed only if the corresponding device-tracking client feature configuration is removed.

Step 4

end

Example:

Device# end

Returns to the privileged EXEC mode.

Step 5

show device-tracking policies[ interface interface]

Example:

Device# show device-tracking policies interface gigabitethernet 1/1/4

Displays policies that match the specified interface type and number.

Attaching a Device Tracking Policy to a VLAN

Beginning in privileged EXEC mode, follow these steps to attach a device-tracking policy to VLANs across multiple interfaces:

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters the global configuration mode.

Step 2

vlan configuration vlan_list

Example:

Device(config)# vlan configuration 333

Specifies the VLANs to which the device tracking policy will be attached; enters the VLAN interface configuration mode.

Step 3

[ no] device-tracking attach-policy policy_name

Example:

Device(config-vlan-config)# device-tracking attach-policy example_policy

Attaches the device tracking policy to the specified VLANs across all switch interfaces.

Note

SISF based device-tracking policies can be disabled only if they are custom policies. Programmatically created policies can be removed only if the corresponding device-tracking client feature configuration is removed.

Step 4

do show device-tracking policies vlan vlan-ID

Example:

Device(config-vlan-config)# do show device-tracking policies vlan 333

Verifies that the policy is attached to the specified VLAN, without exiting the VLAN interface configuration mode.

Programmatically Enabling SISF-Based Device Tracking in Cisco IOS XE Fuji 16.9.x and Later Releases

Programmatically Enabling SISF-Based Device Tracking in Cisco IOS XE Fuji 16.9.x and Later Releases

Device tracking client features that can enable SISF-based device tracking

Starting with Cisco IOS XE Fuji 16.9.x and all later releases, you can programmatically enable SISF-based device tracking for these features:

- IEEE 802.1X, web authentication, Cisco TrustSec, and IPSG features: enter the ip dhcp snooping vlan vlan command.

- Cisco Locator/ID Separation Protocol.

- EVPN on VLAN

Note

If there is more than one programmatically created policy, the policy with the highest priority is effective.

Policy Name

- The IEEE 802.1X, web authentication, Cisco TrustSec, and IPSG features use policy DT-PROGRAMMATIC.

- The LISP feature creates LISP-DT-GUARD-VLAN or LISP-DT-GLEAN-VLAN.

- EVPN on VLAN feature creates evpn-sisf-policy

The list of settings differ with each programmatic policy. See the examples for more information.

User Options

- Policy priority is supported. Priority is determined by how the policy is created. A manually created policy has the highest priority. This enables you to apply policy settings that are different from policies that are generated programmatically.

- Multiple policies can be attached to the same VLAN.

- When multiple policies with different priorities are attached to the same VLAN, the settings of the policy with the highest priority are effective. The exceptions here are the limit address-count for IPv4 per mac and limit address-count for IPv6 per mac settings - the settings of the policy with the lowest priorty are effective.

- The policy cannot be removed unless the device tracking client feature configuration is removed.

- The policy attributes cannot be changed.

- You cannot change the address count limit per MAC. This refers to the limit address-count for IPv4 per mac and limit address-count for IPv6 per mac commands.

- In order to change a policy setting on a VLAN, create a customized device-tracking policy and attach it to the VLAN

- When a device-tracking policy is attached to an interface under a VLAN, the policy settings on the interface take precedence over those on its VLAN; exceptions here are the values for limit address-count for IPv4 per mac and limit address-count for IPv6 per mac , which are aggregated from the policy on both the interface and VLAN.

Configuring a Multi-Switch Network to Stop Creating Binding Entries from a Trunk Port

In a multi-switch network, SISF-based device tracking provides the capability to distribute binding table entries between switches running the feature. Binding entries are only created on the switches where the host appears on an access port. No entry is created for a host that appears over a trunk port. This is achieved by configuring a policy with the trusted-port and device-role switch options, and attaching it to the trunk port.

Important

Both, the trusted-port , and device-role switch options, must be configured in the policy.

Further, we recommended that you apply such a policy on a port facing a device, which also has SISF-based device tracking enabled.

Complete the following steps:

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters the global configuration mode.

Step 2

device-tracking policy policy-name

Example:

Device(config)# device-tracking policy example_trusted_policy

Enters the device-tracking policy configuration mode, for the specified policy.

Step 3

device-role switch

Example:

Device(config-device-tracking)# device-role switch

Specifies the role of the device attached to the port. Default is node. Enter the device-role switch option to stop the creation of binding entries for the port.

Step 4

trusted-port

Example:

Device(config-device-tracking)# trusted-port

Sets up a trusted port. Disables the guard on applicable targets. Bindings learned through a trusted port have preference over bindings learned through any other port. A trusted port is given preference in case of a collision while making an entry in the table.

Step 5

end

Example:

Device(config-device-tracking)# end

Exits the device-tracking policy configuration mode and enters the global configuration mode

Step 6

interface interface

Example:

Device(config)# interface gigabitethernet 1/0/25

Specifies an interface and enters the interface configuration mode.

Step 7

device-tracking attach-policy policy-name

Example:

Device(config-if)# device-tracking attach-policy  example_trusted_policy

Attaches a device tracking policy to the interface or the specified VLANs on the interface.

Configuration Examples for SISF-Based Device Tracking

These examples show sample device-tracking configuration and other recommended or related configuration for certain situations.

- Example: Programmatically Enabling SISF-Based Device Tracking in Cisco IOS XE Fuji 16.9.x

- Example: Disabling IPv6 Device Tracking on a Target

- Example: Enabling IPv6 for SVI on VLAN (To Mitigate the Duplicate Address Problem)

- Example: Mitigating the IPv4 Duplicate Address Problem

- Example: Avoiding a Short Device-Tracking Binding Reachable Time

Example: Programmatically Enabling SISF-Based Device Tracking in Cisco IOS XE Fuji 16.9.x

The sample output in the examples show the different settings of programmatically created policies.

Device tracking client: LISP on VLAN

After you configure LISP, enter the show device-tracking policy command in privileged EXEC mode, to display the LISP-DT-GUARD-VLAN policy that is created and the corresponding settings.

Device# show device-tracking policy LISP-DT-GUARD-VLAN
Policy LISP-DT-GUARD-VLAN configuration:
security-level guard (*)
device-role node
gleaning from Neighbor Discovery
gleaning from DHCP
gleaning from ARP
gleaning from DHCP4
NOT gleaning from protocol unkn
limit address-count for IPv4 per mac 4 (*)
limit address-count for IPv6 per mac 12 (*)
tracking enable
Policy LISP-DT-GUARD-VLAN is applied on the following targets:
Target      Type    Policy                    Feature            Target range
vlan 10     VLAN    LISP-DT-GUARD-VLAN        Device-tracking    vlan all
note:
Binding entry Down timer: 10 minutes (*)
Binding entry Stale timer:   30 minutes (*)

Device tracking client: LISP on VLAN

After you configure LISP, enter the show device-tracking policy command in privileged EXEC mode, to display the LISP-DT-GLEAN-VLAN policy that is created and the corresponding settings:

Device# show device-tracking policy LISP-DT-GLEAN-VLAN
Policy LISP-DT-GLEAN-VLAN configuration:
security-level glean (*)
device-role node
gleaning from Neighbor Discovery
gleaning from DHCP
gleaning from ARP
gleaning from DHCP4
NOT gleaning from protocol unkn
limit address-count for IPv4 per mac 4 (*)
limit address-count for IPv6 per mac 12 (*)
tracking enable
Policy LISP-DT-GUARD-VLAN is applied on the following targets:
Target     Type   Policy                  Feature            Target range
vlan 10    VLAN   LISP-DT-GLEAN-VLAN      Device-tracking    vlan all

note:
Binding entry Down timer: 10 minutes (*)
Binding entry Stale timer:   30 minutes (*)

Device tracking client: EVPN on VLAN

After you configure EVPN, enter the show device-tracking policy command in privileged EXEC mode, to display the evpn-sisf-policy policy that is created and the corresponding settings that are made:

Device# show device-tracking policy evpn-sisf-policy
Policy evpn-sisf-policy configuration:
security-level glean (*)
device-role node
gleaning from Neighbor Discovery
gleaning from DHCP
gleaning from ARP
gleaning from DHCP4
NOT gleaning from protocol unkn
tracking enable
Policy evpn-sisf-policy is applied on the following targets:
Target      Type    Policy                   Feature            Target range
vlan 10     VLAN    evpn-sisf-policy         Device-tracking    vlan all
note:
Binding entry Down timer: 24 hours (*)
Binding entry Stale timer:   24 hours (*)

Device tracking clients: IEEE 802.1X, Web Authentication, Cisco TrustSec, IPSG

Configure the ip dhcp snooping vlan vlan command in global configuration mode to enable device-tracking for the IEEE 802.1X, web authentication, Cisco TrustSec, and IPSG features. Enter the show device-tracking policy command in privileged EXEC mode, to display the DT-PROGRMMATIC policy that is created and the corresponding settings that are made:

Device# configure terminal
Device(config)# ip dhcp snooping vlan 10
Device(config)# end
Device# show device-tracking policy DT-PROGRAMMATIC
Policy DT-PROGRAMMATIC configuration:
security-level glean (*)
device-role node
gleaning from Neighbor Discovery
gleaning from DHCP
gleaning from ARP
gleaning from DHCP4
NOT gleaning from protocol unkn
limit address-count for IPv4 per mac 1 (*)
tracking enable
Policy DT-PROGRAMMATIC is applied on the following targets:
Target      Type    Policy               Feature            Target range
vlan 10     VLAN    DT-PROGRAMMATIC      Device-tracking    vlan all

note:
Binding entry Down timer: 24 hours (*)
Binding entry Stale timer:   24 hours (*)

Identifying the Active Policy When Multiple Policies are Applied to a Target

This example shows you how to identify the active policy when multiple policies are attached to the same VLAN.

In this example, two policies are attached to VLAN 10; LISP-DT-GUARD-VLAN is the active policy.

Device# show device-tracking policies
Target               Type  Policy                 Feature        Target range
vlan 10              VLAN  DT-PROGRAMMATIC        Device-tracking vlan all
vlan 10              VLAN  LISP-DT-GUARD-VLAN     Device-tracking vlan all

Device# show device-tracking capture-policy vlan 10
HW Target vlan 10 HW policy signature 0001DF9F policies#:2 rules 14 sig 0001DF9F
SW policy DT-PROGRAMMATIC feature Device-tracking -
SW policy LISP-DT-GUARD-VLAN feature Device-tracking – Active

Example: Disabling IPv6 Device Tracking on a Target

By default, SISF-based device tracking supports both IPv4 and IPv6. The following configuration examples show how you can disable IPv6 device tracking if you have to:

Disabling IPv6 device tracking when the target is attached to a custom policy:

Device(config)# device-tracking policy example-policy
Device(config-device-tracking)# no protocol ndp
Device(config-device-tracking)# no protocol dhcp6
Device(config-device-tracking)# end

Note

In the Cisco IOS XE Denali 16.3.x release, you cannot disable IPv6 device tracking for a programmatically created policy.

Example: Enabling IPv6 for SVI on VLAN (To Mitigate the Duplicate Address Problem)

When IPv6 is enabled in the network and a switched virtual interface (SVI) is configured on a VLAN, we recommend that you add the following to the SVI configuration. This enables the SVI to acquire a link-local address automatically; this address is used as the source IP address of the SISF probe, thus preventing the duplicate IP address issue.

Device(config)# interface vlan 10
Device(config-if)# ipv6 enable
Device(config-if)# end

Example: Mitigating the IPv4 Duplicate Address Problem

This example show how you can tackle the Duplicate IP Address 0.0.0.0 error message problem encountered by clients that run Microsoft Windows:

Configure the device-tracking tracking auto-source command. This command determines the source IP and MAC address used in the Address Resolution Packet (ARP) request sent by the switch to probe a client, in order to maintain its entry in the device-tracking table. The purpose, is to avoid using 0.0.0.0 as source IP address.

Note

Configure the device-tracking tracking auto-source command only when a switch virtual interface (SVI) is not configured. You do not have to configure it when a SVI is configured with an IPv4 address on the VLAN.

Command

Action

(In order to select source IP and MAC address for device tracking ARP probe)

Notes

device-tracking tracking auto-source

- Set source to VLAN SVI if present.

- Look for IP and MAC binding in device-tracking table from same subnet.

- Use 0.0.0.0

We recommend that you disable device-tracking on all trunk ports to avoid MAC flapping.

device-tracking tracking auto-source override

- Set source to VLAN SVI if present

- Use 0.0.0.0

Not recommended when there is no SVI.

device-tracking tracking auto-source fallback 0.0.0.X 255.255.255.0

- Set source to VLAN SVI if present.

- Look for IP and MAC binding in device-tracking table from same subnet.

- Compute source IP from client IP using host bit and mask provided. Source MAC is taken from the MAC address of the switchport facing the client*.

We recommend that you disable device-tracking on all trunk ports to avoid MAC flapping.

The computed IPv4 address must not be assigned to any client or network device.

device-tracking tracking auto-source fallback 0.0.0.X 255.255.255.0 override

- Set source to VLAN SVI if present.

Compute source IP from client IP using host bit and mask provided*. Source MAC is taken from the MAC address of the switchport facing the client*.

* Depending on the client IP address, an IPv4 address has to be reserved for the source IP.

A reserved source IPv4 address = (client-ip and mask) | host-ip

- Client IP = 192.0.2.25

- Source IP = (192.0.2.25 and 255.255.255.0) | (0.0.0.1) = 192.0.2.1

IP address 192.0.2.1 should not be assigned to any client or network device.

Example: Avoiding a Short Device-Tracking Binding Reachable Time

When migrating from an older release, the following configuration may be present:

device-tracking binding reachable-time 10

Remove this by entering the no version of the command.

Feature History and Information for SISF-Based Device Tracking

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Release

Modification

Cisco IOS XE Denali 16.1.1

This feature was introduced.

Cisco IOS XE Denali 16.3.7

Correction in the system conversion of IPv6 snooping commands and SISF-based device-tracking commands.

IPDT → IPv6 Snooping conversion corrections:

- Until Cisco IOS XE Denali 16.3.6, the system incorrectly converts the ip device tracking probe delay command to ipv6 neighbor tracking retry-interval . Starting from Cisco IOS XE Denali 16.3.7, this is set to the default value and cannot be changed.

- Until Cisco IOS XE Denali 16.3.6, the system incorrectly converts the ip device tracking probe interval command to ipv6 neighbor tracking retry-interval . Starting from Cisco IOS XE Denali 16.3.7, this is correctly converted to ipv6 snooping tracking retry-interval

IPDT → SISF conversion corrections:

- Until Cisco IOS XE Denali 16.3.6 the system incorrectly converts the ip device tracking probe delay command to device-tracking binding reachable-lifetime . In the specified releases, you can still use this command, but to only configure the reachable-lifetime of an entry. Starting from Cisco IOS XE Denali 16.3.7, this is set to the default value and cannot be changed.

- Until Cisco IOS XE Denali 16.3.6, the system incorrectly converts the ip device tracking probe interval command to device-tracking tracking retry-interval . Starting from Cisco IOS XE Denali 16.3.7, this is correctly converted to device-tracking binding reachable-lifetime .

Chapter 20. Configuring IEEE 802.1x Port-Based Authentication

This chapter describes how to configure IEEE 802.1x port-based authentication. IEEE 802.1x authentication prevents unauthorized devices (clients) from gaining access to the network. Unless otherwise noted, the term switch refers to a standalone switch or a switch stack.

- Information About 802.1x Port-Based Authentication

- Monitoring 802.1x Statistics and Status

Information About 802.1x Port-Based Authentication

The 802.1x standard defines a client-server-based access control and authentication protocol that prevents unauthorized clients from connecting to a LAN through publicly accessible ports unless they are properly authenticated. The authentication server authenticates each client connected to a switch port before making available any services offered by the switch or the LAN.

Note

TACACS is not supported with 802.1x authentication.

Until the client is authenticated, 802.1x access control allows only Extensible Authentication Protocol over LAN (EAPOL), Cisco Discovery Protocol (CDP), and Spanning Tree Protocol (STP) traffic through the port to which the client is connected. After authentication is successful, normal traffic can pass through the port.

The table shown below lists the maximum number of each client session supported on Catalyst 3850 and Catalyst 3650 switches:

Client session

Maximum sessions supported

Maximum dot1x or MAB client sessions

2000

Maximum web-based authentication sessions

2000

Maximum dot1x sessions with critical-auth VLAN enabled and server re-initialized

2000

Maximum MAB sessions with various session features applied

2000

Maximum dot1x sessions with service templates or session features applied

2000

- Port-Based Authentication Process

- Port-Based Authentication Initiation and Message Exchange

- Authentication Manager for Port-Based Authentication

- Ports in Authorized and Unauthorized States

- Port-Based Authentication and Switch Stacks

- 802.1x Host Mode

- 802.1x Multiple Authentication Mode

- MAC Move

- MAC Replace

- 802.1x Accounting

- 802.1x Accounting Attribute-Value Pairs

- 802.1x Readiness Check

- Switch-to-RADIUS-Server Communication

- 802.1x Authentication with VLAN Assignment

- 802.1x Authentication with Per-User ACLs

- 802.1x Authentication with Downloadable ACLs and Redirect URLs

- VLAN ID-Based MAC Authentication

- 802.1x Authentication with Guest VLAN

- 802.1x Authentication with Restricted VLAN

- 802.1x Authentication with Inaccessible Authentication Bypass

- 802.1x Critical Voice VLAN

- 802.1x User Distribution

- IEEE 802.1x Authentication with Voice VLAN Ports

- IEEE 802.1x Authentication with Port Security

- IEEE 802.1x Authentication with Wake-on-LAN

- IEEE 802.1x Authentication with MAC Authentication Bypass

- Network Admission Control Layer 2 IEEE 802.1x Validation

- Flexible Authentication Ordering

- Open1x Authentication

- Multidomain Authentication

- 802.1x Supplicant and Authenticator Switches with Network Edge Access Topology (NEAT)

- Voice Aware 802.1x Security

- Common Session ID

Port-Based Authentication Process

To configure IEEE 802.1X port-based authentication, you must enable authentication, authorization, and accounting (AAA) and specify the authentication method list. A method list describes the sequence and authentication method to be queried to authenticate a user.

The AAA process begins with authentication. When 802.1x port-based authentication is enabled and the client supports 802.1x-compliant client software, these events occur:

- If the client identity is valid and the 802.1x authentication succeeds, the switch grants the client access to the network.

- If 802.1x authentication times out while waiting for an EAPOL message exchange and MAC authentication bypass is enabled, the switch can use the client MAC address for authorization. If the client MAC address is valid and the authorization succeeds, the switch grants the client access to the network. If the client MAC address is invalid and the authorization fails, the switch assigns the client to a guest VLAN that provides limited services if a guest VLAN is configured.

- If the switch gets an invalid identity from an 802.1x-capable client and a restricted VLAN is specified, the switch can assign the client to a restricted VLAN that provides limited services.

- If the RADIUS authentication server is unavailable (down) and inaccessible authentication bypass is enabled, the switch grants the client access to the network by putting the port in the critical-authentication state in the RADIUS-configured or the user-specified access VLAN.

Note

Inaccessible authentication bypass is also referred to as critical authentication or the AAA fail policy.

If Multi Domain Authentication (MDA) is enabled on a port, this flow can be used with some exceptions that are applicable to voice authorization.

Authentication Flowchart

The switch re-authenticates a client when one of these situations occurs:

- Periodic re-authentication is enabled, and the re-authentication timer expires.

You can configure the re-authentication timer to use a switch-specific value or to be based on values from the RADIUS server.

After 802.1x authentication using a RADIUS server is configured, the switch uses timers based on the Session-Timeout RADIUS attribute (Attribute[27]) and the Termination-Action RADIUS attribute (Attribute [29]).

The Session-Timeout RADIUS attribute (Attribute[27]) specifies the time after which re-authentication occurs. The range is 1 to 65535 seconds.

The Termination-Action RADIUS attribute (Attribute [29]) specifies the action to take during re-authentication. The actions are Initialize and ReAuthenticate. When the Initialize action is set (the attribute value is DEFAULT), the 802.1x session ends, and connectivity is lost during re-authentication. When the ReAuthenticate action is set (the attribute value is RADIUS-Request), the session is not affected during re-authentication.

- You manually re-authenticate the client by entering the dot1x re-authenticate interface interface-id privileged EXEC command.

Port-Based Authentication Initiation and Message Exchange

During 802.1x authentication, the switch or the client can initiate authentication. If you enable authentication on a port by using the authentication port-control auto interface configuration command, the switch initiates authentication when the link state changes from down to up or periodically as long as the port remains up and unauthenticated. The switch sends an EAP-request/identity frame to the client to request its identity. Upon receipt of the frame, the client responds with an EAP-response/identity frame.

However, if during bootup, the client does not receive an EAP-request/identity frame from the switch, the client can initiate authentication by sending an EAPOL-start frame, which prompts the switch to request the client’s identity.

Note

If 802.1x authentication is not enabled or supported on the network access device, any EAPOL frames from the client are dropped. If the client does not receive an EAP-request/identity frame after three attempts to start authentication, the client sends frames as if the port is in the authorized state. A port in the authorized state effectively means that the client has been successfully authenticated.

When the client supplies its identity, the switch begins its role as the intermediary, passing EAP frames between the client and the authentication server until authentication succeeds or fails. If the authentication succeeds, the switch port becomes authorized. If the authentication fails, authentication can be retried, the port might be assigned to a VLAN that provides limited services, or network access is not granted.

The specific exchange of EAP frames depends on the authentication method being used.

Message Exchange

If 802.1x authentication times out while waiting for an EAPOL message exchange and MAC authentication bypass is enabled, the switch can authorize the client when the switch detects an Ethernet packet from the client. The switch uses the MAC address of the client as its identity and includes this information in the RADIUS-access/request frame that is sent to the RADIUS server. After the server sends the switch the RADIUS-access/accept frame (authorization is successful), the port becomes authorized. If authorization fails and a guest VLAN is specified, the switch assigns the port to the guest VLAN. If the switch detects an EAPOL packet while waiting for an Ethernet packet, the switch stops the MAC authentication bypass process and starts 802.1x authentication.

Message Exchange During MAC Authentication Bypass

Authentication Manager for Port-Based Authentication

- Port-Based Authentication Methods

- Per-User ACLs and Filter-Ids

- Port-Based Authentication Manager CLI Commands

Port-Based Authentication Methods

802.1x Features

Authentication method

Mode

Single host

Multiple host

MDA

Multiple Authentication

802.1x

VLAN assignment

Per-user ACL

Filter-ID attribute

Downloadable ACL

Redirect URL

VLAN assignment

VLAN assignment

Per-user ACL

Filter-Id attribute

Downloadable ACL

Redirect URL

VLAN assignment

Per-user ACL

Filter-Id attribute

Downloadable ACL

Redirect URL

MAC authentication bypass

VLAN assignment

Per-user ACL

Filter-ID attribute

Downloadable ACL

Redirect URL

VLAN assignment

VLAN assignment

Per-user ACL

Filter-Id attribute

Downloadable ACL

Redirect URL

VLAN assignment

Per-user ACL

Filter-Id attribute

Downloadable ACL

Redirect URL

Standalone web authentication

Proxy ACL, Filter-Id attribute, downloadable ACL

NAC Layer 2 IP validation

Filter-Id attribute

Downloadable ACL

Redirect URL

Filter-Id attribute

Downloadable ACL

Redirect URL

Filter-Id attribute

Downloadable ACL

Redirect URL

Filter-Id attribute

Downloadable ACL

Redirect URL

Web authentication as fallback method

Proxy ACL

Filter-Id attribute

Downloadable ACL

Proxy ACL

Filter-Id attribute

Downloadable ACL

Proxy ACL

Filter-Id attribute

Downloadable ACL

Proxy ACL

Filter-Id attribute

Downloadable ACL

1 Supported in Cisco IOS Release 12.2(50)SE and later.

2 For clients that do not support 802.1x authentication.

Per-User ACLs and Filter-Ids

Note

Using role-based ACLs as Filter-Id is not recommended.

More than one host can be authenticated on MDA-enabled and multiauth ports. The ACL policy applied for one host does not effect the traffic of another host. If only one host is authenticated on a multi-host port, and the other hosts gain network access without authentication, the ACL policy for the first host can be applied to the other connected hosts by specifying any in the source address.

Port-Based Authentication Manager CLI Commands

The authentication-manager interface-configuration commands control all the authentication methods, such as 802.1x, MAC authentication bypass, and web authentication. The authentication manager commands determine the priority and order of authentication methods applied to a connected host.

The authentication manager commands control generic authentication features, such as host-mode, violation mode, and the authentication timer. Generic authentication commands include the authentication host-mode , authentication violation , and authentication timer interface configuration commands.

802.1x-specific commands begin with the dot1x keyword. For example, the authentication port-control auto interface configuration command enables authentication on an interface.

To disable dot1x on a switch, remove the configuration globally by using the no dot1x system-auth-control , and also remove it from all configured interfaces.

Note

If 802.1x authentication is globally disabled, other authentication methods are still enabled on that port, such as web authentication.

The authentication manager commands provide the same functionality as earlier 802.1x commands.

When filtering out verbose system messages generated by the authentication manager, the filtered content typically relates to authentication success. You can also filter verbose messages for 802.1x authentication and MAB authentication. There is a separate command for each authentication method:

- The no authentication logging verbose global configuration command filters verbose messages from the authentication manager.

- The no dot1x logging verbose global configuration command filters 802.1x authentication verbose messages.

- The no mab logging verbose global configuration command filters MAC authentication bypass (MAB) verbose messages

Authentication Manager Commands and Earlier 802.1x Commands

The authentication manager commands in Cisco IOS Release 12.2(50)SE or later

The equivalent 802.1x commands in Cisco IOS Release 12.2(46)SE and earlier

Description

authentication control-direction {both | in}

dot1x control-direction {both | in}

Enable 802.1x authentication with the wake-on-LAN (WoL) feature, and configure the port control as unidirectional or bidirectional.

authentication event

dot1x auth-fail vlan

dot1x critical (interface configuration)

dot1x guest-vlan6

Enable the restricted VLAN on a port.

Enable the inaccessible-authentication-bypass feature.

Specify an active VLAN as an 802.1x guest VLAN.

authentication fallback fallback-profile

dot1x fallback fallback-profile

Configure a port to use web authentication as a fallback method for clients that do not support 802.1x authentication.

authentication host-mode [multi-auth | multi-domain | multi-host | single-host]

dot1x host-mode {single-host | multi-host | multi-domain}

Allow a single host (client) or multiple hosts on an 802.1x-authorized port.

authentication order

mab

Provides the flexibility to define the order of authentication methods to be used.

authentication periodic

dot1x reauthentication

Enable periodic re-authentication of the client.

authentication port-control {auto | force-authorized | force-un authorized}

dot1x port-control {auto | force-authorized | force-unauthorized}

Enable manual control of the authorization state of the port.

authentication timer

dot1x timeout

Set the 802.1x timers.

authentication violation {protect | restrict | shutdown}

dot1x violation-mode {shutdown | restrict | protect}

Configure the violation modes that occur when a new device connects to a port or when a new device connects to a port after the maximum number of devices are connected to that port.

Ports in Authorized and Unauthorized States

During 802.1x authentication, depending on the switch port state, the switch can grant a client access to the network. The port starts in the unauthorized state. While in this state, the port that is not configured as a voice VLAN port disallows all ingress and egress traffic except for 802.1x authentication, CDP, and STP packets. When a client is successfully authenticated, the port changes to the authorized state, allowing all traffic for the client to flow normally. If the port is configured as a voice VLAN port, the port allows VoIP traffic and 802.1x protocol packets before the client is successfully authenticated.

Note

CDP bypass is not supported and may cause a port to go into err-disabled state.

If a client that does not support 802.1x authentication connects to an unauthorized 802.1x port, the switch requests the client’s identity. In this situation, the client does not respond to the request, the port remains in the unauthorized 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 standard, the client 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 begins sending frames as if the port is in the authorized state.

You control the port authorization state by using the authentication port-control interface configuration command and these keywords:

- force-authorized —disables 802.1x authentication and causes the port to change to the authorized state without any authentication exchange required. The port sends and receives normal traffic without 802.1x-based authentication of the client. This is the default setting.

- force-unauthorized —causes the port to remain in the unauthorized state, ignoring all attempts by the client to authenticate. The switch cannot provide authentication services to the client through the port.

- auto —enables 802.1x authentication and causes the port to begin in the unauthorized state, allowing only EAPOL frames to be sent and received through the port. The authentication process begins when the link state of the port changes from down to up or when an EAPOL-start frame is received. The switch requests the identity of the client and begins relaying authentication messages between the client and the authentication server. Each client attempting to access the network is uniquely identified by the switch by using the client MAC address.

If the client is successfully authenticated (receives an Accept frame from the authentication server), the port state changes to authorized, and all frames from the authenticated client are allowed through the port. If the authentication fails, the port remains in the unauthorized state, but authentication can be retried. If the authentication server cannot be reached, the switch can resend the request. If no response is received from the server after the specified number of attempts, authentication fails, and network access is not granted.

When a client logs off, it sends an EAPOL-logoff message, causing the switch port to change to the unauthorized state.

If the link state of a port changes from up to down, or if an EAPOL-logoff frame is received, the port returns to the unauthorized state.

Port-Based Authentication and Switch Stacks

If a switch is added to or removed from a switch stack, 802.1x authentication is not affected as long as the IP connectivity between the RADIUS server and the stack remains intact. This statement also applies if the stack's active switch is removed from the switch stack. Note that if the active switch fails, a stack member becomes the new active switch of the stack by using the election process, and the 802.1x authentication process continues as usual.

If IP connectivity to the RADIUS server is interrupted because the switch that was connected to the server is removed or fails, these events occur:

- Ports that are already authenticated and that do not have periodic re-authentication enabled remain in the authenticated state. Communication with the RADIUS server is not required.

- Ports that are already authenticated and that have periodic re-authentication enabled (with the dot1x re-authentication global configuration command) fail the authentication process when the re-authentication occurs. Ports return to the unauthenticated state during the re-authentication process. Communication with the RADIUS server is required.

For an ongoing authentication, the authentication fails immediately because there is no server connectivity.

If the switch that failed comes up and rejoins the switch stack, the authentications might or might not fail depending on the boot-up time and whether the connectivity to the RADIUS server is re-established by the time the authentication is attempted.

To avoid loss of connectivity to the RADIUS server, you should ensure that there is a redundant connection to it. For example, you can have a redundant connection to the stack's active switch and another to a stack member, and if the active switch fails, the switch stack still has connectivity to the RADIUS server.

802.1x Host Mode

You can configure an 802.1x port for single-host or for multiple-hosts mode. In single-host mode, only one client can be connected to the 802.1x-enabled switch port. The switch detects the client by sending an EAPOL frame when the port link state changes to the up state. If a client leaves or is replaced with another client, the switch changes the port link state to down, and the port returns to the unauthorized state.

In multiple-hosts mode, you can attach multiple hosts to a single 802.1x-enabled port. In this mode, only one of the attached clients must be authorized for all clients to be granted network access. If the port becomes unauthorized (re-authentication fails or an EAPOL-logoff message is received), the switch denies network access to all of the attached clients.

The switch supports multidomain authentication (MDA), which allows both a data device and a voice device, such as an IP Phone (Cisco or non-Cisco), to connect to the same switch port.

802.1x Multiple Authentication Mode

Multiple-authentication (multiauth) mode allows multiple authenticated clients on the data VLAN and voice VLAN. Each host is individually authenticated. There is no limit to the number of data or voice device that can be authenticated on a multiauthport.

Note

When a port is in multiple-authentication mode, the authentication-failed VLAN features do not activate.

You can assign a RADIUS-server-supplied VLAN in multi-auth mode, under the following conditions:

- The host is the first host authorized on the port, and the RADIUS server supplies VLAN information

- Subsequent hosts are authorized with a VLAN that matches the operational VLAN.

- A host is authorized on the port with no VLAN assignment, and subsequent hosts either have no VLAN assignment, or their VLAN information matches the operational VLAN.

- The first host authorized on the port has a group VLAN assignment, and subsequent hosts either have no VLAN assignment, or their group VLAN matches the group VLAN on the port. Subsequent hosts must use the same VLAN from the VLAN group as the first host. If a VLAN list is used, all hosts are subject to the conditions specified in the VLAN list.

- After a VLAN is assigned to a host on the port, subsequent hosts must have matching VLAN information or be denied access to the port.

- You cannot configure a guest VLAN or an auth-fail VLAN in multi-auth mode.

- The behavior of the critical-auth VLAN is not changed for multi-auth mode. When a host tries to authenticate and the server is not reachable, all authorized hosts are reinitialized in the configured VLAN.

- Multi-auth Per User VLAN assignment

Multi-auth Per User VLAN assignment

The Multi-auth Per User VLAN assignment feature allows you to create multiple operational access VLANs based on VLANs assigned to the clients on the port that has a single configured access VLAN. The port configured as an access port where the traffic for all the VLANs associated with data domain is not dot1q tagged, and these VLANs are treated as native VLANs.

The number of hosts per multi-auth port is 8, however there can be more hosts.

The following scenarios are associated with the multi-auth Per User VLAN assignments:

Scenario one

When a hub is connected to an access port, and the port is configured with an access VLAN (V0).

The host (H1) is assigned to VLAN (V1) through the hub. The operational VLAN of the port is changed to V1. This behaviour is similar on a single-host or multi-domain-auth port.

When a second host (H2) is connected and gets assigned to VLAN ( V2), the port will have two operational VLANs (V1 and V2). If H1 and H2 sends untagged ingress traffic, H1 traffic is mapped to VLAN (V1) and H2 traffic to VLAN (V2), all egress traffic going out of the port on VLAN (V1) and VLAN (V2) are untagged.

If both the hosts, H1 and H2 are logged out or the sessions are removed due to some reason then VLAN (V1) and VLAN (V2) are removed from the port, and the configured VLAN (V0) is restored on the port.

Scenario two

When a hub is connected to an access port, and the port is configured with an access VLAN (V0). The host (H1) is assigned to VLAN (V1) through the hub. The operational VLAN of the port is changed to V1.

When a second host (H2) is connected and gets authorized without explicit vlan policy, H2 is expected to use the configured VLAN (V0) that is restored on the port. A ll egress traffic going out of two operational VLANs, VLAN (V0) and VLAN (V1) are untagged.

If host (H2 ) is logged out or the session is removed due to some reason then the configured VLAN (V0) is removed from the port, and VLAN (V1) becomes the only operational VLAN on the port.

Scenario three

When a hub is connected to an access port in open mode, and the port is configured with an access VLAN (V0) .

The host (H1) is assigned to VLAN (V1) through the hub. The operational VLAN of the port is changed to V1. When a second host (H2) is connected and remains unauthorized, it still has access to operational VLAN (V1) due to open mode.

If host H1 is logged out or the session is removed due to some reason, VLAN (V1) is removed from the port and host (H2) gets assigned to VLAN (V0).

Note

The combination of Open mode and VLAN assignment has an adverse affect on host (H2) because it has an IP address in the subnet that corresponds to VLAN (V1).

- Limitation in Multi-auth Per User VLAN assignment

Limitation in Multi-auth Per User VLAN assignment

In the Multi-auth Per User VLAN assignment feature, egress traffic from multiple vlans are untagged on a port where the hosts receive traffic that is not meant for them. This can be a problem with broadcast and multicast traffic.

- IPv4 ARPs: Hosts receive ARP packets from other subnets. This is a problem if two subnets in different Virtual Routing and Forwarding (VRF) tables with overlapping IP address range are active on the port. The host ARP cache may get invalid entries.

- IPv6 control packets: In IPv6 deployments, Router Advertisements (RA) are processed by hosts that are not supposed to receive them. When a host from one VLAN receives RA from a different VLAN, the host assign incorrect IPv6 address to itself. Such a host is unable to get access to the network.

The workaround is to enable the IPv6 first hop security so that the broadcast ICMPv6 packets are converted to unicast and sent out from multi-auth enabled ports.. The packet is replicated for each client in multi-auth port belonging to the VLAN and the destination MAC is set to an individual client. Ports having one VLAN, ICMPv6 packets broadcast normally.

- IP multicast: Multicast traffic destined to a multicast group gets replicated for different VLANs if the hosts on those VLANs join the multicast group. When two hosts in different VLANs join a multicast group (on the same mutli-auth port), two copies of each multicast packet are sent out from that port.

MAC Move

When a MAC address is authenticated on one switch port, that address is not allowed on another authentication manager-enabled port of the switch. If the switch detects that same MAC address on another authentication manager-enabled port, the address is not allowed.

There are situations where a MAC address might need to move from one port to another on the same switch. For example, when there is another device (for example a hub or an IP phone) between an authenticated host and a switch port, you might want to disconnect the host from the device and connect it directly to another port on the same switch.

You can globally enable MAC move so the device is reauthenticated on the new port. When a host moves to a second port, the session on the first port is deleted, and the host is reauthenticated on the new port. MAC move is supported on all host modes. (The authenticated host can move to any port on the switch, no matter which host mode is enabled on the that port.) When a MAC address moves from one port to another, the switch terminates the authenticated session on the original port and initiates a new authentication sequence on the new port. The MAC move feature applies to both voice and data hosts.

Note

In open authentication mode, a MAC address is immediately moved from the original port to the new port, with no requirement for authorization on the new port.

MAC Replace

The MAC replace feature can be configured to address the violation that occurs when a host attempts to connect to a port where another host was previously authenticated.

Note

This feature does not apply to ports in multi-auth mode, because violations are not triggered in that mode. It does not apply to ports in multiple host mode, because in that mode, only the first host requires authentication.

If you configure the authentication violation interface configuration command with the replace keyword, the authentication process on a port in multi-domain mode is:

- A new MAC address is received on a port with an existing authenticated MAC address.

- The authentication manager replaces the MAC address of the current data host on the port with the new MAC address.

- The authentication manager initiates the authentication process for the new MAC address.

- If the authentication manager determines that the new host is a voice host, the original voice host is removed.

If a port is in open authentication mode, any new MAC address is immediately added to the MAC address table.

802.1x Accounting

The 802.1x standard defines how users are authorized and authenticated for network access but does not keep track of network usage. 802.1x accounting is disabled by default. You can enable 802.1x accounting to monitor this activity on 802.1x-enabled ports:

- User successfully authenticates.

- User logs off.

- Link-down occurs.

- Re-authentication successfully occurs.

- Re-authentication fails.

The switch does not log 802.1x accounting information. Instead, it sends this information to the RADIUS server, which must be configured to log accounting messages.

802.1x Accounting Attribute-Value Pairs

The information sent to the RADIUS server is represented in the form of Attribute-Value (AV) pairs. These AV pairs provide data for different applications. (For example, a billing application might require information that is in the Acct-Input-Octets or the Acct-Output-Octets attributes of a RADIUS packet.)

AV pairs are automatically sent by a switch that is configured for 802.1x accounting. Three types of RADIUS accounting packets are sent by a switch:

- START–sent when a new user session starts

- INTERIM–sent during an existing session for updates

- STOP–sent when a session terminates

Note

To view debug logs for RADIUS and AAA, use the show platform software trace message smd command. For more information, see the Tracing Commands section in Command Reference Guide, Cisco IOS XE Denali 16.1.1.

This table lists the AV pairs and when they are sent are sent by the switch.

Accounting AV Pairs

Attribute Number

AV Pair Name

START

INTERIM

STOP

Attribute[1]

User-Name

Always

Always

Always

Attribute[4]

NAS-IP-Address

Always

Always

Always

Attribute[5]

NAS-Port

Always

Always

Always

Attribute[8]

Framed-IP-Address

Never

Sometimes[1]

Sometimes

Attribute[30]

Called-Station-ID

Always

Always

Always

Attribute[31]

Calling-Station-ID

Always

Always

Always

Attribute[40]

Acct-Status-Type

Always

Always

Always

Attribute[41]

Acct-Delay-Time

Always

Always

Always

Attribute[42]

Acct-Input-Octets

Never

Always

Always

Attribute[43]

Acct-Output-Octets

Never

Always

Always

Attribute[47]

Acct-Input-Packets

Never

Always

Always

Attribute[48]

Acct-Output-Packets

Never

Always

Always

Attribute[44]

Acct-Session-ID

Always

Always

Always

Attribute[45]

Acct-Authentic

Always

Always

Always

Attribute[46]

Acct-Session-Time

Never

Always

Always

Attribute[49]

Acct-Terminate-Cause

Never

Never

Always

Attribute[61]

NAS-Port-Type

Always

Always

Always

[1] The Framed-IP-Address AV pair is sent when a valid static IP address is configured or w when a Dynamic Host Control Protocol (DHCP) binding exists for the host in the DHCP snooping bindings table.

802.1x Readiness Check

The 802.1x readiness check monitors 802.1x activity on all the switch ports and displays information about the devices connected to the ports that support 802.1x. You can use this feature to determine if the devices connected to the switch ports are 802.1x-capable. You use an alternate authentication such as MAC authentication bypass or web authentication for the devices that do not support 802.1x functionality.

This feature only works if the supplicant on the client supports a query with the NOTIFY EAP notification packet. The client must respond within the 802.1x timeout value.

Switch-to-RADIUS-Server Communication

RADIUS security servers are identified by their hostname or IP address, hostname and specific UDP port numbers, or IP address and specific UDP port numbers. The combination of the IP address and UDP port number creates a unique identifier, which enables RADIUS requests to be sent to multiple UDP ports on a server at the same IP address. If two different host entries on the same RADIUS server are configured for the same service—for example, authentication—the second host entry configured acts as the fail-over backup to the first one. The RADIUS host entries are tried in the order that they were configured.

802.1x Authentication with VLAN Assignment

The switch supports 802.1x authentication with VLAN assignment. After successful 802.1x authentication of a port, the RADIUS server sends the VLAN assignment to configure the switch port. The RADIUS server database maintains the username-to-VLAN mappings, assigning the VLAN based on the username of the client connected to the switch port. You can use this feature to limit network access for certain users.

Voice device authentication is supported with multidomain host mode in Cisco IOS Release 12.2(37)SE. In Cisco IOS Release 12.2(40)SE and later, when a voice device is authorized and the RADIUS server returned an authorized VLAN, the voice VLAN on the port is configured to send and receive packets on the assigned voice VLAN. Voice VLAN assignment behaves the same as data VLAN assignment on multidomain authentication (MDA)-enabled ports.

When configured on the switch and the RADIUS server, 802.1x authentication with VLAN assignment has these characteristics:

- If no VLAN is supplied by the RADIUS server or if 802.1x authentication is disabled, the port is configured in its access VLAN after successful authentication. Recall that an access VLAN is a VLAN assigned to an access port. All packets sent from or received on this port belong to this VLAN.

- If 802.1x authentication is enabled but the VLAN information from the RADIUS server is not valid, authorization fails and configured VLAN remains in use. This prevents ports from appearing unexpectedly in an inappropriate VLAN because of a configuration error.

Configuration errors could include specifying a VLAN for a routed port, a malformed VLAN ID, a nonexistent or internal (routed port) VLAN ID, an RSPAN VLAN, a shut down or suspended VLAN. In the case of a multidomain host port, configuration errors can also be due to an attempted assignment of a data VLAN that matches the configured or assigned voice VLAN ID (or the reverse).

- If 802.1x authentication is enabled and all information from the RADIUS server is valid, the authorized device is placed in the specified VLAN after authentication.

- If the multiple-hosts mode is enabled on an 802.1x port, all hosts are placed in the same VLAN (specified by the RADIUS server) as the first authenticated host.

- Enabling port security does not impact the RADIUS server-assigned VLAN behavior.

- If 802.1x authentication is disabled on the port, it is returned to the configured access VLAN and configured voice VLAN.

- If an 802.1x port is authenticated and put in the RADIUS server-assigned VLAN, any change to the port access VLAN configuration does not take effect. In the case of a multidomain host, the same applies to voice devices when the port is fully authorized with these exceptions:

- If the VLAN configuration change of one device results in matching the other device configured or assigned VLAN, then authorization of all devices on the port is terminated and multidomain host mode is disabled until a valid configuration is restored where data and voice device configured VLANs no longer match.

- If a voice device is authorized and is using a downloaded voice VLAN, the removal of the voice VLAN configuration, or modifying the configuration value to dot1p or untagged results in voice device un-authorization and the disablement of multi-domain host mode.

When the port is in the force authorized, force unauthorized, unauthorized, or shutdown state, it is put into the configured access VLAN.

If an 802.1x port is authenticated and put in the RADIUS server-assigned VLAN, any change to the port access VLAN configuration does not take effect. In the case of a multidomain host, the same applies to voice devices when the port is fully authorized with these exceptions:

- If the VLAN configuration change of one device results in matching the other device configured or assigned VLAN, authorization of all devices on the port is terminated and multidomain host mode is disabled until a valid configuration is restored where data and voice device configured VLANs no longer match.

- If a voice device is authorized and is using a downloaded voice VLAN, the removal of the voice VLAN configuration, or modifying the configuration value to dot1p or untagged results in voice device un-authorization and the disablement of multi-domain host mode.

When the port is in the force authorized, force unauthorized, unauthorized, or shutdown state, it is put into the configured access VLAN.

To configure VLAN assignment you need to perform these tasks:

- Enable AAA authorization by using the network keyword to allow interface configuration from the RADIUS server.

- Enable 802.1x authentication. (The VLAN assignment feature is automatically enabled when you configure 802.1x authentication on an access port).

- Assign vendor-specific tunnel attributes in the RADIUS server. The RADIUS server must return these attributes to the switch:

- [64] Tunnel-Type = VLAN

- [65] Tunnel-Medium-Type = 802

- [81] Tunnel-Private-Group-ID = VLAN name or VLAN ID

- [83] Tunnel-Preference

Attribute [64] must contain the value VLAN (type 13). Attribute [65] must contain the value 802 (type 6). Attribute [81] specifies the VLAN name or VLAN ID assigned to the IEEE 802.1x-authenticated user.

802.1x Authentication with Per-User ACLs

You can enable per-user access control lists (ACLs) to provide different levels of network access and service to an 802.1x-authenticated user. When the RADIUS server authenticates a user connected to an 802.1x port, it retrieves the ACL attributes based on the user identity and sends them to the switch. The switch applies the attributes to the 802.1x port for the duration of the user session. The switch removes the per-user ACL configuration when the session is over, if authentication fails, or if a link-down condition occurs. The switch does not save RADIUS-specified ACLs in the running configuration. When the port is unauthorized, the switch removes the ACL from the port.

You can configure router ACLs and input port ACLs on the same switch. However, a port ACL takes precedence over a router ACL. If you apply input port ACL to an interface that belongs to a VLAN, the port ACL takes precedence over an input router ACL applied to the VLAN interface. Incoming packets received on the port, to which a port ACL is applied, are filtered by the port ACL. Incoming routed packets received on other ports are filtered by the router ACL. Outgoing routed packets are filtered by the router ACL. To avoid configuration conflicts, you should carefully plan the user profiles stored on the RADIUS server.

RADIUS supports per-user attributes, including vendor-specific attributes. These vendor-specific attributes (VSAs) are in octet-string format and are passed to the switch during the authentication process. The VSAs used for per-user ACLs are inacl#<n> for the ingress direction and outacl#<n> for the egress direction. MAC ACLs are supported only in the ingress direction. The switch supports VSAs only in the ingress direction. It does not support port ACLs in the egress direction on Layer 2 ports.

Use only the extended ACL syntax style to define the per-user configuration stored on the RADIUS server. When the definitions are passed from the RADIUS server, they are created by using the extended naming convention. However, if you use the Filter-Id attribute, it can point to a standard ACL.

You can use the Filter-Id attribute to specify an inbound or outbound ACL that is already configured on the switch. The attribute contains the ACL number followed by .in for ingress filtering or .out for egress filtering. If the RADIUS server does not allow the .in or .out syntax, the access list is applied to the outbound ACL by default. The user is marked unauthorized if the Filter-Id sent from the RADIUS server is not configured on the device. Because of limited support of Cisco IOS access lists on the switch, the Filter-Id attribute is supported only for IP ACLs numbered in the range of 1 to 199 (IP standard ACLs) and 1300 to 2699 (IP extended ACLs).

The maximum size of the per-user ACL is 4000 ASCII characters but is limited by the maximum size of RADIUS-server per-user ACLs.

You must meet the following prerequisites to configure per-user ACLs:

- Enable AAA authentication.

- Enable AAA authorization by using the network keyword to allow interface configuration from the RADIUS server.

- Enable 802.1x authentication.

- Configure the user profile and VSAs on the RADIUS server.

- Configure the 802.1x port for single-host mode.

Note

Per-user ACLs are supported only in single-host mode.

802.1x Authentication with Downloadable ACLs and Redirect URLs

You can download ACLs and redirect URLs from a RADIUS server to the switch during 802.1x authentication or MAC authentication bypass of the host. You can also download ACLs during web authentication.

Note

A downloadable ACL is also referred to as a dACL.

If more than one host is authenticated and the host is in single-host, MDA, or multiple-authentication mode, the switch changes the source address of the ACL to the host IP address.

You can apply the ACLs and redirect URLs to all the devices connected to the 802.1x-enabled port.

If no ACLs are downloaded during 802.1x authentication, the switch applies the static default ACL on the port to the host. On a voice VLAN port configured in multi-auth or MDA mode, the switch applies the ACL only to the phone as part of the authorization policies.

For a URL redirect ACL:

- Packets that match a permit access control entry (ACE) rule are sent to the CPU for forwarding to the AAA server.

- Packets that match a deny ACE rule are forwarded through the switch.

- Packets that match neither the permit ACE rule or deny ACE rule are processed by the next dACL, and if there is no dACL, the packets hit the implicit-deny ACL and are dropped.

- Cisco Secure ACS and Attribute-Value Pairs for the Redirect URL

- Cisco Secure ACS and Attribute-Value Pairs for Downloadable ACLs

Cisco Secure ACS and Attribute-Value Pairs for the Redirect URL

The switch uses these cisco-av-pair VSAs:

- url-redirect is the HTTP or HTTPS URL.

- url-redirect-acl is the switch ACL name or number.

The switch uses the CiscoSecure-defined-ACL attribute value pair to intercept an HTTP or HTTPS request from the end point. The switch then forwards the client web browser to the specified redirect address. The url-redirect AV pair on the Cisco Secure ACS contains the URL to which the web browser is redirected. The url-redirect-acl attribute value pair contains the name or number of an ACL that specifies the HTTP or HTTPS traffic to redirect.

Note

- Traffic that matches a permit ACE in the ACL is redirected.

- Define the URL redirect ACL and the default port ACL on the switch.

If a redirect URL is configured for a client on the authentication server, a default port ACL on the connected client switch port must also be configured.

Cisco Secure ACS and Attribute-Value Pairs for Downloadable ACLs

You can set the CiscoSecure-Defined-ACL Attribute-Value (AV) pair on the Cisco Secure ACS with the RADIUS cisco-av-pair vendor-specific attributes (VSAs). This pair specifies the names of the downloadable ACLs on the Cisco Secure ACS with the #ACL#-IP-name-number attribute.

- The name is the ACL name.

- The number is the version number (for example, 3f783768).

If a downloadable ACL is configured for a client on the authentication server, a default port ACL on the connected client switch port must also be configured.

If the default ACL is configured on the switch and the Cisco Secure ACS sends a host-access-policy to the switch, it applies the policy to traffic from the host connected to a switch port. If the policy does not apply, the switch applies the default ACL. If the Cisco Secure ACS sends the switch a downloadable ACL, this ACL takes precedence over the default ACL that is configured on the switch port. However, if the switch receives an host access policy from the Cisco Secure ACS but the default ACL is not configured, the authorization failure is declared.

VLAN ID-Based MAC Authentication

You can use VLAN ID-based MAC authentication if you wish to authenticate hosts based on a static VLAN ID instead of a downloadable VLAN. When you have a static VLAN policy configured on your switch, VLAN information is sent to an IAS (Microsoft) RADIUS server along with the MAC address of each host for authentication. The VLAN ID configured on the connected port is used for MAC authentication. By using VLAN ID-based MAC authentication with an IAS server, you can have a fixed number of VLANs in the network.

The feature also limits the number of VLANs monitored and handled by STP. The network can be managed as a fixed VLAN.

802.1x Authentication with Guest VLAN

You can configure a guest VLAN for each 802.1x port on the switch to provide limited services to clients, such as downloading the 802.1x client. These clients might be upgrading their system for 802.1x authentication, and some hosts, such as Windows 98 systems, might not be IEEE 802.1x-capable.

When you enable a guest VLAN on an 802.1x port, the switch assigns clients to a guest VLAN when the switch does not receive a response to its EAP request/identity frame or when EAPOL packets are not sent by the client.

The switch maintains the EAPOL packet history. If an EAPOL packet is detected on the interface during the lifetime of the link, the switch determines that the device connected to that interface is an IEEE 802.1x-capable supplicant, and the interface does not change to the guest VLAN state. EAPOL history is cleared if the interface link status goes down. If no EAPOL packet is detected on the interface, the interface changes to the guest VLAN state.

If the switch is trying to authorize an 802.1x-capable voice device and the AAA server is unavailable, the authorization attempt fails, but the detection of the EAPOL packet is saved in the EAPOL history. When the AAA server becomes available, the switch authorizes the voice device. However, the switch no longer allows other devices access to the guest VLAN. To prevent this situation, use one of these command sequences:

- Enter the authentication event no-response action authorize vlan vlan-id interface configuration command to allow access to the guest VLAN.

- Enter the shutdown interface configuration command followed by the no shutdown interface configuration command to restart the port.

If devices send EAPOL packets to the switch during the lifetime of the link, the switch no longer allows clients that fail authentication access to the guest VLAN.

Note

If an EAPOL packet is detected after the interface has changed to the guest VLAN, the interface reverts to an unauthorized state, and 802.1x authentication restarts.

Any number of 802.1x-incapable clients are allowed access when the switch port is moved to the guest VLAN. If an 802.1x-capable client joins the same port on which the guest VLAN is configured, the port is put into the unauthorized state in the user-configured access VLAN, and authentication is restarted.

Guest VLANs are supported on 802.1x ports in single host, multiple host, multi-auth and multi-domain modes.

You can configure any active VLAN except an RSPAN VLAN, a private VLAN, or a voice VLAN as an 802.1x guest VLAN. The guest VLAN feature is not supported on internal VLANs (routed ports) or trunk ports; it is supported only on access ports.

The switch supports MAC authentication bypass. When MAC authentication bypass is enabled on an 802.1x port, the switch can authorize clients based on the client MAC address when IEEE 802.1x authentication times out while waiting for an EAPOL message exchange. After detecting a client on an 802.1x port, the switch waits for an Ethernet packet from the client. The switch sends the authentication server a RADIUS-access/request frame with a username and password based on the MAC address. If authorization succeeds, the switch grants the client access to the network. If authorization fails, the switch assigns the port to the guest VLAN if one is specified.

802.1x Authentication with Restricted VLAN

You can configure a restricted VLAN (also referred to as an authentication failed VLAN) for each IEEE 802.1x port on a switch stack or a switch to provide limited services to clients that cannot access the guest VLAN. These clients are 802.1x-compliant and cannot access another VLAN because they fail the authentication process. A restricted VLAN allows users without valid credentials in an authentication server (typically, visitors to an enterprise) to access a limited set of services. The administrator can control the services available to the restricted VLAN.

Note

You can configure a VLAN to be both the guest VLAN and the restricted VLAN if you want to provide the same services to both types of users.

Without this feature, the client attempts and fails authentication indefinitely, and the switch port remains in the spanning-tree blocking state. With this feature, you can configure the switch port to be in the restricted VLAN after a specified number of authentication attempts (the default value is 3 attempts).

The authenticator counts the failed authentication attempts for the client. When this count exceeds the configured maximum number of authentication attempts, the port moves to the restricted VLAN. The failed attempt count increments when the RADIUS server replies with either an EAP failure or an empty response without an EAP packet. When the port moves into the restricted VLAN, the failed attempt counter resets.

Users who fail authentication remain in the restricted VLAN until the next re-authentication attempt. A port in the restricted VLAN tries to re-authenticate at configured intervals (the default is 60 seconds). If re-authentication fails, the port remains in the restricted VLAN. If re-authentication is successful, the port moves either to the configured VLAN or to a VLAN sent by the RADIUS server. You can disable re-authentication. If you do this, the only way to restart the authentication process is for the port to receive a link down or EAP logoff event. We recommend that you keep re-authentication enabled if a client might connect through a hub. When a client disconnects from the hub, the port might not receive the link down or EAP logoff event.

After a port moves to the restricted VLAN, a simulated EAP success message is sent to the client. This prevents clients from indefinitely attempting authentication. Some clients (for example, devices running Windows XP) cannot implement DHCP without EAP success.

Restricted VLANs are supported on 802.1x ports in all host modes and on Layer 2 ports.

You can configure any active VLAN except an RSPAN VLAN, a primary private VLAN, or a voice VLAN as an 802.1x restricted VLAN. The restricted VLAN feature is not supported on internal VLANs (routed ports) or trunk ports; it is supported only on access ports.

Other security port features such as dynamic ARP Inspection, DHCP snooping, and IP source guard can be configured independently on a restricted VLAN.

802.1x Authentication with Inaccessible Authentication Bypass

Use the inaccessible authentication bypass feature, also referred to as critical authentication or the AAA fail policy, when the switch cannot reach the configured RADIUS servers and new hosts cannot be authenticated. You can configure the switch to connect those hosts to critical ports.

When a new host tries to connect to the critical port, that host is moved to a user-specified access VLAN, the critical VLAN. The administrator gives limited authentication to the hosts.

When the switch tries to authenticate a host connected to a critical port, the switch checks the status of the configured RADIUS server. If a server is available, the switch can authenticate the host. However, if all the RADIUS servers are unavailable, the switch grants network access to the host and puts the port in the critical-authentication state, which is a special case of the authentication state.

Note

If critical authentication is configured on interface, then vlan used for critical authorization (critical vlan) should be active on the switch. If the critical vlan is inactive (or) down, critical authentication session will keep trying to enable inactive vlan and fail repeatedly. This can lead to large amount of memory holding.

- Inaccessible Authentication Bypass Support on Multiple-Authentication Ports

- Inaccessible Authentication Bypass Authentication Results

- Inaccessible Authentication Bypass Feature Interactions

Inaccessible Authentication Bypass Support on Multiple-Authentication Ports

When a port is configured on any host mode and the AAA server is unavailable, the port is then configured to multi-host mode and moved to the critical VLAN. To support this inaccessible bypass on multiple-authentication (multiauth) ports, use the authentication event server dead action reinitialize vlan vlan-id command. When a new host tries to connect to the critical port, that port is reinitialized and all the connected hosts are moved to the user-specified access VLAN.

This command is supported on all host modes.

Inaccessible Authentication Bypass Authentication Results

The behavior of the inaccessible authentication bypass feature depends on the authorization state of the port:

- If the port is unauthorized when a host connected to a critical port tries to authenticate and all servers are unavailable, the switch puts the port in the critical-authentication state in the RADIUS-configured or user-specified access VLAN.

- If the port is already authorized and reauthentication occurs, the switch puts the critical port in the critical-authentication state in the current VLAN, which might be the one previously assigned by the RADIUS server.

- If the RADIUS server becomes unavailable during an authentication exchange, the current exchange times out, and the switch puts the critical port in the critical-authentication state during the next authentication attempt.

You can configure the critical port to reinitialize hosts and move them out of the critical VLAN when the RADIUS server is again available. When this is configured, all critical ports in the critical-authentication state are automatically re-authenticated.

Inaccessible Authentication Bypass Feature Interactions

Inaccessible authentication bypass interacts with these features:

- Guest VLAN—Inaccessible authentication bypass is compatible with guest VLAN. When a guest VLAN is enabled on 8021.x port, the features interact as follows:

- If at least one RADIUS server is available, the switch assigns a client to a guest VLAN when the switch does not receive a response to its EAP request/identity frame or when EAPOL packets are not sent by the client.

- If all the RADIUS servers are not available and the client is connected to a critical port, the switch authenticates the client and puts the critical port in the critical-authentication state in the RADIUS-configured or user-specified access VLAN.

- If all the RADIUS servers are not available and the client is not connected to a critical port, the switch might not assign clients to the guest VLAN if one is configured.

- If all the RADIUS servers are not available and if a client is connected to a critical port and was previously assigned to a guest VLAN, the switch keeps the port in the guest VLAN.

- Restricted VLAN—If the port is already authorized in a restricted VLAN and the RADIUS servers are unavailable, the switch puts the critical port in the critical-authentication state in the restricted VLAN.

- 802.1x accounting—Accounting is not affected if the RADIUS servers are unavailable.

- Private VLAN—You can configure inaccessible authentication bypass on a private VLAN host port. The access VLAN must be a secondary private VLAN.

- Voice VLAN—Inaccessible authentication bypass is compatible with voice VLAN, but the RADIUS-configured or user-specified access VLAN and the voice VLAN must be different.

- Remote Switched Port Analyzer (RSPAN)—Do not configure an RSPAN VLAN as the RADIUS-configured or user-specified access VLAN for inaccessible authentication bypass.

In a switch stack:

- The stack master checks the status of the RADIUS servers by sending keepalive packets. When the status of a RADIUS server changes, the stack master sends the information to the stack members. The stack members can then check the status of RADIUS servers when re-authenticating critical ports.

- If the new stack master is elected, the link between the switch stack and RADIUS server might change, and the new stack immediately sends keepalive packets to update the status of the RADIUS servers. If the server status changes from dead to alive, the switch re-authenticates all switch ports in the critical-authentication state.

When a member is added to the stack, the stack master sends the member the server status.

802.1x Critical Voice VLAN

When an IP phone connected to a port is authenticated by the Cisco Identity Services Engine (ISE), the phone is put into the voice domain. If the ISE is not reachable, the switch cannot determine if the device is a voice device. If the server is unavailable, the phone cannot access the voice network and therefore cannot operate.

For data traffic, you can configure inaccessible authentication bypass, or critical authentication, to allow traffic to pass through on the native VLAN when the server is not available. If the RADIUS authentication server is unavailable (down) and inaccessible authentication bypass is enabled, the switch grants the client access to the network and puts the port in the critical-authentication state in the RADIUS-configured or the user-specified access VLAN. When the switch cannot reach the configured RADIUS servers and new hosts cannot be authenticated, the switch connects those hosts to critical ports. A new host trying to connect to the critical port is moved to a user-specified access VLAN, the critical VLAN, and granted limited authentication.

Note

Dynamic assignment of critical voice VLAN is not supported with nested service templates. It causes the device to switch between VLANs continuously in a loop.

You can enter the authentication event server dead action authorize voice interface configuration command to configure the critical voice VLAN feature. When the ISE does not respond, the port goes into critical authentication mode. When traffic coming from the host is tagged with the voice VLAN, the connected device (the phone) is put in the configured voice VLAN for the port. The IP phones learn the voice VLAN identification through Cisco Discovery Protocol (Cisco devices) or through LLDP or DHCP.

You can configure the voice VLAN for a port by entering the switchport voice vlan vlan-id interface configuration command.

This feature is supported in multidomain and multi-auth host modes. Although you can enter the command when the switch in single-host or multi-host mode, the command has no effect unless the device changes to multidomain or multi-auth host mode.

802.1x User Distribution

You can configure 802.1x user distribution to load-balance users with the same group name across multiple different VLANs.

The VLANs are either supplied by the RADIUS server or configured through the switch CLI under a VLAN group name.

- Configure the RADIUS server to send more than one VLAN name for a user. The multiple VLAN names can be sent as part of the response to the user. The 802.1x user distribution tracks all the users in a particular VLAN and achieves load balancing by moving the authorized user to the least populated VLAN.

- Configure the RADIUS server to send a VLAN group name for a user. The VLAN group name can be sent as part of the response to the user. You can search for the selected VLAN group name among the VLAN group names that you configured by using the switch CLI. If the VLAN group name is found, the corresponding VLANs under this VLAN group name are searched to find the least populated VLAN. Load balancing is achieved by moving the corresponding authorized user to that VLAN.

Note

The RADIUS server can send the VLAN information in any combination of VLAN-IDs, VLAN names, or VLAN groups.

- 802.1x User Distribution Configuration Guidelines

802.1x User Distribution Configuration Guidelines

- Confirm that at least one VLAN is mapped to the VLAN group.

- You can map more than one VLAN to a VLAN group.

- You can modify the VLAN group by adding or deleting a VLAN.

- When you clear an existing VLAN from the VLAN group name, none of the authenticated ports in the VLAN are cleared, but the mappings are removed from the existing VLAN group.

- If you clear the last VLAN from the VLAN group name, the VLAN group is cleared.

- You can clear a VLAN group even when the active VLANs are mapped to the group. When you clear a VLAN group, none of the ports or users that are in the authenticated state in any VLAN within the group are cleared, but the VLAN mappings to the VLAN group are cleared.

IEEE 802.1x Authentication with Voice VLAN Ports

A voice VLAN port is a special access port associated with two VLAN identifiers:

- VVID to carry voice traffic to and from the IP phone. The VVID is used to configure the IP phone connected to the port.

- PVID to carry the data traffic to and from the workstation connected to the switch through the IP phone. The PVID is the native VLAN of the port.

The IP phone uses the VVID for its voice traffic, regardless of the authorization state of the port. This allows the phone to work independently of IEEE 802.1x authentication.

In single-host mode, only the IP phone is allowed on the voice VLAN. In multiple-hosts mode, additional clients can send traffic on the voice VLAN after a supplicant is authenticated on the PVID. When multiple-hosts mode is enabled, the supplicant authentication affects both the PVID and the VVID.

A voice VLAN port becomes active when there is a link, and the device MAC address appears after the first CDP message from the IP phone. Cisco IP phones do not relay CDP messages from other devices. As a result, if several IP phones are connected in series, the switch recognizes only the one directly connected to it. When IEEE 802.1x authentication is enabled on a voice VLAN port, the switch drops packets from unrecognized IP phones more than one hop away.

When IEEE 802.1x authentication is enabled on a switch port, you can configure an access port VLAN that is also a voice VLAN.

When IP phones are connected to an 802.1x-enabled switch port that is in single host mode, the switch grants the phones network access without authenticating them. We recommend that you use multidomain authentication (MDA) on the port to authenticate both a data device and a voice device, such as an IP phone

Note

If you enable IEEE 802.1x authentication on an access port on which a voice VLAN is configured and to which a Cisco IP Phone is connected, the Cisco IP phone loses connectivity to the switch for up to 30 seconds.

IEEE 802.1x Authentication with Port Security

In general, Cisco does not recommend enabling port security when IEEE 802.1x is enabled. Since IEEE 802.1x enforces a single MAC address per port (or per VLAN when MDA is configured for IP telephony), port security is redundant and in some cases may interfere with expected IEEE 802.1x operations.

IEEE 802.1x Authentication with Wake-on-LAN

The IEEE 802.1x authentication with wake-on-LAN (WoL) feature allows dormant PCs to be powered when the switch receives a specific Ethernet frame, known as the magic packet. You can use this feature in environments where administrators need to connect to systems that have been powered down.

When a host that uses WoL is attached through an IEEE 802.1x port and the host powers off, the IEEE 802.1x port becomes unauthorized. The port can only receive and send EAPOL packets, and WoL magic packets cannot reach the host. When the PC is powered off, it is not authorized, and the switch port is not opened.

When the switch uses IEEE 802.1x authentication with WoL, the switch forwards traffic to unauthorized IEEE 802.1x ports, including magic packets. While the port is unauthorized, the switch continues to block ingress traffic other than EAPOL packets. The host can receive packets but cannot send packets to other devices in the network.

Note

If PortFast is not enabled on the port, the port is forced to the bidirectional state.

When you configure a port as unidirectional by using the authentication control-direction in interface configuration command, the port changes to the spanning-tree forwarding state. The port can send packets to the host but cannot receive packets from the host.

When you configure a port as bidirectional by using the authentication control-direction both interface configuration command, the port is access-controlled in both directions. The port does not receive packets from or send packets to the host.

IEEE 802.1x Authentication with MAC Authentication Bypass

You can configure the switch to authorize clients based on the client MAC address by using the MAC authentication bypass feature. For example, you can enable this feature on IEEE 802.1x ports connected to devices such as printers.

If IEEE 802.1x authentication times out while waiting for an EAPOL response from the client, the switch tries to authorize the client by using MAC authentication bypass.

When the MAC authentication bypass feature is enabled on an IEEE 802.1x port, the switch uses the MAC address as the client identity. The authentication server has a database of client MAC addresses that are allowed network access. After detecting a client on an IEEE 802.1x port, the switch waits for an Ethernet packet from the client. The switch sends the authentication server a RADIUS-access/request frame with a username and password based on the MAC address. If authorization succeeds, the switch grants the client access to the network. If authorization fails, the switch assigns the port to the guest VLAN if one is configured. This process works for most client devices; however, it does not work for clients that use an alternate MAC address format. You can configure how MAB authentication is performed for clients with MAC addresses that deviate from the standard format or where the RADIUS configuration requires the user name and password to differ.

If an EAPOL packet is detected on the interface during the lifetime of the link, the switch determines that the device connected to that interface is an 802.1x-capable supplicant and uses 802.1x authentication (not MAC authentication bypass) to authorize the interface. EAPOL history is cleared if the interface link status goes down.

If the switch already authorized a port by using MAC authentication bypass and detects an IEEE 802.1x supplicant, the switch does not unauthorize the client connected to the port. When re-authentication occurs, the switch uses the authentication or re-authentication methods configured on the port, if the previous session ended because the Termination-Action RADIUS attribute value is DEFAULT.

Clients that were authorized with MAC authentication bypass can be re-authenticated. The re-authentication process is the same as that for clients that were authenticated with IEEE 802.1x. During re-authentication, the port remains in the previously assigned VLAN. If re-authentication is successful, the switch keeps the port in the same VLAN. If re-authentication fails, the switch assigns the port to the guest VLAN, if one is configured.

If re-authentication is based on the Session-Timeout RADIUS attribute (Attribute[27]) and the Termination-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 session ends, and connectivity is lost during re-authentication. If MAC authentication bypass is enabled and the IEEE 802.1x authentication times out, the switch uses the MAC authentication bypass feature to initiate re-authorization. For more information about these AV pairs, see RFC 3580, “IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines.”

MAC authentication bypass interacts with the features:

- IEEE 802.1x authentication—You can enable MAC authentication bypass only if 802.1x authentication is enabled on the port .

- Guest VLAN—If a client has an invalid MAC address identity, the switch assigns the client to a guest VLAN if one is configured.

- Restricted VLAN—This feature is not supported when the client connected to an IEEE 802.lx port is authenticated with MAC authentication bypass.

- Port security

- Voice VLAN

- Private VLAN—You can assign a client to a private VLAN.

- Network Edge Access Topology (NEAT)—MAB and NEAT are mutually exclusive. You cannot enable MAB when NEAT is enabled on an interface, and you should not enable NEAT when MAB is enabled on an interface.

Cisco IOS Release 12.2(55)SE and later supports filtering of verbose MAB system messages

Network Admission Control Layer 2 IEEE 802.1x Validation

The switch supports the Network Admission Control (NAC) Layer 2 IEEE 802.1x validation, which checks the antivirus condition or posture of endpoint systems or clients before granting the devices network access. With NAC Layer 2 IEEE 802.1x validation, you can do these tasks:

- Download the Session-Timeout RADIUS attribute (Attribute[27]) and the Termination-Action RADIUS attribute (Attribute[29]) from the authentication server.

- Set the number of seconds between re-authentication attempts as the value of the Session-Timeout RADIUS attribute (Attribute[27]) and get an access policy against the client from the RADIUS server.

- Set the action to be taken when the switch tries to re-authenticate the client by using the Termination-Action RADIUS attribute (Attribute[29]). If the value is the DEFAULT or is not set, the session ends. If the value is RADIUS-Request, the re-authentication process starts.

- Set the list of VLAN number or name or VLAN group name as the value of the Tunnel Group Private ID (Attribute[81]) and the preference for the VLAN number or name or VLAN group name as the value of the Tunnel Preference (Attribute[83]). If you do not configure the Tunnel Preference, the first Tunnel Group Private ID (Attribute[81]) attribute is picked up from the list.

- View the NAC posture token, which shows the posture of the client, by using the show authentication privileged EXEC command.

- Configure secondary private VLANs as guest VLANs.

Configuring NAC Layer 2 IEEE 802.1x validation is similar to configuring IEEE 802.1x port-based authentication except that you must configure a posture token on the RADIUS server.

Flexible Authentication Ordering

You can use flexible authentication ordering to configure the order of methods that a port uses to authenticate a new host. The IEEE 802.1X Flexible Authentication feature supports three authentication methods:

- dot1X—IEEE 802.1X authentication is a Layer 2 authentication method.

- mab—MAC-Authentication Bypass is a Layer 2 authentication method.

- webauth—Web authentication is a Layer 3 authentication method.

Using this feature, you can control which ports use which authentication methods, and you can control the failover sequencing of methods on those ports. For example, MAC authentication bypass and 802.1x can be the primary or secondary authentication methods, and web authentication can be the fallback method if either or both of those authentication attempts fail.

The IEEE 802.1X Flexible Authentication feature supports the following host modes:

- multi-auth—Multiauthentication allows one authentication on a voice VLAN and multiple authentications on the data VLAN.

- multi-domain—Multidomain authentication allows two authentications: one on the voice VLAN and one on the data VLAN.

Open1x Authentication

Open1x authentication allows a device access to a port before that device is authenticated. When open authentication is configured, a new host can pass traffic according to the access control list (ACL) defined on the port. After the host is authenticated, the policies configured on the RADIUS server are applied to that host.

You can configure open authentication with these scenarios:

- Single-host mode with open authentication–Only one user is allowed network access before and after authentication.

- MDA mode with open authentication–Only one user in the voice domain and one user in the data domain are allowed.

- Multiple-hosts mode with open authentication–Any host can access the network.

- Multiple-authentication mode with open authentication–Similar to MDA, except multiple hosts can be authenticated.

Note

If open authentication is configured, it takes precedence over other authentication controls. This means that if you use the authentication open interface configuration command, the port will grant access to the host irrespective of the authentication port-control interface configuration command.

Multidomain Authentication

The switch supports multidomain authentication (MDA), which allows both a data device and voice device, such as an IP phone (Cisco or non-Cisco), to authenticate on the same switch port. The port is divided into a data domain and a voice domain.

Note

For all host modes, the line protocol stays up before authorization when port-based authentication is configured.

MDA does not enforce the order of device authentication. However, for best results, we recommend that a voice device is authenticated before a data device on an MDA-enabled port.

Follow these guidelines for configuring MDA:

- You must configure a switch port for MDA.

- You must configure the voice VLAN for the IP phone when the host mode is set to multidomain.

- Voice VLAN assignment on an MDA-enabled port is supported Cisco IOS Release 12.2(40)SE and later.

- To authorize a voice device, the AAA server must be configured to send a Cisco Attribute-Value (AV) pair attribute with a value of device-traffic-class=voice. Without this value, the switch treats the voice device as a data device.

- The guest VLAN and restricted VLAN features only apply to the data devices on an MDA-enabled port. The switch treats a voice device that fails authorization as a data device.

- If more than one device attempts authorization on either the voice or the data domain of a port, it is error disabled.

- Until a device is authorized, the port drops its traffic. Non-Cisco IP phones or voice devices are allowed into both the data and voice VLANs. The data VLAN allows the voice device to contact a DHCP server to obtain an IP address and acquire the voice VLAN information. After the voice device starts sending on the voice VLAN, its access to the data VLAN is blocked.

- A voice device MAC address that is binding on the data VLAN is not counted towards the port security MAC address limit.

- MDA can use MAC authentication bypass as a fallback mechanism to allow the switch port to connect to devices that do not support IEEE 802.1x authentication.

- When a data or a voice device is detected on a port, its MAC address is blocked until authorization succeeds. If the authorization fails, the MAC address remains blocked for 5 minutes.

- If more than five devices are detected on the data VLAN or more than one voice device is detected on the voice VLAN while a port is unauthorized, the port is error disabled.

- When a port host mode is changed from single- or multihost to multidomain mode, an authorized data device remains authorized on the port. However, a Cisco IP phone that has been allowed on the port voice VLAN is automatically removed and must be reauthenticated on that port.

- Active fallback mechanisms such as guest VLAN and restricted VLAN remain configured after a port changes from single- or multihost mode to multidomain mode.

- Switching a port host mode from multidomain to single- or multihost mode removes all authorized devices from the port.

- If a data domain is authorized first and placed in the guest VLAN, non-IEEE 802.1x-capable voice devices need to tag their packets on the voice VLAN to trigger authentication.

- We do not recommend per-user ACLs with an MDA-enabled port. An authorized device with a per-user ACL policy might impact traffic on both the voice and data VLANs of the port. If used, only one device on the port should enforce per-user ACLs.

802.1x Supplicant and Authenticator Switches with Network Edge Access Topology (NEAT)

The Network Edge Access Topology (NEAT) feature extends identity to areas outside the wiring closet (such as conference rooms). This allows any type of device to authenticate on the port.

- 802.1x switch supplicant: You can configure a switch to act as a supplicant to another switch by using the 802.1x supplicant feature. This configuration is helpful in a scenario, where, for example, a switch is outside a wiring closet and is connected to an upstream switch through a trunk port. A switch configured with the 802.1x switch supplicant feature authenticates with the upstream switch for secure connectivity. Once the supplicant switch authenticates successfully the port mode changes from access to trunk in an authenticator switch. In a supplicant switch you must manually configure trunk when enabling CISP.

- If the access VLAN is configured on the authenticator switch, it becomes the native VLAN for the trunk port after successful authentication.

In the default state, when you connect a supplicant switch to an authenticator switch that has BPDU guard enabled, the authenticator port could be error-disabled if it receives a Spanning Tree Protocol (STP) bridge protocol data unit (BPDU) packets before the supplicant switch has authenticated. Beginning with Cisco IOS Release 15.0(1)SE, you can control traffic exiting the supplicant port during the authentication period. Entering the dot1x supplicant controlled transient global configuration command temporarily blocks the supplicant port during authentication to ensure that the authenticator port does not shut down before authentication completes. If authentication fails, the supplicant port opens. Entering the no dot1x supplicant controlled transient global configuration command opens the supplicant port during the authentication period. This is the default behavior.

We strongly recommend using the dot1x supplicant controlled transientcommand on a supplicant switch when BPDU guard is enabled on the authenticator switch port with the spanning-tree bpduguard enable interface configuration command.

Note

If you globally enable BPDU guard on the authenticator switch by using the spanning-tree portfast bpduguard default global configuration command, entering the dot1x supplicant controlled transient command does not prevent the BPDU violation.

You can enable MDA or multiauth mode on the authenticator switch interface that connects to one more supplicant switches. Multihost mode is not supported on the authenticator switch interface.

When you reboot an authenticator switch with single-host mode enabled on the interface, the interface may move to err-disabled state before authentication. To recover from err-disabled state, flap the authenticator port to activate the interface again and initiate authentication.

Use the dot1x supplicant force-multicast global configuration command on the supplicant switch for Network Edge Access Topology (NEAT) to work in all host modes.

- Host Authorization: Ensures that only traffic from authorized hosts (connecting to the switch with supplicant) is allowed on the network. The switches use Client Information Signalling Protocol (CISP) to send the MAC addresses connecting to the supplicant switch to the authenticator switch.

- Auto enablement: Automatically enables trunk configuration on the authenticator switch, allowing user traffic from multiple VLANs coming from supplicant switches. Configure the cisco-av-pair as device-traffic-class=switch at the ISE. (You can configure this under the group or the user settings.)

Authenticator and Supplicant Switch using CISP

1

Workstations (clients)

2

Supplicant switch (outside wiring closet)

3

Authenticator switch

4

Cisco ISE

5

Trunk port

Note

The switchport nonegotiate command is not supported on supplicant and authenticator switches with NEAT. This command should not be configured at the supplicant side of the topology. If configured on the authenticator side, the internal macros will automatically remove this command from the port.

Voice Aware 802.1x Security

Note

To use voice aware IEEE 802.1x authentication, the switch must be running the LAN base image.

You use the voice aware 802.1x security feature to configure the switch to disable only the VLAN on which a security violation occurs, whether it is a data or voice VLAN. In previous releases, when an attempt to authenticate the data client caused a security violation, the entire port shut down, resulting in a complete loss of connectivity.

You can use this feature in IP phone deployments where a PC is connected to the IP phone. A security violation found on the data VLAN results in the shutdown of only the data VLAN. The traffic on the voice VLAN flows through the switch without interruption.

Common Session ID

Authentication manager uses a single session ID (referred to as a common session ID) for a client no matter which authentication method is used. This ID is used for all reporting purposes, such as the show commands and MIBs. The session ID appears with all per-session syslog messages.

The session ID includes:

- The IP address of the Network Access Device (NAD)

- A monotonically increasing unique 32 bit integer

- The session start time stamp (a 32 bit integer)

This example shows how the session ID appears in the output of the show authentication command. The session ID in this example is 160000050000000B288508E5:

Device# show authentication sessions
Interface  MAC Address     Method   Domain   Status         Session ID
Fa4/0/4    0000.0000.0203  mab      DATA     Authz Success  160000050000000B288508E5

This is an example of how the session ID appears in the syslog output. The session ID in this example is also160000050000000B288508E5:

1w0d: %AUTHMGR-5-START: Starting 'mab' for client (0000.0000.0203) on Interface Fa4/0/4
AuditSessionID 160000050000000B288508E5
1w0d: %MAB-5-SUCCESS: Authentication successful for client (0000.0000.0203) on Interface
Fa4/0/4 AuditSessionID 160000050000000B288508E5
1w0d: %AUTHMGR-7-RESULT: Authentication result 'success' from 'mab' for client
(0000.0000.0203) on Interface Fa4/0/4 AuditSessionID 160000050000000B288508E5

The session ID is used by the NAD, the AAA server, and other report-analyzing applications to identify the client. The ID appears automatically. No configuration is required.

Default 802.1x Authentication Configuration

Default 802.1x Authentication Configuration

Feature

Default Setting

Switch 802.1x enable state

Disabled.

Per-port 802.1x enable state

Disabled (force-authorized).

The port sends and receives normal traffic without 802.1x-based authentication of the client.

AAA

Disabled.

RADIUS server

- IP address

- UDP authentication port

- Default accounting port

- Key

- None specified.

- 1645.

- 1646.

- None specified.

Host mode

Single-host mode.

Control direction

Bidirectional control.

Periodic re-authentication

Disabled.

Number of seconds between re-authentication attempts

3600 seconds.

Re-authentication number

2 times (number of times that the switch restarts the authentication process before the port changes to the unauthorized state).

Quiet period

60 seconds (number of seconds that the switch remains in the quiet state following a failed authentication exchange with the client).

Retransmission time

30 seconds (number of seconds that the switch should wait for a response to an EAP request/identity frame from the client before resending the request).

Maximum retransmission number

2 times (number of times that the switch will send an EAP-request/identity frame before restarting the authentication process).

Client timeout period

30 seconds (when relaying a request from the authentication server to the client, the amount of time the switch waits for a response before resending the request to the client.)

Authentication server timeout period

30 seconds (when relaying a response from the client to the authentication server, the amount of time the switch waits for a reply before resending the response to the server.)

You can change this timeout period by using the dot1x timeout server-timeout interface configuration command.

Inactivity timeout

Disabled.

Guest VLAN

None specified.

Inaccessible authentication bypass

Disabled.

Restricted VLAN

None specified.

Authenticator (switch) mode

None specified.

MAC authentication bypass

Disabled.

Voice-aware security

Disabled.

802.1x Authentication

These are the 802.1x authentication configuration guidelines:

- You must enable SISF-Based device tracking to use 802.1x authentication. By default, SISF-Based device tracking is disabled on a switch.

- When 802.1x authentication is enabled, ports are authenticated before any other Layer 2 or Layer 3 features are enabled.

- If the VLAN to which an 802.1x-enabled port is assigned changes, this change is transparent and does not affect the switch. For example, this change occurs if a port is assigned to a RADIUS server-assigned VLAN and is then assigned to a different VLAN after re-authentication.

If the VLAN to which an 802.1x port is assigned to shut down, disabled, or removed, the port becomes unauthorized. For example, the port is unauthorized after the access VLAN to which a port is assigned shuts down or is removed.

- The 802.1x protocol is supported on Layer 2 static-access ports, voice VLAN ports, and Layer 3 routed ports, but it is not supported on these port types:

- Dynamic ports—A port in dynamic mode can negotiate with its neighbor to become a trunk port. If you try to enable 802.1x authentication on a dynamic port, an error message appears, and 802.1x authentication is not enabled. If you try to change the mode of an 802.1x-enabled port to dynamic, an error message appears, and the port mode is not changed.

- EtherChannel port—Do not configure a port that is an active or a not-yet-active member of an EtherChannel as an 802.1x port. If you try to enable 802.1x authentication on an EtherChannel port, an error message appears, and 802.1x authentication is not enabled.

- Switched Port Analyzer (SPAN) and Remote SPAN (RSPAN) destination ports—You can enable 802.1x authentication on a port that is a SPAN or RSPAN destination port. However, 802.1x authentication is disabled until the port is removed as a SPAN or RSPAN destination port. You can enable 802.1x authentication on a SPAN or RSPAN source port.

- Before globally enabling 802.1x authentication on a switch by entering the dot1x system-auth-control global configuration command, remove the EtherChannel configuration from the interfaces on which 802.1x authentication and EtherChannel are configured.

- Cisco IOS Release 12.2(55)SE and later supports filtering of system messages related to 802.1x authentication.

Note

We recommend that you configure all the dependent 802.1x CLIs under the same interface or on the same template.

VLAN Assignment, Guest VLAN, Restricted VLAN, and Inaccessible Authentication Bypass

These are the configuration guidelines for VLAN assignment, guest VLAN, restricted VLAN, and inaccessible authentication bypass:

- When 802.1x authentication is enabled on a port, you cannot configure a port VLAN that is equal to a voice VLAN.

- You can configure any VLAN except an RSPAN VLAN or a voice VLAN as an 802.1x guest VLAN. The guest VLAN feature is not supported on internal VLANs (routed ports) or trunk ports; it is supported only on access ports.

- After you configure a guest VLAN for an 802.1x port to which a DHCP client is connected, you might need to get a host IP address from a DHCP server. You can change the settings for restarting the 802.1x authentication process on the switch before the DHCP process on the client times out and tries to get a host IP address from the DHCP server. Decrease the settings for the 802.1x authentication process (authentication timer inactivity and authentication timer reauthentication interface configuration commands). The amount to decrease the settings depends on the connected 802.1x client type.

- When configuring the inaccessible authentication bypass feature, follow these guidelines:

- The feature is supported on 802.1x port in single-host mode and multihosts mode.

- If the client is running Windows XP and the port to which the client is connected is in the critical-authentication state, Windows XP might report that the interface is not authenticated.

- If the Windows XP client is configured for DHCP and has an IP address from the DHCP server, receiving an EAP-Success message on a critical port might not re-initiate the DHCP configuration process.

- You can configure the inaccessible authentication bypass feature and the restricted VLAN on an 802.1x port. If the switch tries to re-authenticate a critical port in a restricted VLAN and all the RADIUS servers are unavailable, switch changes the port state to the critical authentication state and remains in the restricted VLAN.

- If the CTS links are in Critical Authentication mode and the active switch reloads, the policy where SGT was configured on a device will not be available on the new active switch. This is because the internal bindings will not be synced to the standby switch in a 3750-X switch stack.

- You can configure any VLAN except an RSPAN VLAN or a voice VLAN as an 802.1x restricted VLAN. The restricted VLAN feature is not supported on internal VLANs (routed ports) or trunk ports; it is supported only on access ports.

MAC Authentication Bypass

These are the MAC authentication bypass configuration guidelines:

- Unless otherwise stated, the MAC authentication bypass guidelines are the same as the 802.1x authentication guidelines.

- If you disable MAC authentication bypass from a port after the port has been authorized with its MAC address, the port state is not affected.

- If the port is in the unauthorized state and the client MAC address is not the authentication-server database, the port remains in the unauthorized state. However, if the client MAC address is added to the database, the switch can use MAC authentication bypass to re-authorize the port.

- If the port is in the authorized state, the port remains in this state until re-authorization occurs.

- You can configure a timeout period for hosts that are connected by MAC authentication bypass but are inactive. The range is 1to 65535 seconds.

Maximum Number of Allowed Devices Per Port

This is the maximum number of devices allowed on an 802.1x-enabled port:

- In single-host mode, only one device is allowed on the access VLAN. If the port is also configured with a voice VLAN, an unlimited number of Cisco IP phones can send and receive traffic through the voice VLAN.

- In multidomain authentication (MDA) mode, one device is allowed for the access VLAN, and one IP phone is allowed for the voice VLAN.

- In multihost mode, only one 802.1x supplicant is allowed on the port, but an unlimited number of non-802.1x hosts are allowed on the access VLAN. An unlimited number of devices are allowed on the voice VLAN.

Configuring 802.1x Readiness Check

The 802.1x readiness check monitors 802.1x activity on all the switch ports and displays information about the devices connected to the ports that support 802.1x. You can use this feature to determine if the devices connected to the switch ports are 802.1x-capable.

The 802.1x readiness check is allowed on all ports that can be configured for 802.1x. The readiness check is not available on a port that is configured as dot1x force-unauthorized.

Follow these steps to enable the 802.1x readiness check on the switch:

Before you begin

Follow these guidelines to enable the readiness check on the switch:

- The readiness check is typically used before 802.1x is enabled on the switch.

- If you use the dot1x test eapol-capable privileged EXEC command without specifying an interface, all the ports on the switch stack are tested.

- When you configure the dot1x test eapol-capable command on an 802.1x-enabled port, and the link comes up, the port queries the connected client about its 802.1x capability. When the client responds with a notification packet, it is 802.1x-capable. A syslog message is generated if the client responds within the timeout period. If the client does not respond to the query, the client is not 802.1x-capable. No syslog message is generated

- When you configure the dot1x test eapol-capable command on an 802.1x-enabled port, and the link comes up, the port queries the connected client about its 802.1x capability. When the client responds with a notification packet, it is 802.1x-capable. A syslog message is generated if the client responds within the timeout period. If the client does not respond to the query, the client is not 802.1x-capable. No syslog message is generated

- The readiness check can be sent on a port that handles multiple hosts (for example, a PC that is connected to an IP phone). A syslog message is generated for each of the clients that respond to the readiness check within the timer period.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

dot1x test eapol-capable [interface interface-id]

Example:

Device# dot1x test eapol-capable interface gigabitethernet1/0/13
DOT1X_PORT_EAPOL_CAPABLE:DOT1X: MAC 00-01-02-4b-f1-a3 on gigabitethernet1/0/13 is EAPOL
capable

Enables the 802.1x readiness check on the switch.

(Optional) For interface-id specify the port on which to check for IEEE 802.1x readiness.

Note

If you omit the optional interface keyword, all interfaces on the switch are tested.

Step 4

dot1x test timeout timeout

(Optional) Configures the timeout used to wait for EAPOL response. The range is from 1 to 65535 seconds. The default is 10 seconds.

Step 5

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 6

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 7

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Configuring Voice Aware 802.1x Security

Note

To use voice aware IEEE 802.1x authentication, the switch must be running the LAN base image.

You use the voice aware 802.1x security feature on the switch to disable only the VLAN on which a security violation occurs, whether it is a data or voice VLAN. You can use this feature in IP phone deployments where a PC is connected to the IP phone. A security violation found on the data VLAN results in the shutdown of only the data VLAN. The traffic on the voice VLAN flows through the switch without interruption.

Follow these guidelines to configure voice aware 802.1x voice security on the switch:

- You enable voice aware 802.1x security by entering the errdisable detect cause security-violation shutdown vlan global configuration command. You disable voice aware 802.1x security by entering the no version of this command. This command applies to all 802.1x-configured ports in the switch.

Note

If you do not include the shutdown vlan keywords, the entire port is shut down when it enters the error-disabled state.

- If you use the errdisable recovery cause security-violation global configuration command to configure error-disabled recovery, the port is automatically re-enabled. If error-disabled recovery is not configured for the port, you re-enable it by using the shutdown and no shutdown interface configuration commands.

- You can re-enable individual VLANs by using the clear errdisable interface interface-id vlan [vlan-list] privileged EXEC command. If you do not specify a range, all VLANs on the port are enabled.

Beginning in privileged EXEC mode, follow these steps to enable voice aware 802.1x security:

Procedure

Step 1

configure terminal

Enter global configuration mode.

Step 2

errdisable detect cause security-violation shutdown vlan

Shut down any VLAN on which a security violation error occurs.

Note

If the shutdown vlan keywords are not included, the entire port enters the error-disabled state and shuts down.

Step 3

errdisable recovery cause security-violation

Enter global configuration mode.

Step 4

clear errdisable interfaceinterface-id vlan [vlan-list]

(Optional) Reenable individual VLANs that have been error disabled.

- For interface-id specify the port on which to reenable individual VLANs.

- (Optional) For vlan-list specify a list of VLANs to be re-enabled. If vlan-list is not specified, all VLANs are re-enabled.

Step 5

Enter the following:

- shutdown

- no shutdown

(Optional) Re-enable an error-disabled VLAN, and clear all error-disable indications.

Step 6

end

Return to privileged EXEC mode.

Step 7

show errdisable detect

Verify your entries.

Example

This example shows how to configure the switch to shut down any VLAN on which a security violation error occurs:

Switch(config)# errdisable detect cause security-violation shutdown vlan

This example shows how to re-enable all VLANs that were error disabled on port Gigabit Ethernet 40/2.

Switch# clear errdisable interface gigabitethernet40/2
vlan

You can verify your settings by entering the show errdisable detect privileged EXEC command.

Configuring 802.1x Violation Modes

You can configure an 802.1x port so that it shuts down, generates a syslog error, or discards packets from a new device when:

- a device connects to an 802.1x-enabled port

- the maximum number of allowed about devices have been authenticated on the port

Beginning in privileged EXEC mode, follow these steps to configure the security violation actions on the switch:

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

aaa new-model

Example:

Device(config)# aaa new-model

Enables AAA.

Step 3

aaa authentication dot1x {default} method1

Example:

Device(config)# aaa authentication dot1x default group radius

Creates an 802.1x authentication method list.

To create a default list that is used when a named list is not specified in the authentication command, use the default keyword followed by the method that is to be used in default situations. The default method list is automatically applied to all ports.

For method1 , enter the group radius keywords to use the list of all RADIUS servers for authentication.

Step 4

interface interface-id

Example:

Device(config)# interface gigabitethernet1/0/4

Specifies the port connected to the client that is to be enabled for IEEE 802.1x authentication, and enter interface configuration mode.

Step 5

switchport mode access

Example:

Device(config-if)# switchport mode access

Sets the port to access mode.

Step 6

authentication violation {shutdown | restrict | protect | replace}

Example:

Device(config-if)# authentication violation restrict

Configures the violation mode. The keywords have these meanings:

- shutdown –Error disable the port.

- restrict –Generate a syslog error.

- protect –Drop packets from any new device that sends traffic to the port.

- replace –Removes the current session and authenticates with the new host.

Step 7

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Configuring 802.1x Authentication

To allow per-user ACLs or VLAN assignment, you must enable AAA authorization to configure the switch for all network-related service requests.

This is the 802.1x AAA process:

Before you begin

To configure 802.1x port-based authentication, you must enable authentication, authorization, and accounting (AAA) and specify the authentication method list. A method list describes the sequence and authentication method to be queried to authenticate a user.

Procedure

Step 1

A user connects to a port on the switch.

Step 2

Authentication is performed.

Step 3

VLAN assignment is enabled, as appropriate, based on the RADIUS server configuration.

Step 4

The switch sends a start message to an accounting server.

Step 5

Re-authentication is performed, as necessary.

Step 6

The switch sends an interim accounting update to the accounting server that is based on the result of re-authentication.

Step 7

The user disconnects from the port.

Step 8

The switch sends a stop message to the accounting server.

Configuring 802.1x Port-Based Authentication

Beginning in privileged EXEC mode, follow these steps to configure 802.1x port-based authentication:

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

aaa new-model

Example:

Device(config)# aaa new-model

Enables AAA.

Step 3

aaa authentication dot1x {default} method1

Example:

Device(config)# aaa authentication dot1x default group radius

Creates an 802.1x authentication method list.

To create a default list that is used when a named list is not specified in the authentication command, use the default keyword followed by the method that is to be used in default situations. The default method list is automatically applied to all ports.

For method1, enter the group radius keywords to use the list of all RADIUS servers for authentication.

Note

Though other keywords are visible in the command-line help string, only the group radius keywords are supported.

Step 4

dot1x system-auth-control

Example:

Device(config)# dot1x system-auth-control

Enables 802.1x authentication globally on the switch.

Step 5

aaa authorization network {default} group radius

Example:

Device(config)# aaa authorization network default group radius

(Optional) Configures the switch to use user-RADIUS authorization for all network-related service requests, such as per-user ACLs or VLAN assignment.

Step 6

radius server server name

Example:

Device(config)# radius server rsim address ipv4 124.2.2.12

(Optional) Specifies the IP address of the RADIUS server.

Step 7

address {ipv4 | ipv6} ip address

Example:

Device(config-radius-server)# address ipv4 10.0.1.12

Configures the IP address for the RADIUS server.

Step 8

key string

Example:

Device(config-radius-server)# key rad123

(Optional) Specifies the authentication and encryption key used between the switch and the RADIUS daemon running on the RADIUS server.

Step 9

exit

Example:

Device(config-radius-server)# exit

Exits the RADIUS server mode and enters the global configuration mode.

Step 10

interface interface-id

Example:

Device(config)# interface gigabitethernet1/0/2

Specifies the port connected to the client that is to be enabled for IEEE 802.1x authentication, and enter interface configuration mode.

Step 11

switchport mode access

Example:

Device(config-if)# switchport mode access

(Optional) Sets the port to access mode only if you configured the RADIUS server in Step 6 and Step 7.

Step 12

authentication port-control auto

Example:

Device(config-if)# authentication port-control auto

Enables 802.1x authentication on the port.

Step 13

dot1x pae authenticator

Example:

Device(config-if)# dot1x pae authenticator

Sets the interface Port Access Entity to act only as an authenticator and ignore messages meant for a supplicant.

Step 14

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Configuring the Switch-to-RADIUS-Server Communication

You can globally configure the timeout, retransmission, and encryption key values for all RADIUS servers by using the radius server global configuration command. If you want to configure these options on a per-server basis, use the radius-server timeout , the radius-server retransmit , and the key string global configuration commands.

You also need to configure some settings on the RADIUS server. These settings include the IP address of the switch and the key string to be shared by both the server and the switch. For more information, see the RADIUS server documentation.

Follow these steps to configure the RADIUS server parameters on the switch. This procedure is required.

Before you begin

You must enable authentication, authorization, and accounting (AAA) and specify the authentication method list. A method list describes the sequence and authentication method to be queried to authenticate a user.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

radius server server name

Example:

Device(config)# radius server rsim

Specifies the name the RADIUS server and enters radius server configuration mode.

Step 4

address {ipv4 | ipv6} ip address auth-port port number acct-port port number

Example:

Device(config-radius-server)# address ipv4 124.2.2.12

Specifies the IP address of the RADIUS server.

For auth-port port-number , specify the UDP destination port for authentication requests. The default is 1645. The range is 0 to 65536.

For acct-port port-number , specify the UDP destination port for authentication requests. The default is 1646.

Step 5

key string

Example:

Device(config-radius-server)# key rad123

Specifies the authentication and encryption key used between the Device and the RADIUS daemon running on the RADIUS server.

Note

The key is a text string that must match the encryption key used on the RADIUS server. Always configure the key as the last item in the radius server command. Leading spaces are ignored, but spaces within and at the end of the key are used. If you use spaces in your key, do not enclose the key in quotation marks unless the quotation marks are part of the key.

Step 6

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Configuring the Host Mode

Beginning in privileged EXEC mode, follow these steps to allow multiple hosts (clients) on an IEEE 802.1x-authorized port that has the authentication port-control interface configuration command set to auto . Use the multi-domain keyword to configure and enable multidomain authentication (MDA), which allows both a host and a voice device, such as an IP phone (Cisco or non-Cisco), on the same switch port. This procedure is optional.

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

interface interface-id

Example:

Device(config)# interface gigabitethernet2/0/1

Specifies the port to which multiple hosts are indirectly attached, and enter interface configuration mode.

Step 3

authentication host-mode [multi-auth | multi-domain | multi-host | single-host]

Example:

Device(config-if)# authentication host-mode multi-host

Allows multiple hosts (clients) on an 802.1x-authorized port.

The keywords have these meanings:

- multi-auth –Allow multiple authenticated clients on both the voice VLAN and data VLAN.

Note

The multi-auth keyword is only available with the authentication host-mode command.

- multi-host –Allow multiple hosts on an 802.1x-authorized port after a single host has been authenticated.

- multi-domain –Allow both a host and a voice device, such as an IP phone (Cisco or non-Cisco), to be authenticated on an IEEE 802.1x-authorized port.

Note

You must configure the voice VLAN for the IP phone when the host mode is set to multi-domain .

Make sure that the authentication port-control interface configuration command is set to auto for the specified interface.

Step 4

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Configuring Periodic Re-Authentication

You can enable periodic 802.1x client re-authentication and specify how often it occurs. If you do not specify a time period before enabling re-authentication, the number of seconds between attempts is 3600.

Beginning in privileged EXEC mode, follow these steps to enable periodic re-authentication of the client and to configure the number of seconds between re-authentication attempts. This procedure is optional.

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

interface interface-id

Example:

Device(config)# interface gigabitethernet2/0/1

Specifies the port to be configured, and enter interface configuration mode.

Step 3

authentication periodic

Example:

Device(config-if)# authentication periodic

Enables periodic re-authentication of the client, which is disabled by default.

Note

The default value is 3600 seconds. To change the value of the reauthentication timer or to have the switch use a RADIUS-provided session timeout, enter the authentication timer reauthenticate command.

Step 4

authentication timer {{[inactivity | reauthenticate | restart | unauthorized]} {value}}

Example:

Device(config-if)# authentication timer reauthenticate 180

Sets the number of seconds between re-authentication attempts.

The authentication timer keywords have these meanings:

- inactivity —Interval in seconds after which if there is no activity from the client then it is unauthorized

- reauthenticate —Time in seconds after which an automatic re-authentication attempt is initiated

- restart value —Interval in seconds after which an attempt is made to authenticate an unauthorized port

- unauthorized value —Interval in seconds after which an unauthorized session will get deleted

This command affects the behavior of the switch only if periodic re-authentication is enabled.

Step 5

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Changing the Quiet Period

When the switch cannot authenticate the client, the switch remains idle for a set period of time and then tries again. The authentication timer restart interface configuration command controls the idle period. A failed authentication of the client might occur because the client provided an invalid password. You can provide a faster response time to the user by entering a number smaller than the default.

Beginning in privileged EXEC mode, follow these steps to change the quiet period. This procedure is optional.

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

interface interface-id

Example:

Device(config)# interface gigabitethernet2/0/1

Specifies the port to be configured, and enter interface configuration mode.

Step 3

authentication timer restart seconds

Example:

Device(config-if)# authentication timer restart 30

Sets the number of seconds that the switch remains in the quiet state following a failed authentication exchange with the client.

The range is 1 to 65535 seconds; the default is 60.

Step 4

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Step 5

show authentication sessions interface interface-id

Example:

Device# show authentication sessions interface gigabitethernet2/0/1

Verifies your entries.

Step 6

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Changing the Switch-to-Client Retransmission Time

The client responds to the EAP-request/identity frame from the switch with an EAP-response/identity frame. If the switch does not receive this response, it waits a set period of time (known as the retransmission time) and then resends the frame.

Note

You should change the default value of this command only to adjust for unusual circumstances such as unreliable links or specific behavioral problems with certain clients and authentication servers.

Beginning in privileged EXEC mode, follow these steps to change the amount of time that the switch waits for client notification. This procedure is optional.

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

interface interface-id

Example:

Device(config)# interface gigabitethernet2/0/1

Specifies the port to be configured, and enter interface configuration mode.

Step 3

authentication timer reauthenticate seconds

Example:

Device(config-if)# authentication timer reauthenticate 60

Sets the number of seconds that the switch waits for a response to an EAP-request/identity frame from the client before resending the request.

The range is 1 to 65535 seconds; the default is 5.

Step 4

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Step 5

show authentication sessions interface interface-id

Example:

Device# show authentication sessions interface gigabitethernet2/0/1

Verifies your entries.

Step 6

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Setting the Switch-to-Client Frame-Retransmission Number

In addition to changing the switch-to-client retransmission time, you can change the number of times that the switch sends an EAP-request/identity frame (assuming no response is received) to the client before restarting the authentication process.

Note

You should change the default value of this command only to adjust for unusual circumstances such as unreliable links or specific behavioral problems with certain clients and authentication servers.

Beginning in privileged EXEC mode, follow these steps to set the switch-to-client frame-retransmission number. This procedure is optional.

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

interface interface-id

Example:

Device(config)# interface gigabitethernet2/0/1

Specifies the port to be configured, and enter interface configuration mode.

Step 3

dot1x max-reauth-req count

Example:

Device(config-if)# dot1x max-reauth-req 5

Sets the number of times that the switch sends an EAP-request/identity frame to the client before restarting the authentication process. The range is 1 to 10; the default is 2.

Step 4

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Setting the Re-Authentication Number

You can also change the number of times that the switch restarts the authentication process before the port changes to the unauthorized state.

Note

You should change the default value of this command only to adjust for unusual circumstances such as unreliable links or specific behavioral problems with certain clients and authentication servers.

Beginning in privileged EXEC mode, follow these steps to set the re-authentication number. This procedure is optional.

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

interface interface-id

Example:

Device# interface gigabitethernet2/0/1

Specifies the port to be configured, and enter interface configuration mode.

Step 3

switchport mode access

Example:

Device(config-if)# switchport mode access

Sets the port to access mode only if you previously configured the RADIUS server.

Step 4

dot1x max-req count

Example:

Device(config-if)# dot1x max-req 4

Sets the number of times that the switch restarts the authentication process before the port changes to the unauthorized state. The range is 0 to 10; the default is 2.

Step 5

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Enabling MAC Move

MAC move allows an authenticated host to move from one port on the switch to another.

Beginning in privileged EXEC mode, follow these steps to globally enable MAC move on the switch. This procedure is optional.

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

authentication mac-move permit

Example:

Device(config)# authentication mac-move permit

Enables MAC move on the switch. Default is deny.

In Session Aware Networking mode, the default CLI is access-session mac-move deny. To enable Mac Move in Session Aware Networking, use the no access-session mac-move global configuration command.

In legacy mode (IBNS 1.0), default value for mac-move is deny and in C3PL mode (IBNS 2.0) default value is permit .

Step 3

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 4

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 5

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Enabling MAC Replace

MAC replace allows a host to replace an authenticated host on a port.

Beginning in privileged EXEC mode, follow these steps to enable MAC replace on an interface. This procedure is optional.

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

interface interface-id

Example:

Device(config)# interface gigabitethernet2/0/2

Specifies the port to be configured, and enter interface configuration mode.

Step 3

authentication violation {protect | replace | restrict | shutdown}

Example:

Device(config-if)# authentication violation replace

Use the replace keyword to enable MAC replace on the interface. The port removes the current session and initiates authentication with the new host.

The other keywords have these effects:

- protect : the port drops packets with unexpected MAC addresses without generating a system message.

- restrict : violating packets are dropped by the CPU and a system message is generated.

- shutdown : the port is error disabled when it receives an unexpected MAC address.

Step 4

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Step 5

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 6

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Configuring 802.1x Accounting

Enabling AAA system accounting with 802.1x accounting allows system reload events to be sent to the accounting RADIUS server for logging. The server can then infer that all active 802.1x sessions are closed.

Note

In Cisco IOS XE Denali 16.3.x and Cisco IOS XE Everest 16.6.x, periodic AAA accounting updates are not supported. The switch does not send periodic interim accounting records to the accounting server. Periodic AAA accounting updates are available in Cisco IOS XE Fuji 16.9.x and later releases.

Because RADIUS uses the unreliable UDP transport protocol, accounting messages might be lost due to poor network conditions. If the switch does not receive the accounting response message from the RADIUS server after a configurable number of retransmissions of an accounting request, this system message appears:

Accounting message %s for session %s failed to receive Accounting Response.

When the stop message is not sent successfully, this message appears:

00:09:55: %RADIUS-4-RADIUS_DEAD: RADIUS server 172.20.246.201:1645,1646 is not responding.

Note

You must configure the RADIUS server to perform accounting tasks, such as logging start, stop, and interim-update messages and time stamps. To turn on these functions, enable logging of “Update/Watchdog packets from this AAA client” in your RADIUS server Network Configuration tab. Next, enable “CVS RADIUS Accounting” in your RADIUS server System Configuration tab.

Beginning in privileged EXEC mode, follow these steps to configure 802.1x accounting after AAA is enabled on your switch. This procedure is optional.

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

interface interface-id

Example:

Device(config)# interface gigabitethernet1/0/3

Specifies the port to be configured, and enter interface configuration mode.

Step 3

aaa accounting dot1x default start-stop group radius

Example:

Device(config-if)# aaa accounting dot1x default start-stop group radius

Enables 802.1x accounting using the list of all RADIUS servers.

Step 4

aaa accounting system default start-stop group radius

Example:

Device(config-if)# aaa accounting system default start-stop group radius

(Optional) Enables system accounting (using the list of all RADIUS servers) and generates system accounting reload event messages when the switch reloads.

Step 5

end

Example:

Device(config-if)# end

Returns to privileged EXEc mode.

Step 6

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 7

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Configuring a Guest VLAN

When you configure a guest VLAN, clients that are not 802.1x-capable are put into the guest VLAN when the server does not receive a response to its EAP request/identity frame. Clients that are 802.1x-capable but that fail authentication are not granted network access. The switch supports guest VLANs in single-host or multiple-hosts mode.

Beginning in privileged EXEC mode, follow these steps to configure a guest VLAN. This procedure is optional.

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

interface interface-id

Example:

Device(config)# interface gigabitethernet 2/0/2

Specifies the port to be configured, and enter interface configuration mode.

Step 3

Use one of the following:

- switchport mode access

- switchport mode private-vlan host

Example:

Device(config-if)# switchport mode private-vlan host

- Sets the port to access mode.

- Configures the Layer 2 port as a private-VLAN host port.

Step 4

authentication event no-response action authorize vlan vlan-id

Example:

Device(config-if)# authentication event no-response action authorize vlan 2

Specifies an active VLAN as an 802.1x guest VLAN. The range is 1 to 4094.

You can configure any active VLAN except an internal VLAN (routed port), an RSPAN VLAN or a voice VLAN as an 802.1x guest VLAN.

Step 5

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Configuring a Restricted VLAN

When you configure a restricted VLAN on a switch stack or a switch, clients that are IEEE 802.1x-compliant are moved into the restricted VLAN when the authentication server does not receive a valid username and password. The switch supports restricted VLANs only in single-host mode.

Beginning in privileged EXEC mode, follow these steps to configure a restricted VLAN. This procedure is optional.

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

interface interface-id

Example:

Device(config)# interface gigabitethernet 2/0/2

Specifies the port to be configured, and enter interface configuration mode.

Step 3

Use one of the following:

- switchport mode access

- switchport mode private-vlan host

Example:

Device(config-if)# switchport mode access

- Sets the port to access mode.

- Configures the Layer 2 port as a private-VLAN host port.

Step 4

authentication port-control auto

Example:

Device(config-if)# authentication port-control auto

Enables 802.1x authentication on the port.

Step 5

authentication event fail action authorize vlan vlan-id

Example:

Device(config-if)# authentication event fail action authorize vlan 2

Specifies an active VLAN as an 802.1x restricted VLAN. The range is 1 to 4094.

You can configure any active VLAN except an internal VLAN (routed port), an RSPAN VLAN or a voice VLAN as an 802.1x restricted VLAN.

Step 6

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

- Configuring Number of Authentication Attempts on a Restricted VLAN

Configuring Number of Authentication Attempts on a Restricted VLAN

You can configure the maximum number of authentication attempts allowed before a user is assigned to the restricted VLAN by using the authentication event retry retry count interface configuration command. The range of allowable authentication attempts is 1 to 3. The default is 3 attempts.

Beginning in privileged EXEC mode, follow these steps to configure the maximum number of allowed authentication attempts. This procedure is optional.

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

interface interface-id

Example:

Device(config)# interface gigabitethernet 2/0/3

Specifies the port to be configured, and enter interface configuration mode.

Step 3

Use one of the following:

- switchport mode access

- switchport mode private-vlan host

Example:

or

Device(config-if)# switchport mode access

- Sets the port to access mode.

- Configures the Layer 2 port as a private-VLAN host port.

Step 4

authentication port-control auto

Example:

Device(config-if)# authentication port-control auto

Enables 802.1x authentication on the port.

Step 5

authentication event fail action authorize vlan vlan-id

Example:

Device(config-if)# authentication event fail action authorize vlan 8

Specifies an active VLAN as an 802.1x restricted VLAN. The range is 1 to 4094.

You can configure any active VLAN except an internal VLAN (routed port), an RSPAN VLAN or a voice VLAN as an 802.1x restricted VLAN.

Step 6

authentication event retry retry count

Example:

Device(config-if)# authentication event retry 2

Specifies a number of authentication attempts to allow before a port moves to the restricted VLAN. The range is 1 to 3, and the default is 3.

Step 7

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Configuring 802.1x Inaccessible Authentication Bypass with Critical Voice VLAN

Beginning in privileged EXEC mode, follow these steps to configure critical voice VLAN on a port and enable the inaccessible authentication bypass feature.

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

aaa new-model

Example:

Device(config)# aaa new-model

Enables AAA.

Step 3

radius-server dead-criteria{time seconds } [tries number]

Example:

Device(config)# radius-server dead-criteria time 20 tries 10

Sets the conditions that determine when a RADIUS server is considered un-available or down (dead).

- time— 1 to 120 seconds. The switch dynamically determines a default seconds value between 10 and 60.

- number—1 to 100 tries. The switch dynamically determines a default triesnumber between 10 and 100.

Step 4

radius-serverdeadtimeminutes

Example:

Device(config)# radius-server deadtime 60

(Optional) Sets the number of minutes during which a RADIUS server is not sent requests. The range is from 0 to 1440 minutes (24 hours). The default is 0 minutes.

Step 5

radius server server name

Example:

Device(config)# radius server rsim address ipv4 124.2.2.12

(Optional) Specifies the IP address of the RADIUS server.

Step 6

address {ipv4 | ipv6} ip address auth-port port_number acct-port port_number

Example:

Device(config-radius-server)# address ipv4 10.0.1.2 auth-port 1550 acct-port 1560

Configures the IP address for the RADIUS server.

Step 7

key string

Example:

Device(config-radius-server)# key rad123

(Optional) Specifies the authentication and encryption key used between the switch and the RADIUS daemon running on the RADIUS server.

Step 8

exit

Example:

Device(config-radius-server)# exit

Exits the RADIUS server mode and enters the global configuration mode.

Step 9

dot1x critical {eapol | recovery delay milliseconds}

Example:

Device(config)# dot1x critical eapol
(config)# dot1x critical recovery delay 2000

(Optional) Configure the parameters for inaccessible authentication bypass:

- eapol—Specify that the switch sends an EAPOL-Success message when the switch successfully authenticates the critical port.

- recovery delaymilliseconds—Set the recovery delay period during which the switch waits to re-initialize a critical port when a RADIUS server that was unavailable becomes available. The range is from 1 to 10000 milliseconds. The default is 1000 milliseconds (a port can be re-initialized every second).

Step 10

interface interface-id

Example:

Device(config)# interface gigabitethernet 1/0/1

Specify the port to be configured, and enter interface configuration mode.

Step 11

authentication event server dead action {authorize | reinitialize} vlan vlan-id]

Example:

Device(config-if)# authentication event server dead action
reinitialicze vlan 20

Use these keywords to move hosts on the port if the RADIUS server is unreachable:

- authorize—Move any new hosts trying to authenticate to the user-specified critical VLAN.

- reinitialize—Move all authorized hosts on the port to the user-specified critical VLAN.

Step 12

switchport voice vlan vlan-id

Example:

Device(config-if)# switchport voice vlan

Specifies the voice VLAN for the port. The voice VLAN cannot be the same as the critical data VLAN configured in Step 6.

Step 13

authentication event server dead action authorize voice

Example:

Device(config-if)#  authentication event server dead action
authorize voice

Configures critical voice VLAN to move data traffic on the port to the voice VLAN if the RADIUS server is unreachable.

Step 14

show authentication interface interface-id

Example:

Device(config-if)#  do show authentication interface gigabit 1/0/1

(Optional) Verify your entries.

Step 15

copy running-config startup-config

Example:

Device(config-if)#  do copy running-config startup-config

(Optional) Verify your entries.

Example

To return to the RADIUS server default settings, use the no radius-server dead-criteria, the no radius-server deadtime, and the no radius server global configuration commands. To disable inaccessible authentication bypass, use the no authentication event server dead action interface configuration command. To disable critical voice VLAN, use the no authentication event server dead action authorize voice interface configuration command.

- Example of Configuring Inaccessible Authentication Bypass

Example of Configuring Inaccessible Authentication Bypass

This example shows how to configure the inaccessible authentication bypass feature:

Device(config)# radius-server dead-criteria time 30 tries 20
Device(config)# radius-server deadtime 60
Device(config)# radius server server1
Device(config-radius-server)# address ipv4 172.29.36.49 acct-port 1618 auth-port 1612
Device(config-radius-server)# key abc1234
Device(config-radius-server)# exit
Device(config)# dot1x critical eapol
Device(config)# dot1x critical recovery delay 2000
Device(config)# interface gigabitethernet 1/0/1
Device(config-if)# dot1x critical
Device(config-if)# dot1x critical recovery action reinitialize
Device(config-if)# dot1x critical vlan 20
Device(config-if)# end

Configuring 802.1x Authentication with WoL

Beginning in privileged EXEC mode, follow these steps to enable 802.1x authentication with WoL. This procedure is optional.

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

interface interface-id

Example:

Device(config)# interface gigabitethernet2/0/3

Specifies the port to be configured, and enter interface configuration mode.

Step 3

authentication control-direction {both | in}

Example:

Device(config-if)# authentication control-direction both

Enables 802.1x authentication with WoL on the port, and use these keywords to configure the port as bidirectional or unidirectional.

- both —Sets the port as bidirectional. The port cannot receive packets from or send packets to the host. By default, the port is bidirectional.

- in —Sets the port as unidirectional. The port can send packets to the host but cannot receive packets from the host.

Step 4

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Step 5

show authentication sessions interface interface-id

Example:

Device# show authentication sessions interface gigabitethernet2/0/3

Verifies your entries.

Step 6

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Configuring MAC Authentication Bypass

Beginning in privileged EXEC mode, follow these steps to enable MAC authentication bypass. This procedure is optional.

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

interface interface-id

Example:

Device(config)# interface gigabitethernet 2/0/1

Specifies the port to be configured, and enter interface configuration mode.

Step 3

authentication port-control auto

Example:

Device(config-if)# authentication port-control auto

Enables 802.1x authentication on the port.

Step 4

mab [eap]

Example:

Device(config-if)# mab

Enables MAC authentication bypass.

(Optional) Use the eap keyword to configure the switch to use EAP for authorization.

Step 5

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Configuring 802.1x User Distribution

Beginning in privileged EXEC mode, follow these steps to configure a VLAN group and to map a VLAN to it:

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

vlan group vlan-group-name vlan-list vlan-list

Example:

Device(config)# vlan group eng-dept vlan-list 10

Configures a VLAN group, and maps a single VLAN or a range of VLANs to it.

Step 3

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 4

no vlan group vlan-group-name vlan-list vlan-list

Example:

Device(config)# no vlan group eng-dept vlan-list 10

Clears the VLAN group configuration or elements of the VLAN group configuration.

- Example of Configuring VLAN Groups

Example of Configuring VLAN Groups

This example shows how to configure the VLAN groups, to map the VLANs to the groups, to and verify the VLAN group configurations and mapping to the specified VLANs:

Device(config)# vlan group eng-dept vlan-list 10

Device(config)# show vlan group group-name eng-dept
Group Name                      Vlans Mapped
-------------                   --------------
eng-dept                        10

Device(config)# show dot1x vlan-group all
Group Name                      Vlans Mapped
-------------                   --------------
eng-dept                        10
hr-dept                         20

This example shows how to add a VLAN to an existing VLAN group and to verify that the VLAN was added:

Device(config)# vlan group eng-dept vlan-list 30
Device(config)# show vlan group eng-dept
Group Name                      Vlans Mapped
-------------                   --------------
eng-dept                        10,30

This example shows how to remove a VLAN from a VLAN group:

Device# no vlan group eng-dept vlan-list 10

This example shows that when all the VLANs are cleared from a VLAN group, the VLAN group is cleared:

Device(config)# no vlan group eng-dept vlan-list 30
Vlan 30 is successfully cleared from vlan group eng-dept.

Device(config)# show vlan group group-name eng-dept

This example shows how to clear all the VLAN groups:

Device(config)# no vlan group end-dept vlan-list all
Device(config)# show vlan-group all

For more information about these commands, see the Cisco IOS Security Command Reference.

Configuring NAC Layer 2 802.1x Validation

You can configure NAC Layer 2 802.1x validation, which is also referred to as 802.1x authentication with a RADIUS server.

Beginning in privileged EXEC mode, follow these steps to configure NAC Layer 2 802.1x validation. The procedure is optional.

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

interface interface-id

Example:

Device(config)# interface gigabitethernet2/0/3

Specifies the port to be configured, and enter interface configuration mode.

Step 3

switchport mode access

Example:

Device(config-if)# switchport mode access

Sets the port to access mode only if you configured the RADIUS server.

Step 4

authentication event no-response action authorize vlan vlan-id

Example:

Device(config-if)# authentication event no-response action authorize vlan 8

Specifies an active VLAN as an 802.1x guest VLAN. The range is 1 to 4094.

You can configure any active VLAN except an internal VLAN (routed port), an RSPAN VLAN, or a voice VLAN as an 802.1x guest VLAN.

Step 5

authentication periodic

Example:

Device(config-if)# authentication periodic

Enables periodic re-authentication of the client, which is disabled by default.

Step 6

authentication timer reauthenticate

Example:

Device(config-if)# authentication timer reauthenticate

Sets re-authentication attempt for the client (set to one hour).

This command affects the behavior of the switch only if periodic re-authentication is enabled.

Step 7

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Step 8

show authentication sessions interface interface-id

Example:

Device# show authentication sessions interface gigabitethernet2/0/3

Verifies your entries.

Step 9

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Configuring an Authenticator Switch with NEAT

Configuring this feature requires that one switch outside a wiring closet is configured as a supplicant and is connected to an authenticator switch.

Note

- The authenticator switch interface configuration must be restored to access mode by explicitly flapping it if a line card is removed and inserted in the chassis when CISP or NEAT session is active.

- The cisco-av-pairs must be configured as device-traffic-class=switch on the ISE, which sets the interface as a trunk after the supplicant is successfully authenticated.

Beginning in privileged EXEC mode, follow these steps to configure a switch as an authenticator:

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

cisp enable

Example:

Device(config)# cisp enable

Enables CISP.

Step 3

interface interface-id

Example:

Device(config)# interface gigabitethernet 2/0/1

Specifies the port to be configured, and enter interface configuration mode.

Step 4

switchport mode access

Example:

Device(config-if)# switchport mode access

Sets the port mode to access .

Step 5

authentication port-control auto

Example:

Device(config-if)# authentication port-control auto

Sets the port-authentication mode to auto.

Step 6

dot1x pae authenticator

Example:

Device(config-if)# dot1x pae authenticator

Configures the interface as a port access entity (PAE) authenticator.

Step 7

spanning-tree portfast

Example:

Device(config-if)# spanning-tree portfast trunk

Enables Port Fast on an access port connected to a single workstation or server..

Step 8

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Step 9

show running-config interface interface-id

Example:

Device# show running-config interface gigabitethernet 2/0/1

Verifies your configuration.

Step 10

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Note

Saving changes to the configuration file will mean that the authenticator interface will continue to be in trunk mode after reload.  If you want the authenticator interface to remain as an access port, do not save your changes to the configuration file.

Configuring a Supplicant Switch with NEAT

Beginning in privileged EXEC mode, follow these steps to configure a switch as a supplicant:

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

cisp enable

Example:

Device(config)# cisp enable

Enables CISP.

Step 3

dot1x credential s profile

Example:

Device(config)# dot1x credentials test

Creates 802.1x credentials profile. This must be attached to the port that is configured as supplicant.

Step 4

username suppswitch

Example:

Device(config)# username suppswitch

Creates a username.

Step 5

password password

Example:

Device(config)# password myswitch

Creates a password for the new username.

Step 6

dot1x supplicant force-multicast

Example:

Device(config)# dot1x supplicant force-multicast

Forces the switch to send only multicast EAPOL packets when it receives either unicast or multicast packets.

This also allows NEAT to work on the supplicant switch in all host modes.

Step 7

interface interface-id

Example:

Device(config)# interface gigabitethernet1/0/1

Specifies the port to be configured, and enter interface configuration mode.

Step 8

switchport trunk encapsulation dot1q

Example:

Device(config-if)# switchport trunk encapsulation dot1q

Sets the port to trunk mode.

Step 9

switchport mode trunk

Example:

Device(config-if)# switchport mode trunk

Configures the interface as a VLAN trunk port.

Step 10

dot1x pae supplicant

Example:

Device(config-if)# dot1x pae supplicant

Configures the interface as a port access entity (PAE) supplicant.

Step 11

dot1x credentials profile-name

Example:

Device(config-if)# dot1x credentials test

Attaches the 802.1x credentials profile to the interface.

Step 12

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Step 13

show running-config interface interface-id

Example:

Device# show running-config interface gigabitethernet1/0/1

Verifies your configuration.

Step 14

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Step 15

Configuring NEAT with Auto Smartports Macros

You can also use an Auto Smartports user-defined macro instead of the switch VSA to configure the authenticator switch. For more information, see the Auto Smartports Configuration Guide for this release.

Configuring 802.1x Authentication with Downloadable ACLs and Redirect URLs

Note

You must configure a downloadable ACL on the ACS before downloading it to the switch.

After authentication on the port, you can use the show ip access-list privileged EXEC command to display the downloaded ACLs on the port.

- Configuring Downloadable ACLs

- Configuring a Downloadable Policy

Configuring Downloadable ACLs

The policies take effect after client authentication and the client IP address addition to the IP device tracking table. The switch then applies the downloadable ACL to the port.

Beginning in privileged EXEC mode:

Before you begin

SISF-Based device tracking is a prerequisite to configuring 802.1x authentication. Ensure that you have enabled device tracking programmatically or manually. For more information, see the Confguring SISF-Based Tracking chapter.

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

aaa new-model

Example:

Device(config)# aaa new-model

Enables AAA.

Step 3

aaa authorization network default local group radius

Example:

Device(config)# aaa authorization network default local group radius

Sets the authorization method to local. To remove the authorization method, use the no aaa authorization network default local group radius command.

Step 4

radius-server vsa send authentication

Example:

Device(config)# radius-server vsa send authentication

Configures the radius vsa send authentication.

Step 5

interface interface-id

Example:

Device(config)# interface gigabitethernet2/0/4

Specifies the port to be configured, and enter interface configuration mode.

Step 6

ip access-group acl-id in

Example:

Device(config-if)# ip access-group default_acl in

Configures the default ACL on the port in the input direction.

Note

The acl-id is an access list name or number.

Step 7

show running-config interface interface-id

Example:

Device(config-if)# show running-config interface gigabitethernet2/0/4

Verifies your configuration.

Step 8

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Configuring a Downloadable Policy

Beginning in privileged EXEC mode:

Before you begin

SISF-Based device tracking is a prerequisite to configuring 802.1x authentication. Ensure that you have enabled device tracking programmatically or manually.

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

access-list access-list-number { deny | permit } { hostname | any | host } log

Example:

Device(config)# access-list 1 deny any log

Defines the default port ACL.

The access-list-number is a decimal number from 1 to 99 or 1300 to 1999.

Enter deny or permit to specify whether to deny or permit access if conditions are matched.

The source is the source address of the network or host that sends a packet, such as this:

- hostname: The 32-bit quantity in dotted-decimal format.

- any: The keyword any as an abbreviation for source and source-wildcard value of 0.0.0.0 255.255.255.255. You do not need to enter a source-wildcard value.

- host: The keyword host as an abbreviation for source and source-wildcard of source 0.0.0.0.

(Optional) Applies the source-wildcard wildcard bits to the source.

(Optional) Enters log to cause an informational logging message about the packet that matches the entry to be sent to the console.

Step 3

interface interface-id

Example:

Device(config)# interface gigabitethernet2/0/2

Enters interface configuration mode.

Step 4

ip access-group acl-id in

Example:

Device(config-if)# ip access-group default_acl in

Configures the default ACL on the port in the input direction.

Note

The acl-id is an access list name or number.

Step 5

exit

Example:

Device(config-if)# exit

Returns to global configuration mode.

Step 6

aaa new-model

Example:

Device(config)# aaa new-model

Enables AAA.

Step 7

aaa authorization network default group radius

Example:

Device(config)# aaa authorization network default group radius

Sets the authorization method to local. To remove the authorization method, use the no aaa authorization network default group radius command.

Step 8

radius-server vsa send authentication

Example:

Device(config)# radius-server vsa send authentication

Configures the network access server to recognize and use vendor-specific attributes.

Note

The downloadable ACL must be operational.

Step 9

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Configuring VLAN ID-based MAC Authentication

Beginning in privileged EXEC mode, follow these steps:

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

mab request format attribute 32 vlan access-vlan

Example:

Device(config)# mab request format attribute 32 vlan access-vlan

Enables VLAN ID-based MAC authentication.

Step 3

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Configuring Flexible Authentication Ordering

The examples used in the instructions below changes the order of Flexible Authentication Ordering so that MAB is attempted before IEEE 802.1X authentication (dot1x). MAB is configured as the first authentication method, so MAB will have priority over all other authentication methods.

Beginning in privileged EXEC mode, follow these steps:

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

interface interface-id

Example:

Device(config)# interface gigabitethernet 1/0/1

Specifies the port to be configured, and enter interface configuration mode.

Step 3

switchport mode access

Example:

Device(config-if)# switchport mode access

Sets the port to access mode only if you previously configured the RADIUS server.

Step 4

authentication order [ dot1x | mab ] | {webauth}

Example:

Device(config-if)# authentication order mab dot1x

(Optional) Sets the order of authentication methods used on a port.

Step 5

authentication priority [ dot1x | mab ] | {webauth}

Example:

Device(config-if)# authentication priority mab dot1x

(Optional) Adds an authentication method to the port-priority list.

Step 6

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Configuring Open1x

Beginning in privileged EXEC mode, follow these steps to enable manual control of the port authorization state:

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

interface interface-id

Example:

Device(config)# interface gigabitethernet 1/0/1

Specifies the port to be configured, and enter interface configuration mode.

Step 3

switchport mode access

Example:

Device(config-if)# switchport mode access

Sets the port to access mode only if you configured the RADIUS server.

Step 4

authentication control-direction {both | in}

Example:

Device(config-if)# authentication control-direction both

(Optional) Configures the port control as unidirectional or bidirectional.

Step 5

authentication fallback name

Example:

Device(config-if)# authentication fallback profile1

(Optional) Configures a port to use web authentication as a fallback method for clients that do not support 802.1x authentication.

Step 6

authentication host-mode [multi-auth | multi-domain | multi-host | single-host]

Example:

Device(config-if)# authentication host-mode multi-auth

(Optional) Sets the authorization manager mode on a port.

Step 7

authentication open

Example:

Device(config-if)# authentication open

(Optional) Enables or disable open access on a port.

Step 8

authentication order [ dot1x | mab ] | {webauth}

Example:

Device(config-if)# authentication order dot1x webauth

(Optional) Sets the order of authentication methods used on a port.

Step 9

authentication periodic

Example:

Device(config-if)# authentication periodic

(Optional) Enables or disable reauthentication on a port.

Step 10

authentication port-control {auto | force-authorized | force-un authorized}

Example:

Device(config-if)# authentication port-control auto

(Optional) Enables manual control of the port authorization state.

Step 11

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Disabling 802.1x Authentication on the Port

You can disable 802.1x authentication on the port by using the no dot1x pae interface configuration command.

Beginning in privileged EXEC mode, follow these steps to disable 802.1x authentication on the port. This procedure is optional.

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

interface interface-id

Example:

Device(config)# interface gigabitethernet 2/0/1

Specifies the port to be configured, and enter interface configuration mode.

Step 3

switchport mode access

Example:

Device(config-if)# switchport mode access

(Optional) Sets the port to access mode only if you configured the RADIUS server.

Step 4

no dot1x pae authenticator

Example:

Device(config-if)# no dot1x pae authenticator

Disables 802.1x authentication on the port.

Step 5

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Resetting the 802.1x Authentication Configuration to the Default Values

Beginning in privileged EXEC mode, follow these steps to reset the 802.1x authentication configuration to the default values. This procedure is optional.

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

interface interface-id

Example:

Device(config)# interface gigabitethernet 1/0/2

Enters interface configuration mode, and specify the port to be configured.

Step 3

dot1x default

Example:

Device(config-if)# dot1x default

Resets the 802.1x parameters to the default values.

Step 4

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Monitoring 802.1x Statistics and Status

Privileged EXEC show Commands

Command

Purpose

show dot1x all statistics

Displays 802.1x statistics for all ports

show dot1x interface interface-id statistics

Displays 802.1x statistics for a specific port

show dot1x all [count | details | statistics | summary]

Displays the 802.1x administrative and operational status for a switch

show dot1x interface interface-id

Displays the 802.1x administrative and operational status for a specific port

Global Configuration Commands

Command

Purpose

no dot1x logging verbose

Filters verbose 802.1x authentication messages (beginning with Cisco IOS Release 12.2(55)SE)

For detailed information about the fields in these displays, see the command reference for this release.

Chapter 21. Web-Based Authentication

This chapter describes how to configure web-based authentication on the device. It contains these sections:

- Web-Based Authentication Overview

- Verifying Web-Based Authentication Status

Web-Based Authentication Overview

Use the web-based authentication feature, known as web authentication proxy, to authenticate end users on host systems that do not run the IEEE 802.1x supplicant.

When you initiate an HTTP session, web-based authentication intercepts ingress HTTP packets from the host and sends an HTML login page to the users. The users enter their credentials, which the web-based authentication feature sends to the authentication, authorization, and accounting (AAA) server for authentication.

If authentication succeeds, web-based authentication sends a Login-Successful HTML page to the host and applies the access policies returned by the AAA server.

If authentication fails, web-based authentication forwards a Login-Fail HTML page to the user, prompting the user to retry the login. If the user exceeds the maximum number of attempts, web-based authentication forwards a Login-Expired HTML page to the host, and the user is placed on a watch list for a waiting period.

Note

HTTPS traffic interception for central web authentication redirect is not supported.

Note

You should use global parameter-map (for method-type, custom, and redirect) only for using the same web authentication methods like consent, web consent, and webauth, for all the clients and SSIDs. This ensures that all the clients have the same web-authentication method.

If the requirement is to use Consent for one SSID and Web-authentication for another SSID, then you should use two named parameter-maps. You should configure Consent in first parameter-map and configure webauth in second parameter-map.

Note

The traceback that you receive when webauth client tries to do authentication does not have any performance or behavioral impact. It happens rarely when the context for which FFM replied back to EPM for ACL application is already dequeued (possibly due to timer expiry) and the session becomes ‘unauthorized’.

Based on where the web pages are hosted, the local web authention can be categorozied as follows:

- Internal—The internal default HTML pages (Login, Success, Fail, and Expire) in the controller are used during the local web authentication.

- Customized—The customized web pages (Login, Success, Fail, and Expire) are downloaded onto the controller and used during the local web authentication.

- External—The customized web pages are hosted on the external web server instead of using the in-built or custom web pages.

Based on the various web authentication pages, the types of web authentication are as follows:

- Webauth—This is a basic web authentication. Herein, the controller presents a policy page with the user name and password. You need to enter the correct credentials to access the network.

- Consent or web-passthrough—Herein, the controller presents a policy page with the Accept or Deny buttons. You need to click the Accept button to access the network.

- Webconsent—This is a combination of webauth and consent web authentication types. Herein, the controller presents a policy page with Accept or Deny buttons along with user name or password. You need to enter the correct credentials and click the Accept button to access the network.

- Device Roles

- Host Detection

- Session Creation

- Authentication Process

- Local Web Authentication Banner

- Web Authentication Customizable Web Pages

- Web-based Authentication Interactions with Other Features

Device Roles

With web-based authentication, the devices in the network have these specific roles:

- Client—The device (workstation) that requests access to the LAN and the services and responds to requests from the switch. The workstation must be running an HTML browser with Java Script enabled.

- Authentication server—Authenticates the client. The authentication server validates the identity of the client and notifies the switch that the client is authorized to access the LAN and the switch services or that the client is denied.

- Switch—Controls the physical access to the network based on the authentication status of the client. The switch acts as an intermediary (proxy) between the client and the authentication server, requesting identity information from the client, verifying that information with the authentication server, and relaying a response to the client.

Web-Based Authentication Device Roles

Host Detection

The switch maintains an IP device tracking table to store information about detected hosts.

Note

By default, the IP device tracking feature is disabled on a switch. You must enable the IP device tracking feature to use web-based authentication.

For Layer 2 interfaces, web-based authentication detects IP hosts by using these mechanisms:

- ARP based trigger—ARP redirect ACL allows web-based authentication to detect hosts with a static IP address or a dynamic IP address.

- Dynamic ARP inspection

- DHCP snooping—Web-based authentication is notified when the switch creates a DHCP-binding entry for the host.

Session Creation

When web-based authentication detects a new host, it creates a session as follows:

- Reviews the exception list.

If the host IP is included in the exception list, the policy from the exception list entry is applied, and the session is established.

- Reviews for authorization bypass

If the host IP is not on the exception list, web-based authentication sends a nonresponsive-host (NRH) request to the server.

If the server response is access accepted, authorization is bypassed for this host. The session is established.

- Sets up the HTTP intercept ACL

If the server response to the NRH request is access rejected, the HTTP intercept ACL is activated, and the session waits for HTTP traffic from the host.

Authentication Process

When you enable web-based authentication, these events occur:

- The user initiates an HTTP session.

- The HTTP traffic is intercepted, and authorization is initiated. The switch sends the login page to the user. The user enters a username and password, and the switch sends the entries to the authentication server.

- If the authentication succeeds, the switch downloads and activates the user’s access policy from the authentication server. The login success page is sent to the user.

- If the authentication fails, the switch sends the login fail page. The user retries the login. If the maximum number of attempts fails, the switch sends the login expired page, and the host is placed in a watch list. After the watch list times out, the user can retry the authentication process.

- If the authentication server does not respond to the switch, and if an AAA fail policy is configured, the switch applies the failure access policy to the host. The login success page is sent to the user.

- The switch reauthenticates a client when the host does not respond to an ARP probe on a Layer 2 interface, or when the host does not send any traffic within the idle timeout on a Layer 3 interface.

- The switch reauthenticates a client when the host does not respond to an ARP probe on a Layer 2 interface.

- The feature applies the downloaded timeout or the locally configured session timeout.

- If the terminate action is RADIUS, the feature sends a nonresponsive host (NRH) request to the server. The terminate action is included in the response from the server.

- If the terminate action is default, the session is dismantled, and the applied policy is removed.

Local Web Authentication Banner

With Web Authentication, you can create a default and customized web-browser banners that appears when you log in to a switch.

The banner appears on both the login page and the authentication-result pop-up pages. The default banner messages are as follows:

- Authentication Successful

- Authentication Failed

- Authentication Expired

The Local Web Authentication Banner can be configured in legacy and new-style (Session-aware) CLIs as follows:

- Legacy mode—Use the ip admission auth-proxy-banner http global configuration command.

- New-style mode—Use the parameter-map type webauth global banner global configuration command.

The default banner Cisco Systems and Switch host-name Authentication appear on the Login Page. Cisco Systems appears on the authentication result pop-up page.

Authentication Successful Banner

The banner can be customized as follows:

- Add a message, such as switch, router, or company name to the banner:

- Legacy mode—Use the ip admission auth-proxy-banner http banner-text global configuration command.

- New-style mode—Use the parameter-map type webauth global banner global configuration command.

- Add a logo or text file to the banner:

- Legacy mode—Use the ip admission auth-proxy-banner http file-path global configuration command.

- New-style mode—Use the parameter-map type webauth global banner global configuration command.

Customized Web Banner

If you do not enable a banner, only the username and password dialog boxes appear in the web authentication login screen, and no banner appears when you log into the switch.

Login Screen With No Banner

Web Authentication Customizable Web Pages

During the web-based authentication process, the switch internal HTTP server hosts four HTML pages to deliver to an authenticating client. The server uses these pages to notify you of these four-authentication process states:

- Login—Your credentials are requested.

- Success—The login was successful.

- Fail—The login failed.

- Expire—The login session has expired because of excessive login failures.

- Guidelines

- Authentication Proxy Web Page Guidelines

- Redirection URL for Successful Login Guidelines

Guidelines

- You can substitute your own HTML pages for the default internal HTML pages.

- You can use a logo or specify text in the login, success, failure, and expire web pages.

- On the banner page, you can specify text in the login page.

- The pages are in HTML.

- You must include an HTML redirect command in the success page to access a specific URL.

- The URL string must be a valid URL (for example, http://www.cisco.com). An incomplete URL might cause page not found or similar errors on a web browser.

- If you configure web pages for HTTP authentication, they must include the appropriate HTML commands (for example, to set the page time out, to set a hidden password, or to confirm that the same page is not submitted twice).

- The CLI command to redirect users to a specific URL is not available when the configured login form is enabled. The administrator should ensure that the redirection is configured in the web page.

- If the CLI command redirecting users to specific URL after authentication occurs is entered and then the command configuring web pages is entered, the CLI command redirecting users to a specific URL does not take effect.

- Configured web pages can be copied to the switch boot flash or flash.

- The login page can be on one flash, and the success and failure pages can be another flash (for example, the flash on the active switch or a member switch).

- You must configure all four pages.

- The banner page has no effect if it is configured with the web page.

- All of the logo files (image, flash, audio, video, and so on) that are stored in the system directory (for example, flash, disk0, or disk) and that must be displayed on the login page must use web_auth_<filename> as the file name.

- The configured authentication proxy feature supports both HTTP and SSL.

You can substitute your HTML pages for the default internal HTML pages. You can also specify a URL to which users are redirected after authentication occurs, which replaces the internal Success page.

Customizable Authentication Page

Authentication Proxy Web Page Guidelines

When configuring customized authentication proxy web pages, follow these guidelines:

- To enable the custom web pages feature, specify all four custom HTML files. If you specify fewer than four files, the internal default HTML pages are used.

- The four custom HTML files must be present on the flash memory of the switch. The maximum size of each HTML file is 8 KB.

- Any images on the custom pages must be on an accessible HTTP server. Configure an intercept ACL within the admission rule.

- Any external link from a custom page requires configuration of an intercept ACL within the admission rule.

- To access a valid DNS server, any name resolution required for external links or images requires configuration of an intercept ACL within the admission rule.

- If the custom web pages feature is enabled, a configured auth-proxy-banner is not used.

- If the custom web pages feature is enabled, the redirection URL for successful login feature is not available.

- To remove the specification of a custom file, use the no form of the command.

Because the custom login page is a public web form, consider these guidelines for the page:

- The login form must accept user entries for the username and password and must show them as uname and pwd.

- The custom login page should follow best practices for a web form, such as page timeout, hidden password, and prevention of redundant submissions.

Redirection URL for Successful Login Guidelines

When configuring a redirection URL for successful login, consider these guidelines:

- If the custom authentication proxy web pages feature is enabled, the redirection URL feature is disabled and is not available in the CLI. You can perform redirection in the custom-login success page.

- If the redirection URL feature is enabled, a configured auth-proxy-banner is not used

- To remove the specification of a redirection URL, use the no form of the command.

- If the redirection URL is required after the web-based authentication client is successfully authenticated, then the URL string must start with a valid URL (for example, http://) followed by the URL information. If only the URL is given without http://, then the redirection URL on successful authentication might cause page not found or similar errors on a web browser.

Web-based Authentication Interactions with Other Features

- Port Security

- LAN Port IP

- Gateway IP

- ACLs

- Context-Based Access Control

- EtherChannel

Port Security

You can configure web-based authentication and port security on the same port. Web-based authentication authenticates the port, and port security manages network access for all MAC addresses, including that of the client. You can then limit the number or group of clients that can access the network through the port.

LAN Port IP

You can configure LAN port IP (LPIP) and Layer 2 web-based authentication on the same port. The host is authenticated by using web-based authentication first, followed by LPIP posture validation. The LPIP host policy overrides the web-based authentication host policy.

If the web-based authentication idle timer expires, the NAC policy is removed. The host is authenticated, and posture is validated again.

Gateway IP

You cannot configure Gateway IP (GWIP) on a Layer 3 VLAN interface if web-based authentication is configured on any of the switch ports in the VLAN.

You can configure web-based authentication on the same Layer 3 interface as Gateway IP. The host policies for both features are applied in software. The GWIP policy overrides the web-based authentication host policy.

ACLs

If you configure a VLAN ACL or a Cisco IOS ACL on an interface, the ACL is applied to the host traffic only after the web-based authentication host policy is applied.

For Layer 2 web-based authentication, it is more secure, though not required, to configure a port ACL (PACL) as the default access policy for ingress traffic from hosts connected to the port. After authentication, the web-based authentication host policy overrides the PACL. The Policy ACL is applied to the session even if there is no ACL configured on the port.

You cannot configure a MAC ACL and web-based authentication on the same interface.

You cannot configure web-based authentication on a port whose access VLAN is configured for VACL capture.

Context-Based Access Control

Web-based authentication cannot be configured on a Layer 2 port if context-based access control (CBAC) is configured on the Layer 3 VLAN interface of the port VLAN.

EtherChannel

You can configure web-based authentication on a Layer 2 EtherChannel interface. The web-based authentication configuration applies to all member channels.

Default Web-Based Authentication Configuration

The following table shows the default web-based authentication configuration.

Default Web-based Authentication Configuration

Feature

Default Setting

AAA

Disabled

RADIUS server

- IP address

- UDP authentication port

- Key

- None specified

- 1645

- None specified

Default value of inactivity timeout

3600 seconds

Inactivity timeout

Enabled

Web-Based Authentication Configuration Guidelines and Restrictions

- Web-based authentication is an ingress-only feature.

- You can configure web-based authentication only on access ports. Web-based authentication is not supported on trunk ports, EtherChannel member ports, or dynamic trunk ports.

- External web authentication, where the switch redirects a client to a particular host or web server for displaying login message, is not supported.

- You cannot authenticate hosts on Layer 2 interfaces with static ARP cache assignment. These hosts are not detected by the web-based authentication feature because they do not send ARP messages.

- By default, the IP device tracking feature is disabled on a switch. You must enable the IP device tracking feature to use web-based authentication.

- You must enable SISF-Based device tracking to use web-based authentication. By default, SISF-Based device tracking is disabled on a switch.

- You must configure at least one IP address to run the switch HTTP server. You must also configure routes to reach each host IP address. The HTTP server sends the HTTP login page to the host.

- Hosts that are more than one hop away might experience traffic disruption if an STP topology change results in the host traffic arriving on a different port. This occurs because the ARP and DHCP updates might not be sent after a Layer 2 (STP) topology change.

- Web-based authentication does not support VLAN assignment as a downloadable-host policy.

- Web-based authentication supports IPv6 in Session-aware policy mode. IPv6 Web-authentication requires at least one IPv6 address configured on the switch and IPv6 Snooping configured on the switchport.

- Web-based authentication and Network Edge Access Topology (NEAT) are mutually exclusive. You cannot use web-based authentication when NEAT is enabled on an interface, and you cannot use NEAT when web-based authentication is running on an interface.

- Identify the following RADIUS security server settings that will be used while configuring switch-to-RADIUS-server communication:

- Host name

- Host IP address

- Host name and specific UDP port numbers

- IP address and specific UDP port numbers

The combination of the IP address and UDP port number creates a unique identifier, that enables RADIUS requests to be sent to multiple UDP ports on a server at the same IP address. If two different host entries on the same RADIUS server are configured for the same service (for example, authentication) the second host entry that is configured functions as the failover backup to the first one. The RADIUS host entries are chosen in the order that they were configured.

- When you configure the RADIUS server parameters:

- Specify the key string on a separate command line.

- For key string , specify the authentication and encryption key used between the switch and the RADIUS daemon running on the RADIUS server. The key is a text string that must match the encryption key used on the RADIUS server.

- When you specify the key string , use spaces within and at the end of the key. If you use spaces in the key, do not enclose the key in quotation marks unless the quotation marks are part of the key. This key must match the encryption used on the RADIUS daemon.

- You can globally configure the timeout, retransmission, and encryption key values for all RADIUS servers by using with the radius-server host global configuration command. If you want to configure these options on a per-server basis, use the radius-server timeout , radius-server transmit, and the radius-server key global configuration commands.

Note

You need to configure some settings on the RADIUS server, including: the switch IP address, the key string to be shared by both the server and the switch, and the downloadable ACL (DACL). For more information, see the RADIUS server documentation.

- For a URL redirect ACL:

- Packets that match a permit access control entry (ACE) rule are sent to the CPU for forwarding to the AAA server.

- Packets that match a deny ACE rule are forwarded through the switch.

- Packets that match neither the permit ACE rule or deny ACE rule are processed by the next dACL, and if there is no dACL, the packets hit the implicit-deny ACL and are dropped.

Configuring the Authentication Rule and Interfaces

Follow these steps to configure the authentication rule and interfaces:

Before you begin

SISF-Based device tracking is a prerequisite to Web Authentication. Ensure that you have enabled device tracking programmatically or manually.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ip admission name name proxy http

Example:

Device(config)# ip admission name webauth1 proxy http

Configures an authentication rule for web-based authorization.

Step 4

interface type slot/port

Example:

Device(config)# interface gigabitethernet 1/0/1

Enters interface configuration mode and specifies the ingress Layer 2 or Layer 3 interface to be enabled for web-based authentication.

type can be fastethernet, gigabit ethernet, or tengigabitethernet.

Step 5

ip access-group name

Example:

Device(config-if)# ip access-group webauthag

Applies the default ACL.

Step 6

ip admission name

Example:

Device(config)# ip admission name

Configures an authentication rule for web-based authorization for the interface.

Step 7

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 8

show ip admission

Example:

Device# show ip admission

Displays the configuration.

Step 9

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Configuring AAA Authentication

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

aaa new-model

Example:

Device(config)# aaa new-model

Enables AAA functionality.

Step 4

aaa authentication login default group {tacacs+ | radius}

Example:

Device(config)# aaa authentication login default group tacacs+

Defines the list of authentication methods at login.

named_authentication_list refers to any name that is not greater than 31 characters.

AAA_group_name refers to the server group name. You need to define the server-group server_name at the beginning itself.

Step 5

aaa authorization auth-proxy default group {tacacs+ | radius}

Example:

Device(config)# aaa authorization auth-proxy default group tacacs+

Creates an authorization method list for web-based authorization.

Step 6

tacacs server server-name

Example:

Device(config)# tacacs server yourserver

Specifies an AAA server.

Step 7

address {ipv4 | ipv6} ip address

Example:

Device(config-server-tacacs)# address ipv4 10.0.1.12

Configures the IP address for the TACACS server.

Step 8

key string

Example:

Device(config-server-tacacs)# key cisco123

Configures the authorization and encryption key used between the switch and the TACACS server.

Step 9

exit

Example:

Device(config-server-tacacs)# exit

Exits the TACACS server mode and enters the global configuration mode.

Step 10

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 11

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 12

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Configuring Switch-to-RADIUS-Server Communication

Follow these steps to configure the RADIUS server parameters:

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ip radius source-interface vlan vlan interface number

Example:

Device(config)# ip radius source-interface vlan 80

Specifies that the RADIUS packets have the IP address of the indicated interface.

Step 4

radius server server name

Example:

Device(config)# radius server rsim address ipv4 124.2.2.12

(Optional) Specifies the IP address of the RADIUS server.

Step 5

address {ipv4 | ipv6} ip address

Example:

Device(config-radius-server)# address ipv4 10.0.1.2 auth-port 1550 acct-port 1560

Configures the IP address for the RADIUS server.

Step 6

key string

Example:

Device(config-radius-server)# key rad123

(Optional) Specifies the authentication and encryption key used between the switch and the RADIUS daemon running on the RADIUS server.

Step 7

exit

Example:

Device(config-radius-server)# exit

Exits the RADIUS server mode and enters the global configuration mode.

Step 8

radius-server dead-criteria tries num-tries

Example:

Device(config)# radius-server dead-criteria tries 30

Specifies the number of unanswered sent messages to a RADIUS server before considering the server to be inactive. The range of num-tries is 1 to 100.

Step 9

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Configuring the HTTP Server

To use web-based authentication, you must enable the HTTP server within the Device. You can enable the server for either HTTP or HTTPS.

Note

The Apple psuedo-browser will not open if you configure only the ip http secure-server command. You should also configure the ip http server command.

Follow the procedure given below to enable the server for either HTTP or HTTPS:

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ip http server

Example:

Device(config)# ip http server

Enables the HTTP server. The web-based authentication feature uses the HTTP server to communicate with the hosts for user authentication.

Step 4

ip http secure-server

Example:

Device(config)# ip http secure-server

Enables HTTPS.

You can configure custom authentication proxy web pages or specify a redirection URL for successful login.

Note

To ensure secure authentication when you enter the ip http secure-server command, the login page is always in HTTPS (secure HTTP) even if the user sends an HTTP request.

Step 5

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

- Customizing the Authentication Proxy Web Pages

- Specifying a Redirection URL for Successful Login

Customizing the Authentication Proxy Web Pages

You can configure web authentication to display four substitute HTML pages to the user in place of the Device default HTML pages during web-based authentication.

Follow these steps to specify the use of your custom authentication proxy web pages:

Before you begin

Store your custom HTML files on the Device flash memory.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ip admission proxy http login page file device:login-filename

Example:

Device(config)# ip admission proxy http login page file disk1:login.htm

Specifies the location in the Device memory file system of the custom HTML file to use in place of the default login page. The device: is flash memory.

Step 4

ip admission proxy http success page file device:success-filename

Example:

Device(config)# ip admission proxy http success page file disk1:success.htm

Specifies the location of the custom HTML file to use in place of the default login success page.

Step 5

ip admission proxy http failure page file device:fail-filename

Example:

Device(config)# ip admission proxy http fail page file disk1:fail.htm

Specifies the location of the custom HTML file to use in place of the default login failure page.

Step 6

ip admission proxy http login expired page file device:expired-filename

Example:

Device(config)# ip admission proxy http login expired page file disk1:expired.htm

Specifies the location of the custom HTML file to use in place of the default login expired page.

Step 7

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Specifying a Redirection URL for Successful Login

Follow these steps to specify a URL to which the user is redirected after authentication, effectively replacing the internal Success HTML page:

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ip admission proxy http success redirect url-string

Example:

Device(config)# ip admission proxy http success redirect www.example.com

Specifies a URL for redirection of the user in place of the default login success page.

Step 4

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Configuring Web-Based Authentication Parameters

Follow these steps to configure the maximum number of failed login attempts before the client is placed in a watch list for a waiting period:

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ip admission max-login-attempts number

Example:

Device(config)# ip admission max-login-attempts 10

Sets the maximum number of failed login attempts. The range is 1 to 2147483647 attempts. The default is 5.

Step 4

exit

Example:

Device# exit

Exits global configuration mode and returns to privileged EXEC mode.

Configuring a Web-Based Authentication Local Banner

Follow these steps to configure a local banner on a switch that has web authentication configured.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ip admission auth-proxy-banner http [banner-text | file-path]

Example:

Device(config)# ip admission auth-proxy-banner http C My Switch C

Enables the local banner.

(Optional) Create a custom banner by entering C banner-text C (where C is a delimiting character), or file-path that indicates a file (for example, a logo or text file) that appears in the banner.

Step 4

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 5

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 6

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Removing Web-Based Authentication Cache Entries

Follow these steps to remove web-based authentication cache entries:

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

clear ip auth-proxy cache {* | host ip address}

Example:

Device# clear ip auth-proxy cache 192.168.4.5

Delete authentication proxy entries. Use an asterisk to delete all cache entries. Enter a specific IP address to delete the entry for a single host.

Step 3

clear ip admission cache {* | host ip address}

Example:

Device# clear ip admission cache 192.168.4.5

Delete authentication proxy entries. Use an asterisk to delete all cache entries. Enter a specific IP address to delete the entry for a single host.

Verifying Web-Based Authentication Status

Use the commands in this topic to display the web-based authentication settings for all interfaces or for specific ports.

Privileged EXEC show Commands

Command

Purpose

show authentication sessions method webauth

Displays the web-based authentication settings for all interfaces for fastethernet, gigabitethernet, or tengigabitethernet

show authentication sessions
interface type slot/port[details]

Displays the web-based authentication settings for the specified interface for fastethernet, gigabitethernet, or tengigabitethernet.

In Session Aware Networking mode, use the show access-session interface command.

Chapter 22. Configuring Port-Based Traffic Control

- Overview of Port-Based Traffic Control

Overview of Port-Based Traffic Control

Port-based traffic control is a set of Layer 2 features on the Cisco Catalyst switches used to filter or block packets at the port level in response to specific traffic conditions. The following port-based traffic control features are supported:

- Storm Control

- Protected Ports

- Port Blocking

- Port Security

- Protocol Storm Protection

- Information About Storm Control

- How to Configure Storm Control

- Information About Protected Ports

- How to Configure Protected Ports

- Monitoring Protected Ports

- Monitoring Port Blocking

- Prerequisites for Port Security

- Restrictions for Port Security

- Information About Port Security

- Monitoring Port Security

- Configuration Examples for Port Security

- Information About Protocol Storm Protection

- How to Configure Protocol Storm Protection

- Monitoring Protocol Storm Protection

- Additional References for Port-Based Traffic Control

Information About Storm Control

- Storm Control

- How Traffic Activity is Measured

- Traffic Patterns

Storm Control

Storm control prevents traffic on a LAN from being disrupted by a broadcast, multicast, or unicast storm on one of the physical interfaces. A LAN storm occurs when packets flood the LAN, creating excessive traffic and degrading network performance. Errors in the protocol-stack implementation, mistakes in network configurations, or users issuing a denial-of-service attack can cause a storm.

Storm control (or traffic suppression) monitors packets passing from an interface to the switching bus and determines if the packet is unicast, multicast, or broadcast. The switch counts the number of packets of a specified type received within the 1-second time interval and compares the measurement with a predefined suppression-level threshold.

How Traffic Activity is Measured

Storm control uses one of these methods to measure traffic activity:

- Bandwidth as a percentage of the total available bandwidth of the port that can be used by the broadcast, multicast, or unicast traffic

- Traffic rate in packets per second at which broadcast, multicast, or unicast packets are received

- Traffic rate in bits per second at which broadcast, multicast, or unicast packets are received

- Traffic rate in packets per second and for small frames. This feature is enabled globally. The threshold for small frames is configured for each interface.

With each method, the port blocks traffic when the rising threshold is reached. The port remains blocked until the traffic rate drops below the falling threshold (if one is specified) and then resumes normal forwarding. If the falling suppression level is not specified, the switch blocks all traffic until the traffic rate drops below the rising suppression level. In general, the higher the level, the less effective the protection against broadcast storms.

Note

When the storm control threshold for multicast traffic is reached, all multicast traffic except control traffic, such as bridge protocol data unit (BDPU) and Cisco Discovery Protocol (CDP) frames, are blocked. However, the switch does not differentiate between routing updates, such as OSPF, and regular multicast data traffic, so both types of traffic are blocked.

Traffic Patterns

Broadcast Storm Control Example

Broadcast traffic being forwarded exceeded the configured threshold between time intervals T1 and T2 and between T4 and T5. When the amount of specified traffic exceeds the threshold, all traffic of that kind is dropped for the next time period. Therefore, broadcast traffic is blocked during the intervals following T2 and T5. At the next time interval (for example, T3), if broadcast traffic does not exceed the threshold, it is again forwarded.

The combination of the storm-control suppression level and the 1-second time interval controls the way the storm control algorithm works. A higher threshold allows more packets to pass through. A threshold value of 100 percent means that no limit is placed on the traffic. A value of 0.0 means that all broadcast, multicast, or unicast traffic on that port is blocked.

Note

Because packets do not arrive at uniform intervals, the 1-second time interval during which traffic activity is measured can affect the behavior of storm control.

You use the storm-control interface configuration commands to set the threshold value for each traffic type.

How to Configure Storm Control

- Configuring Storm Control and Threshold Levels

- Configuring Small-Frame Arrival Rate

Configuring Storm Control and Threshold Levels

You configure storm control on a port and enter the threshold level that you want to be used for a particular type of traffic.

However, because of hardware limitations and the way in which packets of different sizes are counted, threshold percentages are approximations. Depending on the sizes of the packets making up the incoming traffic, the actual enforced threshold might differ from the configured level by several percentage points.

Note

Storm control is supported on physical interfaces. You can also configure storm control on an EtherChannel. When storm control is configured on an EtherChannel, the storm control settings propagate to the EtherChannel physical interfaces.

Follow these steps to storm control and threshold levels:

Before you begin

Storm control is supported on physical interfaces. You can also configure storm control on an EtherChannel. When storm control is configured on an EtherChannel, the storm control settings propagate to the EtherChannel physical interfaces.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface interface-id

Example:

Device(config)# interface gigabitethernet1/0/1

Specifies the interface to be configured, and enter interface configuration mode.

Step 4

storm-control {broadcast | multicast | unicast} level {level [level-low] | bps bps [bps-low] | pps pps [pps-low]}

Example:

Device(config-if)# storm-control unicast level 87 65

Configures broadcast, multicast, or unicast storm control. By default, storm control is disabled.

The keywords have these meanings:

- For level , specifies the rising threshold level for broadcast, multicast, or unicast traffic as a percentage (up to two decimal places) of the bandwidth. The port blocks traffic when the rising threshold is reached. The range is 0.00 to 100.00.

- (Optional) For level-low , specifies the falling threshold level as a percentage (up to two decimal places) of the bandwidth. This value must be less than or equal to the rising suppression value. The port forwards traffic when traffic drops below this level. If you do not configure a falling suppression level, it is set to the rising suppression level. The range is 0.00 to 100.00.

If you set the threshold to the maximum value (100 percent), no limit is placed on the traffic. If you set the threshold to 0.0, all broadcast, multicast, and unicast traffic on that port is blocked.

- For bps bps , specifies the rising threshold level for broadcast, multicast, or unicast traffic in bits per second (up to one decimal place). The port blocks traffic when the rising threshold is reached. The range is 0.0 to 10000000000.0.

- (Optional) For bps-low , specifies the falling threshold level in bits per second (up to one decimal place). It can be less than or equal to the rising threshold level. The port forwards traffic when traffic drops below this level. The range is 0.0 to 10000000000.0.

- For pps pps , specifies the rising threshold level for broadcast, multicast, or unicast traffic in packets per second (up to one decimal place). The port blocks traffic when the rising threshold is reached. The range is 0.0 to 10000000000.0.

- (Optional) For pps-low , specifies the falling threshold level in packets per second (up to one decimal place). It can be less than or equal to the rising threshold level. The port forwards traffic when traffic drops below this level. The range is 0.0 to 10000000000.0.

For BPS and PPS settings, you can use metric suffixes such as k, m, and g for large number thresholds.

Step 5

storm-control action {shutdown | trap}

Example:

Device(config-if)# storm-control action trap

Specifies the action to be taken when a storm is detected. The default is to filter out the traffic and not to send traps.

- Select the shutdown keyword to error-disable the port during a storm.

- Select the trap keyword to generate an SNMP trap when a storm is detected.

Step 6

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Step 7

show storm-control [interface-id] [broadcast | multicast | unicast]

Example:

Device# show storm-control gigabitethernet1/0/1 unicast

Verifies the storm control suppression levels set on the interface for the specified traffic type. If you do not enter a traffic type, details for all traffic types (broadcast, multicast and unicast) are displayed.

Step 8

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Configuring Small-Frame Arrival Rate

Incoming VLAN-tagged packets smaller than 67 bytes are considered small frames. They are forwarded by the switch, but they do not cause the switch storm-control counters to increment.

You globally enable the small-frame arrival feature on the switch and then configure the small-frame threshold for packets on each interface. Packets smaller than the minimum size and arriving at a specified rate (the threshold) are dropped since the port is error disabled.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

errdisable detect cause small-frame

Example:

Device(config)# errdisable detect cause small-frame

Enables the small-frame rate-arrival feature on the switch.

Step 4

errdisable recovery interval interval

Example:

Device(config)# errdisable recovery interval 60

(Optional) Specifies the time to recover from the specified error-disabled state.

Step 5

errdisable recovery cause small-frame

Example:

Device(config)# errdisable recovery cause small-frame

(Optional) Configures the recovery time for error-disabled ports to be automatically re-enabled after they are error disabled by the arrival of small frames

Storm control is supported on physical interfaces. You can also configure storm control on an EtherChannel. When storm control is configured on an EtherChannel, the storm control settings propagate to the EtherChannel physical interfaces.

Step 6

interface interface-id

Example:

Device(config)# interface gigabitethernet1/0/2

Enters interface configuration mode, and specify the interface to be configured.

Step 7

small-frame violation-rate pps

Example:

Device(config-if)# small-frame violation rate 10000

Configures the threshold rate for the interface to drop incoming packets and error disable the port. The range is 1 to 10,000 packets per second (pps)

Step 8

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 9

show interfaces interface-id

Example:

Device# show interfaces gigabitethernet1/0/2

Verifies the configuration.

Step 10

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 11

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Information About Protected Ports

- Protected Ports

- Default Protected Port Configuration

- Protected Ports Guidelines

Protected Ports

Some applications require that no traffic be forwarded at Layer 2 between ports on the same switch so that one neighbor does not see the traffic generated by another neighbor. In such an environment, the use of protected ports ensures that there is no exchange of unicast, broadcast, or multicast traffic between these ports on the switch.

Protected ports have these features:

- A protected port does not forward any traffic (unicast, multicast, or broadcast) to any other port that is also a protected port. Data traffic cannot be forwarded between protected ports at Layer 2; only control traffic, such as PIM packets, is forwarded because these packets are processed by the CPU and forwarded in software. All data traffic passing between protected ports must be forwarded through a Layer 3 device.

- Forwarding behavior between a protected port and a nonprotected port proceeds as usual.

Because a switch stack represents a single logical switch, Layer 2 traffic is not forwarded between any protected ports in the switch stack, whether they are on the same or different switches in the stack.

Default Protected Port Configuration

The default is to have no protected ports defined.

Protected Ports Guidelines

You can configure protected ports on a physical interface (for example, Gigabit Ethernet port 1) or an EtherChannel group (for example, port-channel 5). When you enable protected ports for a port channel, it is enabled for all ports in the port-channel group.

How to Configure Protected Ports

- Configuring a Protected Port

Configuring a Protected Port

Before you begin

Protected ports are not pre-defined. This is the task to configure one.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface interface-id

Example:

Device(config)# interface gigabitethernet 1/0/1

Specifies the interface to be configured, and enter interface configuration mode.

Step 4

switchport protected

Example:

Device(config-if)# switchport protected

Configures the interface to be a protected port.

Step 5

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 6

show interfaces interface-id switchport

Example:

Device# show interfaces gigabitethernet 1/0/1 switchport

Verifies your entries.

Step 7

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 8

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Monitoring Protected Ports

Commands for Displaying Protected Port Settings

Command

Purpose

show interfaces [interface-id] switchport

Displays the administrative and operational status of all switching (nonrouting) ports or the specified port, including port blocking and port protection settings.

Port Blocking

By default, the switch floods packets with unknown destination MAC addresses out of all ports. If unknown unicast and multicast traffic is forwarded to a protected port, there could be security issues. To prevent unknown unicast or multicast traffic from being forwarded from one port to another, you can block a port (protected or nonprotected) from flooding unknown unicast or multicast packets to other ports.

Note

With multicast traffic, the port blocking feature blocks only pure Layer 2 packets. Multicast packets that contain IPv4 or IPv6 information in the header are not blocked.

Blocking Flooded Traffic on an Interface

Before you begin

The interface can be a physical interface or an EtherChannel group. When you block multicast or unicast traffic for a port channel, it is blocked on all ports in the port-channel group.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface interface-id

Example:

Device(config)# interface gigabitethernet 1/0/1

Specifies the interface to be configured, and enter interface configuration mode.

Step 4

switchport block multicast

Example:

Device(config-if)# switchport block multicast

Blocks unknown multicast forwarding out of the port.

Step 5

switchport block unicast

Example:

Device(config-if)# switchport block unicast

Blocks unknown unicast forwarding out of the port.

Step 6

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 7

show interfaces interface-id switchport

Example:

Device# show interfaces gigabitethernet 1/0/1 switchport

Verifies your entries.

Step 8

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 9

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Monitoring Port Blocking

Commands for Displaying Port Blocking Settings

Command

Purpose

show interfaces [interface-id] switchport

Displays the administrative and operational status of all switching (nonrouting) ports or the specified port, including port blocking and port protection settings.

Prerequisites for Port Security

Note

If you try to set the maximum value to a number less than the number of secure addresses already configured on an interface, the command is rejected.

Restrictions for Port Security

The maximum number of secure MAC addresses that you can configure on a switch or switch stack is set by the maximum number of available MAC addresses allowed in the system. This number is determined by the active Switch Database Management (SDM) template. This number is the total of available MAC addresses, including those used for other Layer 2 functions and any other secure MAC addresses configured on interfaces.

Information About Port Security

- Port Security

- Types of Secure MAC Addresses

- Sticky Secure MAC Addresses

- Security Violations

- Port Security Aging

- Port Security and Switch Stacks

- Default Port Security Configuration

- Port Security Configuration Guidelines

- Overview of Port-Based Traffic Control

Port Security

You can use the port security feature to restrict input to an interface by limiting and identifying MAC addresses of the stations allowed to access the port. When you assign secure MAC addresses to a secure port, the port does not forward packets with source addresses outside the group of defined addresses. If you limit the number of secure MAC addresses to one and assign a single secure MAC address, the workstation attached to that port is assured the full bandwidth of the port.

If a port is configured as a secure port and the maximum number of secure MAC addresses is reached, when the MAC address of a station attempting to access the port is different from any of the identified secure MAC addresses, a security violation occurs. Also, if a station with a secure MAC address configured or learned on one secure port attempts to access another secure port, a violation is flagged.

Types of Secure MAC Addresses

The switch supports these types of secure MAC addresses:

- Static secure MAC addresses—These are manually configured by using the switchport port-security mac-address mac-address interface configuration command, stored in the address table, and added to the switch running configuration.

- Dynamic secure MAC addresses—These are dynamically configured, stored only in the address table, and removed when the switch restarts.

- Sticky secure MAC addresses—These can be dynamically learned or manually configured, stored in the address table, and added to the running configuration. If these addresses are saved in the configuration file, when the switch restarts, the interface does not need to dynamically reconfigure them.

Sticky Secure MAC Addresses

You can configure an interface to convert the dynamic MAC addresses to sticky secure MAC addresses and to add them to the running configuration by enabling sticky learning. The interface converts all the dynamic secure MAC addresses, including those that were dynamically learned before sticky learning was enabled, to sticky secure MAC addresses. All sticky secure MAC addresses are added to the running configuration.

The sticky secure MAC addresses do not automatically become part of the configuration file, which is the startup configuration used each time the switch restarts. If you save the sticky secure MAC addresses in the configuration file, when the switch restarts, the interface does not need to relearn these addresses. If you do not save the sticky secure addresses, they are lost.

If sticky learning is disabled, the sticky secure MAC addresses are converted to dynamic secure addresses and are removed from the running configuration.

Security Violations

It is a security violation when one of these situations occurs:

- The maximum number of secure MAC addresses have been added to the address table, and a station whose MAC address is not in the address table attempts to access the interface.

- An address learned or configured on one secure interface is seen on another secure interface in the same VLAN.

- Running diagnostic tests with port security enabled.

You can configure the interface for one of three violation modes, based on the action to be taken if a violation occurs:

- protect—when the number of secure MAC addresses reaches the maximum limit allowed on the port, packets with unknown source addresses are dropped until you remove a sufficient number of secure MAC addresses to drop below the maximum value or increase the number of maximum allowable addresses. You are not notified that a security violation has occurred.

Note

We do not recommend configuring the protect violation mode on a trunk port. The protect mode disables learning when any VLAN reaches its maximum limit, even if the port has not reached its maximum limit.

- restrict—when the number of secure MAC addresses reaches the maximum limit allowed on the port, packets with unknown source addresses are dropped until you remove a sufficient number of secure MAC addresses to drop below the maximum value or increase the number of maximum allowable addresses. In this mode, you are notified that a security violation has occurred. An SNMP trap is sent, a syslog message is logged, and the violation counter increments.

- shutdown—a port security violation causes the interface to become error-disabled and to shut down immediately, and the port LED turns off. When a secure port is in the error-disabled state, you can bring it out of this state by entering the errdisable recovery cause psecure-violation global configuration command, or you can manually re-enable it by entering the shutdown and no shut down interface configuration commands. This is the default mode.

- shutdown vlan—Use to set the security violation mode per-VLAN. In this mode, the VLAN is error disabled instead of the entire port when a violation occurs

This table shows the violation mode and the actions taken when you configure an interface for port security.

Security Violation Mode Actions

Violation Mode

Traffic is forwarded

[1]

Sends SNMP trap

Sends syslog message

Displays error message

[2]

Violation counter increments

Shuts down port

protect

No

No

No

No

No

No

restrict

No

Yes

Yes

No

Yes

No

shutdown

No

No

No

No

Yes

Yes

shutdown vlan

No

No

Yes

No

Yes

No

[3]

[1] Packets with unknown source addresses are dropped until you remove a sufficient number of secure MAC addresses.

[2] The switch returns an error message if you manually configure an address that would cause a security violation.

[3] Shuts down only the VLAN on which the violation occurred.

Port Security Aging

You can use port security aging to set the aging time for all secure addresses on a port. Two types of aging are supported per port:

- Absolute—The secure addresses on the port are deleted after the specified aging time.

- Inactivity—The secure addresses on the port are deleted only if the secure addresses are inactive for the specified aging time.

Port Security and Switch Stacks

When a switch joins a stack, the new switch will get the configured secure addresses. All dynamic secure addresses are downloaded by the new stack member from the other stack members.

When a switch (either the active switch or a stack member) leaves the stack, the remaining stack members are notified, and the secure MAC addresses configured or learned by that switch are deleted from the secure MAC address table.

Default Port Security Configuration

Default Port Security Configuration

Feature

Default Setting

Port security

Disabled on a port.

Sticky address learning

Disabled.

Maximum number of secure MAC addresses per port

1.

Violation mode

Shutdown. The port shuts down when the maximum number of secure MAC addresses is exceeded.

Port security aging

Disabled. Aging time is 0.

Static aging is disabled.

Type is absolute.

Port Security Configuration Guidelines

- Port security can only be configured on static access ports or trunk ports. A secure port cannot be a dynamic access port.

- A secure port cannot be a destination port for Switched Port Analyzer (SPAN).

- Note

Voice VLAN is only supported on access ports and not on trunk ports, even though the configuration is allowed.

- When you enable port security on an interface that is also configured with a voice VLAN, set the maximum allowed secure addresses on the port to two. When the port is connected to a Cisco IP phone, the IP phone requires one MAC address. The Cisco IP phone address is learned on the voice VLAN, but is not learned on the access VLAN. If you connect a single PC to the Cisco IP phone, no additional MAC addresses are required. If you connect more than one PC to the Cisco IP phone, you must configure enough secure addresses to allow one for each PC and one for the phone.

- When a trunk port configured with port security and assigned to an access VLAN for data traffic and to a voice VLAN for voice traffic, entering the switchport voice and switchport priority extend interface configuration commands has no effect.

When a connected device uses the same MAC address to request an IP address for the access VLAN and then an IP address for the voice VLAN, only the access VLAN is assigned an IP address.

- When you enter a maximum secure address value for an interface, and the new value is greater than the previous value, the new value overwrites the previously configured value. If the new value is less than the previous value and the number of configured secure addresses on the interface exceeds the new value, the command is rejected.

- The switch does not support port security aging of sticky secure MAC addresses.

This table summarizes port security compatibility with other port-based features.

Port Security Compatibility with Other Switch Features

Type of Port or Feature on Port

Compatible with Port Security

DTP [1] port [2]

No

Trunk port

Yes

Dynamic-access port [3]

No

Routed port

No

SPAN source port

Yes

SPAN destination port

No

EtherChannel

Yes

Tunneling port

Yes

Protected port

Yes

IEEE 802.1x port

Yes

Voice VLAN port [4]

Yes

IP source guard

Yes

Dynamic Address Resolution Protocol (ARP) inspection

Yes

Flex Links

Yes

[1] DTP=Dynamic Trunking Protocol

[2] A port configured with the switchport mode dynamic interface configuration command.

[3] A VLAN Query Protocol (VQP) port configured with the switchport access vlan dynamic interface configuration command.

[4] You must set the maximum allowed secure addresses on the port to two plus the maximum number of secure addresses allowed on the access VLAN.

Overview of Port-Based Traffic Control

Port-based traffic control is a set of Layer 2 features on the Cisco Catalyst switches used to filter or block packets at the port level in response to specific traffic conditions. The following port-based traffic control features are supported:

- Storm Control

- Protected Ports

- Port Blocking

- Port Security

- Protocol Storm Protection

Enabling and Configuring Port Security

Before you begin

This task restricts input to an interface by limiting and identifying MAC addresses of the stations allowed to access the port:

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface interface-id

Example:

Device(config)# interface gigabitethernet1/0/1

Specifies the interface to be configured, and enter interface configuration mode.

Step 4

switchport mode {access | trunk}

Example:

Device(config-if)# switchport mode access

Sets the interface switchport mode as access or trunk; an interface in the default mode (dynamic auto) cannot be configured as a secure port.

Step 5

switchport voice vlan vlan-id

Example:

Device(config-if)# switchport voice vlan 22

Enables voice VLAN on a port.

vlan-id—Specifies the VLAN to be used for voice traffic.

Step 6

switchport port-security

Example:

Device(config-if)# switchport port-security

Enable port security on the interface.

Note

Under certain conditions, when port security is enabled on the member ports in a switch stack, the DHCP and ARP packets would be dropped. To resolve this, configure a shut and no shut on the interface.

Step 7

switchport port-security [maximum value [vlan {vlan-list | {access | voice}}]]

Example:

Device(config-if)# switchport port-security maximum 20

(Optional) Sets the maximum number of secure MAC addresses for the interface. The maximum number of secure MAC addresses that you can configure on a switch or switch stack is set by the maximum number of available MAC addresses allowed in the system. This number is set by the active Switch Database Management (SDM) template. This number is the total of available MAC addresses, including those used for other Layer 2 functions and any other secure MAC addresses configured on interfaces.

(Optional) vlan —sets a per-VLAN maximum value

Enter one of these options after you enter the vlan keyword:

- vlan-list —On a trunk port, you can set a per-VLAN maximum value on a range of VLANs separated by a hyphen or a series of VLANs separated by commas. For nonspecified VLANs, the per-VLAN maximum value is used.

- access —On an access port, specifies the VLAN as an access VLAN.

- voice —On an access port, specifies the VLAN as a voice VLAN.

Note

The voice keyword is available only if a voice VLAN is configured on a port and if that port is not the access VLAN. If an interface is configured for voice VLAN, configure a maximum of two secure MAC addresses.

Step 8

switchport port-security violation {protect | restrict | shutdown | shutdown vlan}

Example:

Device(config-if)# switchport port-security violation restrict

(Optional) Sets the violation mode, the action to be taken when a security violation is detected, as one of these:

- protect —When the number of port secure MAC addresses reaches the maximum limit allowed on the port, packets with unknown source addresses are dropped until you remove a sufficient number of secure MAC addresses to drop below the maximum value or increase the number of maximum allowable addresses. You are not notified that a security violation has occurred.

Note

We do not recommend configuring the protect mode on a trunk port. The protect mode disables learning when any VLAN reaches its maximum limit, even if the port has not reached its maximum limit.

- restrict —When the number of secure MAC addresses reaches the limit allowed on the port, packets with unknown source addresses are dropped until you remove a sufficient number of secure MAC addresses or increase the number of maximum allowable addresses. An SNMP trap is sent, a syslog message is logged, and the violation counter increments.

- shutdown —The interface is error-disabled when a violation occurs, and the port LED turns off. An SNMP trap is sent, a syslog message is logged, and the violation counter increments.

- shutdown vlan —Use to set the security violation mode per VLAN. In this mode, the VLAN is error disabled instead of the entire port when a violation occurs.

Note

When a secure port is in the error-disabled state, you can bring it out of this state by entering the errdisable recovery cause psecure-violation global configuration command. You can manually re-enable it by entering the shutdown and no shutdown interface configuration commands or by using the clear errdisable interface vlan privileged EXEC command.

Step 9

switchport port-security [mac-address mac-address [vlan {vlan-id | {access | voice}}]

Example:

Device(config-if)# switchport port-security mac-address 00:A0:C7:12:C9:25 vlan 3 voice

(Optional) Enters a secure MAC address for the interface. You can use this command to enter the maximum number of secure MAC addresses. If you configure fewer secure MAC addresses than the maximum, the remaining MAC addresses are dynamically learned.

Note

If you enable sticky learning after you enter this command, the secure addresses that were dynamically learned are converted to sticky secure MAC addresses and are added to the running configuration.

(Optional) vlan —sets a per-VLAN maximum value.

Enter one of these options after you enter the vlan keyword:

- vlan-id —On a trunk port, you can specify the VLAN ID and the MAC address. If you do not specify a VLAN ID, the native VLAN is used.

- access —On an access port, specifies the VLAN as an access VLAN.

- voice —On an access port, specifies the VLAN as a voice VLAN.

Note

The voice keyword is available only if a voice VLAN is configured on a port and if that port is not the access VLAN. If an interface is configured for voice VLAN, configure a maximum of two secure MAC addresses.

Step 10

switchport port-security mac-address sticky

Example:

Device(config-if)# switchport port-security mac-address sticky

(Optional) Enables sticky learning on the interface.

Step 11

switchport port-security mac-address sticky [mac-address | vlan {vlan-id | {access | voice}}]

Example:

Device(config-if)# switchport port-security mac-address sticky 00:A0:C7:12:C9:25 vlan voice

(Optional) Enters a sticky secure MAC address, repeating the command as many times as necessary. If you configure fewer secure MAC addresses than the maximum, the remaining MAC addresses are dynamically learned, are converted to sticky secure MAC addresses, and are added to the running configuration.

Note

If you do not enable sticky learning before this command is entered, an error message appears, and you cannot enter a sticky secure MAC address.

(Optional) vlan —sets a per-VLAN maximum value.

Enter one of these options after you enter the vlan keyword:

- vlan-id —On a trunk port, you can specify the VLAN ID and the MAC address. If you do not specify a VLAN ID, the native VLAN is used.

- access —On an access port, specifies the VLAN as an access VLAN.

- voice —On an access port, specifies the VLAN as a voice VLAN.

Note

The voice keyword is available only if a voice VLAN is configured on a port and if that port is not the access VLAN.

Step 12

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 13

show port-security

Example:

Device# show port-security

Verifies your entries.

Step 14

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 15

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Enabling and Configuring Port Security Aging

Use this feature to remove and add devices on a secure port without manually deleting the existing secure MAC addresses and to still limit the number of secure addresses on a port. You can enable or disable the aging of secure addresses on a per-port basis.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface interface-id

Example:

Device(config)# interface gigabitethernet 1/0/1

Specifies the interface to be configured, and enter interface configuration mode.

Step 4

switchport port-security aging {static | time time | type {absolute | inactivity}}

Example:

Device(config-if)# switchport port-security aging time 120

Enables or disable static aging for the secure port, or set the aging time or type.

Note

The switch does not support port security aging of sticky secure addresses.

Enter static to enable aging for statically configured secure addresses on this port.

For time , specifies the aging time for this port. The valid range is from 0 to 1440 minutes.

For type , select one of these keywords:

- absolute —Sets the aging type as absolute aging. All the secure addresses on this port age out exactly after the time (minutes) specified lapses and are removed from the secure address list.

- inactivity —Sets the aging type as inactivity aging. The secure addresses on this port age out only if there is no data traffic from the secure source addresses for the specified time period.

Step 5

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 6

show port-security [interface interface-id] [address]

Example:

Device# show port-security interface gigabitethernet 1/0/1

Verifies your entries.

Step 7

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 8

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Monitoring Port Security

This table displays port security information.

Commands for Displaying Port Security Status and Configuration

Command

Purpose

show port-security [interface interface-id]

Displays port security settings for the switch or for the specified interface, including the maximum allowed number of secure MAC addresses for each interface, the number of secure MAC addresses on the interface, the number of security violations that have occurred, and the violation mode.

show port-security [interface interface-id] address

Displays all secure MAC addresses configured on all switch interfaces or on a specified interface with aging information for each address.

show port-security interface interface-id vlan

Displays the number of secure MAC addresses configured per VLAN on the specified interface.

Configuration Examples for Port Security

This example shows how to enable port security on a port and to set the maximum number of secure addresses to 50. The violation mode is the default, no static secure MAC addresses are configured, and sticky learning is enabled.

Device(config)# interface gigabitethernet 1/0/1
Device(config-if)# switchport mode access
Device(config-if)# switchport port-security
Device(config-if)# switchport port-security maximum 50
Device(config-if)# switchport port-security mac-address sticky

This example shows how to configure a static secure MAC address on VLAN 3 on a port:

Device(config)# interface gigabitethernet 1/0/2
Device(config-if)# switchport mode trunk
Device(config-if)# switchport port-security
Device(config-if)# switchport port-security mac-address 0000.0200.0004 vlan 3

This example shows how to enable sticky port security on a port, to manually configure MAC addresses for data VLAN and voice VLAN, and to set the total maximum number of secure addresses to 20 (10 for data VLAN and 10 for voice VLAN).

Device(config)# interface tengigabitethernet 1/0/1
Device(config-if)# switchport access vlan 21
Device(config-if)# switchport mode access
Device(config-if)# switchport voice vlan 22
Device(config-if)# switchport port-security
Device(config-if)# switchport port-security maximum 20
Device(config-if)# switchport port-security violation restrict
Device(config-if)# switchport port-security mac-address sticky
Device(config-if)# switchport port-security mac-address sticky 0000.0000.0002
Device(config-if)# switchport port-security mac-address 0000.0000.0003
Device(config-if)# switchport port-security mac-address sticky 0000.0000.0001 vlan voice
Device(config-if)# switchport port-security mac-address 0000.0000.0004 vlan voice
Device(config-if)# switchport port-security maximum 10 vlan access
Device(config-if)# switchport port-security maximum 10 vlan voice

Information About Protocol Storm Protection

- Protocol Storm Protection

- Default Protocol Storm Protection Configuration

Protocol Storm Protection

When a switch is flooded with Address Resolution Protocol (ARP) or control packets, high CPU utilization can cause the CPU to overload. These issues can occur:

- Routing protocol can flap because the protocol control packets are not received, and neighboring adjacencies are dropped.

- Spanning Tree Protocol (STP) reconverges because the STP bridge protocol data unit (BPDU) cannot be sent or received.

- CLI is slow or unresponsive.

Using protocol storm protection, you can control the rate at which control packets are sent to the switch by specifying the upper threshold for the packet flow rate. The supported protocols are ARP, ARP snooping, Dynamic Host Configuration Protocol (DHCP) v4, DHCP snooping, Internet Group Management Protocol (IGMP), and IGMP snooping.

When the packet rate exceeds the defined threshold, the switch drops all traffic arriving on the specified virtual port for 30 seconds. The packet rate is measured again, and protocol storm protection is again applied if necessary.

For further protection, you can manually error disable the virtual port, blocking all incoming traffic on the virtual port. You can manually enable the virtual port or set a time interval for automatic re-enabling of the virtual port.

Note

Excess packets are dropped on no more than two virtual ports.

Virtual port error disabling is not supported for EtherChannel and Flexlink interfaces

Default Protocol Storm Protection Configuration

Protocol storm protection is disabled by default. When it is enabled, auto-recovery of the virtual port is disabled by default.

How to Configure Protocol Storm Protection

- Enabling Protocol Storm Protection

Enabling Protocol Storm Protection

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

psp {arp | dhcp | igmp} pps value

Example:

Device(config)# psp dhcp pps 35

Configures protocol storm protection for ARP, IGMP, or DHCP.

For value , specifies the threshold value for the number of packets per second. If the traffic exceeds this value, protocol storm protection is enforced. The range is from 5 to 50 packets per second.

Step 4

errdisable detect cause psp

Example:

Device(config)# errdisable detect cause psp

(Optional) Enables error-disable detection for protocol storm protection. If this feature is enabled, the virtual port is error disabled. If this feature is disabled, the port drops excess packets without error disabling the port.

Step 5

errdisable recovery interval time

Example:

Device

(Optional) Configures an auto-recovery time (in seconds) for error-disabled virtual ports. When a virtual port is error-disabled, the switch auto-recovers after this time. The range is from 30 to 86400 seconds.

Step 6

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 7

show psp config {arp | dhcp | igmp}

Example:

Device# show psp config dhcp

Verifies your entries.

Monitoring Protocol Storm Protection

Command

Purpose

show psp config {arp | dhcp | igmp}

Verify your entries.

Additional References for Port-Based Traffic Control

MIBs

MIB

MIBs Link

All the supported MIBs for this release.

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

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

Technical Assistance

Description

Link

The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies.

To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.

Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.

http://www.cisco.com/support

Chapter 23. Configuring Control Plane Policing

- Restrictions for CoPP

- Information About CoPP

- How to Configure CoPP

- Configuration Examples for CoPP

- Monitoring CoPP

- Feature Information for CoPP

Restrictions for CoPP

Restrictions for control plane policing (CoPP) include the following:

- Only ingress CoPP is supported. The system-cpp-policy policy-map is available on the control plane interface, and only in the ingress direction.

- Only the system-cpp-policy policy-map can be installed on the control plane interface.

- The system-cpp-policy policy-map and the system-defined classes cannot be modified or deleted.

- Only the police action is allowed under the system-cpp-policy policy-map. The police rate for system-defined classes must be configured only in packets per second (pps)

- One or more CPU queues are part of each class-map. Where multiple CPU queues belong to one class-map, changing the policer rate of a class-map affects all CPU queues that belong to that class-map. Similarly, disabling the policer in a class-map disables all queues that belong to that class-map. See Table: System-Defined Values for CoPP for information about which CPU queues belong to each class-map.

- Disabling the policer for a system-defined class map is not recommended. That is, do not configure the no police rate rate pps command. Doing so affects the overall system health in case of high traffic towards the CPU. Further, even if you disable the policer rate for a system-defined class map, the systems automatically reverts to the default policer rate after system bootup in order to protect the system bring-up process.

- The show run command does not display information about classes configured under system-cpp policy, when they are left at default values. Use the show policy-map system-cpp-policy or the show policy-map control-plane commands instead.

You can continue use the show run command to display information about custom policies.

- Starting from Cisco IOS XE Fuji 16.8.1a, the creation of user-defined class-maps is not supported.

Information About CoPP

This chapter describes how control plane policing (CoPP) works on your device and how to configure it.

- CoPP Overview

- System-Defined Aspects of CoPP

- User-Configurable Aspects of CoPP

CoPP Overview

The CoPP feature improves security on your device protecting the CPU from unnecessary traffic and DoS attacks. It can also protect control and management traffic from traffic drops caused by high volumes of other, lower priority traffic.

Your device is typically segmented into three planes of operation, each with its own objective:

- The data plane, to forward data packets.

- The control plane, to route data correctly.

- The management plane, to manage network elements.

You can use CoPP to protect most of the CPU-bound traffic and ensure routing stability, reachability, and packet delivery. Most importantly, you can use CoPP to protect the CPU from a DoS attack.

CoPP uses the modular QoS command-line interface (MQC) and CPU queues to achieve these objectives. Different types of control plane traffic are grouped together based on certain criteria, and assigned to a CPU queue. You can manage these CPU queues by configuring dedicated policers in hardware. For example, you can modify the policer rate for certain CPU queues (traffic-type), or you can disable the policer for a certain type of traffic.

Although the policers are configured in hardware, CoPP does not affect CPU performance or the performance of the data plane. But since it limits the number of packets going to CPU, the CPU load is controlled. This means that services waiting for packets from hardware may see a more controlled rate of incoming packets (the rate being user-configurable).

System-Defined Aspects of CoPP

When you power-up the device for the first time, the system automatically performs the following tasks:

- Looks for policy-map system-cpp-policy . If not found, the system creates and installs it on the control-plane.

- Creates 18 class-maps under system-cpp-policy .

The next time you power-up the device, the system detects the policy and class maps that have already been created.

- Enables all CPU queues by default, with their respective default rate. The default rates are indicated in the table System-Defined Values for CoPP.

The following table lists the class-maps that the system creates when you load the device. It lists the policer that corresponds to each class-map and one or more CPU queues that are grouped under each class-map. There is a one-to-one mapping of a class-map to a policer; and one-to-many mapping of a class-map to CPU queues.

System-Defined Values for CoPP

Class Maps Names

Policer Index (Policer No.)

CPU queues (Queue No.)

Default Policer Rate (pps)

system-cpp- police-data

WK_CPP_POLICE_DATA(0)

WK_CPU_Q_ICMP_GEN(3)

WK_CPU_Q_BROADCAST(12)

WK_CPU_Q_ICMP_REDIRECT (6)

600

600

600

system-cpp-police-l2- control

WK_CPP_POLICE_L2_ CONTROL(1)

WK_CPU_Q_L2_CONTROL(1)

2000

system-cpp-police-routing-control

WK_CPP_POLICE_ROUTING_CONTROL(2)

WK_CPU_Q_ROUTING_CONTROL(4)

WK_CPU_Q_LOW_LATENCY (27)

5400

5400

system-cpp-police-punt-webauth

WK_CPP_POLICE_PU NT_WEBAUTH(7)

WK_CPU_Q_PUNT_WEBAUTH(22)

1000

system-cpp-police- topology-control

WK_CPP_POLICE_TOPOLOGY_CONTROL(8)

WK_CPU_Q_TOPOLOGY_CONTROL(15)

13000

system-cpp-police- multicast

WK_CPP_POLICE_MULTICAST(9)

WK_CPU_Q_TRANSIT_TRAFFIC(18)

WK_CPU_Q_MCAST_DATA(30)

500

500

system-cpp-police-sys- data

WK_CPP_POLICE_SYS _DATA (10)

WK_CPU_Q_OPENFLOW (13)

WK_CPU_Q_CRYPTO_CONTROL(23)

WK_CPU_Q_EXCEPTION(24)

WK_CPU_Q_EGR_EXCEPTION(28)

WK_CPU_Q_NFL_SAMPLED_DATA(26)

WK_CPU_Q_GOLD_PKT(31)

WK_CPU_Q_RPF_FAILED(19)

100

100

100

100

100

100

100

system-cpp-police-dot1x-auth

WK_CPP_POLICE_DOT1X(11)

WK_CPU_Q_DOT1X_AUTH(0)

1000

system-cpp-police- protocol-snooping

WK_CPP_POLICE_PR

WK_CPU_Q_PROTO_SNOOPING(16)

2000

system-cpp-police-dhcp-snooping

WK_CPP_DHCP_SNOOPING

WK_CPU_Q_DHCP_SNOOPING(17)

500

system-cpp-police-sw-forward

WK_CPP_POLICE_SW_FWD (13)

WK_CPU_Q_SW_FORWARDING_Q(14)

WK_CPU_Q_LOGGING(21)

WK_CPU_Q_L2_LVX_DATA_PACK (11)

1000

1000

1000

system-cpp-police-forus

WK_CPP_POLICE_FORUS(14)

WK_CPU_Q_FORUS_ADDR_RESOLUTION(5)

WK_CPU_Q_FORUS_TRAFFIC(2)

4000

4000

system-cpp-police- multicast-end-station

WK_CPP_POLICE_MULTICAST_SNOOPING(15)

WK_CPU_Q_MCAST_END_STA TION_SERVICE(20)

2000

system-cpp-default

WK_CPP_POLICE_DEFAULT_POLICER

WK_CPU_Q_INTER_FED_TRAFFIC

WK_CPU_Q_EWLC_CONTROL(9)

WK_CPU_Q_EWLC_DATA(10)

2000

2000

2000

system-cpp-police-stackwise-virt-control

WK_CPP_STACKWISE_VIRTUAL_CONTROL

WK_CPU_Q_STACKWISE_VIRTUAL_CONTROL (29)

8000

system-cpp-police-l2lvx-control

WK_CPP_ L2_LVX_CONT_PACK

WK_CPU_Q_L2_LVX_CONT_PACK(8)

1000

system-cpp-police-high-rate-app

WK_CPP_HIGH_RATE_APP

WK_CPU_Q_HIGH_RATE_APP

13000

system-cpp-police-system-critical

WK_CPP_SYSTEM_CRITICAL

WK_CPU_Q_SYSTEM_CRITICAL

1000

User-Configurable Aspects of CoPP

You can perform these tasks to manage control plane traffic:

Note

All system-cpp-policy configurations must be saved so they are retained after reboot.

Enable or Disable a Policer for CPU Queues

Enable a policer for a CPU queue, by configuring a policer action (in packets per second) under the corresponding class-map, within the system-cpp-policy policy-map.

Disable a policer for CPU queue, by removing the policer action under the corresponding class-map, within the system-cpp-policy policy-map.

Note

If a default policer is already present, carefully consider and control its removal; otherwise the system may see a CPU hog or other anomalies, such as control packet drops.

Change the Policer Rate

You can do this by configuring a policer rate action (in packets per second), under the corresponding class-map, within thesystem-cpp-policy policy-map.

Set Policer Rates to Default

Set the policer for CPU queues to their default values, by entering the cpp system-default command in global configuration mode.

Software Version Upgrades and CoPP

When you upgrade the software version on your device, the system checks and make the necessary updates as required for CoPP (For instance, it checks for the system-cpp-policy policy map and creates it if missing). You may also have to complete certain tasks before or after the upgrade activity. This is to ensure that any configuration updates are reflected correctly and CoPP continues to work as expected. Depending on the method you use to upgrade the software, upgrade-related tasks may be optional or recommended in some scenarios, and mandatory in others.

The system actions and user actions for an upgrade, are described here. Also included, are any release-specfic caveats.

System Actions for an Upgrade

When you upgrade the software version on your device, the system performs these actions. This applies to all upgrade methods:

- If the device did not have a system-cpp-policy policy map before upgrade, then on upgrade, the system creates a default policy map.

- If the device had a system-cpp-policy policy map before upgrade, then on upgrade, the system does not re-generate the policy.

User Actions for an Upgrade

User actions for an upgrade – depending on upgrade method:

Upgrade Method

Condition

Action Time and Action

Purpose

Regular[1]

None

After upgrade (required)

Enter the cpp system-default command in global configuration mode

To get the latest, default policer rates.

[1] Refers to a software upgrade method that involves a reload of the switch. Can be install or bundle mode.

Software Version Downgrades and CoPP

The system actions and user actions for a downgrade, are described here.

System Actions for a Downgrade

When you downgrade the software version on your device, the system performs these actions. This applies to all downgrade methods:

- The system retains the system-cpp-policy policy map on the device, and installs it on the control plane.

User Actions for a Downgrade

User actions for a downgrade:

Upgrade Method

Condition

Action Time and Action

Purpose

Regular[1]

None

No action required

Not applicable

[1] Refers to a software upgrade method that involves a reload of the switch. Can be install or bundle mode.

If you downgrade the software version and then upgrade, the system action and user actions that apply are the same as those mentioned for upgrades.

How to Configure CoPP

- Enabling a CPU Queue or Changing the Policer Rate

- Disabling a CPU Queue

- Setting the Default Policer Rates for All CPU Queues

Enabling a CPU Queue or Changing the Policer Rate

The procedure to enable a CPU queue and change the policer rate of a CPU queue is the same. Follow these steps:

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

policy-map policy-map-name

Example:

Device(config)# policy-map system-cpp-policy
Device(config-pmap)#

Enters the policy map configuration mode.

Step 4

class class-name

Example:

Device(config-pmap)# class system-cpp-police-protocol-snooping
Device(config-pmap-c)#

Enters the class action configuration mode. Enter the name of the class that corresponds to the CPU queue you want to enable. See table System-Defined Values for CoPP.

Step 5

police rate rate pps

Example:

Device(config-pmap-c)# police rate 100 pps
Device(config-pmap-c-police)#

Specifies an upper limit on the number of incoming packets processed per second, for the specified traffic class.

Note

The rate you specify is applied to all CPU queues that belong to the class-map you have specified.

Step 6

exit

Example:

Device(config-pmap-c-police)# exit
Device(config-pmap-c)# exit
Device(config-pmap)# exit
Device(config)#

Returns to the global configuration mode.

Step 7

control-plane

Example:

Device(config)# control-plane
Device(config-cp)#

Enters the control plane (config-cp) configuration mode

Step 8

service-policy input policy-name

Example:

Device(config)# control-plane
Device(config-cp)#service-policy input system-cpp-policy
Device(config-cp)#

Installs system-cpp-policy in FED. This command is required for you to see the FED policy. Not configuring this command will lead to an error.

Step 9

end

Example:

Device(config-cp)# end

Returns to the privileged EXEC mode.

Step 10

show policy-map control-plane

Example:

Device# show policy-map control-plane

Displays all the classes configured under system-cpp policy, the rates configured for the various traffic types, and statistics

Disabling a CPU Queue

Follow these steps to disable a CPU queue:

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

policy-map policy-map-name

Example:

Device(config)# policy-map system-cpp-policy
Device(config-pmap)#

Enters the policy map configuration mode.

Step 4

class class-name

Example:

Device(config-pmap)# class system-cpp-police-protocol-snooping
Device(config-pmap-c)#

Enters the class action configuration mode. Enter the name of the class that corresponds to the CPU queue you want to disable. See the table, System-Defined Values for CoPP.

Step 5

no police rate rate pps

Example:

Device(config-pmap-c)# no police rate 100 pps

Disables incoming packet processing for the specified traffic class.

Note

This disables all CPU queues that belong to the class-map you have specified.

Step 6

end

Example:

Device(config-pmap-c)# end

Returns to the privileged EXEC mode.

Step 7

show policy-map control-plane

Example:

Device# show policy-map control-plane

Displays all the classes configured under system-cpp policy and the rates configured for the various traffic types and statistics.

Setting the Default Policer Rates for All CPU Queues

Follow these steps to set the policer rates for all CPU queues to their default rates:

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

cpp system-default

Example:

Device(config)# cpp system-default
Defaulting CPP : Policer rate for all classes will be set to their defaults

Sets the policer rates for all the classes to the default rate.

Step 4

end

Example:

Device(config)# end

Returns to the privileged EXEC mode.

Configuration Examples for CoPP

- Example: Enabling a CPU Queue or Changing the Policer Rate of a CPU Queue

- Example: Disabling a CPU Queue

- Example: Setting the Default Policer Rates for All CPU Queues

Example: Enabling a CPU Queue or Changing the Policer Rate of a CPU Queue

This example shows how to enable a CPU queue or to change the policer rate of a CPU queue. Here the class system-cpp-police-protocol-snooping CPU queue is enabled with the policer rate of 2000 pps .

Device> enable
Device# configure terminal
Device(config)# policy-map system-cpp-policy
Device(config-pmap)# class system-cpp-police-protocol-snooping
Device(config-pmap-c)# police rate 2000 pps
Device(config-pmap-c-police)# end

Device# show policy-map control-plane
Control Plane

Service-policy input: system-cpp-policy

<output truncated>

Class-map: system-cpp-police-dot1x-auth (match-any)
0 packets, 0 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: none
police:
rate 1000 pps, burst 244 packets
conformed 0 bytes; actions:
transmit
exceeded 0 bytes; actions:
drop

Class-map: system-cpp-police-protocol-snooping (match-any)
0 packets, 0 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: none
police:
rate 2000 pps, burst 488 packets
conformed 0 bytes; actions:
transmit
exceeded 0 bytes; actions:
drop

<output truncated>

Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: any

Example: Disabling a CPU Queue

This example shows how to disable a CPU queue. Here the class system-cpp-police-protocol-snooping CPU queue is disabled.

Device> enable
Device# configure terminal
Device(config)# policy-map system-cpp-policy
Device(config-pmap)# class system-cpp-police-protocol-snooping
Device(config-pmap-c)# no police rate 100 pps
Device(config-pmap-c)# end

Device# show running-config | begin system-cpp-policy

policy-map system-cpp-policy
class system-cpp-police-data
police rate 200 pps
class system-cpp-police-sys-data
police rate 100 pps
class system-cpp-police-sw-forward
police rate 1000 pps
class system-cpp-police-multicast
police rate 500 pps
class system-cpp-police-multicast-end-station
police rate 2000 pps
class system-cpp-police-punt-webauth
class system-cpp-police-l2-control
class system-cpp-police-routing-control
police rate 500 pps
class system-cpp-police-control-low-priority
class system-cpp-police-wireless-priority1
class system-cpp-police-wireless-priority2
class system-cpp-police-wireless-priority3-4-5
class system-cpp-police-topology-control
class system-cpp-police-dot1x-auth
class system-cpp-police-protocol-snooping
class system-cpp-police-forus
class system-cpp-default

<output truncated>

Example: Setting the Default Policer Rates for All CPU Queues

This example shows how to set the policer rates for all CPU queues to their default and then verify the setting.

Device> enable
Device# configure terminal
Device(config)# cpp system-default
Defaulting CPP : Policer rate for all classes will be set to their defaults
Device(config)# end

Device# show platform hardware fed switch 1 qos queue stats internal cpu policer
CPU Queue Statistics
============================================================================================
(default) (set)     Queue        Queue
QId PlcIdx  Queue Name                Enabled   Rate     Rate      Drop(Bytes)  Drop(Frames)
--------------------------------------------------------------------------------------------
0    11     DOT1X Auth                  Yes     1000      1000     0            0
1    1      L2 Control                  Yes     2000      2000     0            0
2    14     Forus traffic               Yes     4000      4000     0            0
3    0      ICMP GEN                    Yes     600       600      0            0
4    2      Routing Control             Yes     5400      5400     0            0
5    14     Forus Address resolution    Yes     4000      4000     0            0
6    0      ICMP Redirect               Yes     600       600      0            0
7    16     Inter FED Traffic           Yes     2000      2000     0            0
8    4      L2 LVX Cont Pack            Yes     1000      1000     0            0
9    16     EWLC Control                Yes     2000      2000     0            0
10   16     EWLC Data                   Yes     2000      2000     0            0
11   13     L2 LVX Data Pack            Yes     1000      1000     0            0
12   0      BROADCAST                   Yes     600       600      0            0
13   10     Openflow                    Yes     100       100      0            0
14   13     Sw forwarding               Yes     1000      1000     0            0
15   8      Topology Control            Yes     13000     13000    0            0
16   12     Proto Snooping              Yes     2000      2000     0            0
17   6      DHCP Snooping               Yes     500       500      0            0
18   9      Transit Traffic             Yes     500       500      0            0
19   10     RPF Failed                  Yes     100       100      0            0
20   15     MCAST END STATION           Yes     2000      2000     0            0
21   13     LOGGING                     Yes     1000      1000     0            0
22   7      Punt Webauth                Yes     1000      1000     0            0
23   18     High Rate App               Yes     13000     13000    0            0
24   10     Exception                   Yes     100       100      0            0
25   3      System Critical             Yes     1000      1000     0            0
26   10     NFL SAMPLED DATA            Yes     100       200      0            0
27   2      Low Latency                 Yes     5400      5400     0            0
28   10     EGR Exception               Yes     100       100      0            0
29   5      Stackwise Virtual OOB       Yes     8000      8000     0            0
30   9      MCAST Data                  Yes     500       500      0            0
31   10     Gold Pkt                    Yes     100       100      0            0

* NOTE: CPU queue policer rates are configured to the closest hardware supported value

CPU Queue Policer Statistics
====================================================================
Policer    Policer Accept   Policer Accept  Policer Drop  Policer Drop
Index         Bytes          Frames        Bytes          Frames
-------------------------------------------------------------------
0          0                0               0             0
1          0                0               0             0
2          0                0               0             0
3          0                0               0             0
4          0                0               0             0
5          0                0               0             0
6          0                0               0             0
7          0                0               0             0
8          0                0               0             0
9          0                0               0             0
10         0                0               0             0
11         0                0               0             0
12         0                0               0             0
13         0                0               0             0
14         0                0               0             0
15         0                0               0             0
16         0                0               0             0
17         0                0               0             0
18         0                0               0             0

CPP Classes to queue map
======================================================================================
PlcIdx CPP Class                                :  Queues
--------------------------------------------------------------------------------------
0      system-cpp-police-data                   :  ICMP GEN/BROADCAST/ICMP Redirect/
10     system-cpp-police-sys-data               :  Openflow/Exception/EGR Exception/NFL SAMPLED DATA/Gold Pkt/RPF Failed/
13     system-cpp-police-sw-forward             :  Sw forwarding/LOGGING/L2 LVX Data Pack/
9      system-cpp-police-multicast              :  Transit Traffic/MCAST Data/
15     system-cpp-police-multicast-end-station  :  MCAST END STATION /
7      system-cpp-police-punt-webauth           :  Punt Webauth/
1      system-cpp-police-l2-control             :  L2 Control/
2      system-cpp-police-routing-control        :  Routing Control/Low Latency/
3      system-cpp-police-system-critical        :  System Critical/
4      system-cpp-police-l2lvx-control          :  L2 LVX Cont Pack/
8      system-cpp-police-topology-control       :  Topology Control/
11     system-cpp-police-dot1x-auth             :  DOT1X Auth/
12     system-cpp-police-protocol-snooping      :  Proto Snooping/
6      system-cpp-police-dhcp-snooping          :  DHCP Snooping/
14     system-cpp-police-forus                  :  Forus Address resolution/Forus traffic/
5      system-cpp-police-stackwise-virt-control :  Stackwise Virtual OOB/
16     system-cpp-default                       :  Inter FED Traffic/EWLC Control/EWLC Data/
18     system-cpp-police-high-rate-app          :  High Rate App/

Monitoring CoPP

Use these commands to display policer settings, such as, traffic types and policer rates (user-configured and default rates) for CPU queues:

Command

Purpose

show policy-map control-plane

Displays the rates configured for the various traffic types

show policy-map system-cpp-policy

Displays all the classes configured under system-cpp policy, and policer rates

show platform hardware fed switch{ switch-number} qos que stats internal cpu policer

Displays the rates configured for the various traffic types

show platform software fed { switch-number} qos policy target status

Displays information about policy status and the target port type.

Feature Information for CoPP

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

Feature

Release

Feature Information

Control Plane Policing (CoPP) or CPP

Cisco IOS XE 3.3SE

This feature was introduced.

CLI configuration for CoPP

Cisco IOS XE Denali 16.1.2

This feature was made user-configurable. CLI configuration options to enable and disable CPU queues, to change the policer rate, and to set policer rates to default.

User-defined class maps

Cisco IOS XE Everest 16.5.1a

Starting with this release, you can create class maps (with filters) and add these user-defined class maps to system-cpp-policy.

Changes in system-defined values for CoPP

Cisco IOS XE Everest 16.6.1

These new system-defined classes were introduced:

- system-cpp-police-stackwise-virt-control

- system-cpp-police-l2lvx-control

These new CPU queues were added to the existing system-cpp-default class:

- WK_CPU_Q_UNUSED (7)

- WK_CPU_Q_EWLC_CONTROL(9)

- WK_CPU_Q_EWLC_DATA(10)

This new CPU queues was added to the existing system-cpp-police-sw-forward: WK_CPU_Q_L2_LVX_DATA_PACK (11)

This CPU queue is no longer available: WK_CPU_Q_SGT_CACHE_FULL(27)

Removal of support for user-defined class-maps and changes in system-defined values for CoPP

Cisco IOS XE Fuji 16.8.1a

- Starting from this release, the creation of user-defined class-maps is not supported.

- This new system-defined class was introduced: system-cpp-police-dhcp-snooping

- This new CPU queue was added to the existing system-cpp-default class: WK_CPU_Q_INTER_FED_TRAFFIC

- These CPU queues are no longer available:

- WK_CPU_Q_SHOW_FORWARD

- WK_CPU_Q_UNUSED

- The default policer rate (pps) for some CPU queues has changed:

- The default rate for WK_CPU_Q_EXCEPTION(24) was changed to 100

- The default rate for all the CPU queues under system-cpp-default was increased to 2000.

- The default rate for all the CPU queues under system-cpp-police-forus was increased to 4000.

Changes in system-defined values for CoPP

Cisco IOS XE Fuji 16.9.1

Starting with this release, eighteen system-defined classes are created under system-cpp-policy.

These new system-defined classes were introduced:

- system-cpp-police-high-rate-app

- system-cpp-police-system-critical

This was added to class system-cpp-police-sys- data: CPU queue WK_CPU_Q_OPENFLOW (13).

This CPU queue is no longer available: WK_CPU_Q_LEARNING_CACHE_OVFL(13).

Deprecation of system-defined class map

Cisco IOS XE Fuji 16.9.4

This system-defined class map was deprecated: system-cpp-police-control-low-priority

Chapter 24. Configuring Authorization and Revocation of Certificates in a PKI

- Configuring Authorization and Revocation of Certificates in a PKI

Configuring Authorization and Revocation of Certificates in a PKI

- Prerequisites for Authorization and Revocation of Certificates

- Restrictions for Authorization and Revocation of Certificates

- Information About Authorization and Revocation of Certificates

- How to Configure Authorization and Revocation of Certificates for Your PKI

- Configuration Examples for Setting Up Authorization and Revocation of Certificates

- Additional References

- Feature Information for Certificate Authorization and Revocation

Prerequisites for Authorization and Revocation of Certificates

Plan Your PKI Strategy

Tip

It is strongly recommended that you plan your entire PKI strategy before you begin to deploy actual certificates.

Authorization and revocation can occur only after you or a network administrator have completed the following tasks:

- Configured the certificate authority (CA).

- Enrolled peer devices with the CA.

- Identified and configured the protocol (such as IP Security [IPsec] or secure socket layer [SSL]) that is to be used for peer-to-peer communication.

You should decide which authorization and revocation strategy you are going to configure before enrolling peer devices because the peer device certificates might have to contain authorization and revocation-specific information.

High Availability

For high availability, IPsec-secured Stream Control Transmission Protocol (SCTP) must be configured on both the active and the standby routers. For synchronization to work, the redundancy mode on the certificate servers must be set to ACTIVE/STANDBY after you configure SCTP.

Restrictions for Authorization and Revocation of Certificates

- Depending on your Cisco IOS release, Lightweight Directory Access Protocol (LDAP) is supported.

Information About Authorization and Revocation of Certificates

- PKI Authorization

- PKI and AAA Server Integration for Certificate Status

- CRLs or OCSP Server Choosing a Certificate Revocation Mechanism

- When to Use Certificate-Based ACLs for Authorization or Revocation

- PKI Certificate Chain Validation

PKI Authorization

PKI authentication does not provide authorization. Current solutions for authorization are specific to the router that is being configured, although a centrally managed solution is often required.

There is not a standard mechanism by which certificates are defined as authorized for some tasks and not for others. This authorization information can be captured in the certificate itself if the application is aware of the certificate-based authorization information. But this solution does not provide a simple mechanism for real-time updates to the authorization information and forces each application to be aware of the specific authorization information embedded in the certificate.

When the certificate-based ACL mechanism is configured as part of the trustpoint authentication, the application is no longer responsible for determining this authorization information, and it is no longer possible to specify for which application the certificate is authorized. In some cases, the certificate-based ACL on the router gets so large that it cannot be managed. Additionally, it is beneficial to retrieve certificate-based ACL indications from an external server.

Current solutions to the real-time authorization problem involve specifying a new protocol and building a new server (with associated tasks, such as management and data distribution).

PKI and AAA Server Integration for Certificate Status

Integrating your PKI with an authentication, authorization, and accounting (AAA) server provides an alternative online certificate status solution that leverages the existing AAA infrastructure. Certificates can be listed in the AAA database with appropriate levels of authorization. For components that do not explicitly support PKI-AAA, a default label of “all” from the AAA server provides authorization. Likewise, a label of “none” from the AAA database indicates that the specified certificate is not valid. (The absence of any application label is equivalent, but “none” is included for completeness and clarity). If the application component does support PKI-AAA, the component may be specified directly; for example, the application component could be “ipsec,” “ssl,” or “osp.” (ipsec=IP Security, ssl=Secure Sockets Layer, and osp=Open Settlement Protocol.)

Note

Currently, no application component supports specification of the application label.

- There may be a time delay when accessing the AAA server. If the AAA server is not available, the authorization fails.

- RADIUS or TACACS+ Choosing a AAA Server Protocol

- Attribute-Value Pairs for PKI and AAA Server Integration

RADIUS or TACACS+ Choosing a AAA Server Protocol

The AAA server can be configured to work with either the RADIUS or TACACS+ protocol. When you are configuring the AAA server for the PKI integration, you must set the RADIUS or TACACS attributes that are required for authorization.

If the RADIUS protocol is used, the password that is configured for the username in the AAA server should be set to “cisco,” which is acceptable because the certificate validation provides authentication and the AAA database is only being used for authorization. When the TACACS protocol is used, the password that is configured for the username in the AAA server is irrelevant because TACACS supports authorization without requiring authentication (the password is used for authentication).

In addition, if you are using TACACS, you must add a PKI service to the AAA server. The custom attribute “cert-application=all” is added under the PKI service for the particular user or usergroup to authorize the specific username.

Attribute-Value Pairs for PKI and AAA Server Integration

The table below lists the attribute-value (AV) pairs that are to be used when setting up PKI integration with a AAA server. (Note the values shown in the table are possible values.) The AV pairs must match the client configuration. If they do not match, the peer certificate is not authorized.

Note

Users can sometimes have AV pairs that are different from those of every other user. As a result, a unique username is required for each user. The all parameter (within the authorization username command) specifies that the entire subject name of the certificate will be used as the authorization username.

AV Pairs That Must Match

AV Pair

Value

cisco-avpair=pki:cert-application=all

Valid values are “all” and “none.”

cisco-avpair=pki:cert-trustpoint=msca

The value is a Cisco IOS command-line interface (CLI) configuration trustpoint label.

Note

The cert-trustpoint AV pair is normally optional. If it is specified, the Cisco IOS router query must be coming from a certificate trustpoint that has a matching label, and the certificate that is authenticated must have the specified certificate serial number.

cisco-avpair=pki:cert-serial=16318DB7000100001671

The value is a certificate serial number.

Note

The cert-serial AV pair is normally optional. If it is specified, the Cisco IOS router query must be coming from a certificate trustpoint that has a matching label, and the certificate that is authenticated must have the specified certificate serial number.

cisco-avpair=pki:cert-lifetime-end=1:00 jan 1, 2003

The cert-lifetime-end AV pair is available to artificially extend a certificate lifetime beyond the time period that is indicated in the certificate itself. If the cert-lifetime-end AV pair is used, the cert-trustpoint and cert-serial AV pairs must also be specified. The value must match the following form: hours:minutes month day, year.

Note

Only the first three characters of a month are used: Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec. If more than three characters are entered for the month, the remaining characters are ignored (for example Janxxxx).

CRLs or OCSP Server Choosing a Certificate Revocation Mechanism

After a certificate is validated as a properly signed certificate, a certificate revocation method is performed to ensure that the certificate has not been revoked by the issuing CA. Cisco IOS software supports two revocation mechanisms--certificate revocation lists (CRLs) and Online Certificate Status Protocol (OCSP). Cisco IOS software also supports AAA integration for certificate checking; however, additional authorization functionality is included. For more information on PKI and AAA certificate authorization and status check, see the PKI and AAA Server Integration for Certificate Status section.

The following sections explain how each revocation mechanism works:

- What Is a CRL

- What Is OCSP

What Is a CRL

A certificate revocation list (CRL) is a list of revoked certificates. The CRL is created and digitally signed by the CA that originally issued the certificates. The CRL contains dates for when each certificate was issued and when it expires.

CAs publish new CRLs periodically or when a certificate for which the CA is responsible has been revoked. By default, a new CRL is downloaded after the currently cached CRL expires. An administrator may also configure the duration for which CRLs are cached in router memory or disable CRL caching completely. The CRL caching configuration applies to all CRLs associated with a trustpoint.

When the CRL expires, the router deletes it from its cache. A new CRL is downloaded when a certificate is presented for verification; however, if a newer version of the CRL that lists the certificate under examination is on the server but the router is still using the CRL in its cache, the router does not know that the certificate has been revoked. The certificate passes the revocation check even though it should have been denied.

When a CA issues a certificate, the CA can include in the certificate the CRL distribution point (CDP) for that certificate. Cisco IOS client devices use CDPs to locate and load the correct CRL. The Cisco IOS client supports multiple CDPs, but the Cisco IOS CA currently supports only one CDP; however, third-party vendor CAs may support multiple CDPs or different CDPs per certificate. If a CDP is not specified in the certificate, the client device uses the default Simple Certificate Enrollment Protocol (SCEP) method to retrieve the CRL. (The CDP location can be specified through the cdp-url command.)

When implementing CRLs, you should consider the following design considerations:

- CRL lifetimes and the security association (SA) and Internet Key Exchange (IKE) lifetimes.

- The CRL lifetime determines the length of time between CA-issued updates to the CRL. The default CRL lifetime value, which is 168 hours [1 week], can be changed through the lifetime crl command.

- The method of the CDP determines how the CRL is retrieved; some possible choices include HTTP, Lightweight Directory Access Protocol (LDAP), SCEP, or TFTP. HTTP, TFTP, and LDAP are the most commonly used methods. Although Cisco IOS software defaults to SCEP, an HTTP CDP is recommended for large installations using CRLs because HTTP can be made highly scalable.

- The location of the CDP determines from where the CRL is retrieved; for example, you can specify the server and file path from which to retrieve the CRL.

- Querying All CDPs During Revocation Check

Querying All CDPs During Revocation Check

When a CDP server does not respond to a request, the Cisco IOS software reports an error, which may result in the peer’s certificate being rejected. To prevent a possible certificate rejection and if there are multiple CDPs in a certificate, the Cisco IOS software will attempt to use the CDPs in the order in which they appear in the certificate. The router will attempt to retrieve a CRL using each CDP URL or directory specification. If an error occurs using a CDP, an attempt will be made using the next CDP.

Tip

Although the Cisco IOS software will make every attempt to obtain the CRL from one of the indicated CDPs, it is recommended that you use an HTTP CDP server with high-speed redundant HTTP servers to avoid application timeouts because of slow CDP responses.

What Is OCSP

OCSP is an online mechanism that is used to determine certificate validity and provides the following flexibility as a revocation mechanism:

- OCSP can provide real-time certificate status checking.

- OCSP allows the network administrator to specify a central OCSP server, which can service all devices within a network.

- OCSP also allows the network administrator the flexibility to specify multiple OCSP servers, either per client certificate or per group of client certificates.

- OCSP server validation is usually based on the root CA certificate or a valid subordinate CA certificate, but may also be configured so that external CA certificates or self-signed certificates may be used. Using external CA certificates or self-signed certificates allows the OCSP servers certificate to be issued and validated from an alternative PKI hierarchy.

A network administrator can configure an OCSP server to collect and update CRLs from different CA servers. The devices within the network can rely on the OCSP server to check the certificate status without retrieving and caching each CRL for every peer. When peers have to check the revocation status of a certificate, they send a query to the OCSP server that includes the serial number of the certificate in question and an optional unique identifier for the OCSP request, or a nonce. The OCSP server holds a copy of the CRL to determine if the CA has listed the certificate as being revoked; the server then responds to the peer including the nonce. If the nonce in the response from the OCSP server does not match the original nonce sent by the peer, the response is considered invalid and certificate verification fails. The dialog between the OCSP server and the peer consumes less bandwidth than most CRL downloads.

If the OCSP server is using a CRL, CRL time limitations will be applicable; that is, a CRL that is still valid might be used by the OCSP server although a new CRL has been issued by the CRL containing additional certificate revocation information. Because fewer devices are downloading the CRL information on a regular basis, you can decrease the CRL lifetime value or configure the OCSP server not to cache the CRL. For more information, check your OCSP server documentation.

Note

OCSP multiple response handling: Support has been enabled for handling of multiple OCSP single responses from an OCSP responder in a response packet. In addition to the debug log messages the following debug log message will be displayed:

CRYPTO_PKI: Number of single Responses in OCSP response:1(this value can change depending upon the number of responses).

- When to Use an OCSP Server

When to Use an OCSP Server

OCSP may be more appropriate than CRLs if your PKI has any of the following characteristics:

- Real-time certificate revocation status is necessary. CRLs are updated only periodically and the latest CRL may not always be cached by the client device. For example, if a client does not yet have the latest CRL cached and a newly revoked certificate is being checked, that revoked certificate will successfully pass the revocation check.

- There are a large number of revoked certificates or multiple CRLs. Caching a large CRL consumes large portions of Cisco IOS memory and may reduce resources available to other processes.

- CRLs expire frequently, causing the CDP to handle a larger load of CRLs.

When to Use Certificate-Based ACLs for Authorization or Revocation

Certificates contain several fields that are used to determine whether a device or user is authorized to perform a specified action.

Because certificate-based ACLs are configured on the device, they do not scale well for large numbers of ACLs; however, certificate-based ACLs do provide very granular control of specific device behavior. Certificate-based ACLs are also leveraged by additional features to help determine when PKI components such as revocation, authorization, or a trustpoint should be used. They provide a general mechanism allowing users to select a specific certificate or a group of certificates that are being validated for either authorization or additional processing.

Certificate-based ACLs specify one or more fields within the certificate and an acceptable value for each specified field. You can specify which fields within a certificate should be checked and which values those fields may or may not have.

There are six logical tests for comparing the field with the value--equal, not equal, contains, does not contain, less than, and greater than or equal. If more than one field is specified within a single certificate-based ACL, the tests of all of the fields within the ACL must succeed to match the ACL. The same field may be specified multiple times within the same ACL. More than one ACL may be specified, and ACL will be processed in turn until a match is found or all of the ACLs have been processed.

- Ignore Revocation Checks Using a Certificate-Based ACL

Ignore Revocation Checks Using a Certificate-Based ACL

Certificate-based ACLs can be configured to instruct your router to ignore the revocation check and expired certificates of a valid peer. Thus, a certificate that meets the specified criteria can be accepted regardless of the validity period of the certificate, or if the certificate meets the specified criteria, revocation checking does not have to be performed. You can also use a certificate-based ACL to ignore the revocation check when the communication with a AAA server is protected with a certificate.

Ignoring Revocation Lists

To allow a trustpoint to enforce CRLs except for specific certificates, enter the match certificate command with the skip revocation-check keyword. This type of enforcement is most useful in a hub-and-spoke configuration in which you also want to allow direct spoke-to-spoke connections. In pure hub-and-spoke configurations, all spokes connect only to the hub, so CRL checking is necessary only on the hub. For one spoke to communicate directly with another spoke, the match certificate command with the skip revocation-check keyword can be used for neighboring peer certificates instead of requiring a CRL on each spoke.

Ignoring Expired Certificates

To configure your router to ignore expired certificates, enter the match certificate command with the allow expired-certificate keyword. This command has the following purposes:

- If the certificate of a peer has expired, this command may be used to “allow” the expired certificate until the peer can obtain a new certificate.

- If your router clock has not yet been set to the correct time, the certificate of a peer will appear to be not yet valid until the clock is set. This command may be used to allow the certificate of the peer even though your router clock is not set.

Note

If Network Time Protocol (NTP) is available only via the IPSec connection (usually via the hub in a hub-and-spoke configuration), the router clock can never be set. The tunnel to the hub cannot be “brought up” because the certificate of the hub is not yet valid.

- “Expired” is a generic term for a certificate that is expired or that is not yet valid. The certificate has a start and end time. An expired certificate, for purposes of the ACL, is one for which the current time of the router is outside the start and end times specified in the certificate.

Skipping the AAA Check of the Certificate

If the communication with an AAA server is protected with a certificate, and you want to skip the AAA check of the certificate, use the match certificate command with the skip authorization-check keyword. For example, if a virtual private network (VPN) tunnel is configured so that all AAA traffic goes over that tunnel, and the tunnel is protected with a certificate, you can use the match certificate command with the skip authorization-check keyword to skip the certificate check so that the tunnel can be established.

The match certificate command and the skip authorization-check keyword should be configured after PKI integration with an AAA server is configured.

Note

If the AAA server is available only via an IPSec connection, the AAA server cannot be contacted until after the IPSec connection is established. The IPSec connection cannot be “brought up” because the certificate of the AAA server is not yet valid.

PKI Certificate Chain Validation

A certificate chain establishes a sequence of trusted certificates --from a peer certificate to the root CA certificate. Within a PKI hierarchy, all enrolled peers can validate the certificate of one another if the peers share a trusted root CA certificate or a common subordinate CA. Each CA corresponds to a trustpoint.

When a certificate chain is received from a peer, the default processing of a certificate chain path continues until the first trusted certificate, or trustpoint, is reached. An administrator may configure the level to which a certificate chain is processed on all certificates including subordinate CA certificates.

Configuring the level to which a certificate chain is processed allows for the reauthentication of trusted certificates, the extension of a trusted certificate chain, and the completion of a certificate chain that contains a gap.

Reauthentication of Trusted Certificates

The default behavior is for the router to remove any trusted certificates from the certificate chain sent by the peer before the chain is validated. An administrator may configure certificate chain path processing so that the router does not remove CA certificates that are already trusted before chain validation, so that all certificates in the chain are re-authenticated for the current session.

Extending the Trusted Certificate Chain

The default behavior is for the router to use its trusted certificates to extend the certificate chain if there are any missing certificates in the certificate chain sent by the peer. The router will validate only certificates in the chain sent by the peer. An administrator may configure certificate chain path processing so that the certificates in the peer’s certificate chain and the router’s trusted certificates are validated to a specified point.

Completing Gaps in a Certificate Chain

An administrator may configure certificate chain processing so that if there is a gap in the configured Cisco IOS trustpoint hierarchy, certificates sent by the peer can be used to complete the set of certificates to be validated.

Note

If the trustpoint is configured to require parent validation and the peer does not provide the full certificate chain, the gap cannot be completed and the certificate chain is rejected and invalid.

Note

It is a configuration error if the trustpoint is configured to require parent validation and there is no parent trustpoint configured. The resulting certificate chain gap cannot be completed and the subordinate CA certificate cannot be validated. The certificate chain is invalid.

How to Configure Authorization and Revocation of Certificates for Your PKI

- Configuring PKI Integration with a AAA Server

- Configuring a Revocation Mechanism for PKI Certificate Status Checking

- Configuring Certificate Authorization and Revocation Settings

- Configuring Certificate Chain Validation

Configuring PKI Integration with a AAA Server

Perform this task to generate a AAA username from the certificate presented by the peer and specify which fields within a certificate should be used to build the AAA database username.

Note

The following restrictions should be considered when using the all keyword as the subject name for the authorization username command:

- Some AAA servers limit the length of the username (for example, to 64 characters). As a result, the entire certificate subject name cannot be longer than the limitation of the server.

- Some AAA servers limit the available character set that may be used for the username (for example, a space [ ] and an equal sign [=] may not be acceptable). You cannot use the all keyword for a AAA server having such a character-set limitation.

- The subject-name command in the trustpoint configuration may not always be the final AAA subject name. If the fully qualified domain name (FQDN), serial number, or IP address of the router are included in a certificate request, the subject name field of the issued certificate will also have these components. To turn off the components, use the fqdn , serial-number , and ip-address commands with the none keyword.

- CA servers sometimes change the requested subject name field when they issue a certificate. For example, CA servers of some vendors switch the relative distinguished names (RDNs) in the requested subject names to the following order: CN, OU, O, L, ST, and C. However, another CA server might append the configured LDAP directory root (for example, O=cisco.com) to the end of the requested subject name.

- Depending on the tools you choose for displaying a certificate, the printed order of the RDNs in the subject name could be different. Cisco IOS software always displays the least significant RDN first, but other software, such as Open Source Secure Socket Layer (OpenSSL), does the opposite. Therefore, if you are configuring a AAA server with a full distinguished name (DN) (subject name) as the corresponding username, ensure that the Cisco IOS software style (that is, with the least significant RDN first) is used.

or

radius-server host hostname [key string ]

Procedure

Step 1

enable

Example:

Device>enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

aaa new-model

Example:

Device(config)# aaa new-model

Enables the AAA access control model.

Step 4

aaa authorization network listname [method ]

Example:

Device(config)# aaa authorization network maxaaa group tacacs+

Sets the parameters that restrict user access to a network.

- method --Can be group radius , group tacacs+ , or group group-name .

Step 5

crypto pki trustpoint name

Example:

Device(config)# crypto pki trustpoint msca

Declares the trustpoint and a given name and enters ca-trustpoint configuration mode.

Step 6

enrollment [mode] [retry period minutes] [retry count number] url url [pem]

Example:

Device(ca-trustpoint)# enrollment url http://caserver.myexample.com
- or-

Device(ca-trustpoint)# enrollment url http://[2001:DB8:1:1::1]:80

Specifies the following enrollment parameters of the CA:

- (Optional) The mode keyword specifies the registration authority (RA) mode, if your CA system provides an RA. By default, RA mode is disabled.

- (Optional) The retry period keyword and minutes argument specifies the period, in minutes, in which the router waits before sending the CA another certificate request. Valid values are from 1 to 60. The default is 1.

- (Optional) The retry count keyword and number argument specifies the number of times a router will resend a certificate request when it does not receive a response from the previous request. Valid values are from 1 to 100. The default is 10.

- The url argument is the URL of the CA to which your router should send certificate requests.

Note

An IPv6 address can be added to the http: enrolment method. For example: http://[ipv6-address]:80. The IPv6 address must be enclosed in brackets in the URL.

- (Optional) The pem keyword adds privacy-enhanced mail (PEM) boundaries to the certificate request.

Step 7

revocation-check method

Example:

Device(ca-trustpoint)# revocation-check crl

(Optional) Checks the revocation status of a certificate.

Step 8

exit

Example:

Device(ca-trustpoint)# exit

Exits ca-trustpoint configuration mode and returns to global configuration mode.

Step 9

authorization username subjectname subjectname

Example:

Device(config)# authorization username subjectname serialnumber

Sets parameters for the different certificate fields that are used to build the AAA username.

The subjectname argument can be any of the following:

- all —Entire distinguished name (subject name) of the certificate.

- commonname —Certification common name.

- country —Certificate country.

- email —Certificate e-mail.

- ipaddress —Certificate IP address.

- locality —Certificate locality.

- organization —Certificate organization.

- organizationalunit —Certificate organizational unit.

- postalcode —Certificate postal code.

- serialnumber —Certificate serial number.

- state —Certificate state field.

- streetaddress —Certificate street address.

- title —Certificate title.

- unstructuredname —Certificate unstructured name.

Step 10

authorization list listname

Example:

Device(config)# authorization list maxaaa

Specifies the AAA authorization list.

Step 11

tacacs-server host hostname [key string]

Example:

Device(config)# tacacs-server host 192.0.2.2 key a_secret_key

Example:

radius-server host hostname [key string]

Example:

Device(config)# radius-server host 192.0.2.1 key another_secret_key

Specifies a TACACS+ host.

or

Specifies a RADIUS host.

- Troubleshooting Tips

Troubleshooting Tips

To display debug messages for the trace of interaction (message type) between the CA and the router, use the debug crypto pki transactions command. (See the sample output, which shows a successful PKI integration with AAA server exchange and a failed PKI integration with AAA server exchange.)

Successful Exchange

Device# debug crypto pki transactions
Apr 22 23:15:03.695: CRYPTO_PKI: Found a issuer match
Apr 22 23:15:03.955: CRYPTO_PKI: cert revocation status unknown.
Apr 22 23:15:03.955: CRYPTO_PKI: Certificate validated without revocation check

Each line that shows “CRYPTO_PKI_AAA” indicates the state of the AAA authorization checks. Each of the AAA AV pairs is indicated, and then the results of the authorization check are shown.

Apr 22 23:15:04.019: CRYPTO_PKI_AAA: checking AAA authorization (ipsecca_script_aaalist, PKIAAA-L, <all>)
Apr 22 23:15:04.503: CRYPTO_PKI_AAA: reply attribute ("cert-application" = "all")
Apr 22 23:15:04.503: CRYPTO_PKI_AAA: reply attribute ("cert-trustpoint" = "CA1")
Apr 22 23:15:04.503: CRYPTO_PKI_AAA: reply attribute ("cert-serial" = "15DE")
Apr 22 23:15:04.503: CRYPTO_PKI_AAA: authorization passed
Apr 22 23:12:30.327: CRYPTO_PKI: Found a issuer match

Failed Exchange

Device# debug crypto pki transactions
Apr 22 23:11:13.703: CRYPTO_PKI_AAA: checking AAA authorization =
Apr 22 23:11:14.203: CRYPTO_PKI_AAA: reply attribute ("cert-application" = “all”)
Apr 22 23:11:14.203: CRYPTO_PKI_AAA: reply attribute ("cert-trustpoint"= “CA1”)
Apr 22 23:11:14.203: CRYPTO_PKI_AAA: reply attribute ("cert-serial" = “233D”)
Apr 22 23:11:14.203: CRYPTO_PKI_AAA: parsed cert-lifetime-end as: 21:30:00
Apr 22 23:11:14.203: CRYPTO_PKI_AAA: timezone specific extended
Apr 22 23:11:14.203: CRYPTO_PKI_AAA: cert-lifetime-end is expired
Apr 22 23:11:14.203: CRYPTO_PKI_AAA: cert-lifetime-end check failed.
Apr 22 23:11:14.203: CRYPTO_PKI_AAA: authorization failed

In the above failed exchange, the certificate has expired.

Configuring a Revocation Mechanism for PKI Certificate Status Checking

Perform this task to set up a CRL as the certificate revocation mechanism--CRLs or OCSP--that is used to check the status of certificates in a PKI.

- The revocation-check Command

- Nonces and Peer Communications with OCSP Servers

The revocation-check Command

Use the revocation-check command to specify at least one method (OCSP, CRL, or skip the revocation check) that is to be used to ensure that the certificate of a peer has not been revoked. For multiple methods, the order in which the methods are applied is determined by the order specified via this command.

If your router does not have the applicable CRL and is unable to obtain one or if the OCSP server returns an error, your router will reject the peer’s certificate--unless you include the none keyword in your configuration. If the none keyword is configured, a revocation check will not be performed and the certificate will always be accepted.

Nonces and Peer Communications with OCSP Servers

When using OCSP, nonces, unique identifiers for OCSP requests, are sent by default during peer communications with your OCSP server. The use of nonces offers a more secure and reliable communication channel between the peer and OCSP server.

If your OCSP server does not support nonces, you may disable the sending of nonces. For more information, check your OCSP server documentation.

Before you begin

- Before issuing any client certificates, the appropriate settings on the server (such as setting the CDP) should be configured.

- When configuring an OCSP server to return the revocation status for a CA server, the OCSP server must be configured with an OCSP response signing certificate that is issued by that CA server. Ensure that the signing certificate is in the correct format, or the router will not accept the OCSP response. See your OCSP manual for additional information.

Note

- OCSP transports messages over HTTP, so there may be a time delay when you access the OCSP server.

- If the OCSP server depends on normal CRL processing to check revocation status, the same time delay that affects CRLs will also apply to OCSP.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

crypto pki trustpoint name

Example:

Device(config)# crypto pki trustpoint hazel

Declares the trustpoint and a given name and enters ca-trustpoint configuration mode.

Step 4

ocsp url url

Example:

Device(ca-trustpoint)# ocsp url http://ocsp-server

- or -

Device(ca-trustpoint)# ocsp url http://10.10.10.1:80

- or -

Device(ca-trustpoint)# ocsp url http://[2001DB8:1:1::2]:80

The url argument specifies the URL of an OCSP server so that the trustpoint can check the certificate status. This URL overrides the URL of the OCSP server (if one exists) in the Authority Info Access (AIA) extension of the certificate. All certificates associated with a configured trustpoint are checked by the OCSP server. The URL can be a hostname, IPv4 address, or an IPv6 address.

Step 5

revocation-check method1 [method2 method3 ]]

Example:

Device(ca-trustpoint)# revocation-check ocsp none

Checks the revocation status of a certificate.

- crl —Certificate checking is performed by a CRL. This is the default option.

- none —Certificate checking is ignored.

- ocsp —Certificate checking is performed by an OCSP server.

If a second and third method are specified, each method will be used only if the previous method returns an error, such as a server being down.

Step 6

ocsp disable-nonce

Example:

Device(ca-trustpoint)# ocsp disable-nonce

(Optional) Specifies that a nonce, or an OCSP request unique identifier, will not be sent during peer communications with the OCSP server.

Step 7

exit

Example:

Device(ca-trustpoint)# exit

Returns to global configuration mode.

Step 8

exit

Example:

Device(config)# exit

Returns to privileged EXEC mode.

Step 9

show crypto pki certificates

Example:

Device# show crypto pki certificates

(Optional) Displays information about your certificates.

Step 10

show crypto pki trustpoints [status | label [status ]]

Example:

Device# show crypto pki trustpoints

Displays information about the trustpoint configured in router.

Configuring Certificate Authorization and Revocation Settings

Perform this task to specify a certificate-based ACL, to ignore revocation checks or expired certificates, to manually override the default CDP location, to manually override the OCSP server setting, to configure CRL caching, or to set session acceptance or rejection based on a certificate serial number, as appropriate.

- Configuring Certificate-Based ACLs to Ignore Revocation Checks

- Manually Overriding CDPs in a Certificate

- Manually Overriding the OCSP Server Setting in a Certificate

- Configuring CRL Cache Control

- Configuring Certificate Serial Number Session Control

- Troubleshooting Tips

Configuring Certificate-Based ACLs to Ignore Revocation Checks

To configure your router to use certificate-based ACLs to ignore revocation checks and expired certificates, perform the following steps:

- Identify an existing trustpoint or create a new trustpoint to be used when verifying the certificate of the peer. Authenticate the trustpoint if it has not already been authenticated. The router may enroll with this trustpoint if you want. Do not set optional CRLs for the trustpoint if you plan to use the match certificate command and skip revocation-check keyword.

- Determine the unique characteristics of the certificates that should not have their CRL checked and of the expired certificates that should be allowed.

- Define a certificate map to match the characteristics identified in the prior step.

- You can add the match certificate command and skip revocation-check keyword and the match certificate command and allow expired-certificate keyword to the trustpoint that was created or identified in the first step.

Note

Certificate maps are checked even if the peer’s public key is cached. For example, when the public key is cached by the peer, and a certificate map is added to the trustpoint to ban a certificate, the certificate map is effective. This prevents a client with the banned certificate, which was once connected in the past, from reconnecting.

Manually Overriding CDPs in a Certificate

Users can override the CDPs in a certificate with a manually configured CDP. Manually overriding the CDPs in a certificate can be advantageous when a particular server is unavailable for an extended period of time. The certificate’s CDPs can be replaced with a URL or directory specification without reissuing all of the certificates that contain the original CDP.

Manually Overriding the OCSP Server Setting in a Certificate

Administrators can override the OCSP server setting specified in the Authority Information Access ( AIA) field of the client certificate or set by the issuing the ocsp url command. One or more OCSP servers may be manually specified, either per client certificate or per group of client certificates by the match certificate override ocsp command. The match certificate override ocsp command overrides the client certificate AIA field or the ocsp url command setting if a client certificate is successfully matched to a certificate map during the revocation check.

Note

Only one OCSP server can be specified per client certificate.

Configuring CRL Cache Control

By default, a new CRL will be downloaded after the currently cached CRL expires. Administrators can either configure the maximum amount of time in minutes a CRL remains in the cache by issuing the crl cache delete-after command or disable CRL caching by issuing the crl cache none command. Only the crl-cache delete-after command or the crl-cache none command may be specified. If both commands are entered for a trustpoint, the last command executed will take effect and a message will be displayed.

Neither the crl-cache none command nor the crl-cache delete-after command affects the currently cached CRL. If you configure the crl-cache none command, all CRLs downloaded after this command is issued will not be cached. If you configure the crl-cache delete-after command, the configured lifetime will only affect CRLs downloaded after this command is issued.

This functionality is useful is when a CA issues CRLs with no expiration date or with expiration dates days or weeks ahead.

Configuring Certificate Serial Number Session Control

A certificate serial number can be specified to allow a certificate validation request to be accepted or rejected by the trustpoint for a session. A session may be rejected, depending on certificate serial number session control, even if a certificate is still valid. Certificate serial number session control may be configured by using either a certificate map with the serial-number field or an AAA attribute, with the cert-serial-not command.

Using certificate maps for session control allows an administrator to specify a single certificate serial number. Using the AAA attribute allows an administrator to specify one or more certificate serial numbers for session control.

Before you begin

- The trustpoint should be defined and authenticated before attaching certificate maps to the trustpoint.

- The certificate map must be configured before the CDP override feature can be enabled or the serial-number command is issued.

- The PKI and AAA server integration must be successfully completed to use AAA attributes as described in “PKI and AAA Server Integration for Certificate Status.”

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

crypto pki certificate map label sequence-number

Example:

Device(config)# crypto pki certificate map Group 10

Defines values in a certificate that should be matched or not matched and enters ca-certificate-map configuration mode.

Step 4

field-name match-criteria match-value

Example:

Device(ca-certificate-map)# subject-name co MyExample

Specifies one or more certificate fields together with their matching criteria and the value to match.

The field-name is one of the following case-insensitive name strings or a date:

- alt-subject-name

- expires-on

- issuer-name

- name

- serial-number

- subject-name

- unstructured-subject-name

- valid-start

Note

Date field format is dd mm yyyy hh:mm:ss or mmm dd yyyy hh:mm:ss.

The match-criteria is one of the following logical operators:

- co —contains (valid only for name fields and serial number field)

- eq —equal (valid for name, serial number, and date fields)

- ge —greater than or equal (valid only for date fields)

- lt —less than (valid only for date fields)

- nc —does not contain (valid only for name fields and serial number field)

- ne —not equal (valid for name, serial number, and date fields)

The match-value is the name or date to test with the logical operator assigned by match-criteria.

Note

Use this command only when setting up a certificate-based ACL—not when setting up a certificate-based ACL to ignore revocation checks or expired certificates.

Step 5

exit

Example:

Device(ca-certificate-map)# exit

Returns to global configuration mode.

Step 6

crypto pki trustpoint name

Example:

Device(config)# crypto pki trustpoint Access2

Declares the trustpoint, given name and enters ca-trustpoint configuration mode.

Step 7

Do one of the following:

- crl-cache none

Example:

Device(ca-trustpoint)# crl-cache none

- crl-cache delete-after time

Example:

Device(ca-trustpoint)# crl-cache delete-after 20

(Optional) Disables CRL caching completely for all CRLs associated with the trustpoint.

The crl-cache none command does not affect any currently cached CRLs. All CRLs downloaded after this command is configured will not be cached.

(Optional) Specifies the maximum time CRLs will remain in the cache for all CRLs associated with the trustpoint.

- time —The amount of time in minutes before the CRL is deleted.

The crl-cache delete-after command does not affect any currently cached CRLs. The configured lifetime will only affect CRLs downloaded after this command is configured.

Step 8

match certificate certificate-map-label [allow expired-certificate | skip revocation-check | skip authorization-check

Example:

Device(ca-trustpoint)# match certificate Group skip revocation-check

(Optional) Associates the certificate-based ACL (that was defined via the crypto pki certificate map command) to a trustpoint.

- certificate-map-label —Must match the label argument specified via the crypto pki certificate map command.

- allow expired-certificate —Ignores expired certificates.

- skip revocation-check —Allows a trustpoint to enforce CRLs except for specific certificates.

- skip authorization-check —Skips the AAA check of a certificate when PKI integration with an AAA server is configured.

Step 9

match certificate certificate-map-label override cdp {url | directory } string

Example:

Device(ca-trustpoint)# match certificate Group1 override cdp url http://server.cisco.com

(Optional) Manually overrides the existing CDP entries for a certificate with a URL or directory specification.

- certificate-map-label —A user-specified label that must match the label argument specified in a previously defined crypto pki certificate map command.

- url —Specifies that the certificate’s CDPs will be overridden with an HTTP or LDAP URL.

- directory —Specifies that the certificate’s CDPs will be overridden with an LDAP directory specification.

- string —The URL or directory specification.

Note

Some applications may time out before all CDPs have been tried and will report an error message. The error message will not affect the router, and the Cisco IOS software will continue attempting to retrieve a CRL until all CDPs have been tried.

Step 10

match certificate certificate-map-label override ocsp [trustpoint trustpoint-label ] sequence-number url ocsp-url

Example:

Device(ca-trustpoint)# match certificate mycertmapname override ocsp trustpoint mytp 15 url http://192.0.2.2

(Optional) Specifies an OCSP server, either per client certificate or per group of client certificates, and may be issued more than once to specify additional OCSP servers and client certificate settings including alternative PKI hierarchies.

- certificate-map-label —The name of an existing certificate map.

- trustpoint —The trustpoint to be used when validating the OCSP server certificate.

- sequence-number —The order the match certificate override ocsp command statements apply to the certificate being verified. Matches are performed from the lowest sequence number to the highest sequence number. If more than one command is issued with the same sequence number, it overwrites the previous OCSP server override setting.

- url —The URL of the OCSP server.

When the certificate matches a configured certificate map, the AIA field of the client certificate and any previously issued ocsp url command settings are overwritten with the specified OCSP server.

If no map-based match occurs, one of the following two cases will continue to apply to the client certificate.

- If OCSP is specified as the revocation method, the AIA field value will continue to apply to the client certificate.

- If the ocsp url configuration exists, the ocsp url configuration settings will continue to apply to the client certificates.

Step 11

exit

Example:

Device(ca-trustpoint)# exit

Returns to global configuration mode.

Step 12

aaa new-model

Example:

Device(config)# aaa new-model

(Optional) Enables the AAA access control model.

Step 13

aaa attribute list list-name

Example:

Device(config)# aaa attribute list crl

(Optional) Defines an AAA attribute list locally on a router and enters config-attr-list configuration mode.

Step 14

attribute type {name }{value }

Example:

Device(config-attr-list)# attribute type cert-serial-not 6C4A

(Optional) Defines an AAA attribute type that is to be added to an AAA attribute list locally on a router.

To configure certificate serial number session control, an administrator may specify a specific certificate in the value field to be accepted or rejected based on its serial number where name is set to cert-serial-not . If the serial number of the certificate matches the serial number specified by the attribute type setting, the certificate will be rejected.

For a full list of available AAA attribute types, execute the show aaa attributes command.

Step 15

exit

Example:

Device(ca-trustpoint)# exit

Example:

Device(config-attr-list)# exit

Returns to global configuration mode.

Step 16

exit

Example:

Device(config)# exit

Returns to privileged EXEC mode.

Step 17

show crypto pki certificates

Example:

Device# show crypto pki certificates

(Optional) Displays the components of the certificates installed on the router if the CA certificate has been authenticated.

Example

The following is a sample certificate. The OCSP-related extensions are shown using exclamation points.

Certificate:
Data:
Version: v3
Serial Number:0x14
Signature Algorithm:SHAwithRSA - 1.2.840.113549.1.1.4
Issuer:CN=CA server,OU=PKI,O=Cisco Systems
Validity:
Not Before:Thursday, August 8, 2002 4:38:05 PM PST
Not After:Tuesday, August 7, 2003 4:38:05 PM PST
Subject:CN=OCSP server,OU=PKI,O=Cisco Systems
Subject Public Key Info:
Algorithm:RSA - 1.2.840.113549.1.1.1
Public Key:
Exponent:65537
Public Key Modulus:(2048 bits) :
<snip>
Extensions:
Identifier:Subject Key Identifier - 2.5.29.14
Critical:no
Key Identifier:
<snip>
Identifier:Authority Key Identifier - 2.5.29.35
Critical:no
Key Identifier:
<snip>
!                Identifier:OCSP NoCheck:- 1.3.6.1.5.5.7.48.1.5
Critical:no
Identifier:Extended Key Usage:- 2.5.29.37
Critical:no
Extended Key Usage:
OCSPSigning
!
Identifier:CRL Distribution Points - 2.5.29.31
Critical:no
Number of Points:1
Point 0
Distribution Point:
[URIName:ldap://CA-server/CN=CA server,OU=PKI,O=Cisco Systems]
Signature:
Algorithm:SHAwithRSA - 1.2.840.113549.1.1.4
Signature:
<snip>

The following example shows an excerpt of the running configuration output when adding a match certificate override ocsp command to the beginning of an existing sequence:

match certificate map3 override ocsp 5 url http://192.0.2.3/
show running-configuration
.
.
.
match certificate map3 override ocsp 5 url http://192.0.2.3/
match certificate map1 override ocsp 10 url http://192.0.2.1/
match certificate map2 override ocsp 15 url http://192.0.2.2/

The following example shows an excerpt of the running configuration output when an existing match certificate override ocsp command is replaced and a trustpoint is specified to use an alternative PKI hierarchy:

match certificate map4 override ocsp trustpoint tp4 10 url http://192.0.2.4/newvalue
show running-configuration
.
.
.
match certificate map3 override ocsp trustpoint tp3 5 url http://192.0.2.3/
match certificate map1 override ocsp trustpoint tp1 10 url http://192.0.2.1/
match certificate map4 override ocsp trustpoint tp4 10 url               http://192.0.2.4/newvalue
match certificate map2 override ocsp trustpoint tp2 15 url http://192.0.2.2/

Troubleshooting Tips

If you ignored revocation check or expired certificates, you should carefully check your configuration. Verify that the certificate map properly matches either the certificate or certificates that should be allowed or the AAA checks that should be skipped. In a controlled environment, try modifying the certificate map and determine what is not working as expected.

Configuring Certificate Chain Validation

Perform this task to configure the processing level for the certificate chain path of your peer certificates.

Before you begin

- The device must be enrolled in your PKI hierarchy.

- The appropriate key pair must be associated with the certificate.

Note

- A trustpoint associated with the root CA cannot be configured to be validated to the next level.

The chain-validation command is configured with the continue keyword for the trustpoint associated with the root CA, an error message will be displayed and the chain validation will revert to the default chain-validation command setting.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

crypto pki trustpoint name

Example:

Device(config)# crypto pki trustpoint ca-sub1

Declares the trustpoint and a given name and enters ca-trustpoint configuration mode.

Step 4

chain-validation [{stop | continue } [parent-trustpoint ]]

Example:

Device(ca-trustpoint)# chain-validation continue ca-sub1

Configures the level to which a certificate chain is processed on all certificates including subordinate CA certificates.

- Use the stop keyword to specify that the certificate is already trusted. This is the default setting.

- Use the continue keyword to specify that the that the subordinate CA certificate associated with the trustpoint must be validated.

- The parent-trustpoint argument specifies the name of the parent trustpoint the certificate must be validated against.

Step 5

exit

Example:

Device(ca-trustpoint)# exit

Returns to global configuration mode

Configuration Examples for Setting Up Authorization and Revocation of Certificates

- Configuration and Verification Examples fo PKI AAA Authorization

- Examples: Configuring a Revocation Mechanism

- Example:Configuring a Hub Router at a Central Site for Certificate Revocation Checks

- Examples: Configuring Certificate Authorization and Revocation Settings

- Examples: Configuring Certificate Chain Validation

Configuration and Verification Examples fo PKI AAA Authorization

This section provides configuration examples of PKI AAA authorizations:

- Example: Router Configuration

- Example: Debug of a Successful PKI AAA Authorization

- Example:Debug of a Failed PKI AAA Authorization

Example: Router Configuration

The following show running-config command output shows the working configuration of a router that is set up to authorize VPN connections using the PKI Integration with AAA Server feature:

Device#show running-config

Building configuration...
!
version 12.3
!
hostname router7200router7200
!
aaa new-model
!
!
aaa authentication login default group tacacs+
aaa authentication login no_tacacs enable
aaa authentication ppp default group tacacs+
aaa authorization exec ACSLab group tacacs+
aaa authorization network ACSLab group tacacs+
aaa accounting exec ACSLab start-stop group tacacs+
aaa accounting network default start-stop group ACSLab
aaa session-id common
!
ip domain name example.com
!
crypto pki trustpoint EM-CERT-SERV
enrollment url http://192.0.2.33:80
serial-number
crl optional
rsakeypair STOREVPN 2048
auto-enroll
authorization list ACSLab
!
crypto pki certificate chain EM-CERT-SERV
certificate 04
30820214 3082017D A0030201 02020104 300D0609 2A864886 F70D0101 04050030
17311530 13060355 0403130C 454D2D43 4552542D 53455256 301E170D 30343031
31393232 30323535 5A170D30 35303131 38323230 3235355A 3030312E 300E0603
55040513 07314437 45424434 301C0609 2A864886 F70D0109 02160F37 3230302D
312E6772 696C2E63 6F6D3081 9F300D06 092A8648 86F70D01 01010500 03818D00
30818902 818100BD F3B837AA D925F391 2B64DA14 9C2EA031 5A7203C4 92F8D6A8
7D2357A6 BCC8596F A38A9B10 47435626 D59A8F2A 123195BB BE5A1E74 B1AA5AE0
5CA162FF 8C3ACA4F B3EE9F27 8B031642 B618AE1B 40F2E3B4 F996BEFE 382C7283
3792A369 236F8561 8748AA3F BC41F012 B859BD9C DB4F75EE 3CEE2829 704BD68F
FD904043 0F555702 03010001 A3573055 30250603 551D1F04 1E301C30 1AA018A0
16861468 7474703A 2F2F3633 2E323437 2E313037 2E393330 0B060355 1D0F0404
030205A0 301F0603 551D2304 18301680 1420FC4B CF0B1C56 F5BD4C06 0AFD4E67
341AE612 D1300D06 092A8648 86F70D01 01040500 03818100 79E97018 FB955108
12F42A56 2A6384BC AC8E22FE F1D6187F DA5D6737 C0E241AC AAAEC75D 3C743F59
08DEEFF2 0E813A73 D79E0FA9 D62DC20D 8E2798CD 2C1DC3EC 3B2505A1 3897330C
15A60D5A 8A13F06D 51043D37 E56E45DF A65F43D7 4E836093 9689784D C45FD61D
EC1F160C 1ABC8D03 49FB11B1 DA0BED6C 463E1090 F34C59E4
quit
certificate ca 01
30820207 30820170 A0030201 02020101 300D0609 2A864886 F70D0101 04050030
17311530 13060355 0403130C 454D2D43 4552542D 53455256 301E170D 30333132
31363231 34373432 5A170D30 36313231 35323134 3734325A 30173115 30130603
55040313 0C454D2D 43455254 2D534552 5630819F 300D0609 2A864886 F70D0101
01050003 818D0030 81890281 8100C14D 833641CF D784F516 DA6B50C0 7B3CB3C9
589223AB 99A7DC14 04F74EF2 AAEEE8F5 E3BFAE97 F2F980F7 D889E6A1 2C726C69
54A29870 7E7363FF 3CD1F991 F5A37CFF 3FFDD3D0 9E486C44 A2E34595 C2D078BB
E9DE981E B733B868 AA8916C0 A8048607 D34B83C0 64BDC101 161FC103 13C06500
22D6EE75 7D6CF133 7F1B515F 32830203 010001A3 63306130 0F060355 1D130101
FF040530 030101FF 300E0603 551D0F01 01FF0404 03020186 301D0603 551D0E04
16041420 FC4BCF0B 1C56F5BD 4C060AFD 4E67341A E612D130 1F060355 1D230418
30168014 20FC4BCF 0B1C56F5 BD4C060A FD4E6734 1AE612D1 300D0609 2A864886
F70D0101 04050003 81810085 D2E386F5 4107116B AD3AC990 CBE84063 5FB2A6B5
BD572026 528E92ED 02F3A0AE 1803F2AE AA4C0ED2 0F59F18D 7B50264F 30442C41
0AF19C4E 70BD3CB5 0ADD8DE8 8EF636BD 24410DF4 DB62DAFC 67DA6E58 3879AA3E
12AFB1C3 2E27CB27 EC74E1FC AEE2F5CF AA80B439 615AA8D5 6D6DEDC3 7F9C2C79
3963E363 F2989FB9 795BA8
quit
!
!
crypto isakmp policy 10
encr aes
group 14
!
!
crypto ipsec transform-set ISC_TS_1 esp-aes esp-sha-hmac
!
crypto ipsec profile ISC_IPSEC_PROFILE_2
set security-association lifetime kilobytes 530000000
set security-association lifetime seconds 14400
set transform-set ISC_TS_1
!
!
controller ISA 1/1
!
!
interface Tunnel0
description MGRE Interface provisioned by ISC
bandwidth 10000
ip address 192.0.2.172 255.255.255.0
no ip redirects
ip mtu 1408
ip nhrp map multicast dynamic
ip nhrp network-id 101
ip nhrp holdtime 500
ip nhrp server-only
no ip split-horizon eigrp 101
tunnel source FastEthernet2/1
tunnel mode gre multipoint
tunnel key 101
tunnel protection ipsec profile ISC_IPSEC_PROFILE_2
!
interface FastEthernet2/0
ip address 192.0.2.1 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet2/1
ip address 192.0.2.2 255.255.255.0
duplex auto
speed auto
!
!
tacacs-server host 192.0.2.55 single-connection
tacacs-server directed-request
tacacs-server key company lab
!
ntp master 1
!
end

Example: Debug of a Successful PKI AAA Authorization

The following show debugging command output shows a successful authorization using the PKI Integration with AAA Server feature:

Device#show debugging

General OS:
TACACS access control debugging is on
AAA Authentication debugging is on
AAA Authorization debugging is on
Cryptographic Subsystem:
Crypto PKI Trans debugging is on
Device#
May 28 19:36:11.117: CRYPTO_PKI: Trust-Point EM-CERT-SERV picked up
May 28 19:36:12.789: CRYPTO_PKI: Found a issuer match
May 28 19:36:12.805: CRYPTO_PKI: cert revocation status unknown.
May 28 19:36:12.805: CRYPTO_PKI: Certificate validated without revocation check
May 28 19:36:12.813: CRYPTO_PKI_AAA: checking AAA authorization (ACSLab, POD5.example.com, <all>)
May 28 19:36:12.813: AAA/BIND(00000042): Bind i/f
May 28 19:36:12.813: AAA/AUTHOR (0x42): Pick method list 'ACSLab'
May 28 19:36:12.813: TPLUS: Queuing AAA Authorization request 66 for processing
May 28 19:36:12.813: TPLUS: processing authorization request id 66
May 28 19:36:12.813: TPLUS: Protocol set to None .....Skipping
May 28 19:36:12.813: TPLUS: Sending AV service=pki
May 28 19:36:12.813: TPLUS: Authorization request created for 66(POD5.example.com)
May 28 19:36:12.813: TPLUS: Using server 192.0.2.55
May 28 19:36:12.813: TPLUS(00000042)/0/NB_WAIT/203A4628: Started 5 sec timeout
May 28 19:36:12.813: TPLUS(00000042)/0/NB_WAIT: wrote entire 46 bytes request
May 28 19:36:12.813: TPLUS: Would block while reading pak header
May 28 19:36:12.817: TPLUS(00000042)/0/READ: read entire 12 header bytes (expect 27 bytes)
May 28 19:36:12.817: TPLUS(00000042)/0/READ: read entire 39 bytes response
May 28 19:36:12.817: TPLUS(00000042)/0/203A4628: Processing the reply packet
May 28 19:36:12.817: TPLUS: Processed AV cert-application=all
May 28 19:36:12.817: TPLUS: received authorization response for 66: PASS
May 28 19:36:12.817: CRYPTO_PKI_AAA: reply attribute ("cert-application" = "all")
May 28 19:36:12.817: CRYPTO_PKI_AAA: authorization passed
Device#
Device#
May 28 19:36:18.681: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 101: Neighbor 192.0.2.171 (Tunnel0) is up: new adjacency
Device#
Device# show crypto isakmp sa
dst             src             state          conn-id slot
192.0.2.22       192.0.2.102   QM_IDLE             84    0

Example:Debug of a Failed PKI AAA Authorization

The following show debugging command output shows that the router is not authorized to connect using VPN. The messages are typical of those that you might see in such a situation.

In this example, the peer username was configured as not authorized, by moving the username to a Cisco Secure ACS group called VPN_Router_Disabled in Cisco Secure ACS. The router, router7200.example.com, has been configured to check with a Cisco Secure ACS AAA server prior to establishing a VPN connection to any peer.

Device#show debugging

General OS:
TACACS access control debugging is on
AAA Authentication debugging is on
AAA Authorization debugging is on
Cryptographic Subsystem:
Crypto PKI Trans debugging is on

Device#
May 28 19:48:29.837: CRYPTO_PKI: Trust-Point EM-CERT-SERV picked up
May 28 19:48:31.509: CRYPTO_PKI: Found a issuer match
May 28 19:48:31.525: CRYPTO_PKI: cert revocation status unknown.
May 28 19:48:31.525: CRYPTO_PKI: Certificate validated without revocation check
May 28 19:48:31.533: CRYPTO_PKI_AAA: checking AAA authorization (ACSLab, POD5.example.com, <all>)
May 28 19:48:31.533: AAA/BIND(00000044): Bind i/f
May 28 19:48:31.533: AAA/AUTHOR (0x44): Pick method list 'ACSLab'
May 28 19:48:31.533: TPLUS: Queuing AAA Authorization request 68 for processing
May 28 19:48:31.533: TPLUS: processing authorization request id 68
May 28 19:48:31.533: TPLUS: Protocol set to None .....Skipping
May 28 19:48:31.533: TPLUS: Sending AV service=pki
May 28 19:48:31.533: TPLUS: Authorization request created for 68(POD5.example.com)
May 28 19:48:31.533: TPLUS: Using server 192.0.2.55
May 28 19:48:31.533: TPLUS(00000044)/0/NB_WAIT/203A4C50: Started 5 sec timeout
May 28 19:48:31.533: TPLUS(00000044)/0/NB_WAIT: wrote entire 46 bytes request
May 28 19:48:31.533: TPLUS: Would block while reading pak header
May 28 19:48:31.537: TPLUS(00000044)/0/READ: read entire 12 header bytes (expect 6 bytes)
May 28 19:48:31.537: TPLUS(00000044)/0/READ: read entire 18 bytes response
May 28 19:48:31.537: TPLUS(00000044)/0/203A4C50: Processing the reply packet
May 28 19:48:31.537: TPLUS: received authorization response for 68: FAIL
May 28 19:48:31.537: CRYPTO_PKI_AAA: authorization declined by AAA, or AAA server not found.
May 28 19:48:31.537: CRYPTO_PKI_AAA: No cert-application attribute found. Failing.
May 28 19:48:31.537: CRYPTO_PKI_AAA: authorization failed
May 28 19:48:31.537: CRYPTO_PKI: AAA authorization for list 'ACSLab', and user 'POD5.example.com' failed.
May 28 19:48:31.537: %CRYPTO-5-IKMP_INVAL_CERT: Certificate received from 192.0.2.162 is bad: certificate invalid
May 28 19:48:39.821: CRYPTO_PKI: Trust-Point EM-CERT-SERV picked up
May 28 19:48:41.481: CRYPTO_PKI: Found a issuer match
May 28 19:48:41.501: CRYPTO_PKI: cert revocation status unknown.
May 28 19:48:41.501: CRYPTO_PKI: Certificate validated without revocation check
May 28 19:48:41.505: CRYPTO_PKI_AAA: checking AAA authorization (ACSLab, POD5.example.com, <all>)
May 28 19:48:41.505: AAA/BIND(00000045): Bind i/f
May 28 19:48:41.505: AAA/AUTHOR (0x45): Pick method list 'ACSLab'
May 28 19:48:41.505: TPLUS: Queuing AAA Authorization request 69 for processing
May 28 19:48:41.505: TPLUS: processing authorization request id 69
May 28 19:48:41.505: TPLUS: Protocol set to None .....Skipping
May 28 19:48:41.505: TPLUS: Sending AV service=pki
May 28 19:48:41.505: TPLUS: Authorization request created for 69(POD5.example.com)
May 28 19:48:41.505: TPLUS: Using server 198.168.244.55
May 28 19:48:41.509: TPLUS(00000045)/0/IDLE/63B22834: got immediate connect on new 0
May 28 19:48:41.509: TPLUS(00000045)/0/WRITE/63B22834: Started 5 sec timeout
May 28 19:48:41.509: TPLUS(00000045)/0/WRITE: wrote entire 46 bytes request
May 28 19:48:41.509: TPLUS(00000045)/0/READ: read entire 12 header bytes (expect 6 bytes)
May 28 19:48:41.509: TPLUS(00000045)/0/READ: read entire 18 bytes response
May 28 19:48:41.509: TPLUS(00000045)/0/63B22834: Processing the reply packet
May 28 19:48:41.509: TPLUS: received authorization response for 69: FAIL
May 28 19:48:41.509: CRYPTO_PKI_AAA: authorization declined by AAA, or AAA server not found.
May 28 19:48:41.509: CRYPTO_PKI_AAA: No cert-application attribute found. Failing.
May 28 19:48:41.509: CRYPTO_PKI_AAA: authorization failed
May 28 19:48:41.509: CRYPTO_PKI: AAA authorization for list 'ACSLab', and user 'POD5.example.com' failed.
May 28 19:48:41.509: %CRYPTO-5-IKMP_INVAL_CERT: Certificate received from 192.0.2.162 is bad: certificate invalid
Device#
Device# show crypto iskmp sa
dst             src             state          conn-id slot
192.0.2.2          192.0.2.102   MM_KEY_EXCH         95    0

Examples: Configuring a Revocation Mechanism

This section contains the following configuration examples that can be used when specifying a revocation mechanism for your PKI:

- Example:Configuring an OCSP Server

- Example:Specifying a CRL and Then an OCSP Server

- Example: Specifying an OCSP Server

- Example: Disabling Nonces in Communications with the OCSP Server

Example:Configuring an OCSP Server

The following example shows how to configure the router to use the OCSP server that is specified in the AIA extension of the certificate:

Device(config)#crypto pki trustpoint mytp
Device(ca-trustpoint)#revocation-check ocsp

Example:Specifying a CRL and Then an OCSP Server

The following example shows how to configure the router to download the CRL from the CDP. If the CRL is unavailable, the OCSP server that is specified in the AIA extension of the certificate will be used. If both options fail, certificate verification will also fail.

Device(config)#crypto pki trustpoint mytp
Device(ca-trustpoint)#revocation-check crl ocsp

Example: Specifying an OCSP Server

The following example shows how to configure your device to use the OCSP server at the HTTP URL “http://myocspserver:81.” If the server is down, the revocation check will be ignored.

Device(config)# crypto pki trustpoint mytp
Device(ca-trustpoint)# ocsp url http://myocspserver:81
Device(ca-trustpoint)# revocation-check ocsp none

Example: Disabling Nonces in Communications with the OCSP Server

The following example shows communications when a nonce, or a unique identifier for the OCSP request, is disabled for communications with the OCSP server:

Device(config)# crypto pki trustpoint mytp
Device(ca-trustpoint)# ocsp url http://myocspserver:81
Device(ca-trustpoint)# revocation-check ocsp none
Device(ca-trustpoint)# ocsp disable-nonce

Example:Configuring a Hub Router at a Central Site for Certificate Revocation Checks

The following example shows a hub router at a central site that is providing connectivity for several branch offices to the central site.

The branch offices are also able to communicate directly with each other using additional IPSec tunnels between the branch offices.

The CA publishes CRLs on an HTTP server at the central site. The central site checks CRLs for each peer when setting up an IPSec tunnel with that peer.

The example does not show the IPSec configuration--only the PKI-related configuration is shown.

Home Office Hub Configuration

crypto pki trustpoint VPN-GW
enrollment url http://ca.home-office.com:80/certsrv/mscep/mscep.dll
serial-number none
fqdn none
ip-address none
subject-name o=Home Office Inc,cn=Central VPN Gateway
revocation-check crl

Central Site Hub Router

Device# show crypto ca certificate
Certificate
Status: Available
Certificate Serial Number: 2F62BE14000000000CA0
Certificate Usage: General Purpose
Issuer:
cn=Central Certificate Authority
o=Home Office Inc
Subject:
Name: Central VPN Gateway
cn=Central VPN Gateway
o=Home Office Inc
CRL Distribution Points:
http://ca.home-office.com/CertEnroll/home-office.crl
Validity Date:
start date: 00:43:26 GMT Sep 26 2003
end   date: 00:53:26 GMT Sep 26 2004
renew date: 00:00:00 GMT Jan 1 1970
Associated Trustpoints: VPN-GW
CA Certificate
Status: Available
Certificate Serial Number: 1244325DE0369880465F977A18F61CA8
Certificate Usage: Signature
Issuer:
cn=Central Certificate Authority
o=Home Office Inc
Subject:
cn=Central Certificate Authority
o=Home Office Inc
CRL Distribution Points:
http://ca.home-office.com/CertEnroll/home-office.crl
Validity Date:
start date: 22:19:29 GMT Oct 31 2002
end   date: 22:27:27 GMT Oct 31 2017
Associated Trustpoints: VPN-GW

Trustpoint on the Branch Office Router

crypto pki trustpoint home-office
enrollment url http://ca.home-office.com:80/certsrv/mscep/mscep.dll
serial-number none
fqdn none

ip-address none
subject-name o=Home Office Inc,cn=Branch 1
revocation-check crl

A certificate map is entered on the branch office router.

Device# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
branch1(config)# crypto pki certificate map central-site 10
branch1(ca-certificate-map)#

The output from the show certificate command on the central site hub router shows that the certificate was issued by the following:

cn=Central Certificate Authority
o=Home Office Inc

These two lines are combined into one line using a comma (,) to separate them, and the original lines are added as the first criteria for a match.

Device(ca-certificate-map)# issuer-name co cn=Central Certificate Authority, ou=Home Office Inc
!The above line wrapped but should be shown on one line with the line above it.

The same combination is done for the subject name from the certificate on the central site router (note that the line that begins with “Name:” is not part of the subject name and must be ignored when creating the certificate map criteria). This is the subject name to be used in the certificate map.

cn=Central VPN Gateway

o=Home Office Inc

Device(ca-certificate-map)# subject-name eq cn=central vpn gateway, o=home office inc

Now the certificate map is added to the trustpoint that was configured earlier.

Device(ca-certificate-map)# crypto pki trustpoint home-office
Device(ca-trustpoint)# match certificate central-site skip revocation-check
Device(ca-trustpoint)# exit
Device(config)# exit

The configuration is checked (most of configuration is not shown).

Device# write term
!Many lines left out
.
.
.
crypto pki trustpoint home-office
enrollment url http://ca.home-office.com:80/certsrv/mscep/mscep.dll
serial-number none
fqdn none
ip-address none
subject-name o=Home Office Inc,cn=Branch 1
revocation-check crl
match certificate central-site skip revocation-check
!
!
crypto pki certificate map central-site 10
issuer-name co cn = Central Certificate Authority, ou = Home Office Inc
subject-name eq cn = central vpn gateway, o = home office inc
!many lines left out

Note that the issuer-name and subject-name lines have been reformatted to make them consistent for later matching with the certificate of the peer.

If the branch office is checking the AAA, the trustpoint will have lines similar to the following:

crypto pki trustpoint home-office
auth list allow_list
auth user subj commonname

After the certificate map has been defined as was done above, the following command is added to the trustpoint to skip AAA checking for the central site hub.

match certificate central-site skip authorization-check

In both cases, the branch site router has to establish an IPSec tunnel to the central site to check CRLs or to contact the AAA server. However, without the match certificate command and central-site skip authorization-check (argument and keyword) , the branch office cannot establish the tunnel until it has checked the CRL or the AAA server. (The tunnel will not be established unless the match certificate command and central-site skip authorization-check argument and keyword are used.)

The match certificate command and allow expired-certificate keyword would be used at the central site if the router at a branch site had an expired certificate and it had to establish a tunnel to the central site to renew its certificate.

Trustpoint on the Central Site Router

crypto pki trustpoint VPN-GW
enrollment url http://ca.home-office.com:80/certsrv/mscep/mscep.dll
serial-number none
fqdn none
ip-address none
subject-name o=Home Office Inc,cn=Central VPN Gateway
revocation-check crl

Trustpoint on the Branch 1 Site Router

Device# show crypto ca certificate
Certificate
Status: Available
Certificate Serial Number: 2F62BE14000000000CA0
Certificate Usage: General Purpose
Issuer:
cn=Central Certificate Authority
o=Home Office Inc
Subject:
Name: Branch 1 Site
cn=Branch 1 Site
o=Home Office Inc
CRL Distribution Points:
http://ca.home-office.com/CertEnroll/home-office.crl
Validity Date:
start date: 00:43:26 GMT Sep 26 2003
end   date: 00:53:26 GMT Oct 3 2003
renew date: 00:00:00 GMT Jan 1 1970
Associated Trustpoints: home-office
CA Certificate
Status: Available
Certificate Serial Number: 1244325DE0369880465F977A18F61CA8
Certificate Usage: Signature
Issuer:
cn=Central Certificate Authority
o=Home Office Inc
Subject:
cn=Central Certificate Authority
o=Home Office Inc
CRL Distribution Points:
http://ca.home-office.com/CertEnroll/home-office.crl
Validity Date:
start date: 22:19:29 GMT Oct 31 2002
end   date: 22:27:27 GMT Oct 31 2017
Associated Trustpoints: home-office

A certificate map is entered on the central site router.

Device# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Device(config)# crypto pki certificate map branch1 10
Device(ca-certificate-map)# issuer-name co cn=Central Certificate Authority, ou=Home Office Inc
!The above line wrapped but should be part of the line above it.
Device(ca-certificate-map)# subject-name eq cn=Brahcn 1 Site,o=home office inc

The certificate map is added to the trustpoint.

Device(ca-certificate-map)# crypto pki trustpoint VPN-GW
Device(ca-trustpoint)# match certificate branch1 allow expired-certificate
Device(ca-trustpoint)# exit
Device(config) #exit

The configuration should be checked (most of the configuration is not shown).

Device# write term
!many lines left out
crypto pki trustpoint VPN-GW
enrollment url http://ca.home-office.com:80/certsrv/mscep/mscep.dll
serial-number none
fqdn none
ip-address none
subject-name o=Home Office Inc,cn=Central VPN Gateway
revocation-check crl
match certificate branch1 allow expired-certificate
!
!
crypto pki certificate map central-site 10
issuer-name co cn = Central Certificate Authority, ou = Home Office Inc
subject-name eq cn = central vpn gateway, o = home office inc
! many lines left out

The match certificate command and branch1 allow expired-certificate (argument and keyword) and the certificate map should be removed as soon as the branch router has a new certificate.

Examples: Configuring Certificate Authorization and Revocation Settings

This section contains the following configuration examples that can be used when specifying a CRL cache control setting or certificate serial number session control:

- Configuring CRL Cache Control

- Configuring Certificate Serial Number Session Control

Configuring CRL Cache Control

The following example shows how to disable CRL caching for all CRLs associated with the CA1 trustpoint:

crypto pki trustpoint CA1
enrollment url http://CA1:80
ip-address FastEthernet0/0
crl query ldap://ldap_CA1
revocation-check crl
crl-cache none

The current CRL is still cached immediately after executing the example configuration shown above:

Device# show crypto pki crls

CRL Issuer Name:
cn=name Cert Manager,ou=pki,o=example.com,c=US
LastUpdate: 18:57:42 GMT Nov 26 2005
NextUpdate: 22:57:42 GMT Nov 26 2005
Retrieved from CRL Distribution Point:
ldap://ldap.example.com/CN=name Cert Manager,O=example.com

When the current CRL expires, a new CRL is then downloaded to the router at the next update. The crl-cache none command takes effect and all CRLs for the trustpoint are no longer cached; caching is disabled. You can verify that no CRL is cached by executing the show crypto pki crls command. No output will be shown because there are no CRLs cached.

The following example shows how to configure the maximum lifetime of 2 minutes for all CRLs associated with the CA1 trustpoint:

crypto pki trustpoint CA1
enrollment url http://CA1:80
ip-address FastEthernet0/0
crl query ldap://ldap_CA1
revocation-check crl
crl-cache delete-after 2

The current CRL is still cached immediately after executing the example configuration above for setting the maximum lifetime of a CRL:

Device# show crypto pki crls

CRL Issuer Name:
cn=name Cert Manager,ou=pki,o=example.com,c=US
LastUpdate: 18:57:42 GMT Nov 26 2005
NextUpdate: 22:57:42 GMT Nov 26 2005
Retrieved from CRL Distribution Point:
ldap://ldap.example.com/CN=name Cert Manager,O=example.com
When the current CRL expires, a new CRL is downloaded to the router at the next update and the crl-cache delete-after
command takes effect. This newly cached CRL and all subsequent CRLs will be deleted after a maximum lifetime of 2 minutes.
You can verify that the CRL will be cached for 2 minutes by executing the show crypto pki crls
command. Note that the NextUpdate time is 2 minutes after the LastUpdate time.

Device# show crypto pki crls

CRL Issuer Name:
cn=name Cert Manager,ou=pki,o=example.com,c=US
LastUpdate: 22:57:42 GMT Nov 26 2005

NextUpdate: 22:59:42 GMT Nov 26 2005
Retrieved from CRL Distribution Point:

ldap://ldap.example.com/CN=name Cert Manager,O=example.com

Configuring Certificate Serial Number Session Control

The following example shows the configuration of certificate serial number session control using a certificate map for the CA1 trustpoint:

crypto pki trustpoint CA1
enrollment url http://CA1
chain-validation stop
crl query ldap://ldap_server
revocation-check crl
match certificate crl
!
crypto pki certificate map crl 10
serial-number co 279d

Note

If the match-criteria value is set to eq (equal) instead of co (contains), the serial number must match the certificate map serial number exactly, including any spaces.

The following example shows the configuration of certificate serial number session control using AAA attributes. In this case, all valid certificates will be accepted if the certificate does not have the serial number “4ACA.”

crypto pki trustpoint CA1
enrollment url http://CA1
ip-address FastEthernet0/0
crl query ldap://ldap_CA1
revocation-check crl
aaa new-model
!
aaa attribute list crl
attribute-type aaa-cert-serial-not 4ACA

The server log shows that the certificate with the serial number “4ACA” was rejected. The certificate rejection is shown using exclamation points.

.
.
.
Dec 3 04:24:39.051: CRYPTO_PKI: Trust-Point CA1 picked up
Dec 3 04:24:39.051: CRYPTO_PKI: locked trustpoint CA1, refcount is 1
Dec 3 04:24:39.051: CRYPTO_PKI: unlocked trustpoint CA1, refcount is 0
Dec 3 04:24:39.051: CRYPTO_PKI: locked trustpoint CA1, refcount is 1
Dec 3 04:24:39.135: CRYPTO_PKI: validation path has 1 certs
Dec 3 04:24:39.135: CRYPTO_PKI: Found a issuer match
Dec 3 04:24:39.135: CRYPTO_PKI: Using CA1 to validate certificate
Dec 3 04:24:39.135: CRYPTO_PKI: Certificate validated without revocation check
Dec 3 04:24:39.135: CRYPTO_PKI: Selected AAA username: 'PKIAAA'
Dec 3 04:24:39.135: CRYPTO_PKI: Anticipate checking AAA list:'CRL'
Dec 3 04:24:39.135: CRYPTO_PKI_AAA: checking AAA authorization (CRL, PKIAAA-L1, <all>)
Dec 3 04:24:39.135: CRYPTO_PKI_AAA: pre-authorization chain validation status (0x4)
Dec 3 04:24:39.135: AAA/BIND(00000021): Bind i/f
Dec 3 04:24:39.135: AAA/AUTHOR (0x21): Pick method list 'CRL'
.
.
.
Dec 3 04:24:39.175: CRYPTO_PKI_AAA: reply attribute ("cert-application" = "all")
Dec 3 04:24:39.175: CRYPTO_PKI_AAA: reply attribute ("cert-trustpoint" = "CA1")
!
Dec 3 04:24:39.175: CRYPTO_PKI_AAA: reply attribute ("cert-serial-not" = "4ACA")
Dec 3 04:24:39.175: CRYPTO_PKI_AAA: cert-serial doesn't match ("4ACA" != "4ACA")
!
Dec 3 04:24:39.175: CRYPTO_PKI_AAA: post-authorization chain validation status (0x7)
!
Dec 3 04:24:39.175: CRYPTO_PKI: AAA authorization for list 'CRL', and user 'PKIAAA' failed.
Dec 3 04:24:39.175: CRYPTO_PKI: chain cert was anchored to trustpoint CA1, and chain validation result was: CRYPTO_PKI_CERT_NOT_AUTHORIZED
!
Dec 3 04:24:39.175: %CRYPTO-5-IKMP_INVAL_CERT: Certificate received from 192.0.2.43 is bad: certificate invalid
Dec 3 04:24:39.175: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of Main mode failed with peer at 192.0.2.43
.
.
.

Examples: Configuring Certificate Chain Validation

This section contains the following configuration examples that can be used to specify the level of certificate chain processing for your device certificates:

- Configuring Certificate Chain Validation from Peer to Root CA

- Configuring Certificate Chain Validation from Peer to Subordinate CA

- Configuring Certificate Chain Validation Through a Gap

Configuring Certificate Chain Validation from Peer to Root CA

In the following configuration example, all of the certificates will be validated--the peer, SubCA11, SubCA1, and RootCA certificates.

crypto pki trustpoint RootCA
enrollment terminal
chain-validation stop
revocation-check none
rsakeypair RootCA
crypto pki trustpoint SubCA1
enrollment terminal
chain-validation continue RootCA
revocation-check none
rsakeypair SubCA1
crypto pki trustpoint SubCA11
enrollment terminal
chain-validation continue SubCA1
revocation-check none
rsakeypair SubCA11

Configuring Certificate Chain Validation from Peer to Subordinate CA

In the following configuration example, the following certificates will be validated--the peer and SubCA1 certificates.

crypto pki trustpoint RootCA
enrollment terminal
chain-validation stop
revocation-check none
rsakeypair RootCA
crypto pki trustpoint SubCA1
enrollment terminal
chain-validation continue RootCA
revocation-check none
rsakeypair SubCA1
crypto pki trustpoint SubCA11
enrollment terminal
chain-validation continue SubCA1
revocation-check none
rsakeypair SubCA11

Configuring Certificate Chain Validation Through a Gap

In the following configuration example, SubCA1 is not in the configured Cisco IOS hierarchy but is expected to have been supplied in the certificate chain presented by the peer.

If the peer supplies the SubCA1 certificate in the presented certificate chain, the following certificates will be validated--the peer, SubCA11, and SubCA1 certificates.

If the peer does not supply the SubCA1 certificate in the presented certificate chain, the chain validation will fail.

crypto pki trustpoint RootCA
enrollment terminal
chain-validation stop
revocation-check none
rsakeypair RootCA
crypto pki trustpoint SubCA11
enrollment terminal
chain-validation continue RootCA
revocation-check none
rsakeypair SubCA11

Additional References

Related Documents

Related Topic

Document Title

IOS commands.

Master Command List: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mcl/allreleasemcl/all-book.html

Overview of PKI, including RSA keys, certificate enrollment, and CAs

“Cisco IOS PKI Overview: Understanding and Planning a PKI” module

RSA key generation and deployment

“Deploying RSA Keys Within a PKI” module

Certificate enrollment: supported methods, enrollment profiles, configuration tasks

“Configuring Certificate Enrollment for a PKI” module

Cisco IOS certificate server overview information and configuration tasks

“Configuring and Managing a Cisco IOS Certificate Server for PKI Deployment ” module

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

https://www.cisco.com/cisco/web/support/index.html

Feature Information for Certificate Authorization and Revocation

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

Feature Information for PKI Certificate Authorization and Revocation

Feature Name

Releases

Feature Information

PKI Certificate Authorization and Revocation

Cisco IOS XE Fuji 16.8.1a

The feature was introduced.