Table Of Contents
Manually Assigning and Removing Switch IP Information
Using DHCP-Based Autoconfiguration
Understanding DHCP-Based Autoconfiguration
Configuring the Domain Name and the DNS
Assigning Passwords and Privilege Levels
Setting the System Date and Time
Configuring Daylight Saving Time
Configuring the Network Time Protocol
Configuring the Switch as an NTP Client
Configuring the Switch for NTP Broadcast-Client Mode
Configuring CDP for Extended Discovery
Managing the MAC Address Tables
Changing the Address Aging Time
Removing Dynamic Address Entries
Configuring Static Addresses for EtherChannel Port Groups
Enabling the Fast Leave Feature
Disabling the CGMP Fast Leave Feature
Changing the CGMP Router Hold-Time
Setting the Maximum Number of IGMP Groups
Using MVR in a Multicast Television Application
Configuration Guidelines and Limitations
Using STP to Support Redundant Connectivity
Accelerating Aging to Retain Connectivity
Configuring STP and UplinkFast in a Cascaded Cluster
Configuring Redundant Links By Using STP UplinkFast
Configuring Cross-Stack UplinkFast
Events that Cause Fast Convergence
Configuring Cross-Stack UplinkFast
Changing the STP Parameters for a VLAN
Changing the STP Implementation
Changing the BPDU Message Interval
Changing the Hello BPDU Interval
Changing the Forwarding Delay Time
Enabling the Port Fast Feature
Configuring the TACACS+ Server Host
Configuring Login Authentication
Specifying TACACS+ Authorization for EXEC Access and Network Services
Configuring a Switch for Local AAA
Controlling Switch Access with RADIUS
Identifying the RADIUS Server Host
Configuring RADIUS Login Authentication
Configuring RADIUS Authorization for User Privileged Access and Network Services
Configuring Settings for All RADIUS Servers
Configuring the Switch to Use Vendor-Specific RADIUS Attributes
Configuring the Switch for Vendor-Proprietary RADIUS Server Communication
Displaying the RADIUS Configuration
Configuring the Switch for Local Authentication and Authorization
Configuring the System
This chapter provides these topics about changing switch-wide configuration settings:
•
Assigning Passwords and Privilege Levels
•
•
•
For information about configuring these settings from Cluster Management Suite (CMS), refer to the online help.
This switch software release is based on Cisco IOS Release 12.0. It has been enhanced to support a set of features for the Catalyst 2900 XL and Catalyst 3500 XL switches. This chapter provides procedures for using only the commands that have been created or changed for these switches. The switch command reference provides complete descriptions of these commands. This guide does not provide Cisco IOS Release 12.0 commands and information already documented in the Cisco IOS Release 12.0 documentation on Cisco.com.
Changing IP Information
You can assign and change the IP information of your switch in these ways:
•
•
•
Caution
Note
These sections cover these topics:
•
•
Manually Assigning and Removing Switch IP Information
You can manually assign an IP address, mask, and default gateway to the switch. The mask identifies the bits that denote the network number in the IP address. When you use the mask to subnet a network, the mask is then referred to as a subnet mask. The broadcast address is reserved for sending messages to all hosts. The CPU sends traffic to an unknown IP address through the default gateway.
Beginning in privileged EXEC mode, follow these steps to enter the IP information:
Use this procedure to remove the IP information from a switch.
Note
Beginning in privileged EXEC mode, follow these steps to remove an IP address:
Using DHCP-Based Autoconfiguration
The Dynamic Host Configuration Protocol (DHCP) provides configuration information to Internet hosts and internetworking devices. With DHCP-based autoconfiguration, your switch (DHCP client) can be automatically configured during bootup with IP address information and a configuration file that it receives during DHCP-based autoconfiguration.
Note
Understanding DHCP-Based Autoconfiguration
The DHCP provides configuration information to internet hosts and internetworking devices. This protocol consists of two components: one for delivering configuration parameters from a DHCP server to a device and one for allocating network addresses to devices. DHCP is built on a client-server model, where designated DHCP servers allocate network addresses and deliver configuration parameters to dynamically configured devices.
With DHCP-based autoconfiguration, your switch (DHCP client) can be automatically configured at startup with IP address information and a configuration file that it receives during DHCP-based autoconfiguration. No DHCP client-side configuration is required on your switch.
However, you need to configure the DHCP server for various lease options. You might also need to configure a TFTP server, a Domain Name System (DNS) server, and possibly a relay device if the servers are on a different LAN than your switch. A relay device forwards broadcast traffic between two directly connected LANs. A router does not forward broadcast packets, but it forwards packets based on the destination IP address in the received packet. DHCP-based autoconfiguration replaces the BOOTP client functionality on your switch.
DHCP Client Request Process
When you boot your switch, the DHCP client can be invoked and automatically request configuration information from a DHCP server under these conditions:
•
•
•
Figure 6-1 shows the sequence of messages that are exchanged between the DHCP client and the DHCP server.
Figure 6-1 DHCP Request for IP Information from a DHCP Server
The client, Switch A, broadcasts a DHCPDISCOVER message to locate a DHCP server. The DHCP server offers configuration parameters (such as an IP address, subnet mask, gateway IP address, DNS IP address, a lease for the IP address, and so forth) to the client in a DHCPOFFER unicast message.
In a DHCPREQUEST broadcast message, the client returns a request for the offered configuration information to the DHCP server. The request is broadcast so that all other DHCP servers that received the DHCPDISCOVER broadcast message from the client can reclaim the IP addresses that they offered to the client.
The DHCP server confirms that the IP address has been allocated to the client by returning a DHCPACK unicast message to the client. With this message, the client and server are bound, and the client uses configuration information received from the server. The amount of information the switch receives depends on how you configure the DHCP server. For more information, see the "Configuring the DHCP Server" section.
If the configuration parameters sent to the client in the DHCPOFFER unicast message by the DHCP server are invalid (a configuration error exists), the client returns a DHCPDECLINE broadcast message to the DHCP server.
The DHCP server sends the client a DHCPNAK denial broadcast message, which means the offered configuration parameters have not been assigned, an error has occurred during the negotiation of the parameters, or the client has been slow in responding to the DHCPOFFER message (the DHCP server assigned the parameters to another client) of the DHCP server.
A DHCP client might receive offers from multiple DHCP or BOOTP servers and can accept any one of the offers; however, the client usually accepts the first offer it receives. The offer from the DHCP server is not a guarantee that the IP address will be allocated to the client; however, the server usually reserves the address until the client has had a chance to formally request the address. If the switch accepts replies from a BOOTP server and configures itself, the switch will broadcast, instead of unicast, TFTP requests to obtain the switch configuration file.
Configuring the DHCP Server
You should configure the DHCP servers with reserved leases that are bound to each switch by the switch hardware address. If the DHCP server does not support reserved leases, the switch can obtain different IP addresses and configuration files at different boot instances. You should configure the DHCP server with these lease options:
•
•
•
•
•
•
•
If you do not configure the DHCP server with the lease options described earlier, then it replies to client requests with only those parameters that have available values. If the IP address and subnet mask are not in the reply, the switch is not configured. If the DNS server IP address, router IP address, or TFTP server name are not found, the switch might broadcast TFTP requests. Unavailability of other lease options does not affect autoconfiguration.
Note
The DHCP server can be on the same or a different LAN as the switch. If it is on a different LAN, the switch must be able to access it through a relay device. The DHCP server can be running on a UNIX or Linux operating system; however, the Windows NT operating system is not supported in this release.
For more information, see the "Configuring the Relay Device" section. You must also set up the TFTP server with the switch configuration files; for more information, see the next section.
For CLI procedures, refer to the Cisco IOS Release 12.0 documentation on Cisco.com for additional information and CLI procedures.
Configuring the TFTP Server
The TFTP server must contain one or more configuration files in its base directory. The files can include the following:
•
•
•
You must specify the TFTP server name in the DHCP server lease database. You must also specify the TFTP server name-to-IP-address mapping in the DNS server database.
The TFTP server can be on the same or a different LAN as the switch. If it is on a different LAN, the switch must be able to access it through a relay device or a router. For more information, see the "Configuring the Relay Device" section.
If the configuration filename is provided in the DHCP server reply, the configuration files for a switch can be spread over multiple TFTP servers. However, if the configuration filename is not provided, then the configuration files must reside on a single TFTP server.
For CLI procedures, refer to the Cisco IOS Release 12.0 documentation on Cisco.com for additional information and CLI procedures.
Configuring the Domain Name and the DNS
Each unique IP address can have a host name associated with it. The IOS software maintains a cache of host name-to-address mappings for use by the EXEC mode connect, telnet, and ping commands, and related Telnet support operations. This cache speeds the process of converting names to addresses.
IP defines a hierarchical naming scheme that allows a device to be identified by its location or domain. Domain names are pieced together with periods (.) as the delimiting characters. For example, Cisco Systems is a commercial organization that IP identifies by a com domain name, so its domain name is cisco.com. A specific device in this domain, the File Transfer Protocol (FTP) system for example, is identified as ftp.cisco.com.
To keep track of domain names, IP has defined the concept of a Domain Name Server (DNS), which holds a cache (or database) of names mapped to IP addresses. To map domain names to IP addresses, you must first identify the host names and then specify a name server and enable the DNS, the Internet's global naming scheme that uniquely identifies network devices.
You can specify a default domain name that the software uses to complete domain name requests. You can specify either a single domain name or a list of domain names. When you specify a domain name, any IP host name without a domain name will have that domain name appended to it before being added to the host table.
If your network devices require connectivity with devices in networks for which you do not control name assignment, you can assign device names that uniquely identify your devices within the entire internetwork. The Internet's global naming scheme, the DNS, accomplishes this task. This service is enabled by default.
The switch uses the DNS server to resolve the TFTP server name to a TFTP server IP address. You must configure the TFTP server name-to-IP address map on the DNS server. The TFTP server contains the configuration files for the switch.
You must configure the IP addresses of the DNS servers in the lease database of the DHCP server from where the DHCP replies will retrieve them. You can enter up to two DNS server IP addresses in the lease database.
The DNS server can be on the same or a different LAN as the switch. If it is on a different LAN, the switch must be able to access it through a relay device or router. For more information, see the "Configuring the Relay Device" section.
For CLI procedures, refer to the Cisco IOS Release 12.0 documentation on Cisco.com for additional information and CLI procedures.
Configuring the Relay Device
You need to use a relay device if the DHCP, DNS, or TFTP servers are on a different LAN than the switch. You must configure this relay device to forward received broadcast packets on an interface to the destination host. This configuration ensures that broadcasts from the DHCP client can reach the DHCP, DNS, and TFTP servers and that broadcasts from the servers can reach the DHCP client.
If the relay device is a Cisco router, you enable IP routing (ip routing global configuration command) and configure it with helper addresses by using the ip helper-address interface configuration command.
For example, in Figure 6-2, you configure the router interfaces as follows:
On interface 10.0.0.2:
router(config-if)# ip helper-address 20.0.0.2router(config-if)# ip helper-address 20.0.0.3router(config-if)# ip helper-address 20.0.0.4On interface 20.0.0.1
router(config-if)# ip helper-address 10.0.0.1Figure 6-2 Relay Device Used in Autoconfiguration
For CLI procedures, refer to the Cisco IOS Release 12.0 documentation on Cisco.com for additional information and CLI procedures.
Obtaining Configuration Files
Depending on the availability of the IP address and the configuration filename in the DHCP reserved lease, the switch obtains its configuration information in these ways:
•
The switch receives its IP address, subnet mask, and configuration filename from the DHCP server. It also receives a DNS server IP address and a TFTP server name. The switch sends a DNS request to the DNS server, specifying the TFTP server name, to obtain the TFTP server address. Then the switch sends a unicast message to the TFTP server to retrieve the named configuration file from the base directory of the server, and upon receipt, completes its boot-up process.
•
The switch follows the same configuration process described above.
•
The switch receives its IP address and subnet mask from the DHCP server. It also receives a DNS server IP address and a TFTP server name. The switch sends a DNS request to the DNS server, specifying the TFTP server name, to obtain the TFTP server address.
The switch sends a unicast message to the TFTP server to retrieve the network-confg or cisconet.cfg default configuration file. (If the network-confg file cannot be read, the switch reads the cisconet.cfg file.)
The default configuration file contains the host names-to-IP-address mapping for the switch. The switch fills its host table with the information in the file and obtains its host name. If the host name is not found in the file, the switch uses the host name in the DHCP reply. If the host name is not specified in the DHCP reply, the switch uses the default "Switch" as its host name.
After obtaining its host name from the default configuration file or the DHCP reply, the switch reads the configuration file that has the same name as its host name (hostname-confg or hostname.cfg, depending on whether network-confg or cisconet.cfg was read earlier) from the TFTP server. If the cisconet.cfg file is read, the filename of the host is truncated to eight characters.
If the switch cannot read the network-confg, cisconet.cfg, or the host-name file, it reads the router-confg file. If the switch cannot read the router-confg file, it reads the ciscortr.cfg file.
Note
Example Configuration
Figure 6-3 shows a sample network for retrieving IP information using DHCP-based autoconfiguration.
Figure 6-3 DHCP-Based Autoconfiguration Network Example
Table 6-1 shows the configuration of the reserved leases on the DHCP server.
DNS Server Configuration
The DNS server maps the TFTP server name maritsu to IP address 10.0.0.3.
TFTP Server Configuration (on UNIX)
The TFTP server base directory is set to /tftpserver/work/. This directory contains the network-confg file used in the two-file read method. This file contains the host name to be assigned to the switch based on its IP address. The base directory also contains a configuration file for each switch (switch1-confg, switch2-confg, and so forth) as shown in this display:
prompt> cd /tftpserver/work/prompt> lsnetwork-confgswitch1-confgswitch2-confgswitch3-confgswitch4-confgprompt> cat network-confgip host switch1 10.0.0.21ip host switch2 10.0.0.22ip host switch3 10.0.0.23ip host switch4 10.0.0.24DHCP Client Configuration
No configuration file is present on Switch 1 through Switch 4.
Configuration Explanation
In Figure 6-3, Switch 1 reads its configuration file as follows:
•
•
•
•
•
Switches 2 through 4 retrieve their configuration files and IP addresses in the same way.
Assigning Passwords and Privilege Levels
You can assign the password of your switch in these ways:
•
•
Note
Because many privileged EXEC commands are used to set operating parameters, you should password-protect these commands to prevent unauthorized use. Catalyst 2900 XL and Catalyst 3500 XL switches have two commands for setting passwords:
•
•
You must enter one of these passwords to gain access to privileged EXEC mode. We recommend that you use the enable secret password.
Note
•
•
–
–
–
For information about passwords and CMS, see the "Access Modes in CMS" section.
•
Both types of passwords can contain from 1 to 25 uppercase and lowercase alphanumeric characters, and both can start with a number. Spaces are also valid password characters; for example, two words is a valid password. Leading spaces are ignored; trailing spaces are recognized. The password is case sensitive.
If you enter the enable secret command, the text is encrypted before it is written to the config.text file, and it is unreadable. If you enter the enable password command, the text is written as entered to the config.text file where you can read it. To remove a password, use the no version of the commands: no enable secret or no enable password. For CLI procedures, refer to the Cisco IOS Release 12.0 documentation on Cisco.com for additional information and CLI procedures.
You can also specify up to 15 privilege levels and define passwords for them by using the enable password [level level] {password} or the enable secret [level level] {password} command. Level 1 is EXEC-mode user privileges. If you do not specify a level, the privilege level defaults to 15 (privileged EXEC-mode privileges).
You can specify a level, set a password, and give the password only to users who need to have access at this level. Use the privilege level global configuration command to specify commands accessible at various levels.
If you lose or forget your enable password, see the "Recovering from a Lost or Forgotten Password" section.
Setting the System Date and Time
You can change the date and a 24-hour clock time setting on the switch. If you are entering the time for an American time zone, enter the three-letter abbreviation for the time zone, such as PST for Pacific standard time. If you are identifying the time zone by referring to Greenwich mean time, enter UTC (universal coordinated time). You then must enter a negative or positive number as an offset to indicate the number of time zones between the switch and Greenwich, England. Enter a negative number if the switch is west of Greenwich, England, and east of the international date line. For example, California is eight time zones west of Greenwich, so you would enter -8. Enter a positive number if the switch is east of Greenwich. You can also enter negative and positive numbers for minutes.
These sections cover these topics:
•
•
Configuring Daylight Saving Time
You can configure the switch to change to daylight saving time on a particular day every year, on a day that you enter, or not at all.
For CLI procedures, refer to the Cisco IOS Release 12.0 documentation on Cisco.com for additional information and CLI procedures.
Configuring the Network Time Protocol
In complex networks, it is often prudent to distribute time information from a central server. The Network Time Protocol (NTP) can distribute time information by responding to requests from clients or by broadcasting time information.
For CLI procedures, refer to the Cisco IOS Release 12.0 documentation on Cisco.com for additional information and CLI procedures.
Configuring the Switch as an NTP Client
You configure the switch as an NTP client by entering the IP addresses of up to ten NTP servers and specifying which server should be used first. You can also enter an authentication key to be used as a password when requests for time information are sent to the server.
Enabling NTP Authentication
To ensure the validity of information received from NTP servers, you can authenticate NTP messages with public-key encryption. This procedure must be coordinated with the administrator of the NTP servers: the information you enter will be matched by the servers to authenticate it.
Configuring the Switch for NTP Broadcast-Client Mode
You can configure the switch to receive NTP broadcast messages if there is an NTP broadcast server, such as a router, broadcasting time information on the network. You can also enter a value to account for any round-trip delay between the client and the NTP broadcast server.
Configuring CDP
Use the CLI or CMS to enable Cisco Discovery Protocol (CDP) for the switch, to set global CDP parameters, and to display information about neighboring Cisco devices.
CDP enables CMS to display a graphical view of the network. For example, the switch uses CDP to find cluster candidates and to maintain information about cluster members and other devices up to three cluster-enabled devices away from the command switch.
If necessary, you can configure CDP to discover switches running CMS up to seven devices away from the command switch. Devices that do not run clustering software display as edge devices, and CDP cannot discover any device connected to them.
Note
Configuring CDP for Extended Discovery
You can change the default configuration of CDP on the command switch to continue discovering devices up to seven hops away. Figure 6-4 shows a command switch that can discover candidates and cluster members up to seven devices away from it. Figure 6-4 also shows the command switch connected to a Catalyst 5000 series switch. Although the Catalyst 5000 supports CDP, it does not support clustering, and the command switch cannot learn about connected candidate switches connected to it, even if they are running CMS.
Figure 6-4 Discovering Cluster Candidates through CDP
Beginning in privileged EXEC mode, follow these steps to configure the number of hops that CDP uses to discover candidate switches and cluster members:
Managing the MAC Address Tables
You can manage the MAC address tables that the switch uses to forward traffic between ports. All MAC addresses in the address tables are associated with one or more ports. These MAC tables include these types of addresses:
•
•
•
The address tables list the destination MAC address and the VLAN ID, module, and port number associated with the address. Figure 6-5 shows an example list of addresses as they would appear in the dynamic, secure, or static address table. Table 6-2 shows the maximum number of MAC addresses supported on the Catalyst 2900 XL and Catalyst 3500 XL switches.
Figure 6-5 Contents of the Address Table
MAC Addresses and VLANs
All addresses are associated with a VLAN. An address can exist in more than one VLAN and have different destinations in each. Multicast addresses, for example, could be forwarded to port 1 in VLAN 1 and ports 9, 10, and 11 in VLAN 5.
Each VLAN maintains its own logical address table. A known address in one VLAN is unknown in another until it is learned or statically associated with a port in the other VLAN. An address can be secure in one VLAN and dynamic in another. Addresses that are statically entered in one VLAN must be static addresses in all other VLANs.
Changing the Address Aging Time
Dynamic addresses are source MAC addresses that the switch learns and then drops when they are not in use. The aging time parameter defines how long the switch retains unseen addresses in the table. This parameter applies to all VLANs.
Setting too short an aging time can cause addresses to be prematurely removed from the table. Then when the switch receives a packet for an unknown destination, it floods the packet to all ports in the same VLAN as the receiving port. This unnecessary flooding can impact performance. Setting too long an aging time can cause the address table to be filled with unused addresses; it can cause delays in establishing connectivity when a workstation is moved to a new port.
Beginning in privileged EXEC mode, follow these steps to configure the dynamic address table aging time:
Removing Dynamic Address Entries
Beginning in privileged EXEC mode, follow these steps to remove a dynamic address entry:
You can remove all dynamic entries by using the clear mac-address-table dynamic command in privileged EXEC mode.
MAC Address Notification
MAC address notification enables you to track users coming to and going from your network. Whenever a new MAC address is learned or an old MAC address is removed from the switch, an SNMP notification (trap) is generated. If you have many users coming and going from the network, you can set a trap interval time so that traps can be bundled together and sent at regular intervals.
The MAC notification history table stores the MAC address activity for each hardware port for which the trap is enabled. MAC address notifications are generated for dynamic and secure MAC addresses. Events are not generated for self addresses, multicast addresses, or other static addresses.
Beginning in privileged EXEC mode, follow these steps to enable the MAC address notification feature:
To disable the switch from sending MAC address notification traps, use the no snmp-server enable traps mac-notification global configuration command. To disable the MAC address notification traps on a specific interface, use the no snmp trap mac-notification interface configuration command. To disable the MAC address notification feature, use the no mac-address-table notification global configuration command.
This example shows how to specify 172.20.10.10 as the NMS, enable the switch to send MAC address notification traps to the NMS, enable the MAC address notification feature, set the interval time to 60 seconds, set the history-size to 100 entries, and enable traps whenever a MAC address is added on Fast Ethernet interface 0/4.
Switch(config)# snmp-server host 172.20.10.10Switch(config)# snmp-server enable traps mac-notificationSwitch(config)# mac-address-table notification interval 60Switch(config)# mac-address-table notification history-size 100Switch(config)# interface fastethernet0/4Switch(config-if)# snmp trap mac-notification addedYou can verify the previous commands by entering the show mac-address-table notification privileged EXEC command.
Adding Secure Addresses
The secure address table contains secure MAC addresses and their associated ports and VLANs. A secure address is a manually entered unicast address that is forwarded to only one port per VLAN. If you enter an address that is already assigned to another port, the switch reassigns the secure address to the new port.
You can enter a secure port address even when the port does not yet belong to a VLAN. When the port is later assigned to a VLAN, packets destined for that address are forwarded to the port.
Beginning in privileged EXEC mode, follow these steps to add a secure address:
Removing Secure Addresses
Beginning in privileged EXEC mode, follow these steps to remove a secure address:
You can remove all secure addresses by using the clear mac-address-table secure command in privileged EXEC mode.
Adding Static Addresses
A static address has these characteristics:
•
•
•
You can determine how a port that receives a packet forwards it to another port for transmission. Because all ports are associated with at least one VLAN, the switch acquires the VLAN ID for the address from the ports that you select on the forwarding map.
A static address in one VLAN must be a static address in other VLANs. A packet with a static address that arrives on a VLAN where it has not been statically entered is flooded to all ports and not learned.
Static addresses are entered in the address table with an in-port-list, an out-port-list, and a VLAN ID, if needed. Packets received from the in-port list are forwarded to ports listed in the out-port-list.
Note
Beginning in privileged EXEC mode, follow these steps to add a static address:
Removing Static Addresses
Beginning in privileged EXEC mode, follow these steps to remove a static address:
You can remove all secure addresses by using the clear mac-address-table static command in privileged EXEC mode.
Configuring Static Addresses for EtherChannel Port Groups
Follow these rules if you are configuring a static address to forward to ports in an EtherChannel port group:
•
•
Configuring CGMP
CGMP reduces the unnecessary flooding of IP multicast packets by limiting the transmission of these packets to CGMP clients that request them. The Fast Leave feature accelerates the removal of unused CGMP groups. By default, CGMP is enabled, and the Fast Leave feature is disabled.
End stations issue join messages to become part of a CGMP group and issue leave messages to leave the group. The membership of these groups is managed by the switch and by connected routers through the further exchange of CGMP messages.
CGMP groups are maintained on a per-VLAN basis: a multicast IP address packet can be forwarded to one list of ports in one VLAN and to a different list of ports in another VLAN. When a CGMP group is added, it is added on a per-VLAN, per-group basis. When a CGMP group is removed, it is only removed in a given VLAN.
Note
Conversely, you cannot add an address to an MVR group if it is already a CGMP group member. If you want an address that is already a CGMP group member to be an MVR group member, remove the address from the CGMP group, and then statically add it to the MVR group. For information about MVR, see the "Configuring MVR" section.
Enabling the Fast Leave Feature
The CGMP Fast Leave feature reduces the delay when group members leave groups. When an end station requests to leave a CGMP group, the group remains enabled for that VLAN until all members have requested to leave. With the Fast Leave feature enabled, the switch immediately verifies if there are other group members attached to its ports. If there are no other members, the switch removes the port from the group. If there are no other ports in the group, the switch sends a message to routers connected to the VLAN to delete the entire group.
The Fast Leave feature functions only if CGMP is enabled. The client must be running IGMP version 2 for the Fast Leave feature to function properly.
Beginning in privileged EXEC mode, follow these steps to enable the CGMP Fast Leave feature:
Disabling the CGMP Fast Leave Feature
Beginning in privileged EXEC mode, follow these steps to disable the CGMP Fast Leave feature:
Changing the CGMP Router Hold-Time
The router hold-time is the number of seconds the switch waits before removing (aging) a router entry and ceasing to exchange messages with the router. If it is the last router entry in a VLAN, all CGMP groups on that VLAN are removed. You can thus enter a lower router hold-time to accelerate the removal of CGMP groups.
Note
Beginning in privileged EXEC mode, follow these steps to change the router hold-time:
Removing Multicast Groups
You can reduce the forwarding of IP multicast packets by removing groups from the Current Multicast Groups table. Each entry in the table consists of the VLAN, IGMP multicast address, and ports.
You can use the CLI to clear all CGMP groups, all CGMP groups in a VLAN, or all routers, their ports, and their expiration times. Beginning in privileged EXEC mode, follow these steps to remove all multicast groups:
Step 1
clear cgmp group
Clear all CGMP groups on all VLANs on the switch.
Step 2
show cgmp
Verify your entry by displaying CGMP information.
Configuring IGMP Filtering
IGMP filtering works with the Multicast VLAN Registration (MVR) feature to allow you to configure profiles of IP multicast groups. You can then associate these profiles with filtering action.
IGMP filters are associated with each physical switch port. These filters are applied to all VLANs associated with the physical port.
When a host or client in a VLAN sends an IGMP join message, the IGMP message is processed by the filter on the switch port. If the configured filter causes the IGMP report to be dropped, the switch port requesting the stream of IP multicast traffic cannot receive IP multicast traffic for that group. If the filtering action permits a particular IGMP report, the IGMP report is forwarded for normal processing.
The filtering actions are configured on a per-switch-port basis.
Note
Note
IGMP filters can be used in the video service deployment in Ethernet to the home (ETTH). The IGMP filters specify which multicast addresses are allowed to be received by the switch.
Configuring IGMP Profiles
To configure an IGMP profile, use the ip igmp profile global configuration command with a profile number to create an IGMP profile and enter IGMP profile configuration mode. From this mode, you can specify the parameters of the IGMP profile to be used for filtering IGMP join requests from a switch port. When you are in IGMP profile configuration mode, you can create the profile by using these commands:
•
•
•
•
•
The default is for the switch to have no IGMP profiles configured. When a profile is configured, if neither the permit nor deny keyword is included, the default is to deny access to the range of IP addresses.
Beginning in privileged EXEC mode, follow these steps to create an IGMP profile:
To delete a profile, use the no ip igmp profile profile number global configuration command.
To delete an IP multicast address or range of IP multicast addresses, use the no range ip multicast address igmp profile command.
This example shows how to create IGMP profile 22 denying access to the single IP multicast address and how to verify the configuration. Note that because the action was to deny (the default), it does not appear in the show ip igmp profile profile number privileged EXEC command output.
Switch # config tSwitch(config) # ip igmp profile 22Switch(config-igmp-profile)# denySwitch(config-igmp-profile)# range 229.9.9.0Switch(config-igmp-profile)# endSwitch# show ip igmp profile 22IGMP Profile 22range 229.9.9.0 229.9.9.0Applying IGMP Filters
To control access as defined in an IGMP profile, you apply the profile to the appropriate interfaces. IGMP profiles can be applied to Layer 2 ports only. A profile can be applied to multiple interfaces, but each interface can only have one profile applied to it.
Beginning in privileged EXEC mode, follow these steps to apply an IGMP profile to a switch port:
To remove a filter profile from an interface, use the no ip igmp filter profile number interface configuration command.
This example shows how to apply IGMP profile 22 to an interface and verify the configuration.
Switch # config tSwitch(config)# interface fastethernet 0/12Switch(config-if)# ip igmp filter 22Switch(config-if)# endSwitch# show running-config interface fastethernet 0/12Building configuration...Current configuration : 124 bytes!interface FastEthernet0/12no ip addressshutdownsnmp trap link-statusip igmp filter 22endSetting the Maximum Number of IGMP Groups
You can set the maximum number of IGMP groups that a Layer 2 interface can join. Use the no form of this command to set the maximum back to the default, which is no limit.
Beginning in privileged EXEC mode, follow these steps to set the maximum number of IGMP groups for an interface:
To remove the maximum group limitation and return to the default of no maximum, use the no ip igmp max-groups interface configuration command.
This example shows how to limit the number of IGMP groups that an interface can join to 20.
Switch# config tSwitch(config)# interface fastethernet 0/12Switch(config-if)# ip igmp max-groups 20Switch(config-if)# endSwitch# show running-config interface fastethernet 0/12Building configuration...Current configuration : 124 bytes!interface FastEthernet0/12no ip addressshutdownsnmp trap link-statusip igmp max-groups 25ip igmp filter 22endConfiguring MVR
Multicast VLAN Registration (MVR) is designed for applications using wide-scale deployment of multicast traffic (for example, broadcast of multiple television channels) across an Ethernet ring-based service provider network. MVR allows a subscriber on a port to subscribe and unsubscribe to a multicast stream on the network-wide multicast VLAN. It allows the single multicast VLAN to be shared in the network while subscribers remain in separate VLANs. This provides the ability to continuously send multicast streams in the multicast VLAN, but to isolate the streams from the subscriber VLANs for bandwidth and security reasons.
MVR assumes that subscriber ports subscribe and unsubscribe (join and leave) these multicast streams by sending out Internet Group Management Protocol (IGMP) join and leave messages. These messages can originate from an IGMP version-2-compatible set-top box with an Ethernet connection or from a PC capable of generating IGMP version-2 messages. The switch CPU identifies IP multicast streams and their associated MAC addresses in the switch forwarding table, intercepts the IGMP messages, and modifies the forwarding table to include or remove the subscriber as a receiver of the multicast stream. This forwarding behavior selectively allows traffic to cross between the two VLANs.
Because MVR does not support IGMP dynamic joins, the user or administrator must configure static multicast addresses on the router.
Note
Using MVR in a Multicast Television Application
In a multicast television application, a PC or a television with a set-top box can receive the multicast stream. Multiple set-top boxes or PCs can be connected to one subscriber port. (See Figure 6-6.) DHCP assigns an IP address to the set-top box or the PC. When a subscriber selects a channel, the set-top box or PC sends an IGMP report to the access layer switch (S1 switch) to join the appropriate multicast. If the IGMP report matches one of the configured multicast MAC addresses, the switch CPU modifies the hardware address table to include this receiver port and VLAN as a forwarding destination of the specified multicast stream when it is received from the multicast VLAN over the source port.
When a subscriber changes channels or turns off the television, the set-top box sends an IGMP leave message for the multicast stream. The switch CPU sends an IGMP group-specific query through the receiver port VLAN. If there is another set-top box in the VLAN still subscribing to this group, that set-top box must respond within the maximum response time. If the CPU does not receive a response, it eliminates the receiver port as a forwarding destination for this group.
Figure 6-6 Multicast VLAN Registration Example
MVR eliminates the need to duplicate television-channel multicast traffic for subscribers in each VLAN. Multicast traffic for all channels is sent only once around the VLAN trunk—only on the multicast VLAN. Although the IGMP leave and join messages originate with a subscriber, they appear to be initiated by a port in the multicast VLAN rather than in the VLAN to which the subscriber port is assigned. These messages dynamically register for streams of multicast traffic in the multicast VLAN on the switch. The access layer switch (S1 switch) modifies the forwarding behavior to allow the traffic to be forwarded from the multicast VLAN to the subscriber port in a different VLAN, selectively allowing traffic to cross between two VLANs.
IGMP reports are sent to the same MAC addresses as the multicast data. The S1 CPU must capture all IGMP join and leave messages from subscriber ports. Because the Catalyst 2900 and Catalyst 3500 hardware cannot distinguish IP multicast data packets from IP multicast packets carrying IGMP protocol data, all packets from subscriber ports destined for the configured multicast MAC addresses are forwarded to the switch CPU, which distinguishes IGMP packets from regular multicast traffic.
Configuration Guidelines and Limitations
Follow these guidelines when configuring MVR:
•
•
–
–
•
a.
b.
c.
d.
•
•
•
MVR implementation has these limitations:
•
•
•
•
Conversely, you cannot add an address to an MVR group if it is already a CGMP group member. If you want an address that is already a CGMP group member to be an MVR group member, remove the address from the CGMP group, and then statically add it to the MVR group. For information about CGMP, see the "Configuring CGMP" section.
Setting MVR Parameters
You do not need to set MVR parameters if you choose to use the default settings. If you do want to change the default parameters, you must do so before enabling MVR.
Beginning in privileged EXEC mode, follow these steps to configure MVR parameters:
Configuring MVR
Beginning in privileged EXEC mode, follow these steps to configure MVR:
Managing the ARP Table
To communicate with a device (over Ethernet, for example), the software first must determine the 48-bit MAC or the local data link address of that device. The process of determining the local data link address from an IP address is called address resolution.
The Address Resolution Protocol (ARP) associates a host IP address with the corresponding media or MAC addresses and the VLAN ID. Taking an IP address as input, ARP determines the associated MAC address. Once a MAC address is determined, the IP-MAC address association is stored in an ARP cache for rapid retrieval. Then the IP datagram is encapsulated in a link-layer frame and sent over the network. Encapsulation of IP datagrams and ARP requests and replies on IEEE 802 networks other than Ethernet is specified by the Subnetwork Access Protocol (SNAP). By default, standard Ethernet-style ARP encapsulation (represented by the arpa keyword) is enabled on the IP interface.
ARP entries added manually to the table do not age and must be manually removed.
For CLI procedures, refer to the Cisco IOS Release 12.0 documentation on Cisco.com for additional information and CLI procedures.
Configuring STP
Spanning Tree Protocol (STP) provides path redundancy while preventing undesirable loops in the network. Only one active path can exist between any two stations. STP calculates the best loop-free path throughout the network.
Supported STP Instances
You create an STP instance when you assign an interface to a VLAN. The STP instance is removed when the last interface is moved to another VLAN. You can configure switch and port parameters before an STP instance is created. These parameters are applied when the STP instance is created. You can change all VLANs on a switch by using the stp-list parameter when you enter STP commands through the CLI. For more information, refer to the switch command reference.
The Catalyst 2912 XL, Catalyst 2924 XL, and Catalyst 2924C XL support only 64 STP instances and 64 VLANs. All other Catalyst 2900 XL switches and all Catalyst 3500 XL switches support 64 STP instances and 250 VLANs.
Each VLAN is a separate STP instance. If you have already used up all available STP instances on a switch, adding another VLAN anywhere in the VLAN Trunking Protocol (VTP) domain creates a VLAN that is not running STP on that switch. For example, if 250 VLANs are defined in the VTP domain, you can enable STP on 64 of those VLANs. The remaining VLANs must operate with STP disabled.
You can disable STP on one of the VLANs where it is running, and then enable it on the VLAN where you want it to run. Use the no spanning-tree vlan vlan-id global configuration command to disable STP on a specific VLAN, and use the spanning-tree vlan vlan-id global configuration command to enable STP on the desired VLAN.
For more information about VLANs, see "Configuring VLANs."
Caution
Note
Using STP to Support Redundant Connectivity
You can create a redundant backbone with STP by connecting two of the switch ports to another device or to two different devices. STP automatically disables one port but enables it if the other port is lost. If one link is high-speed and the other low-speed, the low-speed link is originally disabled. If the two link speeds are the same, the port priority and the port ID are added together, and STP disables the link with the lowest value.
You can also create redundant links between switches by using EtherChannel port groups. For more information about creating port groups, see the "Creating EtherChannel Port Groups" section.
Disabling STP
STP is enabled by default. Disable STP only if you are sure there are no loops in the network topology.
Caution
Beginning in privileged EXEC mode, follow these steps to disable STP:
Accelerating Aging to Retain Connectivity
The default for aging dynamic addresses is 5 minutes. However, a reconfiguration of the spanning tree can cause many station locations to change. Because these stations could be unreachable for 5 minutes or more during a reconfiguration, the address-aging time is accelerated so that station addresses can be dropped from the address table and then relearned. The accelerated aging is the same as the forward-delay parameter value when STP reconfigures.
Because each VLAN is a separate instance of STP, the switch accelerates aging on a per-VLAN basis. A reconfiguration of STP on one VLAN can cause the dynamic addresses learned on that VLAN to be subject to accelerated aging. Dynamic addresses on other VLANs can be unaffected and remain subject to the aging interval entered for the switch.
Configuring STP and UplinkFast in a Cascaded Cluster
STP uses default values that can be reduced when configuring Catalyst 2900 XL and Catalyst 3500 XL switches in cascaded configurations. If an STP root switch is part of a cluster that is one switch from a cascaded stack, you can customize STP to reconverge more quickly after a switch failure. Figure 6-7 shows modular Catalyst 2900 XL and Catalyst 3500 XL switches in three cascaded clusters that use the GigaStack GBIC. Table 6-3 shows the default STP settings and those that are acceptable for these configurations.
Figure 6-7 Gigabit Ethernet Clusters
Enabling UplinkFast on all cluster switches can further reduce the time it takes cluster switches to begin forwarding after a new root switch is selected.
Configuring Redundant Links By Using STP UplinkFast
Switches in hierarchical networks can be grouped into backbone switches, distribution switches, and access switches. Figure 6-8 shows a complex network where distribution switches and access switches each have at least one redundant link that STP blocks to prevent loops.
If a switch looses connectivity, the switch begins using the alternate paths as soon as STP selects a new root port. STP UplinkFast is a Cisco enhancement that accelerates the choice of a new root port when a link or switch fails or when STP reconfigures itself. The root port transitions to the forwarding state immediately without going through the listening and learning states, as it would with normal STP procedures.
When STP reconfigures the new root port, other ports flood the network with multicast packets, one for each address that was learned on the port. You can limit these bursts of multicast traffic by reducing the max-update-rate parameter. The default for this parameter is 150 packets per second. However, if you enter zero, station-learning frames are not generated, so the STP topology converges more slowly after a loss of connectivity.
UplinkFast is most useful in edge or access switches and might not be appropriate for backbone devices.
Figure 6-8 Switches in a Hierarchical Network
Enabling STP UplinkFast
When you enable UplinkFast, it is enabled for the entire switch and cannot be enabled for individual VLANs.
Beginning in privileged EXEC mode, follow these steps to configure UplinkFast:
When UplinkFast is enabled, the bridge priority of all VLANs is set to 49152, and the path cost of all ports and VLAN trunks is increased by 3000. This change reduces the chance that the switch will become the root switch. When UplinkFast is disabled, the bridge priorities of all VLANs and path costs of all ports are set to default values.
Configuring Cross-Stack UplinkFast
Cross-stack UplinkFast (CSUF) provides a fast spanning-tree transition (fast convergence in less than 2 seconds under normal network conditions) across a stack of switches that use the GigaStack GBICs connected in a shared cascaded configuration (multidrop backbone). During the fast transition, an alternate redundant link on the stack of switches is placed into the forwarding state without causing temporary spanning-tree loops or loss of connectivity to the backbone. With this feature, you can have a redundant and resilient network in some configurations.
CSUF might not provide a fast transition all the time; in these cases, the normal STP transition occurs, which completes in 30 to 40 seconds. For more information, see the "Events that Cause Fast Convergence" section.
How CSUF Works
CSUF ensures that one link in the stack is elected as the path to the root. As shown in Figure 6-9, Switches A, B, and C are cascaded through the Gigastack GBIC to form a multidrop backbone, which communicates control and data traffic across the switches at the access layer. The switches in the stack use their stack ports to communicate with each other and to connect to the stack backbone; stack ports are always in the STP forwarding state. The stack root port on Switch A provides the path to the root of the spanning tree; the alternate stack root ports on Switches B and C can provide an alternate path to the spanning-tree root if the current stack root switch fails or its link to the spanning-tree root fails.
Link A, the root link, is in the STP forwarding state; Links B and C are alternate redundant links that are in the STP blocking state. If Switch A fails, if its stack root port fails, or if Link A fails, CSUF selects either the Switch B or Switch C alternate stack root port and puts it into the forwarding state in less than 1 second.
Figure 6-9 Cross-Stack UplinkFast Topology
CSUF implements the Stack Membership Discovery Protocol and the Fast Uplink Transition Protocol. Using the Stack Membership Discovery Protocol, all stack switches build a neighbor list of stack members through the receipt of discovery hello packets. When certain link loss or STP events occur (described in the "Events that Cause Fast Convergence" section), the Fast Uplink Transition Protocol uses the neighbor list to send fast-transition requests on the stack port to stack members.
The switch sending the fast-transition request needs to do a fast transition to the forwarding state of a port that it has chosen as the root port, and it must obtain an acknowledgement from each stack switch before performing the fast transition.
Each switch in the stack determines if the sending switch is a better choice than itself to be the stack root of this STP instance by comparing STP root, cost, and bridge ID. If the sending switch is the best choice as the stack root, the switch in the stack returns an acknowledgement; otherwise, it does not respond to the sending switch (drops the packet) and prevents the sending switch from receiving acknowledgements from all stack switches.
When acknowledgements are received from all stack switches, the Fast Uplink Transition Protocol on the sending switch immediately transitions its alternate stack root port to the forwarding state. If acknowledgements from all stack switches are not obtained by the sending switch, the normal STP transitions (blocking, listening, learning, forwarding) take place, and the spanning-tree topology converges at its normal rate (2 * forward-delay time + max-age time). The Fast Uplink Transition Protocol is implemented on a per-VLAN basis and affects only one STP instance at a time.
Events that Cause Fast Convergence
Depending on the network event or failure, fast convergence provided by CSUF might or might not occur.
Fast convergence (within 2 seconds under normal network conditions) occurs under these circumstances:
•
If two switches in the stack have alternate paths to the root, only one of the switches performs the fast transition.
•
•
•
Note
Normal STP convergence (30 to 40 seconds) occurs under these conditions:
•
•
•
•
•
Note
Limitations
These limitations apply to CSUF:
•
•
•
•
Connecting the Stack Ports
A fast transition occurs across the stack of switches if the multidrop backbone connections are a continuous link from one GigaStack GBIC to another as shown in Figure 6-10. In addition, follow these guidelines:
•
•
•
•
Figure 6-10 GigaStack GBIC Connections and STP Convergence
Configuring Cross-Stack UplinkFast
Before enabling CSUF, make sure your stack switches are properly connected. For more information, see the "Connecting the Stack Ports" section.
Beginning in privileged EXEC mode, follow these steps to enable CSUF:
To disable CSUF on an interface, use the no spanning-tree stack-port interface configuration command. To disable UplinkFast on the switch, use the no spanning-tree uplinkfast global configuration command.
Changing the STP Parameters for a VLAN
The root switch for each VLAN is the switch with the highest priority and sends topology frames to other switches in the spanning tree. You can change the root parameters for the VLANs on a selected switch. These options define how your switch responds when STP reconfigures itself.
Changing the STP Implementation
Beginning in privileged EXEC mode, follow these steps to change the STP implementation. The stp-list is the list of VLANs to which the STP command applies.
Changing the Switch Priority
Beginning in privileged EXEC mode, follow these steps to change the switch priority and affect which switch is the root switch. The stp-list is the list of VLANs to which the STP command applies.
Changing the BPDU Message Interval
Beginning in privileged EXEC mode, follow these steps to change the BPDU message interval (max age time). The stp-list is the list of VLANs to which the STP command applies.
Changing the Hello BPDU Interval
Beginning in privileged EXEC mode, follow these steps to change the hello BPDU interval (hello time). The stp-list is the list of VLANs to which the STP command applies.
Changing the Forwarding Delay Time
Beginning in privileged EXEC mode, follow these steps to change the forwarding delay time. The stp-list is the list of VLANs to which the STP command applies.
STP Port States
When a port is not forwarding due to STP, it can be in one of these states:
•
•
•
•
•
•
•
Enabling the Port Fast Feature
The Port Fast feature brings a port directly from a blocking state into a forwarding state. This feature is useful when a connected server or workstation times out because its port is going through the normal cycle of STP status changes. A port with Port Fast enabled only goes through the normal cycle of STP status changes when the switch is restarted.
Caution
You can modify these Port Fast parameters:
•
•
Enter a number from 1 to 65535. The default is 100 for 10 Mbps, 19 for 100 Mbps, 14 for 155 Mbps (ATM), 4 for 1 Gbps, 2 for 10 Gbps, and 1 for interfaces with speeds greater than 10 Gbps.
•
Enabling this feature on a port connected to a switch or hub could prevent STP from detecting and disabling loops in your network.
Beginning in privileged EXEC mode, follow these steps to enable the Port Fast feature:
Changing the Path Cost
Beginning in privileged EXEC mode, follow these steps to change the path cost for STP calculations. The STP command applies to the stp-list.
Changing the Port Priority
Beginning in privileged EXEC mode, follow these steps to change the port priority, which is used when two switches tie for position as the root switch. The stp-list is the list of VLANs to which the STP command applies.
Configuring STP Root Guard
The Layer 2 network of a service provider (SP) can include many connections to switches that are not owned by the SP. In such a topology, STP can reconfigure itself and select a customer switch as the STP root switch, as shown in Figure 6-11. You can avoid this situation by configuring the root-guard feature on interfaces that connect to switches outside of your customer's network. If STP calculations cause an interface in the customer network to be selected as the root port, root guard then places the interface into the root-inconsistent (blocked) state to prevent the customer switch from becoming the root switch or being in the path to the root.
If a switch outside the network becomes the root switch, the interface is blocked (root-inconsistent state), and STP selects a new root switch. The customer switch does not become the root switch and is not in the path to the root.
Caution
Figure 6-11 STP in a Service Provider Network
Root guard enabled on a port applies to all the VLANs that the port belongs to. Each VLAN has its own instance of STP.
Beginning in privileged EXEC mode, follow these steps to set root guard on a port:
Use the no version of the spanning-tree rootguard command to disable the root guard feature.
Configuring BPDU Guard
Note
In a valid configuration, Port Fast-enabled interfaces do not receive BPDUs. When the BPDU guard feature is enabled on the switch, STP shuts down Port Fast-enabled interfaces that receive BPDUs rather than putting the interfaces into the blocking state.
Note
Caution
Beginning in privileged EXEC mode, follow these steps to enable the BPDU guard feature on the switch:
Use the no spanning-tree portfast bpduguard global configuration command to disable BPDU guard.
Configuring SNMP
This software release supports these Simple Network Management Protocol (SNMP) versions:
•
•
–
–
You must configure the SNMP agent to use the version of SNMP supported by the management station. An agent can communicate with multiple managers; for this reason, you can configure the software to support communications with one management station using the SNMPv1 protocol and another using the SNMPv2 protocol.
Both SNMPv1 and SNMPv2C use a community-based form of security. The community of managers able to access the agent's Management Information Base (MIB) is defined by an IP address access control list and password.
SNMPv2C includes a bulk retrieval mechanism and more detailed error message reporting to management stations. The bulk retrieval mechanism retrieves tables and large quantities of information, minimizing the number of round-trips required. The SNMPv2C improved error-handling includes expanded error codes that distinguish different kinds of error conditions; these conditions are reported through a single error code in SNMPv1. Error return codes now report the error type.
SNMPv2C replaces the Party-based Administrative and Security Framework of SNMPv2Classic with the Community-based Administrative Framework of SNMPv2C while retaining the bulk retrieval and improved error handling of SNMPv2Classic.
Note
Disabling and Enabling SNMP
SNMP is enabled by default and must be enabled for Cluster Management features to work properly.
SNMP is always enabled for Catalyst 1900 and Catalyst 2820 switches.
For CLI procedures, refer to the Cisco IOS Release 12.0 documentation on Cisco.com for additional information and CLI procedures.
Entering Community Strings
Community strings serve as passwords for SNMP messages, permitting access to the agent on the switch. If you are entering community strings for a cluster member, see the "SNMP Community Strings" section. You can enter community strings with these characteristics:
Read-only (RO)—Requests accompanied by the string can display MIB-object information.
Read-write (RW)—Requests accompanied by the string can display MIB-object information and set MIB objects.
For CLI procedures, refer to the Cisco IOS Release 12.0 documentation on Cisco.com for additional information and CLI procedures.
Adding Trap Managers
A trap manager is a management station that receives and processes traps. When you configure a trap manager, the community strings for each member switch must be unique. If a member switch has an assigned IP address, the management station accesses the switch by using that IP address.
By default, no trap manager is defined, and no traps are issued. Table 6-4 describes SNMP traps that you can configure on the Catalyst 2900 XL and Catalyst 3500 XL. You can enable any or all of these traps and configure a trap manager on these switches to receive them.
Catalyst 1900 and Catalyst 2820 switches support up to four trap managers. When you configure community strings for these switches, limit the string length to 32 characters. When configuring traps on these switches, you cannot configure individual trap managers to receive specific traps.
Table 6-5 describes the Catalyst 1900 and Catalyst 2820 SNMP traps. You can enable any or all of these traps, but these traps are received by all configured trap managers.
Beginning in privileged EXEC mode, follow these steps to add a trap manager and a community string:
Configuring TACACS+
The Terminal Access Controller Access Control System Plus (TACACS+) provides the means to manage network security (authentication, authorization, and accounting [AAA]) from a server. This section describes how TACACS+ works and how you can configure it.
Note
You can only configure this feature by using the CLI; you cannot configure it through CMS.
Note
In large enterprise networks, the task of administering passwords on each device can be simplified by centralizing user authentication on a server. TACACS+ is an access-control protocol that allows a switch to authenticate all login attempts through a central server. The network administrator configures the switch with the address of the TACACS+ server, and the switch and the server exchange messages to authenticate each user before allowing access to the management console.
TACACS+ consists of three services: authentication, authorization, and accounting. Authentication determines who the user is and whether or not the user is allowed access to the switch. Authorization is the action of determining what the user is allowed to do on the system. Accounting is the action of collecting data related to resource usage.
The TACACS+ feature is disabled by default. However, you can enable and configure it by using the CLI. You can access the CLI through the console port or through Telnet. 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
Configuring the TACACS+ Server Host
Use the tacacs-server host command to specify the names of the IP host or hosts maintaining an AAA/TACACS+ server. On TACACS+ servers, you can configure these additional options:
•
•
•
Beginning in privileged EXEC mode, follow these steps to configure the TACACS+ server:
Configuring Login Authentication
Beginning in privileged EXEC mode, follow these steps to configure login authentication by using AAA/TACACS+:
The variable list-name is any character string used to name the list you are creating. The method variable refers to the actual methods the authentication algorithm tries, in the sequence entered. You can choose one of these methods:
•
•
•
To create a default list that is used if no list is specified in the login authentication line configuration command, use the default keyword followed by the methods you want used in default situations.
The additional methods of authentication are used only if the previous method returns an error, not if it fails. To specify that the authentication succeed even if all methods return an error, specify none as the final method in the command line.
Specifying TACACS+ Authorization for 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 Cisco IOS privilege mode (EXEC access) and to network services such as Serial Line Internet Protocol (SLIP), Point-to-Point Protocol (PPP) with Network Control Protocols (NCPs), and AppleTalk Remote Access (ARA).
The aaa authorization exec tacacs+ local command sets these authorization parameters:
•
•
Note
Beginning in privileged EXEC mode, follow these steps to specify TACACS+ authorization for EXEC access and network services:
Starting TACACS+ Accounting
You use the aaa accounting command with the tacacs+ keyword to turn on TACACS+ accounting for each Cisco IOS privilege level and for network services.
Beginning in privileged EXEC mode, follow these steps to enable TACACS+ accounting:
Configuring a Switch for Local AAA
You can configure AAA to operate without a server by setting the switch to implement AAA in local mode. The switch then verifies authentication and authorization. No accounting is available in this configuration.
Beginning in privileged EXEC mode, follow these steps to configure the switch for local AAA:
Controlling Switch Access with RADIUS
Note
This section describes how to enable and configure the Remote Authentication Dial-In User Service (RADIUS), which provides detailed accounting information and flexible administrative control over authentication and authorization processes. RADIUS is facilitated through AAA and can be enabled only through AAA CLI commands.
Note
This section contains this configuration information:
•
Understanding RADIUS
RADIUS is a distributed client/server system that secures networks against unauthorized access. RADIUS clients run on supported Cisco routers and switches and send authentication requests to a central RADIUS server, which contains all user authentication and network service access information. 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, refer to the RADIUS server documentation.
Use RADIUS in these network environments that require access security:
•
•
•
Figure 6-12 Transitioning from RADIUS to TACACS+ Services
•
RADIUS is not suitable in these network security situations:
•
•
•
RADIUS Operation
When a user attempts to log in and authenticate to a switch that is access controlled by a RADIUS server, these events occur:
1.
2.
3.
a.
b.
c.
d.
The ACCEPT or REJECT response is bundled with additional data that is used for privileged EXEC or network authorization. Users must first successfully complete RADIUS authentication before proceeding to RADIUS authorization, if it is enabled. The additional data included with the ACCEPT or REJECT packets includes these items:
•
•
Configuring RADIUS
This section describes how to configure your switch to support RADIUS. 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.
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 (such as TACACS+ or local username lookup), 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.
You should have access to and should configure a RADIUS server before configuring RADIUS features on your switch.
This section contains this configuration information:
•
•
•
•
•
•
•
•
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 who access the switch through the CLI.
Identifying the RADIUS Server Host
Switch-to-RADIUS-server communication involves several components:
•
•
•
•
•
•
You identify RADIUS security servers by their host names or IP addresses, host names and specific UDP port numbers, or their IP addresses 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 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. To apply these settings globally to all RADIUS servers communicating with the switch, use the unique global configuration commands: radius-server timeout, radius-server retransmit, and radius-server key. To apply these values on a specific RADIUS server, use the radius-server host global configuration command.
Note
You can configure the switch to use AAA server groups to group existing server hosts for authentication. For more information, see the "Defining AAA Server Groups" section.
Beginning in privileged EXEC mode, follow these steps to configure per-server RADIUS server communication. This procedure is required.
To remove the specified RADIUS server, use the no radius-server host hostname | ip-address global configuration command.
This example shows how to configure one RADIUS server to be used for authentication and another to be used for accounting:
Switch(config)# radius-server host 172.29.36.49 auth-port 1612 key rad1Switch(config)# radius-server host 172.20.36.50 acct-port 1618 key rad2This example shows how to configure host1 as the RADIUS server and to use the default ports for both authentication and accounting:
Switch(config)# radius-server host host1
Note
Configuring RADIUS Login Authentication
To configure AAA authentication, you define a named list of authentication methods and then apply that list to various interfaces. 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 interface before any of the defined authentication methods are performed. The only exception is the default method list (which is named default). The default method list is automatically applied to all interfaces 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.
Beginning in privileged EXEC mode, follow these steps to configure login authentication. This procedure is required.
Step 1
configure terminal
Enter global configuration mode.
Step 2
aaa new-model
Enable AAA.
Step 3
aaa authentication login {default | list-name} method1 [method2...]
Create a login authentication method list.
•
•
•
Select one of these methods:
•
•
•
•
•
•
Step 4
line [console | tty | vty] line-number [ending-line-number]
Enter line configuration mode, and configure the lines to which you want to apply the authentication list.
Step 5
login authentication {default | list-name}
Apply the authentication list to a line or set of lines.
•
•
Step 6
end
Return to privileged EXEC mode.
Step 7
show running-config
Verify your entries.
Step 8
copy running-config startup-config
(Optional) Save your entries in the configuration file.
To disable AAA, use the no aaa new-model global configuration command. To disable AAA authentication, use the no aaa authentication login {default | list-name} method1 [method2...] global configuration command. To either disable RADIUS authentication for logins or to return to the default value, use the no login authentication {default | list-name} line configuration command.
Defining 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. 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.
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.
Beginning in privileged EXEC mode, follow these steps to define the AAA server group and associate a particular RADIUS server with it:
Step 1
configure terminal
Enter global configuration mode.
Step 2
radius-server host {hostname | ip-address} [auth-port port-number] [acct-port port-number] [timeout seconds] [retransmit retries] [key string]
Specify the IP address or host name of the remote RADIUS server host.
•
•
•
•
•
Note
To configure the switch to recognize more than one host entry associated with a single IP address, enter this command as many times as necessary, making sure that each UDP port number is different. The switch software searches for hosts in the order in which you specify them. Set the timeout, retransmit, and encryption key values to use with the specific RADIUS host.
Step 3
aaa new-model
Enable AAA.
Step 4
aaa group server radius group-name
Define the AAA server-group with a group name.
This command puts the switch in a server group configuration mode.
Step 5
server ip-address
Associate a particular RADIUS server with the defined server group. Repeat this step for each RADIUS server in the AAA server group.
Each server in the group must be previously defined in Step 2.
Step 6
end
Return to privileged EXEC mode.
Step 7
show running-config
Verify your entries.
Step 8
copy running-config startup-config
(Optional) Save your entries in the configuration file.
Step 9
Enable RADIUS login authentication. See the "Configuring RADIUS Login Authentication" section.
To remove the specified RADIUS server, use the no radius-server host hostname | ip-address global configuration command. To remove a server group from the configuration list, use the no aaa group server radius group-name global configuration command. To remove the IP address of a RADIUS server, use the no server ip-address server group configuration command.
In this example, the switch is configured to recognize two different RADIUS group servers (group1 and group2). Group1 has two different host entries on the same RADIUS server configured for the same services. The second host entry acts as a fail-over backup to the first entry.
Switch(config)# radius-server host 172.20.0.1 auth-port 1000 acct-port 1001Switch(config)# radius-server host 172.10.0.1 auth-port 1645 acct-port 1646Switch(config)# aaa new-modelSwitch(config)# aaa group server radius group1Switch(config-sg-radius)# server 172.20.0.1 auth-port 1000 acct-port 1001Switch(config-sg-radius)# exitSwitch(config)# aaa group server radius group2Switch(config-sg-radius)# server 172.20.0.1 auth-port 2000 acct-port 2001Switch(config-sg-radius)# exitConfiguring RADIUS Authorization for User Privileged 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 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.
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:
•
•
Note
Beginning in privileged EXEC mode, follow these steps to specify RADIUS authorization for privileged EXEC access and network services:
To disable authorization, use the no aaa authorization {network | exec} method1 global configuration command.
Starting RADIUS 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 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. This data can then be analyzed for network management, client billing, or auditing.
Beginning in privileged EXEC mode, follow these steps to enable RADIUS accounting for each Cisco IOS privilege level and for network services:
To disable accounting, use the no aaa accounting {network | exec} {start-stop} method1... global configuration command.
Configuring Settings for All RADIUS Servers
Beginning in privileged EXEC mode, follow these steps to configure global communication settings between the switch and all RADIUS servers:
To return to the default setting for the retransmit, timeout, and deadtime, use the no forms of these commands.
Configuring the Switch to Use 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 attribute-value (AV) pair defined in the Cisco TACACS+ specification, and sep is = for mandatory attributes and * for optional attributes. This allows the full set of features available for TACACS+ authorization to also be used for RADIUS.
For example, the following AV pair activates Cisco's multiple named ip address pools feature during IP authorization (during PPP IPCP address assignment):
cisco-avpair= "ip:addr-pool=first"The following example shows how to provide a user logging in from a switch with immediate access to privileged 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, refer to RFC 2138, "Remote Authentication Dial-In User Service (RADIUS)."
Beginning in privileged EXEC mode, follow these steps to configure the switch to recognize and use VSAs:
For a complete list of RADIUS attributes or more information about vendor-specific attribute 26, refer to the "RADIUS Attributes" appendix in the Cisco IOS Security Configuration Guide for Release 12.0.
Configuring the Switch for 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.
Beginning in privileged EXEC mode, follow these steps to specify a vendor-proprietary RADIUS server host and a shared secret text string:
To delete the vendor-proprietary RADIUS host, use the no radius-server host {hostname | ip-address} non-standard global configuration command. To disable the key, use the no radius-server key global configuration command.
This example shows how to specify a vendor-proprietary RADIUS host and to use a secret key of rad124 between the switch and the server:
Switch(config)# radius-server host 172.20.30.15 nonstandardSwitch(config)# radius-server key rad124Displaying the RADIUS Configuration
To display the RADIUS configuration, use the show running-config privileged EXEC command.
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.
Beginning in privileged EXEC mode, follow these steps to configure the switch for local AAA:
To disable AAA, use the no aaa new-model global configuration command. To disable authorization, use the no aaa authorization {network | exec} method1 global configuration command.
