EtherSwitch Network Module

VLAN Trunk Protocol

VLAN Trunk Protocol (VTP) is a Layer 2 messaging protocol that maintains VLAN configuration consistency by managing the addition, deletion, and renaming of VLANs within a VTP domain. A VTP domain (also called a VLAN management domain) is made up of one or more switches that share the same VTP domain name and that are interconnected with trunks. VTP minimizes misconfigurations and configuration inconsistencies that can result in a number of problems, such as duplicate VLAN names, incorrect VLAN-type specifications, and security violations. Before you create VLANs, you must decide whether to use VTP in your network. With VTP, you can make configuration changes centrally on one or more switches and have those changes automatically communicated to all the other switches in the network.

VTP Domain

A VTP domain (also called a VLAN management domain) is made up of one or more interconnected switches that share the same VTP domain name. A switch can be configured to be in only one VTP domain. You make global VLAN configuration changes for the domain using either the command-line interface (CLI) or Simple Network Management Protocol (SNMP).

By default, the switch is in VTP server mode and is in an un-named domain state until the switch receives an advertisement for a domain over a trunk link or until you configure a management domain. You cannot create or modify VLANs on a VTP server until the management domain name is specified or learned.

If the switch receives a VTP advertisement over a trunk link, it inherits the management domain name and the VTP configuration revision number. The switch ignores advertisements with a different management domain name or an earlier configuration revision number.

If you configure the switch as VTP transparent, you can create and modify VLANs, but the changes affect only the individual switch.

When you make a change to the VLAN configuration on a VTP server, the change is propagated to all switches in the VTP domain. VTP advertisements are transmitted out all trunk connections using IEEE 802.1Q encapsulation.

VTP maps VLANs dynamically across multiple LAN types with unique names and internal index associations. Mapping eliminates excessive device administration required from network administrators.

VTP Modes

You can configure a switch to operate in any one of these VTP modes:

• Server--In VTP server mode, you can create, modify, and delete VLANs and specify other configuration parameters (such as VTP version) for the entire VTP domain. VTP servers advertise their VLAN configuration to other switches in the same VTP domain and synchronize their VLAN configuration with other switches based on advertisements received over trunk links. VTP server is the default mode.
• Client--VTP clients behave the same way as VTP servers, but you cannot create, change, or delete VLANs on a VTP client.
• Transparent--VTP transparent switches do not participate in VTP. A VTP transparent switch does not advertise its VLAN configuration and does not synchronize its VLAN configuration based on received advertisements. However, in VTP version 2, transparent switches do forward VTP advertisements that they receive out their trunk interfaces.

VTP Advertisements

Each switch in the VTP domain sends periodic advertisements out each trunk interface to a reserved multicast address. VTP advertisements are received by neighboring switches, which update their VTP and VLAN configurations as necessary.

The following global configuration information is distributed in VTP advertisements:

• VLAN IDs (801.Q)
• VTP domain name
• VTP configuration revision number
• VLAN configuration, including maximum transmission unit (MTU) size for each VLAN
• Frame format

VTP Version 2

If you use VTP in your network, you must decide whether to use VTP version 1 or version 2. VTP version 2 supports the following features not supported in version 1:

Unrecognized Type-Length-Value (TLV) Support--A VTP server or client propagates configuration changes to its other trunks, even for TLVs it is not able to parse. The unrecognized TLV is saved in NVRAM.

Version-Dependent Transparent Mode--In VTP version 1, a VTP transparent switch inspects VTP messages for the domain name and version, and forwards a message only if the version and domain name match. Since only one domain is supported in the NM-16ESW software, VTP version 2 forwards VTP messages in transparent mode, without checking the version.

Consistency Checks--In VTP version 2, VLAN consistency checks (such as VLAN names and values) are performed only when you enter new information through the CLI or SNMP. Consistency checks are not performed when new information is obtained from a VTP message, or when information is read from NVRAM. If the digest on a received VTP message is correct, its information is accepted without consistency checks.

VTP Configuration Guidelines and Restrictions

Follow these guidelines and restrictions when implementing VTP in your network:

• All switches in a VTP domain must run the same VTP version.
• You must configure a password on each switch in the management domain when in secure mode.
• A VTP version 2-capable switch can operate in the same VTP domain as a switch running VTP version 1, provided that VTP version 2 is disabled on the VTP version 2-capable switch. (VTP version 2 is disabled by default).
• Do not enable VTP version 2 on a switch unless all switches in the same VTP domain are version 2-capable. When you enable VTP version 2 on a switch, all version 2-capable switches in the domain enable VTP version 2.
• The Cisco IOS end command and the Ctrl-Z keystrokes are not supported in VLAN database mode.
• The VLAN database stored on internal Flash is supported.
• Use the squeeze flashcommand to remove old copies of overwritten VLAN databases.

Bridge Protocol Data Units

The stable active spanning tree topology of a switched network is determined by the following:

• The unique bridge ID (bridge priority and MAC address) associated with each VLAN on each switch
• The spanning tree path cost to the root bridge
• The port identifier (port priority and MAC address) associated with each Layer 2 interface

The Bridge Protocol Data Units (BPDU) are transmitted in one direction from the root switch, and each switch sends configuration BPDUs to communicate and compute the spanning tree topology. Each configuration BPDU contains the following minimal information:

• The unique bridge ID of the switch that the transmitting switch believes to be the root switch
• The spanning tree path cost to the root
• The bridge ID of the transmitting bridge
• Message age
• The identifier of the transmitting port
• Values for the hello, forward delay, and max-age protocol timers

When a switch transmits a BPDU frame, all switches connected to the LAN on which the frame is transmitted receive the BPDU. When a switch receives a BPDU, it does not forward the frame but instead uses the information in the frame to calculate a BPDU, and, if the topology changes, initiate a BPDU transmission.

A BPDU exchange results in the following:

• One switch is elected as the root switch.
• The shortest distance to the root switch is calculated for each switch based on the path cost.
• A designated bridge for each LAN segment is selected. This is the switch closest to the root bridge through which frames are forwarded to the root.
• A root port is selected. This is the port providing the best path from the bridge to the root bridge.
• Ports included in the spanning tree are selected.
• The Root Bridge is elected.

For each VLAN, the switch with the highest bridge priority (the lowest numerical priority value) is elected as the root switch. If all switches are configured with the default priority (32768), the switch with the lowest MAC address in the VLAN becomes the root switch.

The spanning tree root switch is the logical center of the spanning tree topology in a switched network. All paths that are not needed to reach the root switch from anywhere in the switched network are placed in spanning tree blocking mode.

BPDUs contain information about the transmitting bridge and its ports, including bridge and MAC addresses, bridge priority, port priority, and path cost. Spanning tree uses this information to elect the root bridge and root port for the switched network, as well as the root port and designated port for each switched segment.

STP Timers

The table below describes the STP timers that affect the entire spanning tree performance.

Spanning Tree Port States

Propagation delays can occur when protocol information passes through a switched LAN. As a result, topology changes can take place at different times and at different places in a switched network. When a Layer 2 interface changes directly from nonparticipation in the spanning tree topology to the forwarding state, it can create temporary data loops. Ports must wait for new topology information to propagate through the switched LAN before starting to forward frames. They must allow the frame lifetime to expire for frames that have been forwarded using the old topology.

Each Layer 2 interface on a switch using spanning tree exists in one of the following five states:

• Blocking--The Layer 2 interface does not participate in frame forwarding.
• Listening--First transitional state after the blocking state when spanning tree determines that the Layer 2 interface should participate in frame forwarding.
• Learning--The Layer 2 interface prepares to participate in frame forwarding.
• Forwarding--The Layer 2 interface forwards frames.
• Disabled--The Layer 2 interface does not participate in spanning tree and is not forwarding frames.

A Layer 2 interface moves through these five states as follows:

• From initialization to blocking
• From blocking to listening or to disabled
• From listening to learning or to disabled
• From learning to forwarding or to disabled
• From forwarding to disabled

The figure below illustrates how a port moves through the five stages.

Boot-up Initialization

When you enable spanning tree, every port in the switch, VLAN, or network goes through the blocking state and the transitory states of listening and learning at power up. If properly configured, each Layer 2 interface stabilizes to the forwarding or blocking state.

When the spanning tree algorithm places a Layer 2 interface in the forwarding state, the following process occurs:

1. The Layer 2 interface is put into the listening state while it waits for protocol information that suggests that it should go to the blocking state.
2. The Layer 2 interface waits for the forward delay timer to expire, moves the Layer 2 interface to the learning state, and resets the forward delay timer.
3. In the learning state, the Layer 2 interface continues to block frame forwarding as it learns end station location information for the forwarding database.
4. The Layer 2 interface waits for the forward delay timer to expire and then moves the Layer 2 interface to the forwarding state, where both learning and frame forwarding are enabled.

Blocking State

A Layer 2 interface in the blocking state does not participate in frame forwarding, as shown in the figure below. After initialization, a BPDU is sent out to each Layer 2 interface in the switch. A switch initially assumes it is the root until it exchanges BPDUs with other switches. This exchange establishes which switch in the network is the root or root bridge. If only one switch is in the network, no exchange occurs, the forward delay timer expires, and the ports move to the listening state. A port always enters the blocking state following switch initialization.

A Layer 2 interface in the blocking state performs as follows:

• Discards frames received from the attached segment.
• Discards frames switched from another interface for forwarding.
• Does not incorporate end station location into its address database. (There is no learning on a blocking Layer 2 interface, so there is no address database update.)
• Receives BPDUs and directs them to the system module.
• Does not transmit BPDUs received from the system module.
• Receives and responds to network management messages.

Listening State

The listening state is the first transitional state a Layer 2 interface enters after the blocking state. The Layer 2 interface enters this state when STP determines that the Layer 2 interface should participate in frame forwarding. The figure below shows a Layer 2 interface in the listening state.

A Layer 2 interface in the listening state performs as follows:

• Discards frames received from the attached segment.
• Discards frames switched from another interface for forwarding.
• Does not incorporate end station location into its address database. (There is no learning at this point, so there is no address database update.)
• Receives BPDUs and directs them to the system module.
• Receives, processes, and transmits BPDUs received from the system module.
• Receives and responds to network management messages.

Learning State

A Layer 2 interface in the learning state prepares to participate in frame forwarding. The Layer 2 interface enters the learning state from the listening state. The figure below shows a Layer 2 interface in the learning state.

A Layer 2 interface in the learning state performs as follows:

• Discards frames received from the attached segment.
• Discards frames switched from another interface for forwarding.
• Incorporates end station location into its address database.
• Receives BPDUs and directs them to the system module.
• Receives, processes, and transmits BPDUs received from the system module.
• Receives and responds to network management messages.

Forwarding State

A Layer 2 interface in the forwarding state forwards frames, as shown in the figure below. The Layer 2 interface enters the forwarding state from the learning state.

A Layer 2 interface in the forwarding state performs as follows:

• Forwards frames received from the attached segment.
• Forwards frames switched from another Layer 2 interface for forwarding.
• Incorporates end station location information into its address database.
• Receives BPDUs and directs them to the system module.
• Processes BPDUs received from the system module.
• Receives and responds to network management messages.

Disabled State

A Layer 2 interface in the disabled state does not participate in frame forwarding or spanning tree, as shown in the figure below. A Layer 2 interface in the disabled state is virtually nonoperational.

A disabled Layer 2 interface performs as follows:

• Discards frames received from the attached segment.
• Discards frames switched from another Layer 2 interface for forwarding.
• Does not incorporate end station location into its address database. (There is no learning, so there is no address database update.)
• Does not receive BPDUs.
• Does not receive BPDUs for transmission from the system module.

MAC Address Allocation

The MAC address allocation manager has a pool of MAC addresses that are used as the bridge IDs for the VLAN spanning trees. In the table below, you can view the number of VLANs allowed for each platform.

MAC addresses are allocated sequentially, with the first MAC address in the range assigned to VLAN 1, the second MAC address in the range assigned to VLAN 2, and so forth.

For example, if the MAC address range is 00-e0-1e-9b-2e-00 to 00-e0-1e-9b-31-ff, the VLAN 1 bridge ID is 00-e0-1e-9b-2e-00, the VLAN 2 bridge ID is 00-e0-1e-9b-2e-01, the VLAN 3 bridge ID is 00-e0-1e-9b-2e-02, and so forth.

Default Spanning Tree Configuration

The table below shows the default Spanning Tree configuration values.

Spanning Tree Port Priority

In the event of a loop, spanning tree considers port priority when selecting an interface to put into the forwarding state. You can assign higher priority values to interfaces that you want spanning tree to select first, and lower priority values to interfaces that you want spanning tree to select last. If all interfaces have the same priority value, spanning tree puts the interface with the lowest interface number in the forwarding state and blocks other interfaces. The possible priority range is 0 to 255, configurable in increments of 4 (the default is 128).

Cisco IOS software uses the port priority value when the interface is configured as an access port and uses VLAN port priority values when the interface is configured as a trunk port.

Spanning Tree Port Cost

The spanning tree port path cost default value is derived from the media speed of an interface. In the event of a loop, spanning tree considers port cost when selecting an interface to put into the forwarding state. You can assign lower cost values to interfaces that you want spanning tree to select first and higher cost values to interfaces that you want spanning tree to select last. If all interfaces have the same cost value, spanning tree puts the interface with the lowest interface number in the forwarding state and blocks other interfaces.

The possible cost range is 0 to 65535 (the default is media-specific).

Spanning tree uses the port cost value when the interface is configured as an access port and uses VLAN port cost values when the interface is configured as a trunk port.

BackboneFast

BackboneFast is initiated when a root port or blocked port on a switch receives inferior BPDUs from its designated bridge. An inferior BPDU identifies one switch as both the root bridge and the designated bridge. When a switch receives an inferior BPDU, it means that a link to which the switch is not directly connected (an >indirect link) has failed (that is, the designated bridge has lost its connection to the root switch). Under STP rules, the switch ignores inferior BPDUs for the configured maximum aging time specified by the spanning-tree max-age global configuration command.

The switch tries to determine if it has an alternate path to the root switch. If the inferior BPDU arrives on a blocked port, the root port and other blocked ports on the switch become alternate paths to the root switch. (Self-looped ports are not considered alternate paths to the root switch.) If the inferior BPDU arrives on the root port, all blocked ports become alternate paths to the root switch. If the inferior BPDU arrives on the root port and there are no blocked ports, the switch assumes that it has lost connectivity to the root switch, causes the maximum aging time on the root to expire, and becomes the root switch according to normal STP rules.

If the switch has alternate paths to the root switch, it uses these alternate paths to transmit a new kind of Protocol Data Unit (PDU) called the Root Link Query PDU. The switch sends the Root Link Query PDU on all alternate paths to the root switch. If the switch determines that it still has an alternate path to the root, it causes the maximum aging time on the ports on which it received the inferior BPDU to expire. If all the alternate paths to the root switch indicate that the switch has lost connectivity to the root switch, the switch causes the maximum aging times on the ports on which it received an inferior BPDU to expire. If one or more alternate paths can still connect to the root switch, the switch makes all ports on which it received an inferior BPDU its designated ports and moves them out of the blocking state (if they were in the blocking state), through the listening and learning states, and into the forwarding state.

The figure below shows an example topology with no link failures. Switch A, the root switch, connects directly to Switch B over link L1 and to Switch C over link L2. The interface on Switch C that connects directly to Switch B is in the blocking state.

If link L1 fails, Switch C cannot detect this failure because it is not connected directly to link L1. However, because Switch B is directly connected to the root switch over L1, it detects the failure, elects itself the root, and begins sending BPDUs to Switch C, identifying itself as the root. When Switch C receives the inferior BPDUs from Switch B, Switch C assumes that an indirect failure has occurred. At that point, BackboneFast allows the blocked port on Switch C to move immediately to the listening state without waiting for the maximum aging time for the port to expire. BackboneFast then changes the interface on Switch C to the forwarding state, providing a path from Switch B to Switch A. This switchover takes approximately 30 seconds, twice the Forward Delay time if the default Forward Delay time of 15 seconds is set. The figure below shows how BackboneFast reconfigures the topology to account for the failure of link L1.

If a new switch is introduced into a shared-medium topology as shown in the figure below, BackboneFast is not activated because the inferior BPDUs did not come from the recognized designated bridge (Switch B). The new switch begins sending inferior BPDUs that say it is the root switch. However, the other switches ignore these inferior BPDUs, and the new switch learns that Switch B is the designated bridge to Switch A, the root switch.

Switching Frames Between Segments

Each Ethernet interface on an EtherSwitch Network Module can connect to a single workstation or server, or to a hub through which workstations or servers connect to the network.

On a typical Ethernet hub, all ports connect to a common backplane within the hub, and the bandwidth of the network is shared by all devices attached to the hub. If two stations establish a session that uses a significant level of bandwidth, the network performance of all other stations attached to the hub is degraded.

To reduce degradation, the switch treats each interface as an individual segment. When stations on different interfaces need to communicate, the switch forwards frames from one interface to the other at wire speed to ensure that each session receives full bandwidth.

To switch frames between interfaces efficiently, the switch maintains an address table. When a frame enters the switch, it associates the MAC address of the sending station with the interface on which it was received.

Building the Address Table

The EtherSwitch Network Module builds the address table by using the source address of the frames received. When the switch receives a frame for a destination address not listed in its address table, it floods the frame to all interfaces of the same virtual local-area network (VLAN) except the interface that received the frame. When the destination station replies, the switch adds its relevant source address and interface ID to the address table. The switch then forwards subsequent frames to a single interface without flooding to all interfaces. The address table can store at least 8,191 address entries without flooding any entries. The switch uses an aging mechanism, defined by a configurable aging timer; so if an address remains inactive for a specified number of seconds, it is removed from the address table.

Note	Default parameters on the aging timer are recommended.

VLAN Trunks

A trunk is a point-to-point link between one or more Ethernet switch interfaces and another networking device such as a router or a switch. Trunks carry the traffic of multiple VLANs over a single link and allow you to extend VLANs across an entire network and supports only one encapsulation on all Ethernet interfaces: 802.1Q-802.1Q is an industry-standard trunking encapsulation. You can configure a trunk on a single Ethernet interface or on an EtherChannel bundle.

Layer 2 Interface Modes

Two Ethernet interface modes can be configured. Using the switchport command with the mode access keywords puts the interface into nontrunking mode. The interface will stay in access mode regardless of what the connected port mode is. Only access VLAN traffic will travel on the access port and untagged (802.3).

Using the switchport command with the mode trunk keywords puts the interface into permanent trunking mode.

When you connect a Cisco switch to a device other than a Cisco device through an 802.1Q trunk, the Cisco switch combines the spanning tree instance of the VLAN trunk with the spanning tree instance of the other 802.1Q switch. However, spanning tree information for each VLAN is maintained by Cisco switches separated by a cloud of 802.1Q switches that are not Cisco switches. The 802.1Q cloud separating the Cisco switches that is not Cisco devised, is treated as a single trunk link between the switches.

Make sure that the native VLAN for an 802.1Q trunk is the same on both ends of the trunk link. If the VLAN on one end of the trunk is different from the VLAN on the other end, spanning tree loops might result. Inconsistencies detected by a Cisco switch mark the line as broken and block traffic for the specific VLAN.

Disabling spanning tree on the VLAN of an 802.1Q trunk without disabling spanning tree on every VLAN in the network can potentially cause spanning tree loops. Cisco recommends that you leave spanning tree enabled on the VLAN of an 802.1Q trunk or that you disable spanning tree on every VLAN in the network. Make sure that your network is loop-free before disabling spanning tree.

Layer 2 Interface Configuration Guidelines and Restrictions

Follow these guidelines and restrictions when configuring Layer 2 interfaces:

In a network of Cisco switches connected through 802.1Q trunks, the switches maintain one instance of spanning tree for each VLAN allowed on the trunks. 802.1Q switches that are not Cisco switches, maintain only one instance of spanning tree for all VLANs allowed on the trunks.

Understanding 802.1x Port-Based Authentication

The IEEE 802.1x standard defines a client/server-based access control and authentication protocol that restricts unauthorized devices from connecting to a LAN through publicly accessible ports. The authentication server authenticates each client connected to a switch port before making available any services offered by the switch or the LAN.

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

Device Roles

With 802.1x port-based authentication, the devices in the network have specific roles as shown in the figure below.

• Client --the device (workstation) that requests access to the LAN and switch services and responds to the requests from the switch. The workstation must be running 802.1x-compliant client software such as that offered in the Microsoft Windows XP operating system. (The client is the supplicant in the IEEE 802.1x specification.)
• Authentication server --performs the actual authentication of the client. The authentication server validates the identity of the client and notifies the switch whether or not the client is authorized to access the LAN and switch services. Because the switch acts as the proxy, the authentication service is transparent to the client. In this release, the Remote Authentication Dial-In User Service (RADIUS) security system with Extensible Authentication Protocol (EAP) extensions is the only supported authentication server; it is available in Cisco Secure Access Control Server version 3.0. RADIUS operates in a client/server model in which secure authentication information is exchanged between the RADIUS server and one or more RADIUS clients.
• Switch (edge switch or wireless access point)--controls the physical access to the network based on the authentication status of the client. The switch acts as an intermediary (proxy) between the client and the authentication server, requesting identity information from the client, verifying that information with the authentication server, and relaying a response to the client. The switch includes the RADIUS client, which is responsible for encapsulating and decapsulating the Extensible Authentication Protocol (EAP) frames and interacting with the authentication server.

When the switch receives EAPOL frames and relays them to the authentication server, the Ethernet header is stripped and the remaining EAP frame is reencapsulated in the RADIUS format. The EAP frames are not modified or examined during encapsulation, and the authentication server must support EAP within the native frame format. When the switch receives frames from the authentication server, the server's frame header is removed, leaving the EAP frame, which is then encapsulated for Ethernet and sent to the client.

The devices that can act as intermediaries include the Catalyst 3550 multilayer switch, Catalyst 2950 switch, or a wireless access point. These devices must be running software that supports the RADIUS client and 802.1x.

Authentication Initiation and Message Exchange

The switch or the client can initiate authentication. If you enable authentication on a port by using the dot1x port-control auto interface configuration command, the switch must initiate authentication when it determines that the port link state changes from down to up. It then sends an EAP-request/identity frame to the client to request its identity (typically, the switch sends an initial identity/request frame followed by one or more requests for authentication information). Upon receipt of the frame, the client responds with an EAP-response/identity frame.

However, if during bootup, the client does not receive an EAP-request/identity frame from the switch, the client can initiate authentication by sending an EAPOL-start frame, which prompts the switch to request the client's identity.

Note

If 802.1x is not enabled or supported on the network access device, any EAPOL frames from the client are dropped. If the client does not receive an EAP-request/identity frame after three attempts to start authentication, the client transmits frames as if the port is in the authorized state. A port in the authorized state effectively means that the client has been successfully authenticated.

When the client supplies its identity, the switch begins its role as the intermediary, passing EAP frames between the client and the authentication server until authentication succeeds or fails. If the authentication succeeds, the switch port becomes authorized.

The specific exchange of EAP frames depends on the authentication method being used. The figure below shows a message exchange initiated by the client using the One-Time-Password (OTP) authentication method with a RADIUS server.

Ports in Authorized and Unauthorized States

The switch port state determines whether or not the client is granted access to the network. The port starts in the unauthorized state. While in this state, the port disallows all ingress and egress traffic except for 802.1x packets. When a client is successfully authenticated, the port changes to the authorized state, allowing all traffic for the client to flow normally.

If a client that does not support 802.1x is connected to an unauthorized 802.1x port, the switch requests the client's identity. In this situation, the client does not respond to the request, the port remains in the unauthorized state, and the client is not granted access to the network.

In contrast, when an 802.1x-enabled client connects to a port that is not running 802.1x, the client initiates the authentication process by sending the EAPOL-start frame. When no response is received, the client sends the request for a fixed number of times. Because no response is received, the client begins sending frames as if the port is in the authorized state.

If the client is successfully authenticated (receives an Accept frame from the authentication server), the port state changes to authorized, and all frames from the authenticated client are allowed through the port. If the authentication fails, the port remains in the unauthorized state, but authentication can be retried. If the authentication server cannot be reached, the switch can retransmit the request. If no response is received from the server after the specified number of attempts, authentication fails, and network access is not granted.

When a client logs off, it sends an EAPOL-logoff message, causing the switch port to change to the unauthorized state.

If the link state of a port changes from up to down, or if an EAPOL-logoff frame is received, the port returns to the unauthorized state.

Supported Topologies

The 802.1x port-based authentication is supported in two topologies:

• Point-to-point
• Wireless LAN

In a point-to-point configuration, only one client can be connected to the 802.1x-enabled switch port. The switch detects the client when the port link state changes to the up state. If a client leaves or is replaced with another client, the switch changes the port link state to down, and the port returns to the unauthorized state.

The figure below shows 802.1x-port-based authentication in a wireless LAN. The 802.1x port is configured as a multiple-host port that becomes authorized as soon as one client is authenticated. When the port is authorized, all other hosts indirectly attached to the port are granted access to the network. If the port becomes unauthorized (reauthentication fails or an EAPOL-logoff message is received), the switch denies access to the network to all of the attached clients. In this topology, the wireless access point is responsible for authenticating the clients attached to it, and the wireless access point acts as a client to the switch.

Global Storm Control

Global storm control prevents switchports on a LAN from being disrupted by a broadcast, multicast, or unicast storm on one of the interfaces. Global storm control monitors incoming traffic statistics over a time period and compares the measurement with a predefined suppression level threshold. The threshold represents the percentage of the total available bandwidth of the port. If the threshold of a traffic type is reached, further traffic of that type is suppressed until the incoming traffic falls below the threshold level. Global storm control is disabled by default.

The switch supports global storm control for broadcast, multicast, and unicast traffic. This example of broadcast suppression can also be applied to multicast and unicast traffic.

The graph in the figure below shows broadcast traffic patterns on an interface over a given period of time. In this example, the broadcast traffic exceeded the configured threshold between time intervals T1 and T2 and between T4 and T5. When the amount of specified traffic exceeds the threshold, all traffic of that kind is dropped. Therefore, broadcast traffic is blocked during those intervals. At the next time interval, if broadcast traffic does not exceed the threshold, it is again forwarded.

When global storm control is enabled, the switch monitors packets passing from an interface to the switching bus and determines if the packet is unicast, multicast, or broadcast. The switch monitors the number of broadcast, multicast, or unicast packets received within the 1-second time interval, and when a threshold for one type of traffic is reached, that type of traffic is dropped. This threshold is specified as a percentage of total available bandwidth that can be used by broadcast (multicast or unicast) traffic.

The combination of broadcast suppression threshold numbers and the 1-second time interval control the way the suppression algorithm works. A higher threshold allows more packets to pass through. A threshold value of 100 percent means that no limit is placed on the traffic.

Note	Because packets do not arrive at uniform intervals, the 1-second time interval during which traffic activity is measured can affect the behavior of global storm control.

The switch continues to monitor traffic on the port, and when the utilization level is below the threshold level, the type of traffic that was dropped is forwarded again.

Per-Port Storm Control

A packet storm occurs when a large number of broadcast, unicast, or multicast packets are received on a port. Forwarding these packets can cause the network to slow down or to time out. By default, per-port storm control is disabled.

Per-port storm control uses rising and falling thresholds to block and then restore the forwarding of broadcast, unicast, or multicast packets. You can also set the switch to shut down the port when the rising threshold is reached.

Per-port storm control uses a bandwidth-based method to measure traffic activity. The thresholds are expressed as a percentage of the total available bandwidth that can be used by the broadcast, multicast, or unicast traffic.

The rising threshold is the percentage of total available bandwidth associated with multicast, broadcast, or unicast traffic before forwarding is blocked. The falling threshold is the percentage of total available bandwidth below which the switch resumes normal forwarding. In general, the higher the level, the less effective the protection against broadcast storms.

Load Balancing

EtherChannel balances traffic load across the links in a channel by reducing part of the binary pattern formed from the addresses in the frame to a numerical value that selects one of the links in the channel.

EtherChannel load balancing can use MAC addresses or IP addresses; either source or destination or both source and destination. The selected mode applies to all EtherChannels configured on the switch.

Use the option that provides the greatest variety in your configuration. For example, if the traffic on a channel is going only to a single MAC address, using the destination MAC address always chooses the same link in the channel; using source addresses or IP addresses may result in better load balancing.

EtherChannel Configuration Guidelines and Restrictions

If improperly configured, some EtherChannel interfaces are disabled automatically to avoid network loops and other problems. Follow these guidelines and restrictions to avoid configuration problems:

• All Ethernet interfaces on all modules support EtherChannel (maximum of eight interfaces) with no requirement that interfaces be physically contiguous or on the same module.
• Configure all interfaces in an EtherChannel to operate at the same speed and duplex mode.
• Enable all interfaces in an EtherChannel. If you shut down an interface in an EtherChannel, it is treated as a link failure and its traffic is transferred to one of the remaining interfaces in the EtherChannel.
• An EtherChannel will not form if one of the interfaces is a Switched Port Analyzer (SPAN) destination port.

For Layer 2 EtherChannels:

• Assign all interfaces in the EtherChannel to the same VLAN, or configure them as trunks.

An EtherChannel supports the same allowed range of VLANs on all interfaces in a trunking Layer 2 EtherChannel. If the allowed range of VLANs is not the same, the interfaces do not form an EtherChannel.

Interfaces with different Spanning Tree Protocol (STP) port path costs can form an EtherChannel as long they are otherwise compatibly configured. Setting different STP port path costs does not, by itself, make interfaces incompatible for the formation of an EtherChannel.

After you configure an EtherChannel, configuration that you apply to the port-channel interface affects the EtherChannel.

Switched Port Analyzer Session

A Switched Port Analyzer (SPAN) session is an association of a destination interface with a set of source interfaces. You configure SPAN sessions using parameters that specify the type of network traffic to monitor. SPAN sessions allow you to monitor traffic on one or more interfaces and to send either ingress traffic, egress traffic, or both to one destination interface. You can configure one SPAN session with separate or overlapping sets of SPAN source interfaces or VLANs. Only switched interfaces can be configured as SPAN sources or destinations on the same network module.

SPAN sessions do not interfere with the normal operation of the switch. You can enable or disable SPAN sessions with command-line interface (CLI) or SNMP commands. When enabled, a SPAN session might become active or inactive based on various events or actions, and this would be indicated by a syslog message. The show monitor sessioncommand displays the operational status of a SPAN session.

A SPAN session remains inactive after system power-up until the destination interface is operational.

Destination Interface

A destination interface (also called a monitor interface) is a switched interface to which SPAN sends packets for analysis. You can have one SPAN destination interface. Once an interface becomes an active destination interface, incoming traffic is disabled. You cannot configure a SPAN destination interface to receive ingress traffic. The interface does not forward any traffic except that required for the SPAN session.

An interface configured as a destination interface cannot be configured as a source interface. EtherChannel interfaces cannot be SPAN destination interfaces.

Specifying a trunk interface as a SPAN destination interface stops trunking on the interface.

Source Interface

A source interface is an interface monitored for network traffic analysis. One or more source interfaces can be monitored in a single SPAN session with user-specified traffic types (ingress, egress, or both) applicable for all the source interfaces.

You can configure source interfaces in any VLAN. You can configure EtherChannel as source interfaces, which means that all interfaces in the specified VLANs are source interfaces for the SPAN session.

Trunk interfaces can be configured as source interfaces and mixed with nontrunk source interfaces; however, the destination interface never encapsulates.

Traffic Types

Ingress SPAN (Rx) copies network traffic received by the source interfaces for analysis at the destination interface. Egress SPAN (Tx) copies network traffic transmitted from the source interfaces. Specifying the configuration option both copies network traffic received and transmitted by the source interfaces to the destination interface.

SPAN Traffic

Network traffic, including multicast, can be monitored using SPAN. Multicast packet monitoring is enabled by default. In some SPAN configurations, multiple copies of the same source packet are sent to the SPAN destination interface. For example, a bidirectional (both ingress and egress) SPAN session is configured for sources a1 and a2 to a destination interface d1. If a packet enters the switch through a1 and gets switched to a2, both incoming and outgoing packets are sent to destination interface d1; both packets would be the same (unless a Layer-3 rewrite had occurred, in which case the packets would be different).

Note	Monitoring of VLANs is not supported.

SPAN Configuration Guidelines and Restrictions

Follow these guidelines and restrictions when configuring SPAN:

• Enter the no monitor session session number command with no other parameters to clear the SPAN session number.
• EtherChannel interfaces can be SPAN source interfaces; they cannot be SPAN destination interfaces.
• If you specify multiple SPAN source interfaces, the interfaces can belong to different VLANs.
• Monitoring of VLANs is not supported
• Only one SPAN session may be run at any given time.
• Outgoing CDP and BPDU packets will not be replicated.
• SPAN destinations never participate in any spanning tree instance. SPAN includes BPDUs in the monitored traffic, so any BPDUs seen on the SPAN destination are from the SPAN source.
• Use a network analyzer to monitor interfaces.
• You can have one SPAN destination interface.
• You can mix individual source interfaces within a single SPAN session.
• You cannot configure a SPAN destination interface to receive ingress traffic.
• When enabled, SPAN uses any previously entered configuration.
• When you specify source interfaces and do not specify a traffic type (Tx, Rx, or both), both is used by default.

Immediate-Leave Processing

IGMP snooping Immediate-Leave processing allows the switch to remove an interface that sends a leave message from the forwarding table without first sending out MAC-based general queries to the interface. The VLAN interface is pruned from the multicast tree for the multicast group specified in the original leave message. Immediate-Leave processing ensures optimal bandwidth management for all hosts on a switched network, even when multiple multicast groups are in use simultaneously.

Note

You should use the Immediate-Leave processing feature only on VLANs where only one host is connected to each port. If Immediate-Leave processing is enabled on VLANs where more than one host is connected to a port, some hosts might be inadvertently dropped. Immediate-Leave processing is supported only with IGMP version 2 hosts.

Setting the Snooping Method

Multicast-capable router ports are added to the forwarding table for every IP multicast entry. The switch learns of such ports through one of these methods:

• Snooping on PIM and DVMRP packets
• Statically connecting to a multicast router port with the ip igmp snooping mrouter global configuration command

You can configure the switch to snoop on PIM/Distance Vector Multicast Routing Protocol (PIM/DVMRP) packets. By default, the switch snoops on PIM/DVMRP packets on all VLANs. To learn of multicast router ports through PIM-DVMRP packets, use the ip igmp snooping vlan vlan-id mrouter learn pim-dvmrp interface configuration command.

Joining a Multicast Group

When a host connected to the switch wants to join an IP multicast group, it sends an IGMP join message, specifying the IP multicast group it wants to join. When the switch receives this message, it adds the port to the IP multicast group port address entry in the forwarding table.

See the figure below. Host 1 wants to join multicast group 224.1.2.3 and send a multicast message of an unsolicited IGMP membership report (IGMP join message) to the group with the equivalent MAC destination address of 0100.5E01.0203. The switch recognizes IGMP packets and forwards them to the CPU. When the CPU receives the IGMP multicast report by Host 1, the CPU uses the information to set up a multicast forwarding table entry as shown in the table below that includes the port numbers of Host 1 and the router.

Note that the switch architecture allows the CPU to distinguish IGMP information packets from other packets for the multicast group. The switch recognizes the IGMP packets through its filter engine. This prevents the CPU from becoming overloaded with multicast frames.

The entry in the multicast forwarding table tells the switching engine to send frames addressed to the 0100.5E01.0203 multicast MAC address that are not IGMP packets (!IGMP) to the router and to the host that has joined the group.

If another host (for example, Host 4) sends an IGMP join message for the same group (shown in the figure below), the CPU receives that message and adds the port number of Host 4 to the multicast forwarding table as shown in table below.

Leaving a Multicast Group

The router sends periodic IP multicast general queries, and the switch responds to these queries with one join response per MAC multicast group. As long as at least one host in the VLAN needs multicast traffic, the switch responds to the router queries, and the router continues forwarding the multicast traffic to the VLAN. The switch only forwards IP multicast group traffic to those hosts listed in the forwarding table for that IP multicast group.

When hosts need to leave a multicast group, they can either ignore the periodic general-query requests sent by the router, or they can send a leave message. When the switch receives a leave message from a host, it sends out a group-specific query to determine if any devices behind that interface are interested in traffic for the specific multicast group. If, after a number of queries, the router processor receives no reports from a VLAN, it removes the group for the VLAN from its multicast forwarding table.

Understanding ACLs

Packet filtering can limit network traffic and restrict network use by certain users or devices. ACLs can filter traffic as it passes through a switch and permit or deny packets from crossing specified interfaces. An ACL is a sequential collection of permit and deny conditions that apply to packets. When a packet is received on an interface, the switch compares the fields in the packet against any applied ACLs to verify that the packet has the required permissions to be forwarded, based on the criteria specified in the access lists. The switch tests the packet against the conditions in an access list one by one. The first match determines whether the switch accepts or rejects the packet. Because the switch stops testing conditions after the first match, the order of conditions in the list is critical. If no conditions match, the switch rejects the packet. If there are no restrictions, the switch forwards the packet; otherwise, the switch drops the packet.

You configure access lists on a Layer 2 switch to provide basic security for your network. If you do not configure ACLs, all packets passing through the switch could be allowed onto all parts of the network. You can use ACLs to control which hosts can access different parts of a network or to decide which types of traffic are forwarded or blocked at switch interfaces. For example, you can allow e-mail traffic to be forwarded but not Telnet traffic. ACLs can be configured to block inbound traffic.

An ACL contains an ordered list of access control entries (ACEs). Each ACE specifies permit or deny and a set of conditions the packet must satisfy in order to match the ACE. The meaning of permit or deny depends on the context in which the ACL is used.

The EtherSwitch Network Module supports IP ACLs to filter IP traffic, including TCP or User Datagram Protocol (UDP) traffic (but not both traffic types in the same ACL).

ACLs

You can apply ACLs on physical Layer 2 interfaces. ACLs are applied on interfaces only on the inbound direction.

• Standard IP access lists use source addresses for matching operations.
• Extended IP access lists use source and destination addresses and optional protocol type information for matching operations.

The switch examines access lists associated with features configured on a given interface and a direction. As packets enter the switch on an interface, ACLs associated with all inbound features configured on that interface are examined.

ACLs permit or deny packet forwarding based on how the packet matches the entries in the ACL. For example, you can use ACLs to allow one host to access a part of a network, but to prevent another host from accessing the same part. In the figure below, ACLs applied at the switch input allow Host A to access the Human Resources network, but prevent Host B from accessing the same network.

Handling Fragmented and Unfragmented Traffic

IP packets can be fragmented as they cross the network. When this happens, only the fragment containing the beginning of the packet contains the Layer 4 information, such as TCP or UDP port numbers, ICMP type and code, and so on. All other fragments are missing this information.

Some ACEs do not check Layer 4 information and therefore can be applied to all packet fragments. ACEs that do test Layer 4 information cannot be applied in the standard manner to most of the fragments in a fragmented IP packet. When the fragment contains no Layer 4 information and the ACE tests some Layer 4 information, the matching rules are modified:

• Permit ACEs that check the Layer 3 information in the fragment (including protocol type, such as TCP, UDP, and so on) are considered to match the fragment regardless of what the missing Layer 4 information might have been.
• Deny ACEs that check Layer 4 information never match a fragment unless the fragment contains Layer 4 information.

Consider access list 102, configured with these commands, applied to three fragmented packets:

Router(config)# access-list 102 permit tcp any host 10.1.1.1 eq smtp
Router(config)# access-list 102 deny tcp any host 10.1.1.2 eq telnet
Router(config)# access-list 102 deny tcp any any

Note	In the first and second ACEs in the examples, the eq keyword after the destination address means to test for the TCP-destination-port well-known numbers equaling Simple Mail Transfer Protocol (SMTP) and Telnet, respectively.

• Packet A is a TCP packet from host 10.2.2.2, port 65000, going to host 10.1.1.1 on the SMTP port. If this packet is fragmented, the first fragment matches the first ACE (a permit), as if it were a complete packet because all Layer 4 information is present. The remaining fragments also match the first ACE, even though they do not contain the SMTP port information because the first ACE only checks Layer 3 information when applied to fragments. (The information in this example is that the packet is TCP and that the destination is 10.1.1.1.)
• Packet B is from host 10.2.2.2, port 65001, going to host 10.1.1.2 on the Telnet port. If this packet is fragmented, the first fragment matches the second ACE (a deny) because all Layer 3 and Layer 4 information is present. The remaining fragments in the packet do not match the second ACE because they are missing Layer 4 information.
• Because the first fragment was denied, host 10.1.1.2 cannot reassemble a complete packet, so packet B is effectively denied. However, the later fragments that are permitted will consume bandwidth on the network and resources of host 10.1.1.2 as it tries to reassemble the packet.
• Fragmented packet C is from host 10.2.2.2, port 65001, going to host 10.1.1.3, port FTP. If this packet is fragmented, the first fragment matches the third ACE (a deny). All other fragments also match the third ACE because that ACE does not check any Layer 4 information and because Layer 3 information in all fragments shows that they are being sent to host 10.1.1.3, and the earlier permit ACEs were checking different hosts.

Understanding Access Control Parameters

Before configuring ACLs on the EtherSwitch Network Module, you must have a thorough understanding of the Access Control Parameters (ACPs). ACPs are referred to as masks in the switch CLI commands, and output.

Each ACE has a mask and a rule. The Classification Field or mask is the field of interest on which you want to perform an action. The specific values associated with a given mask are called rules.

Packets can be classified on these Layer 3 and Layer 4 fields.

• Layer 3 fields:
  • IP source address (Specify all 32 IP source address bits to define the flow, or specify a user-defined subnet. There are no restrictions on the IP subnet to be specified.)
  • IP destination address (Specify all 32 IP destination address bits to define the flow, or specify a user-defined subnet. There are no restrictions on the IP subnet to be specified.)

You can use any combination or all of these fields simultaneously to define a flow.

• Layer 4 fields:
  • TCP (You can specify a TCP source, destination port number, or both at the same time.)
  • UDP (You can specify a UDP source, destination port number, or both at the same time.)

Note	A mask can be a combination of multiple Layer 3 and Layer 4 fields.

There are two types of masks:

• User-defined mask--masks that are defined by the user.
• System-defined mask--these masks can be configured on any interface:

Router(config-ext-nacl)# permit tcp any any 
Router(config-ext-nacl)# deny tcp any any 
Router(config-ext-nacl)# permit udp any any 
Router(config-ext-nacl)# deny udp any any 
Router(config-ext-nacl)# permit ip any any 
Router(config-ext-nacl)# deny ip any any 
Router(config-ext-nacl)# deny any any 
Router(config-ext-nacl)# permit any any 

Note

In an IP extended ACL (both named and numbered), a Layer 4 system-defined mask cannot precede a Layer 3 user-defined mask. For example, a Layer 4 system-defined mask such as permit tcp any any or deny udp any any cannot precede a Layer 3 user-defined mask such as permit ip 10.1.1.1 any. If you configure this combination, the ACL is not configured. All other combinations of system-defined and user-defined masks are allowed in security ACLs.

The EtherSwitch Network Module ACL configuration is consistent with Cisco Catalyst switches. However, there are significant restrictions as well as differences for ACL configurations on the EtherSwitch Network Module.

Guidelines for Configuring ACLs on the EtherSwitch Network Module

These configuration guidelines apply to ACL filters:

• Only one ACL can be attached to an interface.
• All ACEs in an ACL must have the same user-defined mask. However, ACEs can have different rules that use the same mask. On a given interface, only one type of user-defined mask is allowed, but you can apply any number of system-defined masks.

The following example shows the same mask in an ACL:

Router(config)# ip access-list extended acl2
Router(config-ext-nacl)# permit tcp 10.1.1.1 0.0.0.0 any eq 80 
Router(config-ext-nacl)# permit tcp 20.1.1.1 0.0.0.0 any eq 23

In this example, the first ACE permits all the TCP packets coming from the host 10.1.1.1 with a destination TCP port number of 80. The second ACE permits all TCP packets coming from the host 20.1.1.1 with a destination TCP port number of 23. Both the ACEs use the same mask; therefore, a EtherSwitch Network Module supports this ACL.

• Only four user-defined masks can be defined for the entire system. These can be used for either security or quality of service (QoS) but cannot be shared by QoS and security. You can configure as many ACLs as you require. However, a system error message appears if ACLs with more than four different masks are applied to interfaces.

The table below lists a summary of the ACL restrictions on EtherSwitch Network Modules.

Understanding Quality of Service

Typically, networks operate on a best-effort delivery basis, which means that all traffic has equal priority and an equal chance of being delivered in a timely manner. When congestion occurs, all traffic has an equal chance of being dropped.

With the QoS feature configured on your EtherSwitch Network Module, you can select specific network traffic, prioritize it according to its relative importance, and use congestion-management and congestion-avoidance techniques to provide preferential treatment. Implementing QoS in your network makes network performance more predictable and bandwidth utilization more effective.

The QoS implementation for this release is based on the DiffServ architecture, an emerging standard from the Internet Engineering Task Force (IETF). This architecture specifies that each packet is classified upon entry into the network. The classification is carried in the IP packet header, using six bits from the deprecated IP type of service (ToS) field to carry the classification (class ) information. Classification can also be carried in the Layer 2 frame. These special bits in the Layer 2 frame or a Layer 3 packet are described here and shown in the figure below:

• Prioritization values in Layer 2 frames:

Layer 2 802.1Q frame headers have a 2-byte Tag Control Information field that carries the CoS value in the three most-significant bits, which are called the User Priority bits. On interfaces configured as Layer 2 802.1Q trunks, all traffic is in 802.1Q frames except for traffic in the native VLAN.

Other frame types cannot carry Layer 2 CoS values.

Layer 2 CoS values range from 0 for low priority to 7 for high priority.

• Prioritization bits in Layer 3 packets:

Layer 3 IP packets can carry a Differentiated Services Code Point (DSCP) value. The supported DSCP values are 0, 8, 10, 16, 18, 24, 26, 32, 34, 40, 46, 48, and 56.

Note	Layer 2 ISL Frame is not supported in this release.

Note	Layer 3 IPv6 packets are dropped when received by the switch.

All switches and routers across the Internet rely on the class information to provide the same forwarding treatment to packets with the same class information and different treatment to packets with different class information. The class information in the packet can be assigned by end hosts or by switches or routers along the way, based on a configured policy, detailed examination of the packet, or both. Detailed examination of the packet is expected to happen closer to the edge of the network so that the core switches and routers are not overloaded.

Switches and routers along the path can use the class information to limit the amount of resources allocated per traffic class. The behavior of an individual device when handling traffic in the DiffServ architecture is called per-hop behavior. If all devices along a path provide a consistent per-hop behavior, you can construct an end-to-end QoS solution.

Implementing QoS in your network can be a simple or complex task and depends on the QoS features offered by your internetworking devices, the traffic types and patterns in your network, and the granularity of control you need over incoming and outgoing traffic.

The EtherSwitch Network Module can function as a Layer 2 switch connected to a Layer 3 router. When a packet enters the Layer 2 engine directly from a switch port, it is placed into one of four queues in the dynamic, 32-MB shared memory buffer. The queue assignment is based on the dot1p value in the packet. Any voice bearer packets that come in from the Cisco IP phones on the voice VLAN are automatically placed in the highest priority (Queue 3) based on the 802.1p value generated by the IP phone. The queues are then serviced on a weighted round robin (WRR) basis. The control traffic, which uses a CoS or ToS of 3, is placed in Queue 2.

The table below summarizes the queues, CoS values, and weights for Layer 2 QoS on the EtherSwitch Network Module.

The weights specify the number of packets that are serviced in the queue before moving on to the next queue. Voice Realtime Transport Protocol (RTP) bearer traffic marked with a CoS or ToS of 5 and Voice Control plane traffic marked with a CoS/ToS of 3 are placed into the highest priority queues. If the queue has no packets to be serviced, it is skipped. Weighted Random Early Detection (WRED) is not supported on the Fast Ethernet ports.

You cannot configure port-based QoS on the Layer 2 switch ports.

Basic QoS Model

The figure below shows the basic QoS model. Actions at the ingress interface include classifying traffic, policing, and marking:

Actions at the egress interface include queueing and scheduling:

• Queuing evaluates the CoS value and determines which of the four egress queues in which to place the packet.
• Scheduling services the four egress queues based on their configured WRR weights.

Classification

Classification is the process of distinguishing one kind of traffic from another by examining the fields in the packet.

Classification occurs only on a physical interface basis. No support exists for classifying packets at the VLAN or the switched virtual interface level.

You specify which fields in the frame or packet that you want to use to classify incoming traffic.

Classification Based on QoS ACLs

You can use IP standard or IP extended ACLs to define a group of packets with the same characteristics (class). In the QoS context, the permit and deny actions in the access control entries (ACEs) have different meanings than with security ACLs:

• If a match with a permit action is encountered (first-match principle), the specified QoS-related action is taken.
• If no match with a permit action is encountered and all the ACEs have been examined, no QoS processing occurs on the packet.
• If multiple ACLs are configured on an interface, the packet matches the first ACL with a permit action, and QoS processing begins.
• Configuration of a deny action is not supported in QoS ACLs on the 16- and 36-port EtherSwitch Network Modules.
• System-defined masks are allowed in class maps with these restrictions:
  • A combination of system-defined and user-defined masks cannot be used in the multiple class maps that are a part of a policy map.
  • System-defined masks that are a part of a policy map must all use the same type of system mask. For example, a policy map cannot have a class map that uses the permit tcp any anyACE and another that uses the permit ip any anyACE.
  • A policy map can contain multiple class maps that all use the same user-defined mask or the same system-defined mask.

Note	For more information on the system-defined mask, see the Quality of Service for the EtherSwitch Network Module.

After a traffic class has been defined with the ACL, you can attach a policy to it. A policy might contain multiple classes with actions specified for each one of them. A policy might include commands to rate-limit the class. This policy is then attached to a particular port on which it becomes effective.

You implement IP ACLs to classify IP traffic by using the access-list global configuration command.

Classification Based on Class Maps and Policy Maps

A class map is a mechanism that you use to isolate and name a specific traffic flow (or class) from all other traffic. The class map defines the criteria used to match against a specific traffic flow to further classify it; the criteria can include matching the access group defined by the ACL. If you have more than one type of traffic that you want to classify, you can create another class map and use a different name. After a packet is matched against the class-map criteria, you further classify it through the use of a policy map.

A policy map specifies which traffic class to act on. Actions can include setting a specific DSCP value in the traffic class or specifying the traffic bandwidth limitations and the action to take when the traffic is out of profile. Before a policy map can be effective, you must attach it to an interface.

The policy map can also contain commands that define the policer, the bandwidth limitations of the traffic, and the action to take if the limits are exceeded. For more information, see the Quality of Service for the EtherSwitch Network Module.

A policy map also has these characteristics:

• A policy map can contain multiple class statements.
• A separate policy-map class can exist for each type of traffic received through an interface.
• A policy-map configuration state supersedes any actions due to an interface trust state.

For configuration information, see the Configuring a QoS Policy.

Policing and Marking

Policing involves creating a policer that specifies the bandwidth limits for the traffic. Packets that exceed the limits are out of profile or nonconforming . Each policer specifies the action to take for packets that are in or out of profile. These actions, carried out by the marker, include dropping the packet, or marking down the packet with a new value that is user-defined.

You can create this type of policer:

Individual--QoS applies the bandwidth limits specified in the policer separately to each matched traffic class. You configure this type of policer within a policy map by using the policy-map configuration command.

For non-IP traffic, you have these marking options:

• Use the port default. If the frame does not contain a CoS value, assign the default port CoS value to the incoming frame.
• Trust the CoS value in the incoming frame (configure the port to trust CoS). Layer 2 802.1Q frame headers carry the CoS value in the three most-significant bits of the Tag Control Information field. CoS values range from 0 for low priority to 7 for high priority.

The trust DSCP configuration is meaningless for non-IP traffic. If you configure a port with this option and non-IP traffic is received, the switch assigns the default port CoS value and classifies traffic based on the CoS value.

For IP traffic, you have these classification options:

• Trust the IP DSCP in the incoming packet (configure the port to trust DSCP), and assign the same DSCP to the packet for internal use. The IETF defines the six most-significant bits of the 1-byte type of service (ToS) field as the DSCP. The priority represented by a particular DSCP value is configurable. The supported DSCP values are 0, 8, 10, 16, 18, 24, 26, 32, 34, 40, 46, 48, and 56.
• Trust the CoS value (if present) in the incoming packet, and generate the DSCP by using the CoS-to-DSCP map.

When configuring policing and policers, keep these items in mind:

• By default, no policers are configured.
• Policers can only be configured on a physical port. There is no support for policing at a VLAN or switched virtual interface (SVI) level.
• Only one policer can be applied to a packet in the input direction.
• Only the average rate and committed burst parameters are configurable.
• Policing occurs on the ingress interfaces:
  • 60 policers are supported on ingress Gigabit-capable Ethernet ports.
  • 6 policers are supported on ingress 10/100 Ethernet ports.
  • Granularity for the average burst rate is 1 Mbps for 10/100 ports and 8 Mbps for Gigabit Ethernet ports.
• On an interface configured for QoS, all traffic received through the interface is classified, policed, and marked according to the policy map attached to the interface. On a trunk interface configured for QoS, traffic in all VLANs received through the interface is classified, policed, and marked according to the policy map attached to the interface.
• VLAN-based egress DSCP-to-COS mapping is supported. DSCP-to-COS mapping occurs for all packets with a specific VLAN ID egressing from the CPU to the physical port. The packets can be placed in the physical port egress queue depending on the COS value. Packets are handled according to type of service.

Note	No policers can be configured on the egress interface on EtherSwitch Network Modules.

Mapping Tables

The EtherSwitch Network Modules support these types of marking to apply to the switch:

• CoS value to the DSCP value
• DSCP value to CoS value

Note	An interface can be configured to trust either CoS or DSCP, but not both at the same time.

Before the traffic reaches the scheduling stage, QoS uses the configurable DSCP-to-CoS map to derive a CoS value from the internal DSCP value.

The CoS-to-DSCP and DSCP-to-CoS map have default values that might or might not be appropriate for your network.

When you delete a VLAN from a router with an EtherSwitch Network Module installed that is in VTP server mode, the VLAN is removed from all EtherSwitch routers and switches in the VTP domain. When you delete a VLAN from an EtherSwitch router or switch that is in VTP transparent mode, the VLAN is deleted only on that specific device.

You cannot delete the default VLANs for the different media types: Ethernet VLAN 1 and FDDI or Token Ring VLANs 1002 to 1005.

Perform this task to configure the VLANs on an EtherSwitch Network Module.

When a router with an EtherSwitch Network Module installed is in VTP server mode, you can change the VLAN configuration and have it propagate throughout the network.

When the router is in VTP client mode, you cannot change the VLAN configuration on the device. The client device receives VTP updates from a VTP server in the management domain and modifies its configuration accordingly.

When you configure the router as VTP transparent, you disable VTP on the device. A VTP transparent device does not send VTP updates and does not act on VTP updates received from other devices. However, a VTP transparent device running VTP version 2 does forward received VTP advertisements out all of its trunk links.

Perform this task to configure the VLAN Trunking Protocol (VTP) on an EtherSwitch Network Module.

Perform this task to enable spanning tree on a per-VLAN basis and configure various spanning tree features. The EtherSwitch Network Module maintains a separate instance of spanning tree for each VLAN (except on VLANs on which you disable spanning tree).

The EtherSwitch Network Module maintains a separate instance of spanning tree for each active VLAN configured on the device. A bridge ID, consisting of the bridge priority and the bridge MAC address, is associated with each instance. For each VLAN, the switch with the lowest bridge ID will become the root bridge for that VLAN.

To configure a VLAN instance to become the root bridge, the bridge priority can be modified from the default value (32768) to a significantly lower value so that the bridge becomes the root bridge for the specified VLAN. Use the spanning-tree vlan vlan-id root command to alter the bridge priority.

The switch checks the bridge priority of the current root bridges for each VLAN. The bridge priority for the specified VLANs is set to 8192 if this value will cause the switch to become the root for the specified VLANs.

If any root switch for the specified VLANs has a bridge priority lower than 8192, the switch sets the bridge priority for the specified VLANs to 1 less than the lowest bridge priority.

For example, if all switches in the network have the bridge priority for VLAN 100 set to the default value of 32768, entering the spanning-tree vlan 100 root primary command on a switch will set the bridge priority for VLAN 100 to 8192, causing the switch to become the root bridge for VLAN 100.

Use the diameter keyword to specify the Layer 2 network diameter (that is, the maximum number of bridge hops between any two end stations in the Layer 2 network). When you specify the network diameter, the switch automatically picks an optimal hello time, forward delay time, and maximum age time for a network of that diameter, which can significantly reduce the spanning tree convergence time. You can use the hello-time keyword to override the automatically calculated hello time.

Note	The root bridge for each instance of spanning tree should be a backbone or distribution switch device. Do not configure an access switch device as the spanning tree primary root.

• You should avoid configuring the hello time, forward delay time, and maximum age time manually after configuring the switch as the root bridge.

Caution

Exercise care when using the spanning-tree vlan command with the priority keyword. For most situations spanning-tree vlanwith the root primary keywords and the spanning-tree vlanwith the root secondary keywords are the preferred commands to modify the bridge priority.

Perform this optional task to verify the spanning tree configuration on a VLAN.

Router> enable

Router# show spanning-tree vlan 200
VLAN200 is executing the ieee compatible Spanning Tree protocol
  Bridge Identifier has priority 32768, address 0050.3e8d.6401
  Configured hello time 2, max age 20, forward delay 15
  Current root has priority 16384, address 0060.704c.7000
  Root port is 264 (FastEthernet5/8), cost of root path is 38
  Topology change flag not set, detected flag not set
  Number of topology changes 0 last change occurred 01:53:48 ago
 
 Times:  hold 1, topology change 24, notification 2
          hello 2, max age 14, forward delay 10
  Timers: hello 0, topology change 0, notification 0

 Port 264 (FastEthernet5/8) of VLAN200 is forwarding
   P
ort path cost 19, Port priority 128, Port Identifier 129.9.
   Designated root has priority 16384, address 0060.704c.7000
   Designated bridge has priority 32768, address 00e0.4fac.b000
   Designated port id is 128.2, designated path cost 19
   Timers: message age 3, forward delay 0, hold 0
   Number of transitions to forwarding state: 1
   BPDU: sent 3, received 3417 

Router# show spanning-tree interface fastethernet 5/8
Port 264 (FastEthernet5/8) of VLAN200 is forwarding
   Port path cost 19, Port priority 100, Port Identifier 129.8.
   Designated root has priority 32768, address 0010.0d40.34c7
   Designated bridge has priority 32768, address 0010.0d40.34c7
   Designated port id is 128.1, designated path cost 0
   Timers: message age 2, forward delay 0, hold 0
   Number of transitions to forwarding state: 1
   BPDU: sent 0, received 13513

Router# show spanning-tree bridge brief vlan 200
	Hello Max  Fwd
Vlan                   Bridge ID      Time  Age Delay  Protocol
---------------- -------------------- ---- ---- -----  --------
VLAN200          33792 0050.3e8d.64c8    2   20    15  ieee

When configuring an interface speed and duplex mode, note these guidelines:

• If both ends of the line support autonegotiation, Cisco highly recommends the default autonegotiation settings.
• If one interface supports autonegotiation and the other end does not, configure duplex and speed on both interfaces; do not use the auto setting on the supported side.
• Both ends of the line need to be configured to the same setting. For example, both hard-set or both auto-negotiate. Mismatched settings are not supported.

Caution

Changing the interface speed and duplex mode configuration might shut down and reenable the interface during the reconfiguration.

Perform this task to configure a range of interfaces, define a range macro, set the interface speed, set the duplex mode, and add a description for the interface.

Perform this task to configure an Ethernet interface as a Layer 2 trunk.

Note	Ports do not support Dynamic Trunk Protocol (DTP). Ensure that the neighboring switch is set to a mode that will not send DTP traffic. >

Perform this task to configure an Ethernet interface as a Layer 2 access.

Perform this task to configure separate voice and data VLANs on the EtherSwitch Network Module.

Perform this task to configure a Cisco IP phone to send voice and data traffic on the same VLAN on the EtherSwitch Network Module.

For network designs with incremental IP telephony deployment, network managers can configure the EtherSwitch Network Module so that the voice and data traffic coexist on the same subnet. This might be necessary when it is impractical either to allocate an additional IP subnet for IP phones or to divide the existing IP address space into an additional subnet at the remote branch, it might be necessary to use a single IP address space for branch offices. (This is one of the simpler ways to deploy IP telephony.) When this is the case, you must still prioritize voice above data at both Layer 2 and Layer 3.

Layer 3 classification is already handled because the phone sets the type of service (ToS) bits in all media streams to an IP Precedence value of 5. (With Cisco CallManager Release 3.0(5), this marking changed to a Differentiated Services Code Point ([DSCP]) value of EF.) However, to ensure that there is Layer 2 classification for admission to the multiple queues in the branch office switches, the phone must also use the User Priority bits in the Layer 2 802.1p header to provide class of service (CoS) marking. Setting the bits to provide marking can be done by having the switch look for 802.1p headers on the native VLAN.

This configuration approach must address two key considerations:

• Network managers should ensure that existing subnets have enough available IP addresses for the new Cisco IP phones, each of which requires a unique IP address.
• Administering a network with a mix of IP phones and workstations on the same subnet might pose a challenge.

Use this task to perform basic management tasks such as adding a trap manager and assigning IP information on the EtherSwitch Network Module with the Cisco IOS CLI. You might find this information useful when you configure the EtherSwitch Network Module for the previous scenarios.

A trap manager is a management station that receives and processes traps. When you configure a trap manager, community strings for each member switch must be unique. If a member switch has an IP address assigned to it, the management station accesses the switch by using its assigned IP address.

By default, no trap manager is defined, and no traps are issued.

The recommended configuration for using multiple cables to connect IP phones to the Cisco AVVID network is to use a separate IP subnet and separate VLANs for IP telephony.

Perform this task to instruct the Cisco 7960 IP phone to give voice traffic a higher priority and to forward all traffic through the 802.1Q native VLAN on the EtherSwitch Network Module. This task also disables inline power to a Cisco 7960 IP phone to allow voice traffic to be forwarded to and from the phone.

The EtherSwitch Network Module can connect to a Cisco 7960 IP phone and carry IP voice traffic. If necessary, the EtherSwitch Network Module can supply electrical power to the circuit connecting it to the Cisco 7960 IP phone.

Because the sound quality of an IP telephone call can deteriorate if the data is unevenly transmitted, the current release of the Cisco IOS software supports QoS based on IEEE 802.1p CoS. QoS uses classification and scheduling to transmit network traffic from the switch in a predictable manner.

The Cisco 7960 IP phone contains an integrated three-port 10/100 switch. The ports are dedicated to connect to the following devices:

• Port 1 connects to the EtherSwitch Network Module switch or other voice-over-IP device
• Port 2 is an internal 10/100 interface that carries the phone traffic
• Port 3 connects to a PC or other device

Because a Cisco 7960 IP phone also supports connection to a PC or other device, a port connecting a EtherSwitch Network Module to a Cisco 7960 IP phone can carry a mix of traffic. There are three ways to configure a port connected to a Cisco 7960 IP phone:

• All traffic is transmitted according to the default COS priority (0) of the port. This is the default.
• Voice traffic is given a higher priority by the phone, and all traffic is in the same VLAN.
• Voice and data traffic are carried on separate VLANs, and voice traffic always has a CoS priority of 5.

The EtherSwitch Network Module can supply inline power to a Cisco 7960 IP phone, if necessary. The Cisco 7960 IP phone can also be connected to an AC power source and supply its own power to the voice circuit. When the Cisco 7960 IP phone is supplying its own power, an EtherSwitch Network Module can forward IP voice traffic to and from the phone.

A detection mechanism on the EtherSwitch Network Module determines whether it is connected to a Cisco 7960 IP phone. If the switch senses that there is no power on the circuit, the switch supplies the power. If there is power on the circuit, the switch does not supply it.

You can configure the switch to never supply power to the Cisco 7960 IP phone and to disable the detection mechanism.

Perform this optional task to verify that Cisco Discovery Protocol (CDP) is enabled globally, is enabled on an interface, and to display information about neighboring equipment. CDP is enabled by default. For more details on CDP commands, see the Cisco IOS Network Management Command Reference .

Router> enable

Router# show cdp
Global CDP information:
        Sending CDP packets every 120 seconds
        Sending a holdtime value of 180 seconds
        Sending CDPv2 advertisements is enabled

Router# show cdp interface fastethernet 5/1
FastEthernet5/1 is up, line protocol is up
  Encapsulation ARPA
  Sending CDP packets every 120 seconds
  Holdtime is 180 seconds

Router# show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater
Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
JAB023807H1      Fas 5/3            127         T S       WS-C2948  2/46
JAB023807H1      Fas 5/2            127         T S       WS-C2948  2/45
JAB023807H1      Fas 5/1            127         T S       WS-C2948  2/44
JAB023807H1      Gig 1/2            122         T S       WS-C2948  2/50
JAB023807H1      Gig 1/1            122         T S       WS-C2948  2/49
JAB03130104      Fas 5/8            167         T S       WS-C4003  2/47
JAB03130104      Fas 5/9            152         T S       WS-C4003  2/48

Perform this task to enable the MAC address secure option, create a static or dynamic entry in the MAC address table, and configure the aging timer.

Port security is implemented by providing the user with the option to make a port secure by allowing only well-known MAC addresses to send in data traffic.