This chapter covers the following topics:
EtherChannel
Cisco Discovery Protocol (CDP)
Protocol Filtering
Broadcast and Multicast Suppression
Multiple Default Gateways
DHCP for Management IP Configuration
MAC Address Notification
Debounce Timer
Baby Giants and Jumbo Frames
Error-Disable
IEEE 802.3 Flow Control
Unidirectional Link Detection (UDLD) and Aggressive Mode UDLD
Previous chapters discussed the model for building Cisco multilayer switched networks and the building blocks of multilayer switched networks such as VLANs and the IEEE Spanning Tree Protocol. Cisco multilayer switches offer additional Layer 2 features to enhance the availability of networks, and to aid in troubleshooting. These services are not mandatory features of multilayer switched networks but using them is among the best practices in the industry.
Features such as the following prevent network outages due to network loops, unauthorized devices, or malfunctioning devices or software. In addition, these features can minimize network traffic packet loss:
Unidirectional Link Detection
Broadcast and multicast suppression
Error-disable
IEEE 802.3 flow control
Protocol filtering
Unicast flood blocking
In addition, the following features are services for adding functionality to the switches to support specific network devices or applications:
Baby giants
Jumbo frames
Debounce timer
This chapter also reviews the EtherChannel feature, which provides link redundancy and increased bandwidth between devices. Finally, features such as DHCP-based management of IP configuration and CDP make management of Cisco devices easier.
These Layer 2 and Layer 3 features are value-adds to the multilayer switched network and help maintain the five 9s (99.999 percent) network uptime guarantee.
This chapter covers these multilayer switch features with a brief description of each feature’s functionality and its support on various switches. Each section includes a sample configuration using Cisco CatOS–and Cisco IOS–based switches. This chapter also includes a case study on how the aggressive mode UDLD helps to prevent network outages. Upon completion of this chapter, you will understand how and where to use these Layer 2 and Layer 3 features to effectively administer the network with improved reliability and stability.
Ethernet ports typically interconnect switches such that devices connected to one switch can pass frames to devices connected on another switch. Ethernet operates at 10 Mbps, 100 Mbps, 1000 Mbps, or 10 Gbps. With the increasing need for higher bandwidth, administrators look for alternate ways to increase the traffic bandwidth available between two devices. In most cases, opting for a higher-bandwidth port type, such as 10 Gigabit Ethernet, as a method of increasing bandwidth is not always feasible due to increased cost.
EtherChannel takes advantage of the existing ports by bundling ports to allow incremental additions to the available bandwidth. Cisco Catalyst switches allow as many as eight ports to be bundled together. In other words, with EtherChannel, Catalyst switches support the aggregation of single logical links for total bandwidth of up to 1600 Mbps (Fast Ethernet full duplex) or 16 Gbps (Gigabit Ethernet full duplex) for Fast Ethernet and Gigabit Ethernet interfaces, respectively. EtherChannel does not support channeling at 10 Mbps.
EtherChannel also provides redundancy in case of a link failure between the connecting devices by maintaining the connectivity through the other, non failing links. If the ports belong to the same module, then there is no significant loss in connectivity because only inflight frames for the failing link are lost.
For more information on the system requirements of EtherChannel on various Catalyst switches, refer to the following document on Cisco.com:
“System Requirements to Implement EtherChannel on Catalyst Switches,” Document ID: 12025
Cisco IOS–based switches support Layer 2 EtherChannel as well as Layer 3 EtherChannel. Layer 3 EtherChannel bundles Layer 3 or routed interfaces. One of the primary advantages of link failure on Layer 3 EtherChannel is that routing protocols consider an EtherChannel as a single link; hence, no reconvergence of the routing protocols occurs during a link failure.
Figure 7-1 shows that EtherChannel is applicable to connections between switches, routers, and switches to routers.
The Catalyst family of switches supports both the Cisco proprietary Port Aggregation Protocol (PAgP) and the industry standard 802.3ad-based protocol Link Aggregation Control Protocol (LACP). PAgP is a management function that checks the parameter consistency at either end of the link and assists the channel in adapting to link failure or addition. PAgP prevents STP loops or packet loss due to misconfigured channels and aids network reliability. LACP has similar functions.
Between Cisco Catalyst switches, EtherChannel typically uses either PAgP or LACP. However, EtherChannel supports an on mode that forces ports on both link partners to operate as an EtherChannel. Furthermore, channeling using PAgP is also possible between Cisco switches and other devices released by licensed vendors, such as network interface cards (NIC) from Intel. For interconnections between Cisco Catalyst switches and non-Cisco vendor switches or servers that support 802.3ad, use LACP to form an EtherChannel.
PAgP operates in different modes. The mode of operation determines whether a group of ports forms a channel. Table 7-1 lists and defines the various modes.
Table 7-1. PAgP Modes
Mode | Description |
|---|---|
On | Forces the ports to form an EtherChannel without the use of PAgP. EtherChannel on both link partners has to be in the on mode for an EtherChannel to operate correctly. |
Off | Prevents the ports from forming an EtherChannel. |
Auto | Places the port into a passive negotiating state and forms an EtherChannel if the port receives PAgP packets. However, in this mode, the port does not initiate the negotiation. This mode is the default. |
Desirable | Places the port into a negotiating state to form an EtherChannel, using PAgP. This is the recommended mode between Catalyst switches for configuring an EtherChannel. |
In addition, the auto and desirable PAgP modes of operation support the following options:
silent—. The default keyword used with auto or desirable mode to indicate that the switch does not expect PAgP frames from the partner device to prevent the switch from reporting the link to the STP as down. This mode is used to connect to non-PAgP-capable devices like traffic-generators.
non-silent—. Keyword used with auto or desirable mode to indicate that the switch expects PAgP frames from the partner device. This mode is used to detect unidirectional link problems because lack of PAgP frames from a partner indicates a loss of communication in one direction. The non-silent option is recommended between two PAgP-capable devices because it will report the link status to the STP as down upon unidirectional link detection.
Both the auto and desirable modes enable interfaces to negotiate with link partners’ interfaces to determine whether they can form an EtherChannel, based on criteria such as interface speed and, for Layer 2 EtherChannel, trunking state and VLAN configuration.
Note
The Cisco recommendation for an EtherChannel mode is the desirable mode because it provides additional stability in the case of a misconfiguration or hardware or software failure.
Interfaces between two connected switches can form an EtherChannel when the interfaces are in different PAgP modes as long as the modes are compatible. On mode is only compatible with another interface in on mode; auto mode is only compatible with desirable mode; and desirable mode is compatible with either auto mode or desirable mode. Setting the port channel mode to on mode turns on EtherChannel manually, regardless of link-partner configuration.
Table 7-2 lists and describes the various LACP operational modes.
Table 7-2. LACP Modes
Mode | Description |
|---|---|
On | Forces the ports to form an EtherChannel without LACP. EtherChannel mode on both sides of the links has to be in on mode for a channel to operate. |
Off | Prevents the ports from forming an EtherChannel. |
Passive | Places the port into a passive negotiating state and forms an EtherChannel if the port receives LACP packets; however, in this mode, the port does not initiate the negotiation of an EtherChannel. This mode is the default. |
Active | Places the port into an active LACP negotiating state where the port initiates to form an EtherChannel. Recommended mode between Catalyst switches. |
Table 7-3 shows the parameters used in configuring LACP.
Table 7-3. Parameters Used in Configuring LACP
Parameter | Description |
|---|---|
System priority | LACP requires that each link partner has a system priority. The switch determines the system priority automatically or through manual configuration. The switch uses the MAC address and the system priority to form the system ID used during negotiation with other systems. |
Port priority | LACP requires that each port has a port priority. The switch determines the port priority automatically or through manual configuration. The port priority and the port number form the port ID. The switch uses the port priority to decide which ports to put in standby mode when a hardware limitation prevents all compatible ports from aggregating. |
Administrative key | LACP requires each port involved in a channel to have a key value, which is determined automatically or administratively configured. The administrative key defines the ability of a port to aggregate with other ports. Port physical characteristics, such as data rate, duplex capability, and point-to-point or shared media, determine the ability of ports to form a channel. LACP also supports additional constraints set up by the configuration. |
When enabled, LACP always tries to configure the maximum number of compatible ports in a channel, up to the maximum allowed by the hardware or eight ports. If LACP cannot aggregate all the ports that are compatible (for example, the remote system might have more restrictive hardware limitations), the switch places all the ports that cannot be actively included in the channel in a hot standby state. LACP uses these ports only if one of the channeled ports fails.
Cisco switches allow configuration of different channels with ports that have the same administrative key. For example, if eight ports are assigned the same administrative key, administrators may configure four ports in a channel using LACP active mode and the remaining four ports in a manually configured channel using on mode. An administrative key is meaningful only in the context of the switch that allocates it, and there is no global significance to administrative key values. The administrative key values range from 1 to 1024. It is possible to manually assign the administrative key or let the switch assign a key automatically. Example 7-1 shows a switch automatically assigning the administrative key.
Cisco IOS–based switches support an EtherChannel on Layer 2 or Layer 3 interfaces. Each EtherChannel has a corresponding numbered port-channel interface. A configuration applied to the port-channel interface affects all physical interfaces assigned to that interface. A configuration applied to the individual physical interface is applicable only to that interface.
The following list contains guidelines and best practices for configuring port channels:
Cisco switches allow for a maximum of eight ports per EtherChannel. The ports do not have to be contiguous or on the same module. There may be restrictions on older-generation Catalyst switches; therefore, check the release notes for that specific product before implementing an EtherChannel.
All ports in an EtherChannel must use the same protocol (PAgP or LACP).
All ports in an EtherChannel must have the same speed and duplex mode. LACP requires that the ports operate only in full-duplex mode.
A port cannot belong to more than one channel group at the same time.
All ports in an EtherChannel must be configured to be in the same access VLAN configuration or be configured as VLAN trunks with the same allowable VLAN list and the same native VLAN.
All ports in an EtherChannel require the same trunk mode to avoid unexpected results. (For instance, a trunk mode of dot1q is desirable.)
All ports in an EtherChannel require the same VLAN cost configuration.
An EtherChannel does not form if one of the ports is configured as a Switched Port Analyzer (SPAN) destination port.
IP addresses should be configured on the port-channel interface for EtherChannels acting as Layer 3 interfaces instead of on the physical interface.
An EtherChannel forms on compatible configured interfaces even with the interfaces configured for different STP port path costs.
Figure 7-2 shows access layer Catalyst 3550s connecting to the distribution layer Catalyst 6500 switches. The administrator wants to configure a Layer 2 EtherChannel with VLAN trunking configured between pairs of access and distribution switches, as shown in Figure 7-2. Channeling provides increased bandwidth for the uplink from the access layer to the distribution layer and at the same time provides redundancy in case of link failure.
Examples 7-2 and 7-3 show the configuration and verification of one of the EtherChannels between the access layer Catalyst 3550 and distribution layer Cisco CatOS–based Catalyst 6500 switch, respectively.
Example 7-2. Configuration and Verification of an EtherChannel on a Catalyst 3550 Switch
3550(config)#interface GigabitEthernet 0/1 3550(config-if)#switchport 3550(config-if)#channel-group 1 mode desirable Creating a port-channel interface Port-channel1 3550(config-if)#exit 3550(config)#interface GigabitEthernet 0/2 3550(config-if)#switchport 3550(config-if)#channel-group 1 mode desirable 3550(config-if)#interface port-channel 1 3550(config-if)#switchport mode trunk 3550#show etherchannel 1 summary Flags: D - down P - in port-channel I - stand-alone s - suspended R - Layer3 S - Layer2 U - port-channel in use Group Port-channel Ports -----+------------+----------------------------------------------------------- 1 Po1(SU) Gi0/1(P) Gi0/2(P)
Example 7-3. Configuration and Verification of an EtherChannel on a Cisco CatOS–Based Catalyst 6500 Switch
cat6000> (enable)set port channel 2/1-2 mode desirable Port(s) 2/1-2 channel mode set to desirable. Cat6000> (enable)set trunk 2/1 dot1q desirable Port(s) 2/1-2 trunk mode set to desirable. Port(s) 2/1-2 trunk type set to dot1q. cat6000>show port channe1 2/1 Port Status Channel Admin Ch Mode Group Id ----- ---------- -------------------- ----- ----- 2/1 connected desirable silent 174 815 2/2 connected desirable silent 174 815 ----- ---------- -------------------- ----- ----- Port Device-ID Port-ID Platform ----- ------------------------------- ------------------------- ---------------- 2/1 3550 Gi0/1 cisco WS-C3550-24 2/2 3550 Gi0/2 cisco WS-C3550-24 ----- ------------------------------- ------------------------- ----------------
For the topology shown in Figure 7-2, each access layer switch has redundant links connecting to the distribution layer and has backup links going to the backup distribution Catalyst 6500 switch. Backup links may stay in STP blocking mode until the primary link totally fails or the primary distribution switch fails. Such a configuration allows for high availability in case of link failure or switch failure. The current recommendation is to configure EtherChannel across multiple modules on the distribution switch to prevent a single module failure from causing a complete channel failure.
Note
The switchport command in Cisco IOS configures an interface as a Layer 2 interface, and the no switchport command sets the interface as a Layer 3 or routed interface. Different model switches vary as to the default setting of interfaces as Layer 2 interfaces or a Layer 3 interfaces. Note that default settings do not appear in the configuration.
The connections between the distribution layers and the core layer are Layer 3 links. To provide link redundancy and increased bandwidth, the design uses Layer 3 port-channel configurations. Example 7-4 shows the configuration and verification of this Layer 3 EtherChannel connection between the Cisco IOS–based distribution layer Catalyst 4507R switch, whereas Example 7-5 shows the configuration and verification on the Cisco IOS–based core layer Catalyst 6500 switch.
Example 7-4. Configuration and Verification of Layer 3 EtherChannel on a Cisco IOS–Based Catalyst 4500 Switch
SwitchC-4500#configure terminal Enter configuration commands, one per line. End with CNTL/Z. SwitchC-4500(config)#interface GigabitEthernet 1/1 SwitchC-4500(config-if)#no switchport SwitchC-4500(config-if)#channel-group 1 mode desirable Creating a port-channel interface Port-channel 1 2d14h: %EC-5-BUNDLE: Interface GigabitEthernet1/1 joined port-channel Port-channel1 SwitchC-4500(config-if)#interface GigabitEthernet 2/13 SwitchC-4500(config-if)#no switchport SwitchC-4500(config-if)#channel-group 1 mode desirable 2d14h: %EC-5-BUNDLE: Interface GigabitEthernet2/13 joined port-channel Port-channel1 SwitchC-4500config)#interface port-channel 1 SwitchC-4500(config-if)#ip address 100.1.1.1 255.255.255.0 SwitchC-4500(config-if)#end SwitchC-4500# SwitchC-4500#show etherchannel 1 summary Flags: D - down P - in port-channel I - stand-alone s - suspended R - Layer3 S - Layer2 U - in use f - failed to allocate aggregator u - unsuitable for bundling Number of channel-groups in use: 1 Number of aggregators: 1 Group Port-channel Protocol Ports ------+-------------+-----------+----------------------------------------------- 1 Po1(RU) PAgP Gi1/1(P) Gi2/13(P)
Example 7-5. Configuration and Verification of Layer 3 Port-Channel on Cisco IOS–Based Catalyst 6500 Switch
SwitchA-6500#configure terminal Enter configuration commands, one per line. End with CNTL/Z. SwitchA-6500(config)#interface GigabitEthernet 2/1 SwitchA-6500(config-if)#no switchport SwitchA-6500(config-if)#channel-group 1 mode desirable Creating a port-channel interface Port-channel 1 2d14h: %EC-5-BUNDLE: Interface GigabitEthernet2/1 joined port-channel Port-channel1 SwitchA-6500(config-if)#interface GigabitEthernet 2/2 SwitchA-6500(config-if)#no switchport SwitchA-6500(config-if)#channel-group 1 mode desirable 2d14h: %EC-5-BUNDLE: Interface GigabitEthernet2/2 joined port-channel Port-channel1 SwitchA-6500config)#interface port-channel 1 SwitchA-6500(config-if)#ip address 100.1.1.2 255.255.255.0 SwitchA-6500(config-if)#end SwitchA-6500# SwitchA-6500#show etherchannel 1 summary Flags: D - down P - in port-channel I - stand-alone s - suspended H - Hot-standby (LACP only) R - Layer3 S - Layer2 U - in use f - failed to allocate aggregator Number of channel-groups in use: 1 Number of aggregators: 1 Group Port-channel Protocol Ports ------+-------------+-----------+----------------------------------------------- 1 Po1(RU) PAgP Gi2/1(P) Gi2/2(P)
In Figure 7-2, because a Cisco CatOS–based distribution-layer Catalyst 6500 switch connects to a Cisco IOS–based core-layer switch through a Layer 3 link, as per the design, configuration of a Layer 2 EtherChannel is necessary. The ports are also in a dedicated subnet and VLAN such that no local user traffic is present on that VLAN. As a result, the EtherChannel carries only the routed traffic.
Example 7-6 shows the configuration and verification of a Layer 3 LACP EtherChannel between two Cisco IOS–based Catalyst switches. In Example 7-6, the LACP system priority, port priority, and administrative key are selected automatically by the switch.
Example 7-6. Configuration and Verification of a Layer 3 LACP EtherChannel
4506#configure terminal Enter configuration commands, one per line. End with CNTL/Z. 4506(config)#interface port-channel 2 4506(config-if)#no switchport 4506(config-if)#ip address 10.1.1.1 255.255.255.0 4506(config-if)#no shut 4506(config-if)#exit 4506(config)#interface gigabitEthernet 3/6 4506(config-if)#no switchport 4506(config-if)#channel-protocol lacp 4506(config-if)#channel-group 2 mode active 4506(config-if)#no shutdown 4506(config-if)#exit 4506(config)#interface gigabitEthernet 3/37 4506(config-if)#no switchport 4506(config-if)#channel-protocol lacp 4506(config-if)#channel-group 2 mode active 4506(config-if)#no shutdown 4506(config-if)#end 4506# *Nov 5 09:12:50: %SYS-5-CONFIG_I: Configured from console by console *Nov 5 09:13:51: %EC-5-BUNDLE: Interface Gi3/36 joined port-channel Po2 *Nov 5 09:14:08: %EC-5-BUNDLE: Interface Gi3/37 joined port-channel Po2 4506#show etherchannel 2 summary Flags: D - down P - in port-channel I - stand-alone s – suspended R - Layer3 S - Layer2 U - in use f - failed to allocate aggregator u - unsuitable for bundling w - waiting to be aggregated d - default port Number of channel-groups in use: 1 Number of aggregators: 1 Group Port-channel Protocol Ports ------+-------------+-----------+----------------------------------------------- 2 Po2(RU) LACP Gi3/36(P) Gi3/37(P) 4503#configure terminal Enter configuration commands, one per line. End with CNTL/Z. 4503(config)#interface port-channel 2 4503(config-if)#no switchport 4503(config-if)#ip address 10.1.1.2 255.255.255.0 4503(config-if)#no shutdown 4503(config-if)#exit 4503(config)#interface gigabitEthernet 3/39 4503(config-if)#no switchport 4503(config-if)#channel-protocol lacp 4503(config-if)#channel-group 2 mode active 4503(config-if)#no shutdown 4503(config-if)#exit *Nov 12 00:06:01.103: %EC-5-BUNDLE: Interface Gi3/39 joined port-channel Po2 4503(config)#interface gigabitEthernet 3/40 4503(config-if)#no switchport 4503(config-if)#channel-protocol lacp 4503(config-if)#channel-group 2 mode active 4503(config-if)#no shutdown 4503(config-if)#end 4503# *Nov 12 00:06:14.131: %SYS-5-CONFIG_I: Configured from console by console *Nov 12 00:06:15.311: %EC-5-BUNDLE: Interface Gi3/40 joined port-channel Po2 4503#show etherchannel 2 summary Flags: D - down P - in port-channel I - stand-alone s - suspended R - Layer3 S - Layer2 U - in use f - failed to allocate aggregator u - unsuitable for bundling w - waiting to be aggregated d - default port Number of channel-groups in use: 2 Number of aggregators: 2 Group Port-channel Protocol Ports ------+-------------+-----------+----------------------------------------------- 2 Po2(RU) LACP Gi3/39(P) Gi3/40(P) 4503#show etherchannel 2 detail Group state = L3 Ports: 2 Maxports = 8 Port-channels: 1 Max Port-channels = 1 Protocol: LACP Ports in the group: ------------------- Port: Gi3/39 ------------ Port state = Up Mstr In-Bndl Channel group = 2 Mode = Active Gcchange = - Port-channel = Po2 GC = - Pseudo port-channel = Po2 Port index = 0 Load = 0x00 Protocol = LACP Flags: S – Device is sending Slow LACPDUs F - Device is sending fast LACPDUs. A – Device is in active mode. P - Device is in passive mode. Local information: LACP port Admin Oper Port Port Port Flags State Priority Key Key Number State Gi3/39 SA bndl 32768 0x2 0x2 0x70 0x3D Partner's information: LACP port Oper Port Port Port Flags Priority Dev ID Age Key Number State Gi3/39 SA 32768 000a.4172.df40 28s 0x2 0xBF 0x3D Age of the port in the current state: 00d:01h:31m:17s Port: Gi3/40 ------------ Port state = Up Mstr In-Bndl Channel group = 2 Mode = Active Gcchange = - Port-channel = Po2 GC = - Pseudo port-channel = Po2 Port index = 1 Load = 0x00 Protocol = LACP Flags: S – Device is sending Slow LACPDUs F - Device is sending fast LACPDUs. A – Device is in active mode. P - Device is in passive mode. Local information: LACP port Admin Oper Port Port Port Flags State Priority Key Key Number State Gi3/40 SA bndl 32768 0x2 0x2 0x71 0x3D Partner's information: LACP port Oper Port Port Port Flags Priority Dev ID Age Key Number State Gi3/40 SA 32768 000a.4172.df40 3s 0x2 0xC1 0x3D Age of the port in the current state: 00d:01h:31m:04s Port-channels in the group: --------------------------- Port-channel: Po2 (Primary Aggregator) ------------ Age of the Port-channel = 00d:01h:32m:11s Logical slot/port = 11/2 Number of ports = 2 Passive port list = Gi3/39 Gi3/40 Port state = Port-channel L3-Ag Ag-Inuse Protocol = LACP Ports in the Port-channel: Index Load Port EC state No of bits ------+------+------+------------------+----------- 0 00 Gi3/39 Active 0 1 00 Gi3/40 Active 0 Time since last port bundled: 00d:01h:31m:09s Gi3/40
EtherChannel supports load balancing of traffic across multiple interfaces. Without EtherChannel, if two links are connected between switches, one of the links does not forward traffic due to STP, which views EtherChannel interfaces as one logical interface and therefore distributes traffic across all ports in the EtherChannel. By distributing the traffic across the EtherChannel, the amount of data loss is minimal in case of failure of the active link, and only in-flight traffic is lost. The traffic also immediately starts using the other links when any other link fails. EtherChannel load balancing selects a specific egress interface based on computation performed with a hash algorithm.
EtherChannel load balancing can use MAC addresses, IP addresses, or Layer 4 port numbers—source, destination, or both source and destination—as the determining factor for deciding to which egress port of the EtherChannel to transmit a frame. The parameters used in the hash algorithm vary depending on the user configuration to distribute the frames accordingly.
Use the option that provides the greatest flexibility in your configuration. For example, consider the scenario shown in Figure 7-3, where the destination MAC or IP address load-balancing algorithm is used. EtherChannel transmits frames only on a single link if the traffic on a channel is going to a single MAC or IP address. As shown in Figure 7-4, using the source MAC or IP address in determining the load-balancing scheme results in more efficient load balancing in this scenario. In addition, load balancing using Layer 4 TCP or User Datagram Protocol (UDP) ports results in more even distribution of traffic across both the links, as shown in Figure 7-5.
Load balancing operates at the switch level rather than per channel, applying globally for all channels on the switch. For the Cisco CatOS–based Catalyst 6500 family of switches, use the following command syntax:
set port channel all distribution {ip | mac | session} [source | destination | both]For the Cisco IOS–based Catalyst 4500 or Catalyst 6500 family of switches, use the following command:
port-channel load-balance {src-mac | dst-mac | src-dst-mac | src-ip | dst-ip | src-dst-ip | src-port | dst-port | src-dst-port}
For the Cisco IOS–based Catalyst 2950 family of switches, use the following command:
port-channel load-balance {dst-mac | src-mac}
Table 7-4 shows the varied support of the load-balancing algorithm Layer 2 (MAC address), Layer 3 (IP address), and Layer 4 (TCP/UDP ports) parameters.
Also, the actual EtherChannel load-balancing algorithm varies depending on the family of switches. For more information, refer to the following technical document on Cisco.com:
“Understanding EtherChannel Load Balancing and Redundancy on Catalyst Switches,” Document ID: 12023
Example 7-7 shows the configuration and verification of source-destination IP-based load balancing on a Cisco IOS–based Catalyst 6500 switch.
To summarize, EtherChannel allows increasing bandwidth up to 16-Gbps (using Gigabit Ethernet interfaces) full duplex by bundling ports and provides redundancy in the case of link failure. EtherChannel is ubiquitous in typical networks of today.
CDP is a Layer 2 protocol enabled by default on Cisco devices and is an important protocol to identify connected device details. CDP is network protocol–independent and runs on all Cisco devices, including routers and Catalyst switches. The Link Layer Discovery Protocol (LLDP) is a vendor-neutral Layer 2 protocol equivalent to Cisco Discovery Protocol (CDP) that allows a network device to advertise its identity and capabilities on the local network. The protocol has been formally ratified as IEEE standard 802.1AB in 2005, and support for LLDP is planned on the Catalyst switches in an upcoming Cisco IOS release.
CDP runs on all media that supports the Subnetwork Access Protocol (SNAP) frames type, including Ethernet, Frame Relay, and ATM physical media. CDP operates at Layer 2 in the OSI model and hence interacts with other Cisco devices regardless of network-layer protocols.
CDP works by sending periodic messages, called advertisement messages, on all CDP-enabled interfaces to the multicast MAC address 01-00-0c-cc-cc-cc. The devices learn information about the connected devices through these messages sent by neighboring devices.
The following list includes significant information related to switches carried by all CDP messages. Table 7-5 provides descriptions of all the fields carried by the CDP messages:
Device ID
Network addresses
Port or interface sending the messages
Capabilities of the sending device
Hardware platform
VTP management domain
Native VLAN
Duplex configuration
Software version
CDP advertisement messages carry the information listed previously in embedded blocks called Type-Length-Value (TLV) fields.
Figure 7-6 shows the general format for a CDP version 2 packet. Table 7-5 describes the fields in the CDPv2 packet.
Figure 7-7 shows the TLV format, and Table 7-6 shows the descriptions of the fields.
Table 7-7 shows the various TLV types and the description of the information carried in them.
Table 7-7. CDPv2 TLV Types and Descriptions
TLV Type | Description |
|---|---|
Device-ID | Identifies the sending device |
Address | Network layer address(es)—typically the address assigned on the interface sending the CDP packet |
Port-ID | Identifies the interface from which the CDP packet is sent |
Capabilities | The device’s functional capability (for example, router or switch) |
Version | Information about which software version the device is running |
Platform | The hardware platform of the device |
Native VLAN | 802.1Q native VLAN (packets sent without 802.1Q tag on native VLAN) |
Appliance VLAN-ID | Contains one or more tuples, each containing Appliance ID (for example, VoIP phone) and VLAN ID for that appliance |
Trigger | Device receiving CDP packets with trigger TLV will respond on the interface of received packet instead of waiting to send packet at the periodic interval |
Power Consumption | Maximum amount of inline power in milliwatts that the device connected on the interface expects to receive |
sysName | System name (same as device’s sysName MIB project) |
sysObjectID | OBJECT-IDENTIFIER value of sending device’s sysObjectID MIB object |
Management-Address | Network layer addresses on which the device would accept SNMP messages |
In addition to this information, the CDP advertisement contains the hold time, which indicates how long the receiving device should hold that CDP information before discarding it.
CDP Version 2 is the latest version of CDP, which provides additional TLVs. Some of the additional TLVs, which are typically used in Architecture for Voice, Video, and Integrated Data (AVVID) installations for Catalyst switches, include the Power Consumption, Extended Trust, COS for Untrusted Ports, and Appliance VLAN-ID TLVs.
For information about configuring the Catalyst switches in an AVVID environment, refer to the following publication:
“Cisco Catalyst QoS: Quality of Service in Campus Networks,” Cisco Press, 2003
Cisco devices send and receive CDP by default. Example 7-8 shows a user displaying the neighboring Cisco devices on a Cisco IOS–based Catalyst switch using CDP.
Example 7-8. Displaying CDP Information About Neighboring Cisco Devices
4506#show cdp neighbor Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone Device ID Local Intrfce Holdtme Capability Platform Port ID TBA03501074(SwitcFa3/21 128 T S I WS-C6506 3/36 SwitchC-4503 Fa3/27 150 R S I WS-C4503 Fa3/14 4506#show cdp neighbor detail ------------------------- Device ID: TBA03501074(SwitchA-6500) Entry address(es): IP address: 10.18.2.137 Platform: WS-C6506, Capabilities: Trans-Bridge Switch IGMP Interface: FastEthernet3/21, Port ID (outgoing port): 3/36 Holdtime : 170 sec Version : WS-C6506 Software, Version McpSW: 7.6(1) NmpSW: 7.6(1) Copyright © 1995-2003 by Cisco Systems advertisement version: 2 VTP Management Domain: '0' Native VLAN: 1 Duplex: full ------------------------- Device ID: SwitchC-4503 Entry address(es): IP address: 10.18.2.132 Platform: cisco WS-C4503, Capabilities: Router Switch IGMP Interface: FastEthernet3/27, Port ID (outgoing port): FastEthernet3/14 Holdtime : 130 sec Version : Cisco Internetwork Operating System Software IOS (tm) Catalyst 4000 L3 Switch Software (cat4000-I5S-M), Version 12.1(19)EW, CISCO ENHANCED PRODUCTION VERSION Copyright © 1986-2003 by cisco Systems, Inc. Compiled Tue 27-May-03 04:31 by prothero advertisement version: 2 VTP Management Domain: 'cisco' Native VLAN: 1 Duplex: full
CDP can be disabled globally or on a per-interface basis. On Cisco IOS–based Catalyst switches, use the following command to disable CDP globally:
no cdp runUse the following interface-level command to disable CDP under individual interfaces on Cisco IOS–based switches:
no cdp enableFor Cisco CatOS–based Catalyst switches, use the following command to disable CDP globally:
set cdp disableUse the following command to disable CDP for a specific port on Cisco CatOS–based switches:
set cdp disable mod/port
Figure 7-8 shows a typical VoIP implementation with a workstation connecting to an IP phone, which in turn connects to the Catalyst switch.
In this configuration, the recommended configuration is to have two separate VLANs:
One for the data traffic from the workstations
Another for the voice traffic from the IP phones
Having two separate VLANs for voice and data traffic helps to apply QoS or other polices per VLAN and helps to differentiate between high-priority voice traffic and low-priority data traffic from the workstation.
To instruct the phone to tag (802.1Q tag) the voice traffic with voice VLAN (also known as auxiliary VLAN), the switch sends CDP packets with the appliance VLAN-ID TLV to the IP phone to mark the packets appropriately.
The following interface-level command is used on Cisco IOS–based Catalyst switches to specify the voice VLAN so that CDP can send it in its packet to the IP phone:
switchport voice vlan vlan-id
On Cisco CatOS–based Catalyst switches, use the following command to specify voice VLAN (auxiliary VLAN):
set port auxiliaryvlan mod/port vlan-id
In Figure 7-9, the native VLAN (untagged VLAN) for data traffic is 2 and the Voice VLAN is 111.
For more information on Voice VLANs, refer to Chapter 13, “Best Practices for Deploying Cisco IP Telephony using Cisco Catalyst Switches.”
CDP provides useful information and helps in troubleshooting in most networks; however, CDP does cause security concerns because it sends information about the system on all the interfaces by default. The security concern is more evident when multiple organizations are interconnected. An example of such a connection is when the enterprise network connects to the service provider network. Best practice is to disable CDP on the interfaces connected to the service provider and the enterprise edge routers to avoid exchange of device information. In addition, disable CDP on a per-interface basis wherever you feel security can be compromised.
The Multiple Default Gateway (MDG) feature is available exclusively to the Cisco CatOS–based Catalyst family of switches. The benefit of this feature is the redundancy associated with multiple default gateways to maintain management connectivity in case of a primary default gateway failure. In addition, the default gateway configured as the Hot Standby Routing Protocol (HSRP) virtual address offers redundancy in case of active router failure. The switches support as many as three default gateways, with one switch acting as the primary gateway and the other two as the backup gateways. Cisco IOS–based Catalyst switches support multiple default gateways via standard Cisco IOS Software IP routing commands. However, the MDG feature allows for additional failover monitoring that is not available on Layer 2–only Cisco IOS–based Catalyst switches.
When the MDG feature is enabled, the switch pings the configured default gateways every 10 seconds to verify that they are still available. If the primary gateway becomes unavailable, the switch automatically routes the packet to the backup gateway. This prevents the switch from becoming unreachable in case of primary gateway failure for any reason. This behavior is similar to the multiple-gateway feature available in Microsoft Windows XP and 2003.
Use the following command to enable or disable the MDG feature:
set feature mdg {enable | disable}
Example 7-9 shows a user configuring three default gateways and enabling the MDG feature on a Cisco CatOS–based Catalyst 6500 switch.
Example 7-9. Configuration and Verification of the MDG Feature on Cisco CatOS–Based Switches
6500> (enable) set ip route default 10.18.2.21 Route added. 6500> (enable) set ip route default 10.18.2.22 Route added. 6500> (enable) set ip route default 10.18.2.23 Route added. 6500> (enable) show ip route Fragmentation Redirect Unreachable ------------- -------- ----------- enabled enabled enabled The primary gateway: 10.18.2.21 Destination Gateway RouteMask Flags Use Interface --------------- --------------- ---------- ----- -------- --------- default 10.18.2.23 0x0 G 0 sc0 default 10.18.2.22 0x0 G 0 sc0 default 10.18.2.21 0x0 UG 0 sc0 10.18.2.0 10.18.2.145 0xffffff00 U 13 sc0 default default 0xff000000 UH 0 sl0 6500> (enable) set feature mdg enable Multiple Default Gateway feature enabled.
In Example 7-9, the switch selects the first configured default gateway as the primary gateway. To configure the primary gateway explicitly, use the following command:
set ip route default ip-address-of-gateway primary
To summarize, the MDG feature is useful for adding redundancy for the default gateway for maintaining management connectivity for the Catalyst switch itself such that network connectivity from remote subnets is possible in the case of default gateway failure. To reiterate, this feature is available only on Cisco CatOS–based Catalyst switches.
The MAC address notification feature can monitor new devices that connect to the network. In an “Ethernet To The Home (ETTH)” scenario, a typical access layer switch has each user port connecting to a different subscriber to provide network access. The MAC address notification feature helps control access and logs the network access of the subscribers. Furthermore, the MAC address notification feature is a useful troubleshooting tool in specific circumstances.
The MAC address notification feature works by sending Simple Network Management Protocol (SNMP) traps from the switch to a management system upon learning of one or more new MAC addresses on an access port. The information contained in the trap includes the specific port number of the user and the newly learned MAC addresses.
A DHCP server may be used for added flexibility. The DHCP server—upon receiving a request for a new IP address—verifies the MAC address with the switch and port information in its database to make sure the request is from a paying customer port. If this check verifies in the system, the DHCP server grants an IP address to the host, and the associated IP and MAC address information is stored in the database for tracking purposes.
This feature is currently available on the Cisco CatOS–based Catalyst 6500 family of switches and the Cisco IOS–based Catalyst 3750 family of switches.
Perform the following steps to enable the MAC address notification feature:
Enable the MAC address notification feature globally.
set cam notification enableEnable MAC notification for additions or deletions per port, for tracking purposes.
set cam notification {added | deleted} enable {mod/port}
Specify the MAC address notification interval.
set cam notification interval time
Enable the switch to send MAC notification SNMP traps.
set snmp enable macnotification
Example 7-10 shows a user configuring the MAC address notification feature for MAC addresses learned on port 3/47 on a Cisco CatOS–based Catalyst 6500 switch.
Example 7-10. Configuration of MAC Address Notification Feature
6500> (enable) set cam notification enable MAC address change detection globally enabled Be sure to specify which ports are to detect MAC address changes with the 'set cam notification [added | removed] enable <m/p> command. SNMP traps will be sent if 'set snmp trap enable macnotification' has been set. 6500> (enable) set cam notification added enable 3/47 MAC address change notifications for added addresses are enabled on port(s) 3/47. 6500> (enable) set cam notification interval 30 MAC address change notification interval set to 30 seconds This interval will be applied when the process wakes up next time 6500> (enable) set snmp enable macnotification SNMP enabled.
The MAC address notification feature is not currently widely available on Cisco IOS–based Catalyst switches. Currently, the Cisco Catalyst 3750-metro series of switches support this feature in Cisco IOS–based switches.
To summarize, the MAC address notification feature is useful in specific scenarios where the management station needs notification of MAC address changes. This feature is not used as commonly as some of the other features presented in this chapter, but it is nevertheless a valuable one.
Layer 3 (L3) protocol filtering prevents forwarding of broadcast and unknown unicast flood traffic in a VLAN belonging to certain Layer 3 protocols based on configuration. For instance, a port configured for IP only does not forward IPX and AppleTalk broadcast traffic or IPX and AppleTalk unknown unicast traffic.
Catalyst switches classify protocols into the following groups:
IP
IPX
AppleTalk, DECnet, and Banyan VINES (group mode)
Other protocols
The default port protocol configuration is on for IP and auto for other protocol groups. The protocol-filtering configuration also allows explicit configuration of on mode for other protocol groups.
In auto mode, the switch port forwards broadcast and unknown unicast traffic other than the regular traffic of that protocol. For instance, if the port receives an IPX packet, the switch assumes that an IPX device connects to that port, and the switch forwards the broadcast and unknown unicast IPX traffic in addition to the traffic destined to the device using IPX. The switch stops forwarding IPX protocol packets out the respective port if it does not receive an IPX protocol packet within a 60-minute window. On a port configured for off mode for a particular protocol, the switch does not forward packets to or from that port for the specified protocol packets.
Example 7-11 shows the configuration of protocol filtering on ports 3/1 and 3/2. In this example, the administrator disallows IPX on ports 3/1 and 3/2.
Example 7-11. Configuring and Verifying Protocol Filtering on Cisco CatOS–Based Catalyst Switches
6500> (enable) set protocolfilter enable Protocol filtering enabled on this switch. 6500> (enable) set port protocol 3/1-2 ipx off IPX protocol disabled on ports 3/1-2. 6500> (enable) show port protocol 3/1-2 Port Vlan AuxVlan IP IP IPX IPX Group Group Status Hosts Status Hosts Status Hosts -------- ---------- ------- -------- ----- -------- ----- -------- ----- 3/1 1 none on 0 off 0 on 0 3/2 1 none on 0 off 0 on 0 6500> (enable)
Example 7-12 shows the configuration of protocol filtering on Cisco IOS–based Catalyst 6500 on the FastEthernet 5/8 interface. The administrator turns off IP and AppleTalk packet forwarding and turns on IPX packet forwarding for that interface.
Example 7-12. Configuring and Verifying Protocol Filtering on Cisco IOS–Based Catalyst Switches
6500#configure terminal 6500(config)#protocol-filtering 6500(config)#interface FastEthernet 5/8 6500(config-if)#switchport protocol appletalk off 6500(config-if)#switchport protocol ip off 6500(config-if)#switchport protocol ipx on 6500#show protocol-filtering interface FastEthernet 5/8 Interface IP Mode IPX Mode Group Mode Other Mode -------------------------------------------------------------------------- Fa5/8 OFF ON OFF OFF
To summarize, protocol filtering is a useful feature in a multiprotocol environment where devices run certain protocols exclusively but may share the Layer 2 domains with other devices working with different protocols. Protocol-filtering features enable administrators to minimize the extent of traffic being flooded unnecessarily on all ports in a VLAN.
DHCP-based management IP configuration is a convenient feature to allow centralized configuration of IP addresses and switch configuration. The administrator configures the DHCP server with reserved leases that are bound to each switch interface by the MAC address.
The Cisco CatOS–based Catalyst family of switches uses a management interface, sc0, for the switch management. Refer to Chapter 3, “Initial Configuration and Troubleshooting of Cisco Multilayer Switches,” for more information about sc0.
IP configuration through DHCP is possible only for the sc0 management interface. This eliminates the need for manual configuration that may lead to error. In the DHCP server, the supervisor’s MAC address is manually bound to a predetermined IP address. This manual binding ensures that the IP address does not change each time the switch reboots.
To configure the switch to use DHCP for managing IP configuration with Cisco CatOS, use the set interface sc0 0.0.0.0 command and reset the switch. When the module becomes available, the switch sends the DHCP request, as shown in Example 7-13. You can verify the assigned IP address using the show interface command.
Example 7-13. Using DHCP for Management IP Configuration
Sending RARP request with address 00:30:7b:4e:37:ff
Sending DHCP packet with address: 00:30:7b:4e:37:ff
Sending DHCP packet with address: 00:30:7b:4e:37:ff
10.18.2.21 added to DNS server table as primary server.
Default DNS domain name set to cisco.com
2003 May 23 17:28:41 %MGMT-5-DHCP_S:Assigned IP address 10.18.2.1 from DHCP Server
10.18.2.132
6500> (enable) show interface
sl0: flags=51<UP,POINTOPOINT,RUNNING>
slip 0.0.0.0 dest 0.0.0.0
sc0: flags=63<UP,BROADCAST,RUNNING>
vlan 1 inet 10.18.2.1 netmask 255.255.255.0 broadcast 10.18.2.255
sc1: flags=62<DOWN,BROADCAST,RUNNING>
vlan 2 inet 0.0.0.0 netmask 0.0.0.0 broadcast 0.0.0.0
dhcp server: 10.18.2.132To renew the IP configuration manually, use the following command:
set interface sc0 dhcp renewTo release the IP configuration manually, use the following command:
set interface sc0 dhcp releaseOn Cisco IOS–based switches, when you boot your switch, the switch automatically requests configuration information from a DHCP server only if a configuration file is not present on the switch.
DHCP-based IP configuration does not occur under these conditions:
When the switch has a configuration file and the service config global configuration command is disabled.
When the switch has a configuration file present in NVRAM and the service config global configuration command is enabled. In this case, the switch broadcasts TFTP requests for the configuration file.
Note
Without a configuration, the switch executes the setup program by default. Do not respond to any of the questions in the setup program until the switch receives the dynamically assigned IP address from the DHCP server and reads the switch configuration file.
For more information about DHCP-based auto-configuration, refer to the “Configuring the Switch for the First Time” section of the Catalyst 4500 software configuration guide at Cisco.com.
To summarize, DHCP for management of IP configuration is a convenient feature in a network scenario where manual configuration error is possible and a central assignment of IP addresses is preferred.
Jitter tolerance, according to IEEE 802.3-2002, clause 25, shall not exceed 1.4 nanoseconds. However, there have been situations where NICs operating out of spec with respect to excessive jitter may cause repeated link flaps in the Catalyst family of switches. You can address this issue by troubleshooting the NIC and either updating the drivers or replacing the NIC.
However, Catalyst switches provide a workaround in such a scenario by increasing the jitter tolerance on the switch. The debounce timer feature is used to change the jitter tolerance timer such that the switch does not move the link into a down state for noncomplying NICs. It is highly recommended that you troubleshoot auto-negotiation before using this feature.
For more information about troubleshooting auto-negotiation issues with Ethernet ports, refer to the following technical document on Cisco.com:
“Configuring and Troubleshooting Ethernet 10/100/1000Mb Half/Full Duplex Auto-Negotiation,” Document ID: 10561
In Cisco CatOS–based switches, use the following command:
set option debounce enableTable 7-8 shows the port debounce timer with the debounce timer feature disabled and enabled on the Catalyst 6500 family of switches
Table 7-8. Delay Time With and Without the Debounce Timer Feature
Port Type | Delay Time with Debounce Timer Feature Disabled | Delay Time with Debounce Timer Feature Enabled |
|---|---|---|
10BASE-FL | 300 milliseconds | 3100 milliseconds |
10/100BASE-TX | 300 milliseconds | 3100 milliseconds |
100BASE-FX | 300 milliseconds | 3100 milliseconds |
10/100/1000BASE-TX | 300 milliseconds | 3100 milliseconds |
1000BASE-TX | 300 milliseconds | 3100 milliseconds |
1000BASE-FX | 10 milliseconds | 100 milliseconds |
10-Gigabit Ethernet | 1000 milliseconds | 1000 milliseconds |
Caution
Enabling the debounce timer feature causes delays in the detection of link up and down situations, which may cause loss of traffic. Only use this option as a temporary workaround.
Example 7-14 illustrates enabling the debounce timer feature on a Cisco CatOS–based Catalyst 6500 switch for port 3/15, which is connected to a user PC with a NIC operating incorrectly.
Example 7-14. Enabling Debounce Timer Feature on Cisco CatOS–Based Catalyst Switches
6500> (enable) set port debounce 3/15 enable
Debounce is enabled on port 3/15
Warning: Enabling port debounce causes Link Up/Down detections to be delayed.
It results in loss of data traffic during debouncing period, which might
affect the convergence/reconvergence of various Layer 2 and Layer 3 protocols.
Use with caution.It is also possible to change the debounce timer from the default values upon enabling the debounce timer feature. This modifying option is available only for fiber-based Gigabit Ethernet ports.
On Cisco CatOS–based switches, use the following command syntax:
set port debounce {mod/port} delay {time-in-milliseconds}
Example 7-15 shows a user configuring the debounce timer feature on a fiber-based Gigabit Ethernet port 5/2 on a Catalyst 6500 switch.
Example 7-15. Configuration and Verification of Debounce Timer Feature on Cisco CatOS–Based Catalyst 6500 Switches
6500> (enable) set port debounce 5/2 delay 1500 Debounce time for port 5/2 set to 1500 ms. Warning:Enabling port debounce causes Link Up/Down detections to be delayed. It results in loss of data traffic during debouncing period, which might affect the convergence/reconvergence of various Layer 2 and Layer 3 protocols. Use with caution. 6500> (enable) show port debounce 5/3 Port Debounce Debounce status timer ----- -------- --------- 5/2 enabled 1500 ms
On Cisco IOS–based Catalyst switches, use the following interface command to enable the debounce timer feature:
link-debounceOn fiber-based Gigabit Ethernet interfaces, changing the debounce timer is supported using the following command:
link-debounce time debounce-time
Example 7-16 shows a network administrator configuring and verifying a debounce timer of 5000 milliseconds on GigabitEthernet 4/1 on a Cisco IOS–based Catalyst 6500 switch.
Example 7-16. Configuration and Verification of Debounce Timer Feature on Cisco IOS–Based Catalyst Switch
6500(config)#interface GigabitEthernet 4/1 6500(config-if)#link debounce time ? <100-5000> Extended debounce time value 6500(config-if)#link debounce time 5000 Warning: Enabling debounce feature causes link down detection to be delayed 6500#show interfaces GigabitEthernet 4/1 debounce Port Debounce time Value(ms) Gi4/1 enable 5000
To summarize, the debounce timer feature is useful in a scenario where the switch needs to work with out-of-spec NIC workstations or servers. Enabling the debounce timer feature stabilizes the links to those devices and prevents unnecessary network device downtime. The recommended solution to this problem, though, is to replace the faulty NIC or upgrade the NIC driver instead of using the workaround.
Broadcast packets have a unique characteristic in that every device in the broadcast domain processes them. If there is excessive broadcast traffic on a network segment, all devices are affected. Subsequently, if there is a broadcast storm, it ultimately leads to congestion and severe degradation of network performance. Unknown multicast addressed frames get flooded in the VLAN and affect the rest of the devices in the subnet. Hence, it is critical that the network protect against misbehaving faulty devices or malicious attacks caused by excessive multicast or broadcast traffic. Note that excessive broadcasts can also result from misconfiguration of applications or network devices.
The Catalyst family of switches offers the broadcast-suppression feature to alleviate excessive broadcasts. The action taken upon detection of broadcast suppression is to drop the excessive traffic or to disable the port receiving the excessive traffic.
This feature works by monitoring the traffic entering the port over a period of 1 second. If the broadcast traffic exceeds the configured threshold, the switches act on the configured violation action.
In the Catalyst 6500 family of switches, multicast and unicast suppression is configurable on Gigabit Ethernet ports. The feature is similar to broadcast suppression, described previously, except that multicast and unicast suppression controls excessive multicast or unicast traffic as well as broadcast traffic. This feature is extremely useful in controlling congestion and mitigating network loops.
On Cisco CatOS–based switches, use the following command to enable broadcast suppression:
set port broadcast mod/port threshold% [violation {drop-packets | err-disable}] [multicast {enable | disable}][unicast {enable | disable}]
In the command syntax, threshold% is in terms of bandwidth of the port. For example, if you enable the broadcast suppression on a Fast Ethernet, a 10 percent threshold is 10 Mbps of traffic. Specifying a threshold of 100 percent does not suppress traffic. A 0 percent threshold means the switch suppresses all traffic. Choose the threshold percentage based on your network traffic pattern. Furthermore, make sure that you do not set the value too low such that the switch drops legitimate traffic. We recommend enabling broadcast and multicast suppression on user ports in the access layer to limit the amount of broadcast or multicast traffic that a specific host port can transmit into the network.
The violation action is to either drop the packets or err-disable the respective port. The action chosen depends on the network requirements. When a port goes into err-disabled state, the switch displays an error message and generates an SNMP trap message to notify the management station immediately of the excessive traffic.
Example 7-17 illustrates the configuration of broadcast suppression and multicast suppression on Gigabit Ethernet port 2/1 with a threshold set to 5 percent. In this configuration, if the combined broadcast and multicast traffic exceeds the threshold in a 1-second interval, the port transitions into the err-disabled state.
Example 7-17. Configuration and Verification of Broadcast and Multicast Suppression
6500> (enable) set port broadcast 2/1 5% violation err-disable multicast enable Port 2/1 broadcast and multicast traffic limited to 5.00%. On broadcast suppression port 2/1 is configured to move to err-disabled state. 6500> (enable) show port broadcast 2/1 Port Broadcast-Limit Multicast Unicast Total-Drop Action -------- --------------- --------- ------- -------------------- ------------ 2/1 5.00 % 5.00 % - 0 err-disable
Table 7-9 shows support for broadcast, multicast, and unicast suppression features on various Catalyst families of switches.
Table 7-9. Support of Broadcast, Multicast, and Unicast Suppression on the Catalyst Family of Switches
Catalyst Switch | Broadcast Suppression | Multicast Suppression | Unicast Suppression |
|---|---|---|---|
Catalyst 2950/Catalyst 2955/Catalyst 2940/Catalyst 2970 | Yes | Yes | Yes |
Catalyst 3550/Catalyst 3560/Catalyst 3750 | Yes | Yes | Yes |
Catalyst 4500 family | Yes | Yes | Yes |
Catalyst 6500 family | Yes | Yes | Yes |
Cisco IOS–based switches refer to broadcast suppression as storm control. With the storm-control feature, the only violation action is to drop packets for the Cisco IOS–based Catalyst 6500 family of switches. On the Cisco IOS–based Catalyst 4500 family of switches, violations include the shutdown action in addition to the option for dropping the packets. Use the following interface-level command syntax for enabling storm control:
storm-control {broadcast | multicast | unicast} level level
Example 7-18 shows a Cisco IOS–based Catalyst switch configuration of storm control. In this example, the user configures both the broadcast and multicast suppression threshold level to 5 percent.
To summarize, broadcast and multicast suppression aids in preventing unexpected attacks or misbehavior of network devices where an anomalous device sends a large number of broadcasts or multicasts. A large number of broadcasts per second may cause high CPU utilization on the network devices, which in turn may cause network outages. Configuring the suppression feature aids in preventing such outages and increases the stability of the network.
The standard Ethernet frame maximum transmission unit (MTU) is 1500 bytes. This does not include the Ethernet header (14 bytes) and cyclic redundancy check (CRC) trailer (4 bytes), which makes the total Ethernet frame size 1518 bytes. In this section, the MTU size or packet size refers only to the Ethernet payload. Ethernet frame size refers to the whole Ethernet frame, including the header and the trailer.
Baby giant frames are slightly larger than standard Ethernet frames and are designed to accommodate various encapsulations with an MTU of up to 1600 bytes. Some of the applications of baby giants include QinQ (802.1Q on top of 802.1Q tagged frame), Multiprotocol Label Switching (MPLS), Virtual Private Network (VPN), and Layer 2 Tunneling Protocol (L2TP). Figure 7-10 shows the frame formats of several applications that need frame size support greater than the standard MTU size of 1500 bytes.
Note
The datagram size specified in the extended Cisco IOS PING utility refers to the Data field of the frame and does not include the Ethernet header and FCS fields.
A jumbo Ethernet frame is an Ethernet frame whose size is as large as 9236 bytes. The jumbo frame feature is used to increase Ethernet performance.
Theoretically, TCP throughput of a flow directly depends on the frame size of that flow. An example of an application that benefits from the jumbo frame feature is the NFS file transfer application. Servers require special NICs to send and receive jumbo frames. Nevertheless, jumbo frame support is becoming a standard feature of current-model NICs.
The Catalyst family of switches supports baby giants and the jumbo frame feature with many variations, but none of the Catalyst switches supports these features consistently on all of its modules. Also, if a frame gets forwarded from an interface that supports jumbo frames to an interface on the same switch in the same VLAN that does not support jumbo frames, the switch drops the frame because it can send only frames of the allowed size out of the egress interface. To avoid such a problem, make sure that all the interfaces that are communicating within a VLAN have jumbo frame support enabled.
If jumbo frames need to be routed between VLANs or subnets, the routing device needs to be configured to accept jumbo frames and to then fragment the frames if the egress interface does not support jumbo frames. Typically, the fragmentation and forwarding between VLANs is accomplished by software switching; it is not recommended to use software switching, however, because performance is decreased while the likelihood of higher CPU utilization is increased. As a result, the performance gain of using jumbo frames is lost.
The support of baby giant and jumbo frames varies across the Catalyst family of switches, as Table 7-10 briefly highlights.
Table 7-10. Support of Baby Giants and Jumbo Frames on Catalyst Switches
Catalyst Switch | Baby Giant Support | Jumbo Frame Support |
|---|---|---|
Catalyst 2940 | No | No |
Catalyst 2950/Catalyst 2955 | Yes (on some models) | No |
Catalyst 2970 | Yes | Yes |
Catalyst 3550 | Yes | No |
Catalyst 3560/Catalyst 3750 | Yes | Yes |
Catalyst 4500 family | Yes | Yes |
Catalyst 6500 family | Yes | Yes |
For more information, see the following technical documents at Cisco.com:
“Configuring Jumbo/Giant Frame Support on Catalyst Switches,” Document ID: 24048
“Understanding Baby Giant/Jumbo Frames Support on Catalyst 4000/4500 with Supervisor III/IV,” Document ID: 29805
Example 7-19 shows the configuration and verification of jumbo frame support on port 2/1 on a Cisco CatOS–based Catalyst 6500 switch.
On Cisco IOS–based switches, use the following global-level command to configure a baby giant:
system mtu size
This MTU size configuration is applicable to all interfaces in the system that have hardware support for it.
To enable jumbo frames, use the following interface-level command:
mtu size
Example 7-20 shows the configuration and verification of baby giant support globally and jumbo frame support on interface Gigabit Ethernet 1/1, respectively, on a Cisco IOS–based Catalyst 4500 switch.
Example 7-20. Configuration and Verification of Baby Giant and Jumbo Frame Support on Cisco IOS–Based Catalyst Switches
4506(config)#system mtu 1552 Global Ethernet MTU is set to 1552 bytes. Note: this is the Ethernet payload size, not the total Ethernet frame size, which includes the Ethernet header/trailer 4506(config)#interface gigabitEthernet 1/1 4506(config-if)#mtu ? <1500-9198> MTU size in bytes 4506(config-if)#mtu 9198 4506(config-if)#end 4506#show system mtu Global Ethernet MTU is 1552 bytes. 4506#show interfaces GigabitEthernet 1/1 mtu Port Name MTU Gi1/1 9198
To summarize, baby giant and jumbo frame support provides support for frames greater than the standard Ethernet MTU size. Larger frame sizes are needed to support various encapsulations such as QinQ and to achieve higher TCP throughput. Also, make sure that there is no requirement for fragmentation (for example, switching jumbo frame packets to an interface that does not support jumbo frames), because fragmentation may lead to slower performance than using standard Ethernet frame sizes across the entire network.
The error-disable feature allows the switch to detect certain error conditions on interfaces and disable them before the error condition affects the entire switch or the rest of the network. The error-disable feature can be activated for many error conditions, and it varies slightly per Catalyst switch and software version. For example, the Catalyst 4500 series switches can detect the following error conditions:
UDLD
BPDU guard detection
Port-security violation
EtherChannel misconfiguration
VMPS client violation
PAgP flapping
DTP flapping
Link flapping
L2PT guard
Invalid GBIC
DHCP rate limit violation
Unicast flood
Storm control
ARP inspection
When any one of the supported error conditions is detected, the switch can be configured to transition the interface into the err-disable state, which is an operational state similar to the link-down state.
There are two ways to recover from this error-disabled state of an interface:
Manual recovery—. Issue the shutdown command followed by the no shutdown interface level command to recover the error-disabled interface on Cisco IOS–based Catalyst switches. On Cisco CatOS–based switches, use the set port disable mod/port command followed by the set port enable mod/port command.
Automatic recovery—. The switch can be configured to automatically recover the error-disabled interface after a specified interval.
Note
If the error condition persists after the manual or automatic recovery, the interface goes into the error-disabled state again. Fixing the root cause of the problem prevents interfaces from error-disabling after the recovery.
To enable detection for the error-disable feature, use the following command on Cisco IOS–based Catalyst switches:
errdisable detect cause {all | arp-inspection | dhcp-rate-limit | dtp-flap | gbic-invalid | l2ptguard | link-flap | pagp-flap}
Note
The error-disable feature is already integrated into features such as UDLD and Port-Security; hence, explicit enabling of those error condition causes is not required.
To enable automatic recovery from error-disabled condition, use the following command on Cisco IOS–based Catalyst switches:
errdisable recovery cause {all | arp-inspection | bpduguard | channel-misconfig | dhcp-rate-limit | dtp-flap | gbic-invalid | l2ptguard | link-flap | pagp-flap | pesecure-violation | security-violation | storm-control | udld | unicastflood | vmps}
To enable automatic recovery on Cisco CatOS–based Catalyst switches, use the following command:
set errdisable-timeout {enable | disable} {bpdu-guard | channel-misconfig | duplex-mismatch | udld | other | all}
To specify the interval for attempting to recover from error-disabled state, use the following command on Cisco IOS–based Catalyst switches.
errdisable recovery interval interval
To specify the interval for recovery, use the following command on Cisco CatOS–based Catalyst switches:
set errdisable-timeout interval interval-in-seconds
Example 7-21 shows a user configuring the error-disable feature detection and recovery for all supported conditions. In addition, the user increases the recovery interval to 60 seconds from the default 30 seconds. Finally, the user verifies the configuration changes using the show commands.
Example 7-21. Configuration and Verification of the Error-Disable Feature
4500#configure terminal Enter configuration commands, one per line. End with CNTL/Z. 4500(config)#errdisable detect cause all 4500(config)#errdisable recovery cause all 4500(config)#errdisable recovery interval 60 4500(config)#end 4500#show errdisable detect ErrDisable Reason Detection status ----------------- ---------------- udld Enabled bpduguard Enabled security-violatio Enabled channel-misconfig Enabled psecure-violation Enabled vmps Enabled loopback Enabled unicast-flood Enabled pagp-flap Enabled dtp-flap Enabled link-flap Enabled l2ptguard Enabled gbic-invalid Enabled dhcp-rate-limit Enabled unicast-flood Enabled storm-control Enabled ilpower Enabled arp-inspection Enabled 4500#show errdisable recovery ErrDisable Reason Timer Status ----------------- -------------- udld Enabled bpduguard Enabled security-violatio Enabled channel-misconfig Enabled vmps Enabled pagp-flap Enabled dtp-flap Enabled link-flap Enabled l2ptguard Enabled psecure-violation Enabled gbic-invalid Enabled dhcp-rate-limit Enabled unicast-flood Enabled storm-control Enabled arp-inspection Enabled loopback Enabled Timer interval: 60 seconds Interfaces that will be enabled at the next timeout:
Example 7-22 shows the error-disable feature in action where the BPDU guard feature error-disables an interface and the automatic recovery of error-disable feature recovers the interface after the specified interval. However, because the misconfiguration persists, the interface is immediately moved to the error-disabled state again. After the misconfiguration is corrected, the interface is recovered.
Example 7-22. Error-Disable Feature in Action Sample Output
4500# *Oct 30 04:09:12.623: %SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port GigabitEthernet1/1 with BPDU Guard enabled. Disabling port. 4500# *Oct 30 04:09:12.623: %PM-4-ERR_DISABLE: bpduguard error detected on Gi1/1, putting Gi1/1 in err-disable state 4500#show interfaces gigabitEthernet 1/1 status Port Name Status Vlan Duplex Speed Type Gi1/1 err-disabled 10 full 1000 1000BaseSX 4500#show errdisable recovery ErrDisable Reason Timer Status ----------------- -------------- udld Enabled bpduguard Enabled security-violatio Enabled channel-misconfig Enabled vmps Enabled pagp-flap Enabled dtp-flap Enabled link-flap Enabled l2ptguard Enabled psecure-violation Enabled gbic-invalid Enabled dhcp-rate-limit Enabled unicast-flood Enabled storm-control Enabled arp-inspection Enabled loopback Enabled Timer interval: 60 seconds Interfaces that will be enabled at the next timeout: Interface Errdisable reason Time left(sec) --------- ----------------- -------------- Gi1/1 bpduguard 28 4500# *Oct 30 04:10:04.299: %PM-4-ERR_RECOVER: Attempting to recover from bpduguard err- disable state on Gi1/1 *Oct 30 04:10:08.643: %SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port GigabitEthernet1/1 with BPDU Guard enabled. Disabling port. *Oct 30 04:10:08.643: %PM-4-ERR_DISABLE: bpduguard error detected on Gi1/1, putting Gi1/1 in err-disable state 4500#configure terminal Enter configuration commands, one per line. End with CNTL/Z. 4500(config)#interface gigabitEthernet 1/1 4500(config-if)#spanning-tree bpduguard disable 4500(config-if)#end 4500# 4500#show interfaces gigabitEthernet 1/1 status Port Name Status Vlan Duplex Speed Type Gi1/1 err-disabled 10 full 1000 1000BaseSX 4500# *Oct 30 04:11:02.011: %PM-4-ERR_RECOVER: Attempting to recover from bpduguard err- disable state on Gi1/1 4500#show interfaces gig 1/1 status Port Name Status Vlan Duplex Speed Type Gi1/1 connected 10 full 1000 1000BaseSX
To summarize, the error-disable feature is an essential feature to prevent error conditions on one or more ports from affecting the entire switch or the rest of the network. This feature is a recommended best practice configuration.
The IEEE 802.3 flow control feature is used to prevent the loss of traffic between two devices. This loss of traffic is due to buffer overflow on the receiving device. The amount of receiver buffer on the sending and receiving device might not be the same, even though either side is operating at the same speed. Also, the receiving device might not be able to empty receive buffers fast enough due to bottleneck issues within that device or from downstream switches. Similar issues happen between Catalyst switches and servers with Gigabit NICs. To prevent loss of traffic in these scenarios, the IEEE 802.3 flow control feature enables communication between the link partners about buffer full conditions of the receive buffer. When a link partner discovers that its peer is in a buffer full condition, it ceases transmitting traffic until its peer communicates that it is capable of accepting traffic again. This feature complements QoS and is useful in preventing buffer overflow and packet loss.
Note
IEEE 802.3 flow control is commonly called IEEE 802.3z to refer to the first version introduced for Gigabit Ethernet. Currently, flow control is supported for Fast Ethernet as well.
IEEE 802.3 uses specific frames called pause frames used to instruct its link partner to delay sending frames for a specified time. The specified time is not user configurable and is decided by the receiving switch port logic. Figure 7-11 shows a Catalyst switch using pause frames to instruct a file server to delay sending frames for a specified time due to congestion.
To configure IEEE 802.3 flow control, use the following interface command on Cisco IOS switches:
[no] flowcontrol [receive | send] {desired | off | on}
The receive keyword instructs the configured interface whether or not to process the received pause frames. The send keyword instructs the configured interface whether to send pause frames when congestion is experienced. The desired keyword is used if the link partner 802.3 flow control configuration is unknown.
Example 7-23 shows sample output of user configuration and verification of IEEE 802.3 flow control on a Cisco IOS–based Catalyst switch.
Example 7-23. Configuration and Verification IEEE 802.3 Flow Control on a Cisco IOS–Based Catalyst Switch
6500#configure terminal Enter configuration commands, one per line. End with CNTL/Z. 6500(config)#interface gigabitEthernet 1/1 6500(config-if)#flowcontrol receive on 6500(config-if)#flowcontrol send on 6500(config-if)#end 6500#show flowcontrol interface gigabitEthernet 1/1 Port Send FlowControl Receive FlowControl RxPause TxPause admin oper admin oper --------- -------- -------- -------- -------- ------- ------- Gi1/1 on on on on 0 0
Example 7-24 shows sample output of user configuration and verification of IEEE 802.3 flow control on a Cisco CatOS–based Catalyst switch.
Example 7-24. Configuration and Verification of Flow Control on CatOS–Based Catalyst Switches
Cat6500 (enable) set port flowcontrol 2/4 receive on Port 2/4 flow control receive administration status set to on (port will require far end to send flowcontrol) Cat6500 (enable) set port flowcontrol 2/4 send on Port 2/4 flow control send administration status set to on (port will send flowcontrol to far end) Cat6500 (enable) show port flowcontrol 2/4 Port Send FlowControl Receive FlowControl RxPause TxPause Unsupported admin oper admin oper opcodes ----- -------- -------- --------- --------- ---------- ---------- ----------- 2/4 on disagree on on 0 0 0
To summarize, IEEE 802.3 flow control prevents packet loss in oversubscribed scenarios and is a recommended configuration for critical and high-end servers and workstations.
The UDLD protocol allows for detection of unidirectional link conditions on switch ports in situations where a link remains in the up state but the interface is not passing traffic. This situation typically arises in the case of faulty Gigabit Interface Converters (GBIC) or interfaces, software malfunction, hardware failure, or other anomalous behavior. UDLD aids in preventing catastrophic events that may occur during these types of failures.
UDLD is a Layer 2 protocol that works with Layer 1 mechanisms to determine the physical status of a link. At Layer 1, auto-negotiation takes care of the physical signaling and fault detection. UDLD performs tasks that auto-negotiation cannot, such as detecting the identities of neighbors and shutting down misconnected ports. When enabling both auto-negotiation and UDLD, Layer 1 and Layer 2 detections work together to prevent physical and logical unidirectional connections and the malfunctioning of other protocols.
With UDLD enabled, the switch periodically sends UDLD protocol packets to its neighbor and expects the packets to be echoed back before a predetermined timer expires. If the timer expires, the switch determines the link to be unidirectional and shuts down the port.
UDLD packets contain information about sending the port’s device ID and port ID and the neighbor’s device ID and port ID. Neighbor devices with UDLD enabled send the same hello message. The link is bidirectional if devices on both sides receive each other’s UDLD packets.
Consider the network scenario shown in Figure 7-12 where the following is true:
Switch A’s tx strand is connected to switch B.
Switch A’s rx strand is connected to switch C.
Switch B’s tx strand is connected to switch C.
In Figure 7-12, the UDLD protocol on switch A detects that it is receiving UDLD advertisement from switch C, but switch C is advertising switch B as its neighbor. All switches in this topology detect the miswiring and potentially err-disable the ports. Note that when one link partner err-disables a port, the other link partner does not err-disable the port, because the link has already transitioned to the down state.
The default interval for UDLD message is 15 seconds, which is configurable for faster detection.
Aggressive mode UDLD is a variation of UDLD that provides additional benefits, as shown in Table 7-11. With aggressive mode UDLD enabled, when a port stops receiving UDLD packets, UDLD tries to re-establish the connection with the neighbor. After eight failed retries, the port state changes to the err-disable state, which effectively disables the port.
Table 7-11. Differences in Behavior Between UDLD and Aggressive Mode UDLD
UDLD State | Aggressive Mode UDLD State | |
|---|---|---|
Link is bidirectional; no issues. | Bidirectional. | Bidirectional. |
Layer 1 remains up but with unidirectional link condition. | An error message is displayed and the port is put into the err-disable state. | An error message is displayed, and the port is put into the err-disable state. |
One side of a link has a port stuck (both tx and rx). | Undetermined. | An error message is displayed, and the port is put into the err-disable state. |
One side of a link remains up while the other side of the link has gone down. | Undetermined. | An error message is displayed, and the port is put into the err-disable state. |
To re-enable the port after correcting the problem, use the following interface-level commands in Cisco IOS–based Catalyst switches:
shutdown no shutdown
In Cisco CatOS–based Catalyst switches, use the following commands to recover an err-disabled port:
set port disable mod/port set port enable mod/port
Spanning Tree Protocol prevents loops in the network by detecting loops and blocking the redundant ports. This loop detection is based on BPDUs received on switch ports. If a switch receives the same root BPDU from more than one port, it chooses the best port to the root bridge and blocks the other, redundant ports. Because receiving BPDUs is a critical part of the loop-prevention process, it is important to detect unidirectional links by another method to ensure that BPDUs are sent in the appropriate direction on all links at all times. Otherwise, a unidirectional link ultimately leads to spanning-tree loops or black holes for routed traffic. For instance, if a Layer 3 or routed interface is experiencing a unidirectional link condition but the interface, stays up, the switch continues to forward traffic to that interface but the packet never reaches the far-end device. In this situation, a routing black hole exists. The solution to preventing these issues is to use aggressive mode UDLD.
To illustrate this concept, consider the three switches shown in Figure 7-13. Switch A is the root bridge, and the link between switch B and switch C is in the blocking state because a physical loop is present in the network.
Now consider a situation where the link between switches B and C becomes unidirectional, as shown in Figure 7-14. Switch B can receive traffic from switch C, but switch C cannot receive traffic from switch B. On the segment between switches B and C, switch B is the designated bridge sending the root BPDUs, and switch C expects to receive the BPDUs.
Switch C waits until the max-age timer (20 seconds) expires before it takes action. When this timer expires, switch C moves through the listening and learning states of STP and then eventually to the STP forwarding state on the port toward switch B. At this moment, both switch B and switch C are forwarding to each other and, essentially, there is no blocking port in the network. This situation is a network loop where severe connectivity issues will exist.
Aggressive mode UDLD running on switches B and C in this scenario would detect the condition and would be able to take corrective action before STP moves into the forwarding state.
UDLD works by exchanging UDLD protocol packets between connected switches. For UDLD to function correctly, it must be enabled on switches on both sides of the link. A UDLD-enabled switch sends UDLD protocol packets with its own device ID and port ID to the neighboring device. The UDLD is in determined status if the switch sees its own information in the packet sent by the neighbor. If the device does not see itself in the neighboring device’s UDLD protocol packets, the link is determined as unidirectional.
Example 7-25 shows a user configuring and verifying aggressive mode UDLD on interface GigabitEthernet 5/1 on a Cisco IOS-based Catalyst switch.
Example 7-25. Configuration and Verification of UDLD on Cisco IOS–Based Switches
SwitchA#configure terminal Enter configuration commands, one per line. End with CNTL/Z. SwitchA(config)#interface gigabitEthernet 5/1 SwitchA(config-if)#udld port aggressive SwitchA(config-if)#end SwitchA# SwitchA#show udld gigabitEthernet 5/1 Interface Gi5/1 --- Port enable administrative configuration setting: Enabled / in aggressive mode Port enable operational state: Enabled / in aggressive mode Current bidirectional state: Bidirectional Current operational state: Advertisement - Single neighbor detected Message interval: 15 Time out interval: 5 Entry 1 --- Expiration time: 38 Device ID: 1 Current neighbor state: Bidirectional Device name: FOX06310RW1 Port ID: Gi1/1 Neighbor echo 1 device: FOX0627A001 Neighbor echo 1 port: Gi5/1 Message interval: 15 Time out interval: 5 CDP Device name: SwitchB
Example 7-26 shows a user configuring and verifying aggressive mode UDLD on port 3/47 on a Cisco CatOS–based Catalyst switch.
Example 7-26. Configuration and Verification of UDLD on Cisco CatOS–Based Switches
6500> (enable) set udld enable UDLD enabled globally 6500> (enable) set udld enable 3/47 UDLD enabled on port 3/47 6500> (enable) set udld aggressive-mode enable 3/47 Aggressive mode UDLD enabled on port 3/47. 6500> (enable) show udld port 3/47 UDLD : enabled Message Interval : 15 seconds Port Admin Status Aggressive Mode Link State -------- ------------ --------------- ---------------- 3/47 enabled enabled bidirectional
To summarize, UDLD and aggressive mode UDLD are critical features recommended on all ports to prevent various issues that may potentially cause network outages.
This case study illustrates the advantages of aggressive mode UDLD using a Cisco CatOS–based Catalyst 6500 switch and Cisco IOS–based Catalyst 3550 switch interconnected by a fiber-based Gigabit Ethernet port, as shown in Figure 7-15.
To simulate a UDLD link failure, the tx fiber strand was removed from the Catalyst 6500 port 2/1, leaving the rx fiber still receiving frames from the Catalyst 3550, as shown in Figure 7-15. To illustrate the behavior of UDLD in this example, auto-negotiation was disabled because auto-negotiation will detect the link-down status if the fiber strand fails. In a normal network scenario, auto-negotiation should remain enabled. If the link fails, auto-negotiation takes care of bringing the link down correctly. UDLD protects in cases where the link remains in the up state but behaves unidirectionally in the event of a hardware or software failure. To summarize, auto-negotiation is disabled in this case study, as shown in Example 7-27, to illustrate aggressive mode UDLD behavior compared to normal UDLD mode and is not a recommended practice.
Example 7-27. Disabling Auto-Negotiation on a CatOS–Based Catalyst 6500 Switch
6500> (enable) set port negotiation 2/1 disable Port 2/1 negotiation disabled. 6500> (enable) show port negotiation 2/1 Port Link Negotiation Link Negotiation admin oper ----- ---------------- ---------------- 2/1 disabled disabled
Examples 7-28 and 7-29 display the UDLD state with UDLD enabled on both sides and with aggressive mode UDLD disabled.
Example 7-29. Checking the UDLD Status on Catalyst 3550 Switches
3550#show udld GigabitEthernet 0/1
Interface Gi0/1
---
Port enable administrative configuration setting: Enabled
Port enable operational state: Enabled
Current bidirectional state: Bidirectional
Current operational state: Advertisement - Single neighbor detected
Message interval: 15
Time out interval: 5
Entry 1
---
Expiration time: 42
Device ID: 1
Current neighbor state: Bidirectional
Device name: 00307b4e3400
Port ID: 2/1
Neighbor echo 1 device: CAT0606X0AL
Neighbor echo 1 port: Gi0/1
Message interval: 5
CDP Device name: TBA03501074(6500)Now the tx fiber strand of port 2/1 on the Catalyst 6500 is removed. The Catalyst 3550 shows the link-down status, whereas the Catalyst 6500 shows the port in connected status, as illustrated in Examples 7-30 and 7-31.
Example 7-31. Checking the Interface Status of the Fiber Link on a Catalyst 3550 Switch
3550#show interfaces GigabitEthernet 0/1
GigabitEthernet0/1 is down, line protocol is down (notconnect)
Hardware is Gigabit Ethernet, address is 0008.a391.0399 (bia 0008.a391.0399)
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Auto-duplex, Auto-speed
input flow-control is off, output flow-control is off
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:01:58, output 00:01:58, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue :0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
2268443 packets input, 166039787 bytes, 0 no buffer
Received 2149615 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 2149131 multicast, 0 pause input
0 input packets with dribble condition detected
618068374 packets output, 2539581729 bytes, 0 underruns
0 output errors, 0 collisions, 28 interface resetsThe Cisco Catalyst 6500 maintains the link because auto-negotiation is purposefully disabled. The UDLD state changes to undetermined on the Catalyst 6500, as shown in Example 7-32. Catalyst 3550 displays the current operational status as link down, as shown in Example 7-33.
Example 7-32. Verification of UDLD Configuration on Cisco CatOS–Based Catalyst 6500 Switches
6500> (enable) show udld port 2/1 UDLD : enabled Message Interval : 15 seconds Port Admin Status Aggressive Mode Link State -------- ------------ --------------- ---------------- 2/1 enabled disabled undetermined 6500> (enable) 6500> (enable) show spantree 2/1 Port Vlan Port-State Cost Prio Portfast Channel_id ------------------------ ---- ------------- --------- ---- -------- ---------- 2/1 1 forwarding 4 32 disabled 0 6500> (enable)
Example 7-33. Verification of UDLD Configuration on Catalyst 3550 Switches
3550#show udld GigabitEthernet 0/1
Interface Gi0/1
---
Port enable administrative configuration setting: Enabled
Port enable operational state: Enabled
Current bidirectional state: Bidirectional
Current operational state: Link down
Message interval: 15
Time out interval: 5
No neighbor cache information stored
Switch#The UDLD scenario described in this section would lead to a routing black hole because the Catalyst 3550 interface is not up and operational but the Catalyst 6500 switch is still transmitting. To prevent this type of failure, use aggressive mode UDLD. In Examples 7-34 and 7-35, aggressive mode UDLD was enabled on both the switches after connectivity was restored.
Example 7-34. Configuration and Verification of Aggressive Mode UDLD on Cisco CatOS–Based Catalyst 6500 Switches
6500> (enable) set udld aggressive-mode enable 2/1 Aggressive mode UDLD enabled on port 2/1. Warning: Aggressive Mode for UniDirectional Link Detectionb should be enabled only on ports not connected to hubs, media converters or similar devices. 6500> (enable) show udld port 2/1 UDLD : enabled Message Interval : 15 seconds Port Admin Status Aggressive Mode Link State -------- ------------ --------------- ---------------- 2/1 enabled enabled bidirectional
Example 7-35. Configuration and Verification of Aggressive Mode UDLD on Catalyst 3550 Switches
3550(config)#interface GigabitEthernet 0/1 3550(config-if)#udld port aggressive 3550#show udld GigabitEthernet 0/1 Interface Gi0/1 --- Port enable administrative configuration setting: Enabled / in aggressive mode Port enable operational state: Enabled / in aggressive mode Current bidirectional state: Bidirectional Current operational state: Advertisement – Single neighbor detected Message interval: 15 Time out interval: 5 Entry 1 --- Expiration time: 40 Device ID: 1 Current neighbor state: Bidirectional Device name: 00307b4e3400 Port ID: 2/1 Neighbor echo 1 device: CAT0606X0AL Neighbor echo 1 port: Gi0/1 Message interval: 5 CDP Device name: TBA03501074(6500) Switch#
If the tx strand of fiber is now removed from port 2/1, the 6500 switch detects the UDLD condition and err-disables the port, as shown in Example 7-36.
Example 7-36. Aggressive Mode UDLD Err-Disables the Port
2003 Jun 07 15:13:58 %UDLD-3-AGGRDISABLE:Neighbor(s) of port 2/1 disappeared on
bidirectional link. Port disabled
2003 Jun 07 15:13:58 %ETHC-5-PORTFROMSTP:Port 2/1 left bridge port 2/1
6500> (enable) show port status 2/1
Port Name Status Vlan Duplex Speed Type
----- -------------------- ---------- ---------- ------ ----- ------------
2/1 err-disable 1 full 1000 1000-LX/LHThis behavior demonstrates that aggressive mode UDLD is the preferable configuration over UDLD because it prevents black holes in the network by actively err-disabling interfaces instead of just informing the system of a unidirectional link. In addition, UDLD sends SNMP traps to the network management station, which are configurable as trigger alarms. These alarms can be set to notify the network administrator immediately upon a UDLD condition. The biggest advantage to aggressive mode UDLD is that it prevents spanning-tree loops, as described in the previous section.
The following bullets review important BCMSN exam preparation points of this chapter. The bullets only briefly highlight the main points of this chapter related to the BCMSN exam. Consult the text of this chapter for additional information regarding these topics. Table 7-12 lists important commands to review for the BCMSN exam:
Two variations of the EtherChannel protocol exist—PagP and LACP.
Catalyst switches support up to eight ports in an EtherChannel.
CDP is a useful Cisco proprietary protocol to collect value information about neighboring devices in a network; however, CDP is considered a security risk on public interfaces.
MAC address notification is used in service provider environments to track MAC addresses and control user access.
The debounce timer feature enables Catalyst switches to work with noncompliant NICs by providing administrators the ability to configure higher jitter tolerance.
Using the baby giant and jumbo frame features can increase TCP throughput performance between servers and allow various encapsulated packets to travel through the switch.
DHCP for management IP configuration of Catalyst switches eases IP address assignment and avoids manual configuration.
UDLD and aggressive mode UDLD prevent network outages due to hardware, software, or physical-layer fault resulting in unidirectional links.
IEEE 802.3 flow control helps to prevent packet loss when a downstream switch receive buffer is full. Pause frames are sent to the upstream switch to indicate the congestion condition.
The Layer 3 protocol filtering feature filters certain Layer 3 protocol packets from entering the network.
The broadcast and multicast suppression feature prevents an unauthorized or malfunctioning device from flooding and disrupting the network.
The error-disable feature prevents many erroneous conditions that generally disrupt the multilayer switch network. The error-disable features prevent these conditions by error-disabling (shutting down) the interface in question. In addition, error-disable is a major function of other features such as BPDU guard, UDLD, and so on.
Table 7-12. Commands to Review
Command | Description |
|---|---|
(config)#errdisable detect cause [all | arp-inspection | dhcp-rate- limit | dtp-flap | gbic-invalid | l2ptguard | link-flap | pagp-flap] | Configures error-disable feature detection causes |
(config-if)#channel-group group- number mode {active | auto | desirable | on | passive} | Configures the interface to be part of a EtherChannel group in the specified mode of operation |
(config-if)#udld port aggressive | Configures aggressive mode UDLD on the interface regardless of global default |
errdisable recovery cause {all | arp-inspection | bpduguard | channel-misconfig | dhcp-rate-limit | dtp-flap | gbic-invalid | l2ptguard | link-flap | pagp-flap | pesecure- violation | security-violation | storm-control | udld | unicastflood | vmps} | Configures error-disable feature recovery causes |
show cdp neighbor | Displays information about neighboring devices discovered via CDP |
show cdp neighbor detail | Displays detailed information about neighboring devices discovered via CDP |
show etherchannel summary | Displays a one-line summary for each EtherChannel group |
show interface | Displays status and statistics regarding all the interfaces present in the system |
show interfaces interface-id switchport | Displays information related to switchport configuration of the specified interface |
show interfaces interface-id trunk | Displays information related to trunk configuration for the specified interface |
show interfaces port-channel {port- channel-interface-number} | Displays the status and statistics information regarding the specified EtherChannel interface |
show ip interface brief | Displays the status of IP protocol information of all interfaces present in the system |
show ip protocols | Displays information regarding IP configured routing protocol process parameters and statistics |
show ip route | Displays the IP routing table |
show running-config | Displays the running configuration of the system |
show udld interface-id | Displays the UDLD status information for the specified interface |
show version | Displays the software and hardware version running on the system |
Layer 2 and Layer 3 advanced features discussed in this chapter are essential to enhance network performance and to prevent unexpected network outages.
The features described in this chapter are not required in every network scenario. The administrator needs to understand and apply the features on appropriate switches to achieve maximum benefit.
Complete this configuration exercise to practice features discussed in this chapter.
The following resources and equipment are required to complete this exercise:
Catalyst switches, as shown in Figure 7-16
Terminal server connected to the console port of each laboratory device
PC connected to the terminal server to access the devices
The devices in the network should be connected and ready for use. In this exercise, you configure and verify some of the features reviewed in this chapter.
After completing this exercise, you will be able to
Configure and verify PAgP EtherChannel
Configure and verify LACP EtherChannel
Configure and verify CDP
Configure and verify UDLD and aggressive mode UDLD
Configure and verify jumbo frames
Configure and verify error-disable
Figure 7-16 shows the network layout for this configuration exercise.
In this configuration exercise, you use the commands listed in Table 7-13. The commands are listed in alphabetical order so that you can easily locate the information you need. Refer to this table if you need configuration command assistance during the exercise.
Table 7-13. Command List for Configuration Exercise
Command | Description |
|---|---|
cdp enable | Enables CDP protocol on a per-interface basis. To disable CDP on a per-interface basis, use the no cdp enable command. |
cdp run | Enables CDP protocol globally on the router or switch. |
channel-group port- channel-number mode desirable | Assigns and configures an interface to a PAgP EtherChannel. |
channel-protocol lacp | Specifies the EtherChannel protocol as LACP. |
channel-group group-number mode active | Assigns and configures an interface to an LACP EtherChannel. |
configure terminal | From privileged EXEC mode, enters global configuration mode. |
end | Exits configuration mode. |
errdisable detect cause all | Enables error-disable detection for all supported error conditions. |
errdisable recovery cause all | Enables error-disable recovery for all supported error conditions. |
exit | Exits the current mode. |
interface FastEthernet | GigabitEthernet slot/port | Enters interface configuration mode for a Catalyst switch with a Fast Ethernet or Gigabit Ethernet interface installed. |
mtu size | Configures MTU size up to jumbo frame sizes (9k) on an interface of a Catalyst 4500 switch. |
show cdp | Displays the CDP protocol status and parameters on the device. |
show cdp neighbors | Displays a list of all the neighboring devices discovered through the CDP protocol. |
show errdisable detect | Displays the status of the error-disable detection causes configured on the switch. |
show errdisable recovery | Displays the status of the error-disable recovery causes configured on the switch as well as any interfaces about to be recovered from an error condition. |
show etherchannel summary | Displays EtherChannel information for a channel with a one-line summary per channel group. |
show interfaces mtu module module-number | Displays the configured MTU value of interfaces belonging to a specified module. |
show running-config module module-number | Displays running configuration of the specific module. |
udld port aggressive | Enables aggressive mode UDLD on an interface in Cisco IOS. |
For EtherChannel to work properly, make sure the ports on Switch A, B, and C are configured similarly. To do so, use the show running-config interface interface-id or show running-config module module-number command on the Cisco IOS–based switches.
SwitchA#show running-config module 5 Building configuration... Current configuration : 191 bytes ! interface GigabitEthernet5/1 ! interface GigabitEthernet5/2 ! interface GigabitEthernet5/3 ! interface GigabitEthernet5/4 ! interface GigabitEthernet5/5 ! interface GigabitEthernet5/6 end ___________________________________________________________________ SwitchB#show running-config module 1 Building configuration... Current configuration : 67 bytes ! interface GigabitEthernet1/1 ! interface GigabitEthernet1/2 end ___________________________________________________________________ SwitchC#show running-config module 1 Building configuration... Current configuration : 67 bytes ! interface GigabitEthernet1/1 ! interface GigabitEthernet1/2 end
Configure a Layer 2 EtherChannel between Switch A and B using the PAgP protocol. To do so, use the interface-level channel-group group-id command on Cisco IOS–based switches.
SwitchA#configure terminal Enter configuration commands, one per line. End with CNTL/Z. SwitchA(config)#interface gigabitEthernet 5/1 SwitchA(config-if)#channel-group 10 mode desirable Creating a port-channel interface Port-channel 10 SwitchA(config-if)#interface gigabitEthernet 5/2 SwitchA(config-if)#channel-group 10 mode desirable SwitchA(config-if)#end SwitchA# *Nov 7 13:14:28: %SYS-5-CONFIG_I: Configured from console by console *Nov 7 13:14:55: %EC-5-BUNDLE: Interface GigabitEthernet5/1 joined port-channel Port-channel10 *Nov 7 13:14:59: %EC-5-BUNDLE: Interface GigabitEthernet5/2 joined port-channel Port-channel10 ___________________________________________________________________ SwitchB#configure terminal Enter configuration commands, one per line. End with CNTL/Z. SwitchB(config)#interface gigabitEthernet 1/1 SwitchB(config-if)#channel-group 10 mode desirable Creating a port-channel interface Port-channel 10 SwitchB(config-if)#interface gigabitEthernet 1/2 SwitchB(config-if)#channel-group 10 mode desirable SwitchB(config-if)#end 6w2d: %EC-5-BUNDLE: Interface GigabitEthernet1/1 joined port-channel Port-channel10 SwitchB# 6w2d: %SYS-5-CONFIG_I: Configured from console by console 6w2d: %EC-5-BUNDLE: Interface GigabitEthernet1/2 joined port-channel Port-channel10
Verify the PAgP EtherChannel operational status using the show etherchannel summary command on Cisco IOS–based switches.
SwitchA#show etherchannel summary Flags: D - down P - in port-channel I - stand-alone s - suspended R - Layer3 S - Layer2 U - in use f - failed to allocate aggregator u - unsuitable for bundling w - waiting to be aggregated d - default port Number of channel-groups in use: 1 Number of aggregators: 1 Group Port-channel Protocol Ports ------+-------------+-----------+------------------------------------- 10 Po10(SU) PAgP Gi5/1(P) Gi5/2(P) ___________________________________________________________________ SwitchB#show etherchannel summary Flags: D - down P - in port-channel I - stand-alone s - suspended R - Layer3 S - Layer2 U - in use f - failed to allocate aggregator u - unsuitable for bundling w - waiting to be aggregated d - default port Number of channel-groups in use: 1 Number of aggregators: 1 Group Port-channel Protocol Ports ------+-------------+-----------+------------------------------------- 10 Po10(SU) PAgP Gi1/1(P) Gi1/2(P)
Configure a Layer 2 LACP EtherChannel between switch A and switch C. Use the channel-protocol lacp command to change the EtherChannel protocol, and use the channel-group group-number mode active command on Cisco IOS–based Catalyst switches to configure the EtherChannel.
SwitchA#configure terminal Enter configuration commands, one per line. End with CNTL/Z. SwitchA(config)#interface gigabitEthernet 5/3 SwitchA(config-if)#channel-protocol lacp SwitchA(config-if)#channel-group 20 mode active Creating a port-channel interface Port-channel 20 SwitchA(config-if)#interface gigabitEthernet 5/4 SwitchA(config-if)#channel-protocol lacp SwitchA(config-if)#channel-group 20 mode active SwitchA(config-if)#end SwitchA# *Nov 7 13:23:04: %SYS-5-CONFIG_I: Configured from console by console *Nov 7 13:23:06: %EC-5-L3DONTBNDL2: Gi5/3 suspended: LACP currently not enabled on the remote port. *Nov 7 13:23:12: %EC-5-L3DONTBNDL2: Gi5/4 suspended: LACP currently not enabled on the remote port. *Nov 7 13:23:35: %EC-5-BUNDLE: Interface Gi5/3 joined port-channel Po20 *Nov 7 13:23:36: %EC-5-L3DONTBNDL2: Gi5/4 suspended: LACP currently not enabled on the remote port. *Nov 7 13:23:38: %EC-5-BUNDLE: Interface Gi5/4 joined port-channel Po20 ________________________________________________________________________ SwitchC#configure terminal Enter configuration commands, one per line. End with CNTL/Z. SwitchC(config)#interface GigabitEthernet 1/1 SwitchC(config-if)#channel-protocol lacp SwitchA(config-if)#channel-group 20 mode active Creating a port-channel interface Port-channel 20 SwitchC(config-if)#interface GigabitEthernet 1/2 SwitchC(config-if)#channel-protocol lacp SwitchA(config-if)#channel-group 20 mode active SwitchC(config-if)#end *Nov 14 04:15:44.746: %EC-5-BUNDLE: Interface Gi1/1 joined port-channel Po20 SwitchC# *Nov 14 04:15:46.474: %SYS-5-CONFIG_I: Configured from console by console *Nov 14 04:15:47.646: %EC-5-BUNDLE: Interface Gi1/2 joined port-channel Po20
Verify the LACP EtherChannel operational status using the show etherchannel summary command on Cisco IOS–based Catalyst switches.
SwitchA#show etherchannel summary Flags: D - down P - in port-channel I - stand-alone s - suspended R - Layer3 S - Layer2 U - in use f - failed to allocate aggregator u - unsuitable for bundling w - waiting to be aggregated d - default port Number of channel-groups in use: 2 Number of aggregators: 2 Group Port-channel Protocol Ports ------+-------------+-----------+------------------------------------- 10 Po10(SU) PAgP Gi5/1(P) Gi5/2(P) 20 Po20(SU) LACP Gi5/3(P) Gi5/4(P) ______________________________________________________________________ SwitchC#show etherchannel summary Flags: D - down P - in port-channel I - stand-alone s - suspended R - Layer3 S - Layer2 U - in use f - failed to allocate aggregator u - unsuitable for bundling w - waiting to be aggregated d - default port Number of channel-groups in use: 1 Number of aggregators: 1 Group Port-channel Protocol Ports ------+-------------+-----------+------------------------------------- 20 Po20(SU) LACP Gi1/1(P) Gi1/2(P)
CDP is enabled by default on the Cisco Catalyst switches and routers on all interfaces. If for some reason CDP was disabled, you can turn it back on using the cdp run global command and cdp enable interface-level command. Enable CDP on the switch A GigabitEthernet 5/1 interface.
SwitchA#configure terminal Enter configuration commands, one per line. End with CNTL/Z. SwitchA(config)#cdp run SwitchA(config)#interface gigabitEthernet 5/1 SwitchA(config-if)#cdp enable SwitchA(config-if)#end SwitchA#
Verify the CDP operation status and neighbors on all three switches.
SwitchA#show cdp Global CDP information: Sending CDP packets every 60 seconds Sending a holdtime value of 180 seconds Sending CDPv2 advertisements is enabled SwitchA#show cdp neighbors Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone Device ID Local Intrfce Holdtme Capability Platform Port ID SwitchB Gig 5/2 178 R S I WS-C4006 Gig 1/2 SwitchB Gig 5/1 178 R S I WS-C4006 Gig 1/1 SwitchC Gig 5/4 153 R S I WS-C4503 Gig 1/2 SwitchC Gig 5/3 150 R S I WS-C4503 Gig 1/1 ___________________________________________________________________________ SwitchB#show cdp Global CDP information: Sending CDP packets every 60 seconds Sending a holdtime value of 180 seconds Sending CDPv2 advertisements is enabled SwitchB#show cdp neighbors Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone Device ID Local Intrfce Holdtme Capability Platform Port ID SwitchA Gig 1/2 160 R S I WS-C4506 Gig 5/2 SwitchA Gig 1/1 160 R S I WS-C4506 Gig 5/1 ___________________________________________________________________________ SwitchC#show cdp Global CDP information: Sending CDP packets every 60 seconds Sending a holdtime value of 180 seconds Sending CDPv2 advertisements is enabled SwitchC#show cdp neighbors Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone Device ID Local Intrfce Holdtme Capability Platform Port ID SwitchA Gig 1/2 144 R S I WS-C4506 Gig 5/4 SwitchA Gig 1/1 144 R S I WS-C4506 Gig 5/3
On the interconnecting ports between switches, configure aggressive mode UDLD. To do so, use the interface-level udld port aggressive command on Cisco IOS–based switches.
SwitchA#configure terminal Enter configuration commands, one per line. End with CNTL/Z. SwitchA(config)#interface gigabitEthernet 5/1 SwitchA(config-if)#udld port aggressive SwitchA(config-if)#interface gigabitEthernet 5/2 SwitchA(config-if)#udld port aggressive SwitchA(config-if)#interface gigabitEthernet 5/3 SwitchA(config-if)#udld port aggressive SwitchA(config-if)#interface gigabitEthernet 5/4 SwitchA(config-if)#udld port aggressive SwitchA(config-if)#end SwitchA# _________________________________________________ SwitchB#configure terminal Enter configuration commands, one per line. End with CNTL/Z. SwitchB(config)#interface gigabitethernet 1/1 SwitchB(config-if)#udld port aggressive SwitchB(config-if)#interface gigabitethernet 1/2 SwitchB(config-if)#udld port aggressive SwitchB(config-if)#end SwitchB# ______________________________________________________________ SwitchC#configure terminal Enter configuration commands, one per line. End with CNTL/Z. SwitchC(config)#interface gigabitethernet 1/1 SwitchC(config-if)#udld port aggressive SwitchC(config)#interface gigabitethernet 1/2 SwitchC(config-if)#udld port aggressive SwitchC(config-if)#end SwitchC#
Verify the UDLD status using the show udld interface-id command on Cisco IOS–based switches.
SwitchA#show udld gigabitEthernet 5/1 Interface Gi5/1 --- Port enable administrative configuration setting: Enabled / in aggressive mode Port enable operational state: Enabled / in aggressive mode Current bidirectional state: Bidirectional Current operational state: Advertisement - Single neighbor detected Message interval: 15 Time out interval: 5 Entry 1 --- Expiration time: 38 Device ID: 1 Current neighbor state: Bidirectional Device name: FOX06310RW1 Port ID: Gi1/1 Neighbor echo 1 device: FOX0627A001 Neighbor echo 1 port: Gi5/1 Message interval: 15 Time out interval: 5 CDP Device name: SwitchB SwitchA#show udld gigabitEthernet 5/3 Interface Gi5/3 --- Port enable administrative configuration setting: Enabled / in aggressive mode Port enable operational state: Enabled / in aggressive mode Current bidirectional state: Bidirectional Current operational state: Advertisement - Single neighbor detected Message interval: 15 Time out interval: 5 Entry 1 --- Expiration time: 34 Device ID: 1 Current neighbor state: Bidirectional Device name: FOX06210AXY Port ID: Gi1/1 Neighbor echo 1 device: FOX0627A001 Neighbor echo 1 port: Gi5/3 Message interval: 15 Time out interval: 5 CDP Device name: SwitchC ___________________________________________________________________ SwitchB#show udld gigabitEthernet 1/1 Interface Gi1/1 --- Port enable administrative configuration setting: Enabled / in aggressive mode Port enable operational state: Enabled / in aggressive mode Current bidirectional state: Bidirectional Current operational state: Advertisement - Single neighbor detected Message interval: 15 Time out interval: 5 Entry 1 --- Expiration time: 36 Device ID: 1 Current neighbor state: Bidirectional Device name: FOX0627A001 Port ID: Gi5/1 Neighbor echo 1 device: FOX06310RW1 Neighbor echo 1 port: Gi1/1 Message interval: 15 Time out interval: 5 CDP Device name: SwitchA ___________________________________________________________________ SwitchC#show udld gigabitEthernet 1/1 Interface Gi1/1 --- Port enable administrative configuration setting: Enabled / in aggressive mode Port enable operational state: Enabled / in aggressive mode Current bidirectional state: Bidirectional Current operational state: Advertisement - Single neighbor detected Message interval: 15 Time out interval: 5 Entry 1 --- Expiration time: 42 Device ID: 1 Current neighbor state: Bidirectional Device name: FOX0627A001 Port ID: Gi5/3 Neighbor echo 1 device: FOX06210AXY Neighbor echo 1 port: Gi1/1 Message interval: 15 Time out interval: 5 CDP Device name: SwitchA
Enable jumbo frames on all interconnecting interfaces on switch A, switch B, and switch C. Use the mtu 9198 interface level command on a Cisco IOS–based Catalyst 4500 switch. Because you are changing the MTU for interfaces in an EtherChannel, apply the command on the logical port-channel interface.
SwitchA#configure terminal Enter configuration commands, one per line. End with CNTL/Z. SwitchA(config)#interface port-channel 10 SwitchA(config-if)#mtu 9198 *Nov 7 14:57:34: %EC-5-UNBUNDLE: Interface GigabitEthernet5/2 left the port-channel Port-channel10 *Nov 7 14:57:34: %EC-5-CANNOT_BUNDLE2: Gi5/2 is not compatible with Gi5/1 and will be suspended (MTU of Gi5/2 is 9198, Gi5/1 is 1500) *Nov 7 14:57:34: %EC-5-UNBUNDLE: Interface GigabitEthernet5/1 left the port-channel Port-channel10 *Nov 7 14:57:34: %EC-5-COMPATIBLE: Gi5/2 is compatible with port- channel members *Nov 7 14:57:36: %EC-5-BUNDLE: Interface GigabitEthernet5/2 joined port-channel Port-channel10 *Nov 7 14:57:36: %EC-5-BUNDLE: Interface GigabitEthernet5/1 joined port-channel Port-channel10 SwitchA(config-if)#interface port-channel 20 SwitchA(config-if)#mtu 9198 *Nov 7 14:57:43: %EC-5-CANNOT_BUNDLE2: Gi5/4 is not compatible with Gi5/3 and will be suspended (MTU of Gi5/4 is 9198, Gi5/3 is 1500) *Nov 7 14:57:43: %EC-5-UNBUNDLE: Interface Gi5/4 left the port-channel Po20 *Nov 7 14:57:43: %EC-5-COMPATIBLE: Gi5/4 is compatible with port- channel members *Nov 7 14:57:45: %EC-5-BUNDLE: Interface Gi5/4 joined port-channel Po20 SwitchA(config-if)#end SwitchA# _________________________________________________________________________ SwitchB#configure terminal Enter configuration commands, one per line. End with CNTL/Z. SwitchB(config)#interface port-channel 10 SwitchB(config-if)#mtu 9198 SwitchB(config-if)#end SwitchB# 6w2d: %EC-5-UNBUNDLE: Interface GigabitEthernet1/2 left the port- channel Port-channel10 6w2d: %EC-5-CANNOT_BUNDLE2: Gi1/2 is not compatible with Gi1/1 and will be suspended (MTU of Gi1/2 is 9198, Gi1/1 is 1500) 6w2d: %EC-5-UNBUNDLE: Interface GigabitEthernet1/1 left the port- channel Port-channel10 6w2d: %EC-5-COMPATIBLE: Gi1/2 is compatible with port-channel members 6w2d: %SYS-5-CONFIG_I: Configured from console by console SwitchB# 6w2d: %EC-5-BUNDLE: Interface GigabitEthernet1/2 joined port-channel Port-channel10 6w2d: %EC-5-BUNDLE: Interface GigabitEthernet1/1 joined port-channel Port-channel10 _________________________________________________________________________ SwitchC#configure terminal Enter configuration commands, one per line. End with CNTL/Z. SwitchC(config)#interface port-channel 20 SwitchC(config-if)#mtu 9198 SwitchC(config-if)#end SwitchC# *Nov 14 05:52:19.025: %EC-5-CANNOT_BUNDLE2: Gi1/2 is not compatible with Gi1/1 and will be suspended (MTU of Gi1/2 is 9198, Gi1/1 is 1500) *Nov 14 05:52:19.025: %EC-5-UNBUNDLE: Interface Gi1/2 left the port- channel Po20 *Nov 14 05:52:19.033: %EC-5-COMPATIBLE: Gi1/2 is compatible with port- channel members *Nov 14 05:52:19.649: %SYS-5-CONFIG_I: Configured from console by console *Nov 14 05:52:20.841: %EC-5-BUNDLE: Interface Gi1/2 joined port-channel Po20
Verify the jumbo frame configuration using the show interface mtu interface-id command or the show interface mtu module module-number command on Cisco IOS–based Catalyst switches.
SwitchA#show interfaces mtu module 5 Port Name MTU Gi5/1 9198 Gi5/2 9198 Gi5/3 9198 Gi5/4 9198 Gi5/5 1500 Gi5/6 1500 SwitchA# _________________________________________________________________________ SwitchB#show interfaces mtu module 1 Port Name MTU Gi1/1 9198 Gi1/2 9198 SwitchB# _________________________________________________________________________ SwitchC#show interfaces mtu module 1 Port Name MTU Gi1/1 9198 Gi1/2 9198 SwitchC#
Enable error-disable detection and recovery for all causes on all three switches in this exercise. Use the errdisable detect cause all global level command for enabling detecton for all supported causes on Cisco IOS–based switches. Use the errdisable recovery cause all global command for enabling error-disable for all supported causes on Cisco IOS–based Catalyst switches.
SwitchA#configure terminal Enter configuration commands, one per line. End with CNTL/Z. SwitchA(config)#errdisable detect cause all SwitchA(config)#errdisable recovery cause all SwitchA(config)#end SwitchA# _________________________________________________________________________ SwitchB#configure terminal Enter configuration commands, one per line. End with CNTL/Z. SwitchB(config)#errdisable detect cause all SwitchB(config)#errdisable recovery cause all SwitchB(config)#end SwitchB# _________________________________________________________________________ SwitchC#configure terminal Enter configuration commands, one per line. End with CNTL/Z. SwitchC(config)#errdisable detect cause all SwitchC(config)#errdisable recovery cause all SwitchC(config)#end SwitchC#
Verify the error-disable configuration on Switch A. Use the show errdisable detect command to display the status of error-disable detection for the various causes on Cisco IOS–based Catalyst switches. Furthermore, use the show errdisable recovery command to display the status of error-disable recovery for the various causes as well as any interfaces that are error-disabled and are about to be recovered.
SwitchA#show errdisable detect ErrDisable Reason Detection status ----------------- ---------------- udld Enabled bpduguard Enabled security-violatio Enabled channel-misconfig Enabled psecure-violation Enabled vmps Enabled loopback Enabled unicast-flood Enabled pagp-flap Enabled dtp-flap Enabled link-flap Enabled l2ptguard Enabled gbic-invalid Enabled dhcp-rate-limit Enabled unicast-flood Enabled storm-control Enabled ilpower Enabled arp-inspection Enabled _________________________________________________________________________ SwitchC#show errdisable recovery ErrDisable Reason Timer Status ----------------- -------------- udld Enabled bpduguard Enabled security-violatio Enabled channel-misconfig Enabled vmps Enabled pagp-flap Enabled dtp-flap Enabled link-flap Enabled l2ptguard Enabled psecure-violation Enabled gbic-invalid Enabled dhcp-rate-limit Enabled unicast-flood Enabled storm-control Enabled arp-inspection Enabled loopback Enabled Timer interval: 300 seconds Interfaces that will be enabled at the next timeout:
For multiple-choice questions, there might be more than one correct answer.