Guest

Cisco Catalyst 3750 Metro Series Switches

Release Notes for the Catalyst 3750 Metro Switch, Cisco IOS Release 12.2(25)SEE and Later

  • Viewing Options

  • PDF (875.5 KB)
  • Feedback
Release Notes for the Catalyst 3750 Metro Switch Cisco IOS Release 12.2(25)SEE and Later

Table Of Contents

Release Notes for the Catalyst 3750 Metro Switch
Cisco IOS Release 12.2(25)SEE and Later

Contents

Hardware Supported

Upgrading the Switch Software

Finding the Software Version and Feature Set

Deciding Which Files to Use

Archiving Software Images

Upgrading a Switch by Using the CLI

Recovering from a Software Failure

Installation Notes

New Features

New Hardware Features

New Software Features

Minimum Cisco IOS Release for Major Features

Limitations and Restrictions

Configuration

Ethernet

Fallback Bridging

HSRP

IP

IP Telephony

MAC Addressing

MPLS and EoMPLS

Multicasting

QoS

Routing

SPAN and RSPAN

Trunking

Tunneling

VLAN

Important Notes

Open Caveats

Resolved Caveats

Caveats Resolved in Cisco IOS Release 12.2(25)SEE4

Caveats Resolved in Cisco IOS Release 12.2(25)SEE

Documentation Updates

Updates for the Software Configuration Guide

Link-State Tracking

Upgrading Devices with Cisco IOS Image Agent

Configuring IP Unicast Routing Chapter

Configuring DHCP Features and IP Source Guard Chapter

Configuring Port-Based Traffic Control Chapter

Configuring Network Security with ACLs Chapter

Configuring QoS Chapter

Supported MIBs Chapter

Updates for the Command Reference

ip dhcp snooping information option format remote-id

ip dhcp snooping vlan information option format-type circuit-id string

link state group

link state track

show link state group

Updates for the Hardware Installation Guide

Statement 361—VoIP and Emergency Calling Services do not Function if Power Fails

Related Documentation

Obtaining Documentation, Obtaining Support, and Security Guidelines


Release Notes for the Catalyst 3750 Metro Switch
Cisco IOS Release 12.2(25)SEE and Later


Revised June 10, 2008

Cisco IOS Release 12.2(25)SEE and 12.2(25)SEE4 run on all Catalyst 3750 Metro switches.

These release notes include important information about Cisco IOS Release 12.2(25)SEE, 12.2(25)SEE4, and any limitations, restrictions, and caveats that apply to the releases.

Verify that these release notes are correct for your switch:

If you are installing a new switch, see the Cisco IOS release label on the rear panel of your switch.

If your switch is on, use the show version privileged EXEC command. See the "Finding the Software Version and Feature Set" section.

If you are upgrading to a new release, see the software upgrade filename for the software version. See the "Deciding Which Files to Use" section.

For the complete list of switch documentation, see the "Related Documentation" section.

You can download the switch software from this site:

http://www.cisco.com/kobayashi/sw-center/sw-lan.shtml

This software release is part of a special release of Cisco IOS software that is not released on the same 8-week maintenance cycle that is used for other platforms. As maintenance releases and future software releases become available, they will be posted to Cisco.com in the Cisco IOS software area.

Cisco IOS Release 12.2(25)SEE is based on Cisco IOS Release 12.2(25)S. Open caveats in Cisco IOS Release 12.2(25)S also affect Cisco IOS Release 12.2(25)SEE, unless they are listed in the Cisco IOS Release 12.2(25)SEE resolved caveats list. The list of open caveats in Cisco IOS Release 12.2(25)S is available at this URL:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122relnt/122srn.htm#wp2367913

Contents

This information is in the release notes:

"Hardware Supported" section

"Upgrading the Switch Software" section

"Installation Notes" section

"New Features" section

"Minimum Cisco IOS Release for Major Features" section

"Limitations and Restrictions" section

"Important Notes" section

"Open Caveats" section

"Resolved Caveats" section

"Documentation Updates" section

"Related Documentation" section

"Obtaining Documentation, Obtaining Support, and Security Guidelines" section

Hardware Supported

Table 1 lists the supported hardware and the minimum Cisco IOS release required.

Table 1 Supported Hardware 

Switch
Description
Supported by Minimum Cisco IOS Release

Catalyst 3750 Metro 24-AC switch

24 10/100 Ethernet ports, 2 1000X standard SFP1 module slots, 2 1000X ES2 SFP slots, and field-replaceable AC power supply

Cisco IOS Release 12.1(14)AX

Catalyst 3750 Metro 24-DC switch

24 10/100 Ethernet ports, 2 1000X standard SFP module slots, 2 1000X ES SFP slots, and field-replaceable DC power supply

Cisco IOS Release 12.1(14)AX

SFP modules

1000BASE-T, 1000BASE-SX, and1000BASE-LX

1000BASE-ZX and CWDM3

100BASE-FX MMF4

1000BASE-BX

Cisco IOS Release 12.1(14)AX


Cisco IOS Release 12.1(14)AX1

Cisco IOS Release 12.2(25)EY

Cisco IOS Release 12.2(25)EY2

1 SFP = small form-factor pluggable

2 ES = enhanced services

3 CWDM = coarse wavelength-division multiplexer

4 MMF = multimode fiber


Upgrading the Switch Software

These are the procedures for downloading software:

"Finding the Software Version and Feature Set" section

"Deciding Which Files to Use" section

"Archiving Software Images" section

"Upgrading a Switch by Using the CLI" section

"Recovering from a Software Failure" section


Note Before downloading software, read this section for important information.


Finding the Software Version and Feature Set

The Cisco IOS image is stored as a bin file in a directory that is named with the Cisco IOS release. The image is stored on the system board flash device (flash:).

You can use the show version privileged EXEC command to see the software version that is running on your switch.

You can also use the dir filesystem: privileged EXEC command to see the directory names of other software images that you might have stored in flash memory.

Deciding Which Files to Use

The upgrade procedures in these release notes describe how to perform the upgrade by using a combined tar file. This file contains the Cisco IOS image file. To upgrade the switch through the command-line interface (CLI), use the tar file and the archive download-sw privileged EXEC command.

Table 2 lists the software filename for this software release.

Table 2 Cisco IOS Software Image Files for Catalyst 3750 Metro Switches 

Filename

Description

c3750me-i5-tar.122-25.SEE4.tar

Cisco IOS image tar file.
This image has Layer 2+ and Layer 3 features.

c3750me-i5k91-tar.122-25.SEE4.tar

Cisco IOS cryptographic image tar file.
This image has the Kerberos, SSH1 , SSL2 , Layer 2+, and Layer 3 features.

1 SSH = Secure Shell

2 SSL = Secure Socket Layer


Archiving Software Images

Before upgrading your switch software, make sure that you have archived copies of the current Cisco IOS release and the Cisco IOS release to which you are upgrading. You should keep these archived images until you have upgraded all devices in the network to the new Cisco IOS image and until you have verified that the new Cisco IOS image works properly in your network.

Cisco routinely removes old Cisco IOS versions from Cisco.com. See Product Bulletin 2863 for more information:

http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps5187/prod_bulletin0900aecd80281c0e.
Html

You can copy the bin software image file on the flash memory to the appropriate TFTP directory on a host by using the copy flash: tftp: privileged EXEC command.


Note Although you can copy any file on the flash memory to the TFTP server, it is time consuming to copy all of the HTML files in the tar file. We recommend that you download the tar file from Cisco.com and archive it on an internal host in your network.


You can also configure the switch as a TFTP server to copy files from one switch to another without using an external TFTP server by using the tftp-server global configuration command. For more information about the tftp-server command, see the "Basic File Transfer Services Commands" section of the Cisco IOS Configuration Fundamentals Command Reference, Release 12.2 at this URL:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/ffun_r/ffrprt2/frf011.htm#wp1018426

Upgrading a Switch by Using the CLI

This procedure is for copying the tar file to the switch. You copy the file to the switch from a TFTP server and extract the files. You can download an image file and replace or keep the current image.

Download the software from Cisco.com to your management station by following these steps:


Step 1 Use Table 2 to identify the file that you want to download.

Step 2 Download the software image file from Cisco.com.

Go to this URL and log in to download the appropriate files:

http://www.cisco.com/kobayashi/sw-center/sw -lan.shtml

To download the files, click the link for your switch platform, and then follow the links on the page to select the correct tar image file.

Step 3 Copy the image to the appropriate TFTP directory on the workstation, and make sure that the TFTP server is properly configured.

For more information, see Appendix B in the software configuration guide for this release.

Step 4 Log in to the switch through the console port or a Telnet session.

Step 5 Check your VLAN 1 configuration by using the show interfaces vlan 1 privileged EXEC command, and verify that VLAN 1 is part of the same network as the TFTP server. (Check the Internet address is line near the top of the display.)

Step 6 Download the image file from the TFTP server to the switch. If you are installing the same version of software that is currently on the switch, overwrite the current image by using this privileged EXEC command:

archive download-sw /overwrite /reload tftp:[[//location]/directory]/image-name.tar

The /overwrite option overwrites the software image in flash memory with the downloaded one.

The /reload option reloads the system after downloading the image unless the configuration has been changed and not been saved.

For //location, specify the IP address of the TFTP server.

For /directory/image-name.tar, specify the directory (optional) and the image to download. Directory and image names are case sensitive.

This example shows how to download an image from a TFTP server at 198.30.20.19 and to overwrite the image on the switch:

Switch# archive download-sw /overwrite tftp://198.30.20.19/c3750me-i5-tar.122-25.SEE.tar

You can also download the image file from the TFTP server to the switch and keep the current image by replacing the /overwrite option with the /leave-old-sw option.


Recovering from a Software Failure

Switch software can be corrupted during an upgrade, by downloading the wrong file to the switch, and by deleting the image file. In all of these cases, the switch does not pass the power-on self-test (POST), and there is no connectivity. You can use the Xmodem protocol to recover from these failures.

For detailed recovery procedures, see the "Troubleshooting" chapter in the software configuration guide for this release.

Installation Notes

You can assign IP information to your switch by using these methods:

The Express Setup program (See the Catalyst 3750 Metro Switch Hardware Installation Guide.)

The CLI-based setup program (See the Catalyst 3750 Metro Switch Hardware Installation Guide.)

The DHCP-based autoconfiguration (See the Catalyst 3750 Metro Switch Software Configuration Guide.)

Manually assigning an IP address (See the Catalyst 3750 Metro Switch Software Configuration Guide.)

New Features

These are the new supported hardware and the new software features provided this release:

"New Hardware Features" section

"New Software Features" section

New Hardware Features

For a list of all supported hardware, see the "Hardware Supported" section.

New Software Features

This release contains these new switch features (available in all software images):

Supports Flex Link preemptive switchovers allowing you to configure a Flex Link to complete a master switchover.

Support for the ip directed-broadcast interface configuration command. This command can be configured on a VPN routing/forwarding (VRF) interface so that directed broadcast traffic is routed only within the VRF.

Support for an option-82 enhancement that allows users to configure the remote-ID and circuit-ID suboptions.

Support for the CISCO-DHCP-SNOOPING-MIB that provides SNMP management support for the DHCP snooping feature.

Support for the CISCO-PORT-QOS-MIB that provides QoS statistics and per-port rate-limiting and traffic shaping.

Support for OSPF nonbroadcast and point-to-multipoint (broadcast and nonbroadcast) networks. The switch now supports all OSFP network types.

Support for CNS image agent for downloading a new image to a switch.

Minimum Cisco IOS Release for Major Features

Table 3 lists the minimum software release required to support the major features on the Catalyst 3750 Metro switch.


Note Features not included in the table are available in all releases. You can see a list of features from the first release at this URL:
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat3750m/12225ey/3750mscg
/swintro.htm


Table 3 Catalyst 3750 Metro Switch Features and the Minimum Cisco IOS Release Required 

Feature
Minimum Cisco IOS Release Required

DHCP Option-82 configurable remote Id and circuit ID

12.2(25)SEE

H-VPLS

12.2(25)SED

IEEE 802.1x restricted VLANs

12.2(25)SED

IEEE 802.1x accounting and MIBs (IEEE8021-PAE-MIB and CISCO-PAE-MIB)

12.2(25)EY

DHCP snooping with the option-82 information option

12.2(25)EY

DHCP snooping binding database configuration

12.2(25)EY

Dynamic ARP inspection

12.2(25)EY

EtherChannel guard

12.2(25)EY

Flex Links

12.2(25)EY

IGMPv3 snooping

12.2(25)EY

IGMP throttling

12.2(25)EY

IP source guard

12.2(25)EY

MultipleVPN Routing/Forwarding (Multi-VRF) CE

12.2(25)EY

Private VLAN

12.2(25)EY

SFP diagnostic management interface

12.2(25)EY

SSHv2 server application (cryptographic images only)

12.2(25)EY

SSL Version 3.0 for secure HTTP communication (cryptographic images only)

12.2(25)EY

Smartports macros

12.2(25)EY

Auto-QoS

12.2(25)EY

VLAN-based QoS and dual-level hierarchical policy maps on SVIs

12.2(25)EY

Matching the CoS of the inner tag for IEEE 802.1Q tunneling traffic.

12.2(25)EY

Applying hierarchical service policies in the inbound direction on an ES port.

12.2(25)EY

Storm control enhancements

12.2(25)EY

SFP diagnostic management interface

12.2(25)EY

Unicast MAC address filtering

12.2(25)EY

QoS egress priority queue

12.1(14)AX2

QoS DSCP transparency

12.1(14)AX2

Point-to-point Layer 2 protocol tunneling

12.1(14)AX1

Flex Link Preemptive Switchover

12.2(25)SEE

OSPF nonbroadcast and point-to-multipoint networks

12.2(25)SEE


Limitations and Restrictions

You should review this section before you begin working with the switch. These are known limitations that will not be fixed, and there is not always a workaround. Some features might not work as documented, and some features could be affected by recent changes to the switch hardware or software.

"Configuration" section

"Ethernet" section

"Fallback Bridging" section

"HSRP" section

"IP" section

"IP Telephony" section

"MAC Addressing" section

"MPLS and EoMPLS" section

"Multicasting" section

"QoS" section

"Routing" section

"SPAN and RSPAN" section

"Trunking" section

"Tunneling" section

"VLAN" section

Configuration

These are the configuration limitations:

A static IP address might be removed when the previously acquired DHCP IP address lease expires.

This problem occurs under these conditions:

When the switch is booted without a configuration (no config.text file in flash memory).

When the switch is connected to a DHCP server that is configured to give an address to it (the dynamic IP address is assigned to VLAN 1).

When an IP address is configured on VLAN 1 before the dynamic address lease assigned to VLAN 1 expires.

The workaround is to reconfigure the static IP address. (CSCea71176)

When the show interface privileged EXEC is entered on a port that is running IEEE 802.1Q, inconsistent statistics from ports running IEEE 802.1Q might be reported.

The workaround is to upgrade to Cisco IOS Release 12.2(25)EY. (CSCec35100)

When you change a port from a nonrouted port to a routed port or the reverse, the applied auto-QoS setting is not changed or updated when you verify it by using the show running interface or show mls qos interface user EXEC commands.

These are the workarounds:

1. Disable auto-QoS on the interface.

2. Change the routed port to a nonrouted port or the reverse.

3. Re-enable auto-QoS on the interface. (CSCec44169)

The DHCP snooping binding database is not written to flash or a remote file in any of these situations:

When the Network Time Protocol (NTP) is configured, but the NTP clock is not synchronized. You can check the clock status by entering the show NTP status privileged EXEC command and verifying that the network connection to the NTP server and peer work correctly.

The DHCP snooping database file is manually removed from the file system. After enabling the DHCP snooping database by configuring a database URL, a database file is created. If the file is removed manually from the file system, the DHCP snooping database does not create another database file. You need to disable the DHCP snooping database and enable it again to create the database file.

The URL for the configured DHCP snooping database was replaced because the original URL is not accessible. The new URL might not take effect after the timeout of the old URL.

No workaround is necessary; these are the designed behaviors. (CSCed50819)

When dynamic ARP inspection is enabled on a switch or switch stack, ARP and RARP packets greater than 2016 bytes are dropped by the switch or switch stack. This is a hardware limitation.

However, when dynamic ARP inspection is not enabled and jumbo MTU is configured, ARP and RARP packets are correctly bridged in hardware. (CSCed79734)

When connected to some third-party devices that send early preambles, a switch port operating at 100 Mbps full duplex or 100 Mbps half duplex might bounce the line protocol up and down. The problem is observed only when the switch is receiving frames.

The workaround is to configure the port for 10 Mbps and half duplex or to connect a hub or a nonaffected device to the switch. (CSCed39091)

Dynamic ARP inspection log entries might be lost after a switch failure. Any log entries that are still in the log buffer (have not been output as a system message) on a switch that fails will be lost.

When you enter the show ip arp inspection log privileged EXEC command, the log entries from all switches in the stack are moved to the switch on which the command was entered.

There is no workaround. (CSCed95822)

When port security is enabled on an interface in restricted mode and the switchport block unicast interface command has been entered for that interface, MAC addresses are incorrectly forwarded when they should be blocked.

The workaround is to enter the no switchport block unicast interface configuration command for that specific interface. (CSCee93822)

The Catalyst 3750 Metro switch does not learn its own MAC address on Layer 2 interfaces. For example: Ports 1/0/1 and 1/0/2 belong to VLAN x, port 1/0/3 is a Layer 3 port with an IP address that belongs to the subnet of VLAN x, and ports 1/0/2 and 1/0/3 are connected. In this case, a host connected to port 1/0/1 cannot ping port 1/0/3. The switch does not update the CAM table and does not use the MAC address of port 1/0/3 in the CAM table for port 1/0/2.

The workaround is to statically configure the MAC address of port 1/0/3 in the CAM table of the switch bound to port 1/0/2 by using the mac address-table static mac-addr vlan vlan-id interface fastethernet1/0/2 global configuration command. (CSCee87864)

A traceback error occurs if a crypto key is generated after an SSL client session.

There is no workaround. This is a cosmetic error and does not affect the functionality of the switch. (CSCef59331)

When ES interfaces in an EtherChannel are carrying Multiprotocol Label Switching (MPLS) traffic and more routes are configured than are supported in the SDM template, messages similar to the following might appear when the interface is shut down and brought back up:

2d20h: %PLATFORM_UCAST-3-LB: PI<->PD handles out of sync for Adj 222.1.1.1 LB -Traceback= 252620 A919CC A847E0 A85BE0 A927FC AA2D28 A965E0 A89C08 A78744 B08F48 ADF504 ADDC4C AE3460 AD25CC B94AA0 B94F20

There is no workaround. (CSCeh13477)

Ethernet

This is the Ethernet limitation:

SNAP-encapsulated IP packets are dropped without an error message being reported at the interface. The switch does not support SNAP-encapsulated IP packets. There is no workaround. (CSCdz89142)

Fallback Bridging

These are the fallback bridging limitations:

If a bridge group contains a VLAN that has a static MAC address configured, all non-IP traffic in the bridge group with this MAC address destination is sent to all ports in the bridge group.

The workaround is to remove the VLAN from the bridge group or to remove the static MAC address from the VLAN. (CSCdw81955)

Known unicast (secured addresses) are flooded within a bridge group under this condition: If secure addresses are learned or configured on a port and the VLAN on this port is part of a bridge group, non-IP traffic destined to the secure addresses is flooded within the bridge group.

The workaround is to disable fallback bridging. To remove an interface from a bridge group and to remove the bridge group, use the no bridge-group bridge-group interface configuration command. Another workaround is to disable port security on all ports in all VLANs participating in fallback bridging by using the no switchport port-security interface configuration command. (CSCdz80499)

HSRP

These are the Hot Standby Routing Protocol (HSRP) limitations:

When the active switch fails in a switch cluster that uses HSRP redundancy, the new active switch might not contain a full cluster member list.

The workaround is to ensure that the ports on the standby cluster members are not in the spanning-tree blocking state. To verify that these ports are not in the blocking state, see the "Configuring STP" chapter in the software configuration guide. (CSCec76893)

HSRP does not function on multiprotocol label switching (MPLS) interfaces.

There is no workaround. Do not configure HSRP on MPLS interfaces. (CSCeg76540)

IP

These are the IP limitations:

The switch does not create an adjacency table entry when the Address Resolution Protocol (ARP) timeout value is 15 seconds and the ARP request times out.

The workaround is to set an ARP timeout value higher than 120 seconds. (CSCea21674)

When the rate of received DHCP requests exceeds 2,000 packets per minute for a long time, the response time might be slow when you are using the console.

The workaround is to use rate limiting on DHCP traffic to prevent a denial of service attack from occurring. (CSCeb59166)

IP Telephony

These are the IP telephony limitations:

Some access point (AP)-350 devices are incorrectly discovered as IEEE 802.3af Class 1 devices. These APs should be discovered as Cisco pre-standard devices. The show power inline user EXEC command shows the AP-350 as an IEEE Class 1 device.

The workaround is to power the AP by using an AC wall adaptor. (CSCin69533)

After changing the access VLAN on a port that has IEEE 802.1x enabled, the IP phone address is removed. Because learning is restricted on IEEE 802.1x capable ports, it takes approximately 30 seconds before the address is relearned.

There is no workaround. (CSCea85312)

MAC Addressing

This is the MAC addressing limitation:

When a MAC address is configured for filtering on the internal VLAN of a routed port, incoming packets from the MAC address to the routed port are not dropped. (CSCeb67937)

MPLS and EoMPLS

These are the multiprotocol label switching (MPLS) and Ethernet over MPLS (EoMPLS) limitations:

Port-based Ethernet over Multiprotocol Label Switching (EoMPLS) sessions do not function if the incoming port is configured as an Inter-Switch Link (ISL) trunk.

The workaround is to configure the incoming ports as an IEEE 802.1Q trunk or as an access port. (CSCeb44014)

The display for the show mpls ldp neighbor ipaddr-of-neighbor detail user EXEC command always shows the targeted hello holdtime value as infinite.

The workaround is to use the show mpls ldp parameter user EXEC command to see the configured value. (CSCeb76775)

When MPLS is enabled, traceroute is not supported.

There is no workaround. (CSCec13655)

Multicasting

These are the multicasting limitations:

The switch does not support tunnel interfaces for unicast routed traffic. Only Distance Vector Multicast Routing Protocol (DVMRP) tunnel interfaces are supported for multicast routing.

Nonreverse-path forwarded (RPF) IP multicast traffic to a group that is bridged in a VLAN is leaked onto a trunk port in the VLAN even if the port is not a member of the VLAN group, but it is a member in some other VLAN group. Unnecessary traffic is sent on the trunk port and needlessly reduces the bandwidth of the port.

There is no workaround because non-RPF traffic is continuous in certain topologies. As long as the trunk port is a member on a trunk port in at least one VLAN, this problem for the non-RPF traffic occurs. (CSCdu25219)

If the number of multicast routes and Internet Group Management Protocol (IGMP) groups are more than the maximum number in the Switch Database Management (SDM) template shown with the show sdm prefer global configuration command, the traffic received on unknown groups is flooded in the received VLAN even though the show ip igmp snooping multicast-table privileged EXEC command output shows otherwise.

The workaround is to reduce the number of multicast routes and IGMP snooping groups to less than the maximum supported value. (CSCdy09008)

IGMP filtering is applied to packets that are forwarded through hardware. It is not applied to packets that are forwarded through software. Hence, with multicast routing enabled, the first few packets are sent from a port even when IGMP filtering is set to deny those groups on that port.

There is no workaround. (CSCdy82818)

When you use the ip access-group interface configuration command with a router access control list (ACL) to deny access to a group in a VLAN, multicast data to the group that is received in the VLAN is always flooded in the VLAN regardless of IGMP group membership in the VLAN. This provides access to directly connected clients, if any, in the VLAN.

The workaround is to not apply a router ACL configured to deny access to a VLAN interface. Apply the security through other means; for example, apply VLAN maps to the VLAN instead of using a router ACL for the group. (CSCdz86110)

(Catalyst 3750 switches) When IP Protocol-Independent Multicast (PIM) is enabled on a tunnel interface, the switch incorrectly displays the Multicast is not supported on tunnel interfaces error message. IP PIM is not supported on tunnel interfaces.

There is no workaround. (CSCeb75366)

If an IGMP report packet has two multicast group records, the switch removes or adds interfaces depending on the order of the records in the packet:

If the ALLOW_NEW_SOURCE record is before the BLOCK_OLD_SOURCE record, the switch removes the port from the group.

If the BLOCK_OLD_SOURCE record is before the ALLOW_NEW_SOURCE record, the switch adds the port to the group.

There is no workaround. (CSCec20128)

When IGMP snooping is disabled and you enter the switchport block multicast interface configuration command, IP multicast traffic is not blocked.

The switchport block multicast interface configuration command is only applicable to non-IP multicast traffic.

There is no workaround. (CSCee16865)

Incomplete multicast traffic can be seen under either of these conditions:

You disable and then re-enable IP multicast routing on an interface.

A switch mroute table temporarily runs out of resources and recovers later.

The workaround is to enter clear ip mroute privileged EXEC command on the interface. (CSCef42436)

When more multicast groups are configured than are supported by the selected Security Device Manager (SDM) template, Layer 2 multicast traffic is flooded on one or more multicast groups.

There is no workaround. (CSCef67261)

QoS

These are the QoS limitations:

Some switch queues are disabled if the buffer size or threshold level is set too low with the mls qos queue-set output global configuration command. The ratio of buffer size to threshold level should be greater than ten to avoid disabling the queue.

The workaround is to choose compatible buffer sizes and threshold levels. (CSCea76893)

When traffic with different class of service (CoS) values is sent into a IEEE 802.1Q tunnel, only the CoS 0 statistics increment in the show mls qos interface user EXEC command display.

There is no workaround. (CSCeb75230)

The bandwidth interface configuration command is not supported at the interface level, but it appears in the CLI.

There is no workaround. (CSCeb80223)

The random-detect interface configuration command is not supported at the interface level, but it appears in the CLI.

There is no workaround. (CSCeb80300)

The display for the show policy-map interface user EXEC command shows zeros for the counters associated with class-map match criteria.

There is no workaround. (CSCec08205)

The priority policy-map class configuration command cannot be configured for the default traffic class in a policy map.

The workaround is to configure explicit matches for traffic that requires priority treatment. (CSCec38901)

Modifying a QoS class within a very large service policy that is attached to an ES port can cause high CPU utilization and an unresponsive CLI for an excessive period of time.

The workaround is to detach the service policy from the port while making the modifications and then to re-attach the service policy. (CSCec75945)

When packets are queued for egress on an ES port due to the application of a QoS service policy, they consume packet buffer memory on the switch. If many queues are simultaneously congested and are unable to drain, packet loss can occur in either direction (ingress or egress) due to the lack of buffer memory.

If this becomes a problem, you can change switch behavior by using the queue-limit policy-map class configuration command at the class level to set shorter queue depths. Each shaper has an associated buffer queue with a default depth of 128 packets.

For example:

Switch(config)# policy-map cos2-policy
Switch(config-pmap)# class cos2
Switch(config-pmap-c)# bandwidth 50000
Switch(config-pmap-c)# queue-limit 32

The point at which buffer memory is exhausted depends on the number of queues, the sizes of the queued packets, and whether or not the traffic pattern being sent to the switch allows the queues to drain at all.

Upgrading your switch to Cisco IOS Release 12.2(25)EY greatly reduces the possibility of this situation happening, although it can still occur with some configurations and traffic patterns. (CSCed83886)

When auto-QoS is enabled on the switch, priority queuing is not enabled. Instead, the switch uses shaped round robin (SRR) as the queuing mechanism. The auto-QoS feature is designed on each platform based on the feature set and hardware limitations, and the queuing mechanism supported on each platform might be different.

There is no workaround. (CSCee22591)

Routing

These are the routing limitations:

The switch does not support tunnel interfaces for unicast routed traffic. Only Distance Vector Multicast Routing Protocol (DVMRP) tunnel interfaces are supported for multicast routing.

A route map that contains an ACL with a DSCP clause cannot be applied to a Layer 3 interface. The switch rejects this configuration and issues an error message that shows that the route map is unsupported.

There is no workaround. (CSCea52915)

A spanning-tree loop might occur if all of these conditions are true:

Port security is enabled with the violation mode set to protected.

The maximum number of secure addresses is less than the number of switches connected to the port.

There is a physical loop in the network through a switch whose MAC address has not been secured, and its BPDUs cause a secure violation.

The workaround is to change any one of the listed conditions. (CSCed53633)

SPAN and RSPAN

These are the SPAN and Remote SPAN (RSPAN) limitations:

An egress SPAN copy of routed unicast traffic might show an incorrect destination MAC address on both local and remote SPAN sessions. This limitation does not apply to bridged packets. The workaround for local SPAN is to use the replicate option. There is no workaround for a remote SPAN session. This is a hardware limitation. (CSCdy72835)

Egress SPAN routed packets (both unicast and multicast) show the incorrect source MAC address. For remote SPAN packets, the source MAC address should be the MAC address of the egress VLAN, but instead the packet shows the MAC address of the remote SPAN (RSPAN) VLAN. For local SPAN packets with native encapsulation on the destination port, the packet shows the MAC address of VLAN 1. This problem does not appear with local SPAN when the encapsulation replicate option is used and does not apply to bridged packets.

The workaround is to use the encapsulate replicate keywords in the monitor session global configuration command. This is a hardware limitation. (CSCdy81521)

During periods of very high traffic and when two RSPAN source sessions are configured, the VLAN ID of packets in one RSPAN session might overwrite the VLAN ID of the other RSPAN session. Packets intended for one RSPAN VLAN are incorrectly sent to the other RSPAN VLAN. This problem does not affect RSPAN destination sessions.

The workaround is to configure only one RSPAN source session. (CSCea72326)

The egress-SPAN data rate might degrade when fallback bridging or multicast routing is enabled. The amount of degradation depends on the processor loading. Typically, the switch can process egress-SPAN at up to 40,000 packets per second (64-byte packets). When the total traffic being monitored is below this limit, there is no degradation. However, if the traffic exceeds the limit, only a portion of the source stream is monitored. When this occurs, this console message appears: Decreased egress SPAN rate.

In all cases, normal traffic is not affected; the degradation limits only how much of the original source stream can be monitored. If fallback bridging and multicast routing are disabled, egress-SPAN monitoring is not degraded.

There is no workaround. If possible, disable fallback bridging and multicast routing. If possible, use ingress-SPAN to observe the same traffic. (CSCeb01216)

Some IGMP report and query packets with IP options might not be ingress-span monitored. Packets that are susceptible to this problem are IGMP packets with 4 bytes of IP options (IP header length of 24). Examples of such packets are IGMP reports and queries having the router alert IP option. Ingress-span monitoring of such packets is not accurate and can vary with traffic rate. Typically, very few or none of these packets are monitored.

There is no workaround. (CSCeb23352)

Cisco Discovery Protocol (CDP), VLAN Trunking Protocol (VTP), and Port Aggregation Protocol (PAgP) packets received from a SPAN source are not sent to the destination interfaces of a local SPAN session.

The workaround is to use the monitor session session_number destination {interface interface-id encapsulation replicate} global configuration command for a local SPAN session. (CSCed24036)

Trunking

These are the trunking limitations:

The switch treats frames received with mixed encapsulation (IEEE 802.1Q and Inter-Switch Link [ISL]) as frames with FCS errors, increments the error counters, and causes the port LED to blink amber. This happens when an ISL-unaware device receives an ISL-encapsulated packet and forwards the frame to an IEEE 802.1Q trunk interface.

There is no workaround. (CSCdz33708)

IP traffic with IP options set is sometimes leaked on a trunk port. For example, a trunk port is a member of an IP multicast group in VLAN X but is not a member in VLAN Y. If VLAN Y is the output interface for the multicast route entry assigned to the multicast group and an interface in VLAN Y belongs to the same multicast group, the IP-option traffic received on an input VLAN interface other than one in VLAN Y is sent on the trunk port in VLAN Y. This is because the trunk port is forwarding in VLAN Y, even though the port has no group membership in VLAN Y.

There is no workaround. (CSCdz42909)

For trunk ports or access ports configured with IEEE 802.1Q tagging, inconsistent statistics might appear in the show interfaces counters privileged EXEC command output. Valid IEEE 802.1Q frames of 64 to 66 bytes are correctly forwarded even though the port LED blinks amber, and the frames are not counted on the interface statistics.

There is no workaround. (CSCec35100).

When a trunk interface is converted to an IEEE 802.1Q tunnel, a traceback error message similar to the following might appear:

3d20h: %PLATFORM_UCAST-3-LB: PI<->PD handles out of sync for Adj 222.1.1.1 LB -Traceback= 252620 A9204C A84E60 A86260 A92E7C AA36A0 AA3520 A96C60 A8A288 A78DC4 B095C8

There is no workaround. This does not affect switch functionality. (CSCeh20081)

Tunneling

This is the tunneling limitation:

VLAN mappings can be configured on a per-interface basis. A different set of mappings can be configured on each ES interface. The per-interface VLAN mappings remain in effect even when the ES ports are bundled in an EtherChannel. For example, if you map Gigabit Ethernet 1/1/1 to VLAN 20 through VLAN 50 and Gigabit Ethernet 1/1/2 to VLAN 20 through VLAN 70, traffic on VLAN 20 leaving the switch through the ES port bundle should be load-balanced across the individual ES interfaces. However, some of that traffic is incorrectly translated to VLAN 50, and some is incorrectly translated to VLAN 70.

The workaround is to configure identical VLAN mappings on both ES ports if they are going to be bundled into an EtherChannel. (CSCec49520)

VLAN

These are the VLAN limitations:

If the number of VLANs times the number of trunk ports exceeds the recommended limit of 13,000, the switch can halt.

The workaround is to reduce the number of VLANs or trunks. (CSCeb31087)

A CPUHOG message sometimes appears when you configure a private VLAN. Enable port security on one or more of the ports affected by the private VLAN configuration.

There is no workaround. (CSCed71422)

When you apply a per-VLAN QoS per-port policer policy-map to a VLAN SVI, the second-level (child) policy-map in use cannot be re-used by another policy-map.

The workaround is to define another policy-map name for the second-level policy-map with the same configuration to be used for another policy-map. (CSCef47377)

Important Notes

These are the important notes related to this software release:

The behavior of the no logging on global configuration command changed in Cisco IOS Release 12.2(25)EY and later. In software releases earlier than Cisco IOS Release 12.2(25)EY, both of these command pairs disabled logging to the console:

the no logging on and then the no logging console global configuration commands

the logging on and then the no logging console global configuration commands

In Cisco IOS Release 12.2(18)SE and later, you can only use the logging on and then the no logging console global configuration commands to disable logging to the console. (CSCec71490)

Beginning with Cisco IOS Release 12.2(25)EY, ISL encapsulation is supported only on standard ports and not on enhanced services (ES) ports. The ES ports support only IEEE 802.1Q encapsulation and the switchport trunk encapsulation interface configuration command is no longer visible on these ports. When you are upgrading a switch from Cisco IOS Release 12.1(14)AX to Cisco IOS Release 12.2(25)EY or later, during the initial configuration process, the switchport trunk encapsulation option is rejected on ES ports and an error message appears. You can ignore this error message. If you save the new configuration by using the copy running-config startup-config privileged EXEC command and later re-install the Cisco IOS Release 12.1(14)AX image, the trunk encapsulation method originally configured on ES ports is lost and the ES ports use the default encapsulation method, which is to negotiate.

In Cisco IOS Release 12.1(14)AX and earlier, port-based EoMPLS sessions could only be configured on switch ports. In Cisco IOS Release 12.2(25)EY and later, port-based EoMPLS sessions can only be configured on routed ports.


Note This change is handled automatically during an upgrade to Cisco IOS 12.2(25)EY or later, but if a configuration is written to NVRAM and the switch is then reloaded with Cisco IOS 12.1(14)AX, the new-style configuration is lost.


Beginning with Cisco IOS Release 12.2(25)EY, you must specify the encapsulation type when using the xconnect interface configuration command.


Note This change is handled automatically during an upgrade to Cisco IOS 12.2(25)EY or later, but if a configuration is written to NVRAM and the switch is then reloaded with Cisco IOS 12.1(14)AX, the new-style configuration is lost.


In Cisco IOS Release 12.1(14)AX1, the switch supported point-to-point Layer 2 protocol tunneling, which was not documented in the Cisco IOS Release 12.1(14)AX software documentation. This information is in the Release Notes for the Catalyst 3750 Metro Switch, Cisco IOS Release 12.1(14) AX1 at this URL:

http://www.cisco.com/univercd/cc/td/doc/product/lan/cat3750m/12114ax/ol464602.htm#wp44273

This information is part of Chapter 26, "Configuring QoS." For the complete chapter (minus these updates), go to this URL:

http://www.cisco.com/univercd/cc/td/doc/product/lan/cat3750m/12114ax/3750mscg/swqos.htm

Open Caveats

These are the Cisco IOS severity-3 open configuration caveats with possible unexpected activity in this software release:

CSCea80105

When an IP phone is connected to the switch, the port VLAN ID (PVID) and the voice VLAN ID (VVID) both learn its MAC address. However, after dynamic MAC addresses are deleted, only VVID relearns the IP phone MAC address. MAC addresses are deleted manually or automatically for a topology change or when port security or an IEEE 802.1x feature is enabled or disabled.

There is no workaround.

CSCed84163

When configured for a Voice VLAN, the phone sends untagged Cisco Discovery Protocol (CDP) packets and tagged voice packets. All frames from any devices connected to the Cisco IP Phone are sent tagged with the access VLAN ID. Catalyst 2970, 3560, and 3750 switches do not populate the secure address-table with the source MAC address from CDP packets.

The workaround when using Cisco IP Phones with the fix for CSCed84163 and port-security configured on the switchport is to configure switches with one secure address for the phone, plus additional MAC addresses for any devices connected to the Cisco IP Phone.

CSCeg36369

A Catalyst ME 3750 running Release 12.1(14)AX2 does not learn the source MAC address of a Cisco Discovery Protocol (CDP) frame when CDP is disabled on the port.

There is no workaround.

CSCei63394

When an IEEE 802.1x restricted VLAN is configured on a port and a hub with multiple devices is connected to that port, no syslog messages are generated.

This is not a supported configuration. Only one host should be connected to an IEEE 802.1x restricted VLAN port.

CSCei80087

When configuring a hierarchical policy map, changes to the match criteria of the VLAN level class-map do not take effect until the policy map is detached and reapplied.

The workaround is to detach the policy map from the interface, make the VLAN-level changes, and reapply the policy map.

CSCsb56438

There is an extra index in the port table of the ciscoStpExtensions MIB that does not exist in the portCrossIndex MIB. For example, extra indexes like 1000-16/40 are seen in stpxRootGuardConfigEnabled displays that do not exist in portCrossIndex, and they appear during an SNMP walk operation.

There is no workaround.

CSCsb60164

When a stack master fails or leaves the stack, a cross-stack EtherChannel in trunk mode running Link Aggregation Control Protocol (LACP) protocol might stop forwarding traffic on some VLANs.

The workaround is to enable the stack-mac persistent feature by using the stack-mac persistent timer global configuration command. You can also use the shutdown interface configuration command and then the no shutdown command on the EtherChannel interface.

CSCsb79198

During IEEE 802.1x authentication, a RADIUS server might download a per-user IP address access control list (ACL) or a MAC address ACL that is applied to the interface as part of the Access-Accept message. If the ACL is too large, the switch might not be able to apply it, and authentication fails and starts over.

The workaround is to reduce the size of the per-user ACL access control entries (ACEs) to less than 20 if ACLs are downloaded as part of IEEE 802.1x authorization.

CSCsb79318

If the re-authentication timer and re-authentication action is downloaded from the RADIUS server using the Session-Timeout and Termination-Action RADIUS attributes, the switch performs the termination action even when the port is not configured with the dot1x timeout reauth server global configuration command and uses the Termination-Action downloaded from a RADIUS server as part of IEEE 802.1x authorization.

The workaround is to remove the Termination-Action attribute from the IEEE 802.1x policy on the RADIUS server if dot1x timeout reauth server is not configured on the port.

CSCsb81283

MAC address notification traps do not work when port security is enabled on the interface.

The workaround is to disable port security on the interface.

CSCsb82422

The switch does not forward an IEEE802.1x request that has null credentials.

There is no workaround.

CSCsb97854

When a source port for a SPAN session has IEEE 802.1x enabled, Extensible Authentication Protocol over LAN (EAPOL) packets are not visible to the packet sniffing tool.

The workaround is to enable a voice VLAN on the SPAN source port.

CSCsc93768

The switch fails when the VPN Routing and Forwarding (VRF) configuration is removed under these conditions:

VRF is removed by using the no ip vrf global configuration command.

Interfaces are configured in two or more VRFs.

One VRF has static address resolution protocols (ARPs) configured.

The VRF with static ARPs is removed first.

The failure occurs when the second VRF is removed.

The workaround is to remove the static ARP entries configured on a VRF prior to deleting it.

Resolved Caveats

These sections describe the caveats that have been resolved in these releases:

Caveats Resolved in Cisco IOS Release 12.2(25)SEE4

Caveats Resolved in Cisco IOS Release 12.2(25)SEE

Caveats Resolved in Cisco IOS Release 12.2(25)SEE4

These caveats are resolved in Cisco IOS Release 12.2(25)SEE4:

CSCsf04754

Multiple Cisco products contain either of two authentication vulnerabilities in the Simple Network Management Protocol version 3 (SNMPv3) feature. These vulnerabilities can be exploited when processing a malformed SNMPv3 message. These vulnerabilities could allow the disclosure of network information or may enable an attacker to perform configuration changes to vulnerable devices. The SNMP server is an optional service that is disabled by default. Only SNMPv3 is impacted by these vulnerabilities. Workarounds are available for mitigating the impact of the vulnerabilities described in this document.

The United States Computer Emergency Response Team (US-CERT) has assigned Vulnerability Note VU#878044 to these vulnerabilities.

Common Vulnerabilities and Exposures (CVE) identifier CVE-2008-0960 has been assigned to these vulnerabilities.

This advisory will be posted at http://www.cisco.com/warp/public/707/cisco-sa-20080610-snmpv3.shtml

CSCsj39211

The switch no longer incorrectly overwrites the class of service (CoS) packets of internally generated Multicast Listener Discovery (MLD) queries and other control packets.

CSCsh89429

The switch no longer reloads when the write core privileged EXEC command is entered when testing a core dump configuration and FTP is selected as the file transfer protocol.

CSCsd00028

When OSPF SNMP is enabled on the switch, this message no longer appears on the console:

%ALIGN-3-SPURIOUS: Spurious memory access made at xxx reading yyy

Caveats Resolved in Cisco IOS Release 12.2(25)SEE

These caveats were resolved in Cisco IOS Release 12.2(25)SEE:

CSCeg09032

Open Shortest Path First (OSPF) routes now appear in the routing table after a topology change when Incremental SPF (iSPF) is enabled.

CSCeg44446

Policy-based routing (PBR) for IP Version 4 (IPv4) traffic is available when you run IPv4 and IPv6 traffic on the switch because the Dual IPv4-IPv6 Switch Database Management (SDM) templates now have resource provisions for PBR.

CSCei35702

The cross-stack UplinkFast feature is no longer delayed by 30 seconds when all the interfaces on the root switch are configured with the no shutdown interface configuration command.

CSCin33082

Configuring static IP routes with new distance values no longer causes routes to disappear from the routing table.

CSCsb62432

If two VLANs are configured on the same switch (for example, VLAN 1 and VLAN 2) with an SVI configured in VLAN 1 and an external bridging device connected to the switch, traffic sent from VLAN 2 to the SVI in VLAN 1 is no longer dropped.

CSCsb87895

The hierarchical per-VLAN policy-map police action now works correctly when a child policy-map is not configured in the first class-map.

Documentation Updates

This section provides these updates to the product documentation:

"Updates for the Software Configuration Guide" section

"Updates for the Command Reference" section

"Updates for the Hardware Installation Guide" section

Updates for the Software Configuration Guide

These are the documentation updates for the software configuration guides for this release:

Link-State Tracking

Upgrading Devices with Cisco IOS Image Agent

Configuring IP Unicast Routing Chapter

Configuring DHCP Features and IP Source Guard Chapter

Configuring Port-Based Traffic Control Chapter

Configuring QoS Chapter

Supported MIBs Chapter

Link-State Tracking

In the "Overview" chapter, this information will be added in the "Redundancy" section:

In Cisco IOS Release 12.2(25)SEE or later, link-state tracking mirrors the state of the ports that carry upstream traffic from connected hosts, servers, and other downstream devices. This feature allows the failover of the downstream traffic traffic to an operational link on another Cisco Ethernet switch.

Understanding Link-State Tracking

Beginning with Cisco IOS Release 12.2(25)SEE, link-state tracking, also known as trunk failover, is a feature that binds the link state of multiple interfaces. For example, link-state tracking provides redundancy in the network when used with Flex Links. If the link is lost on the primary interface, connectivity is transparently switched to the secondary interface.

As shown in Figure 1, Catalyst 3750 Metro switches are used as user-facing provider edge (UPE) switches in a customer site at the edge of the provider network connected to a customer premises equipment (CPE) switch. The UPE switches are connected to the provider edge (PE) switches in the service provider (SP) network. Customer devices, such as clients, connected to the CPE switch have multiple connections to the SP network. This configuration ensures that the traffic flow is balanced from the customer site to the SP and the reverse. Ports connected to the CPE are referred to as downstream ports, and ports connected to PE switches are referred to as upstream ports.

UPE switch A provides links to the CPE through link-state group 1. Port 1 and port 2 are connected to the CPE. Port 3 and port 4 are connected to PE switch A through link-state group 1.

UPE switch B provides links to the CPE through link-state group 2. Port 1 and port 2 are connected to CPE. Port 3 and 4 are connected to PE switch A through link-state group 2.

When you enable link-state tracking on the switch, the link state of the downstream ports is bound to the link state of one or more of the upstream ports. After you associate a set of downstream ports to a set of upstream ports, if all of the upstream ports become unavailable, link-state tracking automatically puts the associated downstream ports in an error-disabled state. This causes the CPE primary interface to failover to the secondary interface.

If the PE switch fails, the cables are disconnected, or the link is lost, the upstream interfaces can lose connectivity. When link-state tracking is not enabled and the upstream interfaces lose connectivity, the link state of the downstream interfaces remain unchanged. The CPE is not aware that upstream connectivity has been lost and does not failover to the secondary interface.

An interface can be an aggregation of ports (an EtherChannel), a single physical port in access or trunk mode, or routed ports. These interfaces can be bundled together, and each downstream interface can be associated with a single group consisting of multiple upstream interfaces, referred to as a link-state group.

The link state of the downstream interfaces is dependent on the link state of the upstream interfaces in the associated link-state group. If all of the upstream interfaces in a link-state group are in a link-down state, the associated downstream interfaces are forced into a link-down state. If any one of the upstream interfaces in the link-state group is in a link-up state, the associated downstream interfaces are allowed to change to, or remain in, a link-up state.

For example, in Figure 1, downstream interfaces 1 and 2 on UPE switch A are defined in link-state group 1 with upstream interfaces 3 and 4. Similarly, downstream interfaces 1 and 2 on UPE switch B are defined in link-state group 2 with upstream interfaces 3 and 4.

If the link is lost on upstream interface 3, the link state of downstream interfaces 1 and 2 does not change. If upstream interface 4 also loses link, downstream interfaces 1 and 2 go into a link-down state. The CPE switch stops forwarding traffic to PE switch A and starts to forward traffic to PE switch B.

You can recover a downstream interface link-down condition by removing the failed downstream port from the link-state group. You can also enable one of the upstream interfaces in the group to change to the link-up state. To recover multiple downstream interfaces, disable the link-state group.

Figure 1 Typical Link-State Tracking Configuration

Configuring Link-State Tracking

These sections describe how to configure link-state tracking ports:

Default Link-State Tracking Configuration

Layer 2 Trunk Failover Configuration Guidelines

Configuring Link-State Tracking

Default Link-State Tracking Configuration

There are no link-state groups defined, and link-state tracking is not enabled for any group.

Link-State Tracking Configuration Guidelines

Follow these guidelines to avoid configuration problems:

An interface that is defined as an upstream interface cannot also be defined as a downstream interface in the same or a different link-state group. The reverse is also true.

An interface cannot be a member of more than one link-state group.

You can configure only ten link-state groups per switch.

Configuring Link-State Tracking

Beginning in privileged EXEC mode, follow these steps to configure a link-state group and to assign an interface to a group:

 
Command
Purpose

Step 1 

configure terminal

Enter global configuration mode.

Step 2 

link state track number

Create a link-state group, and enable link-state tracking. The group number can be 1 to 10; the default is 1.

Step 3 

interface interface-id

Specify a physical interface or range of interfaces to configure, and enter interface configuration mode.

Valid interfaces include switch ports in access or trunk mode (IEEE 802.1q), routed ports, or multiple ports bundled into an EtherChannel interface (static or LACP) in trunk mode.

Step 4 

link state group [number] {upstream | downstream}

Specify a link-state group, and configure the interface as either an upstream or downstream interface in the group. The group number can be 1 to 10; the default is 1.

Step 5 

end

Return to privileged EXEC mode.

Step 6 

show running-config

Verify your entries.

Step 7 

copy running-config startup-config

(Optional) Save your entries in the configuration file.

This example shows how to create a link-state group and configure the interfaces:

Switch# configure terminal 
Switch(config)# link state track 1
Switch(config)# interface range fastethernet1//0/9 -10 
Switch(config-if)# link state group 1 upstream
Switch(config-if)# interface fastethernet1//0/1 
Switch(config-if)# link state group 1 downstream
Switch(config-if)# interface fastethernet1//0/3 
Switch(config-if)# link state group 1 downstream
Switch(config-if)# interface fastethernet1//0/5 
Switch(config-if)# link state group 1 downstream
Switch(config-if)# end

To disable a link-state group, use the no link state track number global configuration command.

Displaying Link-State Tracking Status

Use the show link state group command to display the link-state group information. Enter this command without keywords to display information about all link-state groups. Enter the group number to display information specific to the group. Enter the detail keyword to display detailed information about the group.

This is an example of output from the show link state group 1 command:

Switch> show link state group 1

Link State Group: 1      Status: Enabled, Down

This is an example of output from the show link state group detail command:

Switch> show link state group detail

(Up):Interface up   (Dwn):Interface Down   (Dis):Interface disabled

Link State Group: 1 Status: Enabled, Down 
Upstream Interfaces : Fa1/0/15(Dwn) Fa1/0/16(Dwn) 
Downstream Interfaces : Fa1/0/11(Dis) Fa1/0/12(Dis) Fa1/0/13(Dis) Fa1/0/14(Dis)

Link State Group: 2 Status: Enabled, Down 
Upstream Interfaces : Fa1/0/15(Dwn) Fa1/0/16(Dwn) Fa1/0/17(Dwn) 
Downstream Interfaces : Fa1/0/11(Dis) Fa1/0/12(Dis) Fa1/0/13(Dis) Fa1/0/14(Dis)

(Up):Interface up (Dwn):Interface Down (Dis):Interface disabled

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

Upgrading Devices with Cisco IOS Image Agent

Administrators maintaining large networks of Cisco IOS devices need an automated mechanism to load image files onto large numbers of remote devices. Existing network management applications are useful to determine which images to run and how to manage images received from the Cisco online software center. Other image distribution solutions do not scale to cover thousands of devices and cannot distribute images to devices behind a firewall or using Network Address Translation (NAT). The CNS image agent enables the managed device to initiate a network connection and request an image download allowing devices using NAT, or behind firewalls, to access the image server.

You can use image agent to download one or more devices. The switches must have the image agent running on them.

Prerequisites for the CNS Image Agent

Confirm these prerequisites before upgrading one or more devices with image agent:

Determine where to store the Cisco IOS images on a file server to make the image available to the other networking devices. If the CNS Event Bus is to be used to store and distribute the images, the CNS event agent must be configured.

Set up a file server to enable the networking devices to download the new images using the HTTPS protocol.

Determine how to handle error messages generated by image agent operations. Error messages can be sent to the CNS Event Bus or an HTTP or HTTPS URL.

Restrictions for the CNS Image Agent

During automated image loading operations you must try to prevent the Cisco IOS device from losing connectivity with the file server that is providing the image. Image reloading is subject to memory issues and connection issues. Boot options must also be configured to allow the Cisco IOS device to boot another image if the first image reload fails.

These other restrictions apply to the image agent running on a the switch:

You can only download the tar image file. Downloading the bin image file is not supported.

Only the immediate download option is supported. You cannot schedule a download to occur at a specified date and time.

The Destination field in the Associate Image with Device window is not supported.

For more details, see your CNS IE2100 documentation and see the "File Management" section of the Cisco IOS Configuration Fundamentals Configuration Guide, Release 12.2.

Beginning in privileged EXEC mode, follow these steps to initiate the image agent to check for a new image and upgrade a device:

 
Command
Purpose

Step 1 

configure terminal

Enter global configuration mode

Step 2 

ip host {ip-address} {hostname}

Enter the IP address and the hostname of the event gateway.

Step 3 

cns trusted-server all-agents {hostname}

Specify a trusted server for CNS agent.

Step 4 

no cns aaa enable cns event {ip-address} {port number}

Disable AAA authentication on the event gateway.

Step 5 

cns image retry {number}

Specify the number of times to retry and download the image.

Step 6 

cns image server {ip-address} status {ip-address}

Download the image from the server to the switch.

Step 7 

end

Return to privileged EXEC mode.


Note This example shows how to upgrade a switch from a server with the address of 172.20.249.20:


Switch(config)> configure terminal
Switch(config)# ip host cns-dsbu.cisco.com 172.20.249.20 
Switch(config)# cns trusted-server all-agents cns-dsbu.cisco.com 
Switch(config)# no cns aaa enable cns event 172.20.249.20 22022 
Switch(config)# cns image retry 1 
Switch(config)# cns image server http://172.20.249.20:80/cns/HttpMsgDispatcher status 
http://172.20.249.20:80/cns/HttpMsgDispatcher
Switch(config)#end

You can check the status of the image download by using the show cns image status user EXEC command.

Configuring IP Unicast Routing Chapter

Configuring OSPF Network Types


Note OSPF classifies different media into broadcast, nonbroadcast multiaccess (NBMA), or point-to-point networks. Broadcast and nonbroadcast networks can also be configured as point-to-multipoint networks. Starting with Cisco IOS release 12.2(25) SEE, the switch supports all these network types.


OSPF classifies different media into the three types of networks by default:

Broadcast networks (Ethernet, Token Ring, and FDDI)

Nonbroadcast multiaccess (NBMA) networks (Switched Multimegabit Data Service [SMDS], Frame Relay, and X.25)

Point-to-point networks (High-Level Data Link Control [HDLC], PPP)

You can also configure network interfaces as either a broadcast or an NBMA network and as point-to point or point-to-multipoint, regardless of the default media type.

Configuring OSPF for Nonbroadcast Networks

Because many routers might be attached to an OSPF network, a designated router is selected for the network. If broadcast capability is not configured in the network, the designated router selection requires special configuration parameters. You need to configure these parameters only for devices that are eligible to become the designated router or backup designated router (in other words, routers with a nonzero router priority value).

Beginning in privileged EXEC mode, follow these steps to configure routers that interconnect to nonbroadcast networks:

 
Command
Purpose

Step 1 

configure terminal

Enter global configuration mode.

Step 2 

router ospf process-id

Configure an OSPF routing process and enter router configuration mode.

Step 3 

neighbor ip-address [priority number] [poll-interval seconds]

Specify an OSPF neighbor with neighbor parameters as required.

ip-address—Enter the interface IP address of the OSPF neighbor.

(Optional) priority number—Specify the router priority value of the nonbroadcast neighbor associated with the IP address. The range is 0 to 255; the default is 0.

(Optional) poll-interval seconds—Specify a number that represents the poll interval time (in seconds). This value should be much larger than the hello interval. The range is 0-4294967295; the default is 120 seconds (2 minutes).

Step 4 

end

Return to privileged EXEC mode.

Step 5 

show ip ospf [process-id]

Display OSPF-related information.

Step 6 

copy running-config startup-config

(Optional) Save your entries in the configuration file.

On point-to-multipoint, nonbroadcast networks, you then use the neighbor router configuration command to identify neighbors. Assigning a cost to a neighbor is optional.

Configuring Network Types for OSPF Interfaces

You can configure network interfaces as either broadcast or NBMA and as point-to point or point-to-multipoint, regardless of the default media type.

An OSPF point-to-multipoint interface is defined as a numbered point-to-point interface with one or more neighbors. On point-to-multipoint broadcast networks, specifying neighbors is optional. When you configure an interface as point-to-multipoint when the media does not support broadcast, you should use the neighbor command to identify neighbors.

Beginning in privileged EXEC mode, follow these steps to configure OSPF network type for an interface:

 
Command
Purpose

Step 1 

configure terminal

Enter global configuration mode.

Step 2 

interface interface-id

Enter interface configuration mode, and specify the Layer 3 interface to configure.

Step 3 

ip ospf network {broadcast | non-broadcast | {point-to-multipoint [non-broadcast] | point-to-point}}

Configure the OSFP network type for the specified interface. Select one of these network types:

broadcast—Specify an OSPF broadcast multi-access network.

non-broadcast—Specify an OSPF NBMA network.

point-to-multipoint—Specify an OSPF point-to-multipoint network. If you do not enter another keyword, the interface is point-to-point for broadcast media.

point-to-multipoint non-broadcast—Specify an OSPF nonbroadcast point-to-multipoint network.

point-to-point—Specify an OSPF point-to-point network.

Step 4 

exit

Return to global configuration mode.

Step 5 

router ospf process-id

(Optional for point-to-multipoint; required for point-to-multipoint nonbroadcast) Configure an OSPF routing process and enter router configuration mode.

Step 6 

neighbor ip-address cost number

(Optional for point-to-multipoint; required for point-to-multipoint nonbroadcast). Specify a configured OSPF neighbor and assign a cost to the neighbor.

ip-address—Enter the interface IP address of the OSPF neighbor.

cost number—Specify a cost for the neighbor as an integer from 1 to 65535.

Note On point-to-multipoint broadcast networks, specifying a neighbor is optional, but if you do specify a neighbor, you must specify a cost for that neighbor.
On point-to-multipoint nonbroadcast neighbors, you must specify a neighbor, but assigning a cost to the neighbor is optional. If not specified, neighbors assume the cost of the interface, based on the ip ospf cost interface configuration command.

Step 7 

end

Return to privileged EXEC mode.

Step 8 

show ip ospf interface [interface-id]

Display OSPF-related interface information.

Step 9 

copy running-config startup-config

(Optional) Save your entries in the configuration file.

Use the no form of the ip ospf network command to return to the default network type for the media.

EIGRP Stub Routing

The EIGRP stub routing feature, available in all images, reduces resource utilization by moving routed traffic closer to the end user.


Note The IP base image contains only EIGRP stub routing. The IP services image contains complete EIGRP routing.


In a network using EIGRP stub routing, the only route for IP traffic to follow to the user is through a switch that is configured with EIGRP stub routing. The switch sends the routed traffic to interfaces that are configured as user interfaces or are connected to other devices.

When using EIGRP stub routing, you need to configure the distribution and remote routers to use EIGRP and to configure only the switch as a stub. Only specified routes are propagated from the switch. The switch responds to all queries for summaries, connected routes, and routing updates.

Any neighbor that receives a packet informing it of the stub status does not query the stub router for any routes, and a router that has a stub peer does not query that peer. The stub router depends on the distribution router to send the proper updates to all peers.

In Figure 2, switch B is configured as an EIGRP stub router. Switches A and C are connected to the rest of the WAN. Switch B advertises connected, static, redistribution, and summary routes to switch A and C. Switch B does not advertise any routes learned from switch A (and the reverse).

Figure 2 EIGRP Stub Router Configuration

For more information about EIGRP stub routing, see "Configuring EIGRP Stub Routing" part of the Cisco IOS IP Configuration Guide, Volume 2 of 3: Routing Protocols, Release 12.2.

Enabling Directed Broadcast-to-Physical Broadcast Translation

By default, IP directed broadcasts are dropped; they are not forwarded. Dropping IP-directed broadcasts makes routers less susceptible to denial-of-service attacks.

You can enable forwarding of IP-directed broadcasts on an interface where the broadcast becomes a physical (MAC-layer) broadcast. Only those protocols configured by using the ip forward-protocol global configuration command are forwarded.

You can specify an access list to control which broadcasts are forwarded. When an access list is specified, only those IP packets permitted by the access list are eligible to be translated from directed broadcasts to physical broadcasts. For more information on access lists, see the "Configuring Network Security with ACLS" chapter of the software configuration guide for this release.

Beginning in privileged EXEC mode, follow these steps to enable forwarding of IP-directed broadcasts on an interface:

 
Command
Purpose

Step 1 

configure terminal

Enter global configuration mode.

Step 2 

interface interface-id

Enter interface configuration mode, and specify the interface to configure.

Step 3 

ip directed-broadcast [access-list-number]

Enable directed broadcast-to-physical broadcast translation on the interface. You can include an access list to control which broadcasts are forwarded. When you specify an access list, only IP packets permitted by the access list can be translated.

Note The ip directed-broadcast interface configuration command can be configured on a VPN routing/forwarding(VRF) interface and is VRF aware. Directed broadcast traffic is routed only within the VRF.

Step 4 

exit

Return to global configuration mode.

Step 5 

ip forward-protocol {udp [port] | nd | sdns}

Specify which protocols and ports the router forwards when forwarding broadcast packets.

udp—Forward UPD datagrams.

port: (Optional) Destination port that controls which UDP services are forwarded.

nd—Forward ND datagrams.

sdns—Forward SDNS datagrams

Step 6 

end

Return to privileged EXEC mode.

Step 7 

show ip interface [interface-id]

or

show running-config

Verify the configuration on the interface or all interfaces.

Step 8 

copy running-config startup-config

(Optional) Save your entries in the configuration file.

Use the no ip directed-broadcast interface configuration command to disable translation of directed broadcast to physical broadcasts. Use the no ip forward-protocol global configuration command to remove a protocol or port.

Configuring the Number of Equal-Cost Routing Paths

When a router has two or more routes to the same network with the same metrics, these routes can be thought of as having an equal cost. The term parallel path is another way to see occurrences of equal-cost routes in a routing table. If a router has two or more equal-cost paths to a network, it can use them concurrently. Parallel paths provide redundancy in case of a circuit failure and also enable a router to load balance packets over the available paths for more efficient use of available bandwidth.

Even though the router automatically learns about and configures equal-cost routes, you can control the maximum number of parallel paths supported by an IP routing protocol in its routing table. Although the switch software allows a maximum of 32 equal-cost routes, the switch hardware will never use more than 16 paths per route.

Beginning in privileged EXEC mode, follow these steps to change the maximum number of parallel paths installed in a routing table from the default:

 
Command
Purpose

Step 1 

configure terminal

Enter global configuration mode.

Step 2 

router {bgp | rip | ospf | eigrp}

Enter router configuration mode.

Step 3 

maximum-paths maximum

Set the maximum number of parallel paths for the protocol routing table. The range is from 1 to 16; the default is 4 for most IP routing protocols, but only 1 for BGP.

Step 4 

end

Return to privileged EXEC mode.

Step 5 

show ip protocols

Verify the setting in the Maximum path field.

Step 6 

copy running-config startup-config

(Optional) Save your entries in the configuration file.

Use the no maximum-paths router configuration command to restore the default value.

Configuring DHCP Features and IP Source Guard Chapter

Option-82 Data Insertion

When you enable the DHCP snooping information option 82 on the switch, this 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. Beginning with Cisco IOS Release 12.2(25)SEE, you can configure the remote ID and circuit ID. For information on configuring these suboptions, see the "Enabling DHCP Snooping and Option 82" chapter of the software configuration guide for this release.

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 previously described sequence of events occurs, the values in these fields in Figure 3 do not change:

Circuit ID suboption fields

Suboption type

Length of the suboption type

Circuit ID type

Length of the circuit ID type

Remote ID suboption fields

Suboption type

Length of the suboption type

Remote ID type

Length of the circuit ID type

In the port field of the circuit ID suboption, the port numbers start at 3. For example, on the switch, port 3 is the Fast Ethernet 1/0/1 port, port 4 is the Fast Ethernet 1/0/2 port, port 5 is the Fast Ethernet 1/0/3 port, and so on. Port 27 is the small form-factor pluggable (SFP) module slot 1/0/1, and port 28 is the SFP module slot 2/0/2, and so on.

Figure 3 shows the packet formats for the default configuration of the remote ID suboption and the circuit ID suboption. For the circuit ID suboption, the module number corresponds to the switch number in the stack. The switch uses the packet formats when DHCP snooping is globally enabled and when the ip dhcp snooping information option global configuration command is entered.

Figure 3 Default Suboption Packet Formats

Figure 4 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 the ip dhcp snooping vlan information option format-type circuit-id string interface configuration command are entered.

The values for the following 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 you configure.

Remote-ID suboption fields

The remote-ID type is 1.

The length values are variable, depending on the length of the string you configure.

Figure 4 User-Configured Suboption Packet Formats

DHCP Snooping Configuration Guidelines

When configuring a large number of circuit IDs on a switch, consider the impact of lengthy character strings on the NVRAM or flash memory. If the circuit-ID configurations, combined with other data, exceed the capacity of the NVRAM or flash memory, an error message appears.

Enabling DHCP Snooping and Option 82

Beginning in privileged EXEC mode, follow these steps to enable DHCP snooping on the switch.

 
Command
Purpose

Step 1 

configure terminal

Enter global configuration mode.

Step 2 

ip dhcp snooping

Enable DHCP snooping globally.

Step 3 

ip dhcp snooping vlan vlan-range

Enable DHCP snooping on a VLAN or range of VLANs. The range is 1 to 4094.

You can enter a single VLAN ID identified by VLAN ID number, a series of VLAN IDs separated by commas, a range of VLAN IDs separated by hyphens, or a range of VLAN IDs separated by entering the starting and ending VLAN IDs separated by a space.

Step 4 

ip dhcp snooping information option

Enable the switch to insert and remove DHCP relay information (option-82 field) in forwarded DHCP request messages to the DHCP server.

The default is enabled.

Step 5 

ip dhcp snooping information option format remote-id [string ASCII-string | hostname]

(Optional) Configure the remote-ID suboption.

You can configure the remote ID to be:

a string of up to 63 ASCII characters (no spaces)

the configured hostname for the switch

Note If the hostname is longer than 63 characters, it will be truncated to 63 characters in the remote-ID configuration.

The default remote ID is the switch MAC address.

Step 6 

ip dhcp snooping information option allowed-untrusted

(Optional) If the switch is an aggregation switch connected to an edge switch, enable the switch to accept incoming DHCP snooping packets with option-82 information from the edge switch.

The default is disabled.

Note You must enter this command only on aggregation switches that are connected to trusted devices.

Step 7 

interface interface-id

Enter interface configuration mode, and specify the interface to be configured.

Step 8 

ip dhcp snooping vlan vlan information option format-type circuit-id string ASCII-string

(Optional) Configure the circuit-ID suboption for the specified interface.

Specify the VLAN and port identifier, using the VLAN ID (1-4094).

You can configure the circuit ID to be a string of 3-63 ASCII characters (no spaces).

The default circuit ID is the port identifier, in the format vlan-mod-port.

Step 9 

ip dhcp snooping trust

(Optional) Configure the interface as trusted or untrusted. You can use the no keyword to configure an interface to receive messages from an untrusted client. The default is untrusted.

Step 10 

ip dhcp snooping limit rate rate

(Optional) Configure the number of DHCP packets per second than an interface can receive. The range is 1 to 2048. The default is no rate limit configured.

Note We recommend an untrusted rate limit of not more than 100 packets per second. If you configure rate limiting for trusted interfaces, you might need to increase the rate limit if the port is a trunk port assigned to more than one VLAN on which DHCP snooping is enabled.

Step 11 

exit

Return to global configuration mode.

Step 12 

ip dhcp snooping verify mac-address

(Optional) Configure the switch to verify that the source MAC address in a DHCP packet that is received on untrusted ports matches the client hardware address in the packet. The default is to verify that the source MAC address matches the client hardware address in the packet.

Step 13 

end

Return to privileged EXEC mode.

Step 14 

show running-config

Verify your entries.

Step 15 

copy running-config startup-config

(Optional) Save your entries in the configuration file.

To disable DHCP snooping, use the no ip dhcp snooping global configuration command. To disable DHCP snooping on a VLAN or range of VLANs, use the no ip dhcp snooping vlan vlan-range global configuration command. To disable the insertion and removal of the option-82 field, use the no ip dhcp snooping information option global configuration command. To configure an aggregation switch to drop incoming DHCP snooping packets with option-82 information from an edge switch, use the no ip dhcp snooping information option allowed-untrusted global configuration command.

This example shows how to enable DHCP snooping globally and on VLAN 10 and to configure a rate limit of 100 packets per second on a port:

Switch(config)# ip dhcp snooping
Switch(config)# ip dhcp snooping vlan 10
Switch(config)# ip dhcp snooping information option
Switch(config)# interface gigabitethernet1/0/1
Switch(config-if)# ip dhcp snooping limit rate 100

Configuring Port-Based Traffic Control Chapter

Configuration Guidelines

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.

Enabling and Configuring Port Security Section (Step 5)

(Optional) Set the maximum number of secure MAC addresses for the interface. If an interface is configured for voice VLAN, configure a maximum of two secure MAC addresses.

Configuring Network Security with ACLs Chapter

the note in Step 3 of the "Configuring VLAN Maps" section is inaccurate. The correct text is:


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, then all IP and Layer 2 packets are dropped.


Configuring QoS Chapter

Classifying, Policing, and Marking Traffic on SVIs by Using Hierarchical Policy Maps

In Cisco IOS Release 12.2(25)SE or later, you can configure hierarchical policy maps on SVIs, (but not on other types of interfaces). Hierarchical policing combines the VLAN- and interface-level policy maps to create a single policy map.

Supported MIBs Chapter

MIB List Section

CISCO-DHCP-SNOOPING-MIB

CISCO-PORT-QOS-MIB

Extended Bridge MIB

Updates for the Command Reference

These are updates to the command reference:

The show ip dhcp snooping user EXEC command was updated to show the global suboption configuration. This command only displays the results of global configuration. Therefore, in this example, the circuit-ID suboption appears in its default format of vlan-mod-port, even if you configure a string for the circuit ID.

This is an example of output from the show ip dhcp snooping command:

Switch> show ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
40-42
Insertion of option 82 is enabled
	circuit-id format: vlan-mod-port
	remote-id format: string
Option 82 on untrusted port is not allowed 
Verification of hwaddr field is enabled
Interface                    Trusted     Rate limit (pps)
------------------------     -------     ----------------
GigabitEthernet1/0/1             yes         unlimited
GigabitEthernet1/0/2             yes         unlimited
GigabitEthernet2/0/3             no          2000 
GigabitEthernet2/0/4             yes         unlimited
GigabitEthernet0/1               yes         unlimited
GigabitEthernet0/2               yes         unlimited

The show interfaces accounting privileged EXEC command was updated with this note:


Note The display shows only packets processed in software; hardware-switched packets cannot be displayed.


The match class map configuration command was updated to add this to the syntax description for the keywords input-interface:

This command can only be used in the child-level policy map, and must be the only match condition in the child-level policy map.

The show mls qos interface user EXEC command port bandwidth limit field was updated to add the operational bandwidth value:

Switch> show mls qos interface fastethernet1/0/7 queueing
GigabitEthernet1/0/7
Egress Priority Queue :enabled
Shaped queue weights (absolute) :  25 0 0 0
Shared queue weights  :  25 25 25 25
The port bandwidth limit : 100  (Operational Bandwidth:100.0)
The port is mapped to qset : 1

These commands were added for this release:

ip dhcp snooping information option format remote-id

ip dhcp snooping vlan information option format-type circuit-id string

link state group

link state track

show link state group

ip dhcp snooping information option format remote-id

Use the ip dhcp snooping information option format remote-id global configuration command on the switch stack or on a standalone switch to configure the option-82 remote-ID suboption. Use the no form of this command to configure the default remote-ID suboption.

ip dhcp snooping information option format remote-id [string ASCII-string | hostname]

no ip dhcp snooping information option format remote-id

Syntax Description

string ASCII-string

Specify a remote ID, using from 1 to 63 ASCII characters (no spaces).

hostname

Specify the switch hostname as the remote ID.


Defaults

The switch MAC address is the remote ID.

Command Modes

Global configuration

Command History

Release
Modification

12.2(25)SEE

This command was introduced.


Usage Guidelines

You must globally enable DHCP snooping by using the ip dhcp snooping global configuration command for any DHCP snooping configuration to take effect.

When the option-82 feature is enabled, the default remote-ID suboption is the switch MAC address. You can use this command to configure either the switch hostname or a string of up to 63 ASCII characters (but no spaces) to be the remote ID.


Note If the hostname exceeds 63 characters, it is truncated to 63 characters in the remote-ID configuration.


Examples

This example shows how to configure the option-82 remote-ID suboption:

Switch(config)# ip dhcp snooping information option format remote-id hostname

You can verify your settings by entering the show ip dhcp snooping user EXEC command.

Related Commands

Command
Description

ip dhcp snooping vlan information option format-type circuit-id string

Configure the option-82 circuit-ID suboption.

show ip dhcp snooping

Displays the DHCP snooping configuration.


ip dhcp snooping vlan information option format-type circuit-id string

Use the ip dhcp snooping information option format remote-id interface configuration command on the switch stack or on a standalone switch to configure the option-82 circuit-ID suboption. Use the no form of this command to configure the default circuit-ID suboption.

ip dhcp snooping vlan vlan information option format-type circuit-id string ASCII-string

no ip dhcp snooping vlan vlan information option format-type circuit-id string

Syntax Description

vlan vlan

Specify the VLAN ID. The range is 1-4094.

string ASCII-string

Specify a circuit ID, using from 3 to 63 ASCII characters (no spaces).


Defaults

The switch VLAN and the port identifier, in the format vlan-mod-port, is the default circuit ID.

Command Modes

Interface configuration

Command History

Release
Modification

12.2(25)SEE

This command was introduced.


Usage Guidelines

You must globally enable DHCP snooping by using the ip dhcp snooping global configuration command for any DHCP snooping configuration to take effect.

When the option-82 feature is enabled, the default circuit-ID suboption is the switch VLAN and the port identifier, in the format vlan-mod-port. You can use this command to configure a string of ASCII characters to be the circuit ID.


Note When configuring a large number of circuit IDs on a switch, consider the impact of lengthy character strings on the NVRAM or the flash memory. If the circuit-ID configurations, combined with other data, exceed the capacity of the NVRAM or the flash memory, an error message appears.


Examples

This example shows how to configure the option-82 circuit-ID suboption:

Switch(config-if)# ip dhcp snooping vlan 250 information option format-type circuit-id 
string customerABC-250-0-0

You can verify your settings by entering the show ip dhcp snooping user EXEC command.


Note The show ip dhcp snooping command only displays the global command output, including a remote-ID configuration. It will not display any per-interface, per-VLAN string you have configured for the circuit ID.


Related Commands

Command
Description

ip dhcp snooping information option format remote-id

Configure the option-82 remote-ID suboption.

show ip dhcp snooping

Displays the DHCP snooping configuration.


link state group

Use the link state group interface configuration command to configure a port as a member of a link-state group. Use the no form of this command to remove the port from the link-state group.

link state group [number] {upstream | downstream}

no link state group [number] {upstream | downstream}

Syntax Description

number

(Optional) Specify the link-state group number. The group number can be 1 to 10.The default is 1.

upstream

Configure a port as an upstream port for a specific link-state group.

downstream

Configure a port as a downstream port for a specific link-state group.


Defaults

The default group is group 1.

Command Modes

Interface configuration

Command History

Release
Modification

12.2(25)SEE

This command was introduced.


Usage Guidelines

Use the link state group interface configuration command to configure a port as an upstream or downstream port for a specific link-state group. If the group number is omitted, the default group is assumed.

An interface can be an aggregation of ports (an EtherChannel), a single switch port in access or trunk mode, or a routed port. Each downstream interface can be associated with one or more upstream interfaces. Upstream interfaces can be bundled together, and each downstream interface can be associated with a single group consisting of multiple upstream interfaces, referred to as link-state groups.

The link state of the downstream interfaces are dependent on the link state of the upstream interfaces in the associated link-state group. If all of the upstream interfaces in a link-state group are in a link-down state, the associated downstream interfaces are forced into a link-down state. If any one of the upstream interfaces in the link-state group is in a link-up state, the associated downstream interfaces are allowed to change to, or remain in, a link-up state.

Follow these guidelines to avoid configuration problems:

An interface that is defined as an upstream interface cannot also be defined as a downstream interface in the same or a different link-state group. The reverse is also true.

An interface cannot be a member of more than one link-state group.

You can configure only ten link-state groups per switch.

Examples

This example shows how to configure the interfaces as upstream in group 2:

Switch# configure terminal 
Switch(config)# interface range fastethernet1/0/11 - 14 
Switch(config-if-range)# link state group 2 downstream
Switch(config-if-range)# end
Switch(config-if)# end

You can verify your settings by entering the show running-config privileged EXEC command.

Related Commands

Command
Description

link state track

Enables a link-state group.

show link state group

Displays the link-state group information.

show running-config

Displays the current operating configuration. For syntax information, select Cisco IOS Configuration Fundamentals Command Reference for Release 12.2 > Cisco IOS File Management Commands > Configuration File Commands.


link state track

Use the link state track user EXEC command to enable a link-state group. Use the no form of this command to disable a link-state group.

link state track [number]

no link state track [number]

Syntax Description

number

(Optional) Specify the link-state group number. The group number can be 1 to 10. The default is 1.


Defaults

Link-state tracking is disabled for all groups.

Command Modes

Global configuration

Command History

Release
Modification

12.2(25)SEE

This command was introduced.


Usage Guidelines

Use the link state track global configuration command to enable a link-state group.

Examples

This example shows how enable link-state group 2:

Switch(config)# link state track 2

You can verify your settings by entering the show running-config privileged EXEC command.

Related Commands

Command
Description

link state group

Configures an interface as a member of a link-state group.

show link state group

Displays the link-state group information.

show running-config

Displays the current operating configuration. For syntax information, select Cisco IOS Configuration Fundamentals Command Reference for Release 12.2 > Cisco IOS File Management Commands > Configuration File Commands.


show link state group

Use the show link state group global configuration command to display the link-state group information.

show link state group [number] [detail] [ | {begin | exclude | include} expression]

Syntax Description

number

(Optional) Number of the link-state group.

detail

(Optional) Specify that detailed information appears.

| begin

(Optional) Display begins with the line that matches the expression.

| exclude

(Optional) Display excludes lines that match the expression.

| include

(Optional) Display includes lines that match the specified expression.

expression

Expression in the output to use as a reference point.


Defaults

There is no default.

Command Modes

Privileged EXEC

Command History

Release
Modification

12.2(25)SEE

This command was introduced.


Usage Guidelines

Use the show link state group command to display the link-state group information. Enter this command without keywords to display information about all link-state groups. Enter the group number to display information specific to the group. Enter the detail keyword to display detailed information about the group.

Expressions are case sensitive. For example, if you enterexclude output, the lines that contain output are not displayed, but the lines that contain Output are displayed.

Examples

This is an example of output from the show link state group 1 command:

Switch> show link state group 1
Link State Group: 1      Status: Enabled, Down

This is an example of output from the show link state group detail command:

Switch> show link state group detail
Link State Group: 1 Status: Enabled, Down 
Upstream Interfaces : Fa1/0/15(Dwn) Fa1/0/16(Dwn) 
Downstream Interfaces : Fa1/0/11(Dis) Fa1/0/12(Dis) Fa1/0/13(Dis) Fa1/0/14(Dis)

Link State Group: 2 Status: Enabled, Down 
Upstream Interfaces : Fa1/0/15(Dwn) Fa1/0/16(Dwn) Fa1/0/17(Dwn) 
Downstream Interfaces : Fa1/0/11(Dis) Fa1/0/12(Dis) Fa1/0/13(Dis) Fa1/0/14(Dis)

(Up):Interface up (Dwn):Interface Down (Dis):Interface disabled

Related Commands

Command
Description

link state group

Configures an interface as a member of a link-state group.

link state track

Enables a link-state group.

show running-config

Displays the current operating configuration. For syntax information, select Cisco IOS Configuration Fundamentals Command Reference for Release 12.2 > Cisco IOS File Management Commands > Configuration File Commands.


Updates for the Hardware Installation Guide

The preface for the Catalyst 3750 Metro Switch Hardware Installation Guide does not include the translations for the warning symbol and explanation (Statement 1071) or a change to the warning statement about installation for short-circuit (overcurrent) protection (Statement 1005-Circuit Breaker) in Appendix E, "Translated Safety Warnings."

This information is in the Release Notes for the Catalyst 3750 Metro Switch, Cisco IOS Release 12.1(14)AX at this URL:

http://www.cisco.com/univercd/cc/td/doc/product/lan/cat3750m/12114ax/ol464601.htm#35851

This warning was added to the Catalyst 3750 Metro Switch Hardward Installation Guide:

Statement 361—VoIP and Emergency Calling Services do not Function if Power Fails

Warning


Voice over IP (VoIP) service and the emergency calling service do not function if power fails or is disrupted. After power is restored, you might have to reset or reconfigure equipment to regain access to VoIP and the emergency calling service. In the USA, this emergency number is 911. You need to be aware of the emergency number in your country. Statement 361

Waarschuwing

Voice over IP (VoIP)-service en de service voor noodoproepen werken niet indien er een stroomstoring is. Nadat de stroomtoevoer is hersteld, dient u wellicht de configuratie van uw apparatuur opnieuw in te stellen om opnieuw toegang te krijgen tot VoIP en de noodoproepen. In de VS is het nummer voor noodoproepen 911. U dient u zelf op de hoogte te stellen van het nummer voor noodoproepen in uw land.

Varoitus

Voice over IP (VoIP) -palvelu ja hätäpuhelupalvelu eivät toimi, jos virta katkeaa tai sen syötössä esiintyy häiriöitä. Kun virransyöttö on taas normaali, sinun täytyy mahdollisesti asettaa tai määrittää laitteisto uudelleen, jotta voisit jälleen käyttää VoIP-palvelua ja hätäpuhelupalvelua. Yhdysvalloissa hätänumero on 911. Selvitä, mikä on omassa kotimaassasi käytössä oleva hätänumero.

Attention

Le service Voice over IP (VoIP) et le service d'appels d'urgence ne fonctionnent pas en cas de panne de courant. Une fois que le courant est rétabli, vous devrez peut-être réinitialiser ou reconfigurer le système pour accéder de nouveau au service VoIP et à celui des appels d'urgence. Aux États-Unis, le numéro des services d'urgence est le 911. Vous devez connaître le numéro d'appel d'urgence en vigueur dans votre pays.

Warnung

Bei einem Stromausfall oder eingeschränkter Stromversorgung funktionieren VoIP-Dienst und Notruf nicht. Sobald die Stromversorgung wieder hergestellt ist, müssen Sie möglicherweise die Geräte zurücksetzen oder neu konfigurieren, um den Zugang zu VoIP und Notruf wieder herzustellen. Die Notrufnummer in den USA lautet 911. Wählen Sie im Notfall die für Ihr Land vorgesehene Notrufnummer.

Avvertenza

Il servizio Voice over IP (VoIP) e il servizio per le chiamate di emergenza non funzionano in caso di interruzione dell'alimentazione. Ristabilita l'alimentazione, potrebbe essere necessario reimpostare o riconfigurare l'attrezzatura per ottenere nuovamente l'accesso al servizio VoIP e al servizio per le chiamate di emergenza. Negli Stati Uniti, il numero di emergenza è 911. Si consiglia di individuare il numero di emergenza del proprio Paese.

Advarsel

Tjenesten Voice over IP (VoIP) og nødanropstjenesten fungerer ikke ved strømbrudd. Etter at strømmen har kommet tilbake, må du kanskje nullstille eller konfigurere utstyret på nytt for å få tilgang til VoIP og nødanropstjenesten. I USA er dette nødnummeret 911. Du må vite hva nødnummeret er i ditt land.

Aviso

O serviço Voice over IP (VoIP) e o serviço de chamadas de emergência não funcionam se houver um corte de energia. Depois do fornecimento de energia ser restabelecido, poderá ser necessário reiniciar ou reconfigurar o equipamento para voltar a utilizar os serviços VoIP ou chamadas de emergência. Nos EUA, o número de emergência é o 911. É importante que saiba qual o número de emergência no seu país.

¡Advertencia!

El servicio de voz sobre IP (VoIP) y el de llamadas de emergencia no funcionan si se interrumpe el suministro de energía. Tras recuperar el suministro es posible que deba que restablecer o volver a configurar el equipo para tener acceso a los servicios de VoIP y de llamadas de emergencia. En Estados Unidos el número de emergencia es el 911. Asegúrese de obtener el número de emergencia en su país.

Varning!

Tjänsten Voice over IP (VoIP) och larmnummertjänsten fungerar inte vid strömavbrott. Efter att strömmen kommit tillbaka måste du kanske återställa eller konfigurera om utrustningen för att få tillgång till VoIP och larmnummertjänsten. I USA är det här larmnumret 911. Du bör ta reda på det larmnummer som gäller i ditt land.

 

 



Related Documentation

These documents provide information about the switch and are available from this Cisco.com site:

http://www.cisco.com/univercd/cc/td/doc/product/lan/cat3750m/index.htm

You can order printed copies of documents with a DOC-xxxxxx= number from the Cisco.com sites and from the telephone numbers listed in the "Obtaining Documentation, Obtaining Support, and Security Guidelines" section.

Catalyst 3750 Metro Switch Software Configuration Guide (order number DOC-7816793=)

Catalyst 3750 Metro Switch Command Reference (order number DOC-7816797=)

Catalyst 3750 Metro Switch System Message Guide (order number DOC-7816792=)

Catalyst 3750 Metro Switch Hardware Installation Guide (order number DOC-7815869=)

Cisco Small Form-Factor Pluggable Modules Installation Notes (not orderable but available on Cisco.com)

Obtaining Documentation, Obtaining Support, and Security Guidelines

For information on obtaining documentation, obtaining support, providing documentation feedback, security guidelines, and also recommended aliases and general Cisco documents, see the monthly What's New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation, at:

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