Apa maksud dari acl change not allowed

An access control list (ACL) is a list of rules that specifies which users or systems are granted or denied access to a particular object or system resource. Access control lists are also installed in routers or switches, where they act as filters, managing which traffic can access the network.

Each system resource has a security attribute that identifies its access control list. The list includes an entry for every user who can access the system. The most common privileges for a file system ACL include the ability to read a file or all the files in a directory, to write to the file or files, and to execute the file if it is an executable file or program. ACLs are also built into network interfaces and operating systems (OSes), including Linux and Windows. On a computer network, access control lists are used to prohibit or allow certain types of traffic to the network. They commonly filter traffic based on its source and destination.

What are access control lists used for?

Access control lists are used for controlling permissions to a computer system or computer network. They are used to filter traffic in and out of a specific device. Those devices can be network devices that act as network gateways or endpoint devices that users access directly.

On a computer system, certain users have different levels of privilege, depending on their role. For example, a user logged in as network administrator may have read, write and edit permissions for a sensitive file or other resource. By contrast, a user logged in as a guest may only have read permissions.

Access control lists can help organize traffic to improve network efficiency and to give network administrators granular control over users on their computer systems and networks. ACLs can also be used to improve network security by keeping out malicious traffic.

How do ACLs work?

Each ACL has one or more access control entries (ACEs) consisting of the name of a user or group of users. The user can also be a role name, such as programmer or tester. For each of these users, groups or roles, the access privileges are stated in a string of bits called an access mask. Generally, the system administrator or the object owner creates the access control list for an object.

Types of access control lists

There are two basic types of ACLs:

1. File system ACLs manage access to files and directories. They give OSes the instructions that establish user access permissions for the system and their privileges once the system has been accessed.
2. Networking ACLs manage network access by providing instructions to network switches and routers that specify the types of traffic that are allowed to interface with the network. These ACLs also specify user permissions once inside the network. The network administrator predefines the networking ACL rules. In this way, they function similar to a firewall.

ACLs can also be categorized by the way they identify traffic:

• Standard ACLs block or allow an entire protocol suite using source IP addresses.
• Extended ACLs block or allow network traffic based on a more differentiated set of characteristics that includes source and destination IP addresses and port numbers, as opposed to just source address.

Benefits of using an ACL

There are several benefits of using an ACL, including the following:

• Simplified user identification. An access control list simplifies the way that users are identified. ACLs ensure that only approved users and traffic have access to a system.
• Performance. ACLs provide performance advantages over other technologies that perform the same function. They are configured directly on the routing device's forwarding hardware, so access control lists do not have a negative performance effect on routing devices. Compare this to a stateful inspection firewall, which is a separate piece of software that may cause performance degradation. Also, controlling network traffic enables networks to be more efficient.
• Control. ACLs can give administrators more granular control over user and traffic permissions on a network at many different points in the network. They help control access to network endpoints and traffic flowing between internal networks.

Where can you place an access control list?

Access control lists can be placed on virtually any security or routing device, and having multiple ACLs in different parts of the network can be beneficial.

ACLs are well suited to network endpoints -- like applications or servers -- that require high speed and performance, as well as security.

Network administrators may choose to place an access control list at different points in the network depending on the network architecture. ACLs are often placed on the edge routers of a network because they border the public internet. This gives the ACL a chance to filter traffic before it reaches the rest of the network.

Edge routers with ACLs can be placed in the demilitarized zone (DMZ) between the public internet and the rest of the network. A DMZ is a buffer zone with an outward-facing router that provides general security from all external networks. It also features an internal router that separates the DMZ from the protected network.

DMZs may contain different network resources, like application servers, web servers, domain name servers or virtual private networks. The configuration of the ACL on the routing device is different, depending on the devices behind it and the categories of user that need access to those devices.

Components of an access control list

ACL entries consist of several different components that specify how the ACL treats different traffic types. Some examples of common ACL components include the following:

• Sequence number. The sequence number shows the identity of the object in the ACL entry.
• ACL name. This identifies an ACL using a name instead of a number. Some ACLs allow both numbers and letters.
• Comments. Some ACLs enable users to add comments, which are extra descriptions of the ACL entry.
• Network protocol. This enables admins to allow or deny traffic based on a network protocol, such as IP, Internet Control Message Protocol, TCP, User Datagram Protocol or NetBIOS, for example.
• Source and destination. This defines a specific IP address to block or allow or an address range based on Classless Inter-Domain Routing.
• Log. Some ACL devices keep a log of objects that the ACL recognizes.

More advanced ACL entries can specify traffic based on certain IP packet header fields, like Differentiated Services Code Point, Type of Service or IP precedence.

How to implement an ACL

To implement an ACL, network administrators must understand the types of traffic that flow in and out of the network, as well as the types of resources they are trying to protect. Administrators should hierarchically organize and manage IT assets in separate categories and administer different privileges to users.

A standard ACL list is generally implemented close to the destination that it is trying to protect. Extended access control lists are generally implemented close to the source. Extended ACLs can be configured using access list names instead of access list numbers.

The basic syntax used to create a standard numbered access control list on a Cisco router is as follows:

The various parts mean the following:

• (1300-1999) specifies the ACL IP number range. This names the ACL and defines the type of ACL. 1300-1999 makes this a standard ACL.
• (permit | deny) specifies the packet to permit or reject.
• Source-addr specifies the source IP address.
• Source-wildcard specifies the wildcard mask.

A wildcard mask tells a router which bits of an IP address are available for a network device to examine and determine if it matches the access list.

Users can enter the above configuration code into the command line to create the access control list. Cloud platforms from vendors, including Oracle and IBM, also typically offer an option to create an access control list in their user login portal.

Setting user permissions throughout a computer system can be tedious, but there are ways to automate the script.

Access control lists must be configured differently based on differences in network architecture. This includes differences between on-premises, physical networks and cloud networks. Learn the basics of cloud network architecture and network management.

This chapter describes how to configure port ACLs (PACLs) and VLAN ACLs (VACLs) in Cisco IOS Release 12.2SX.

Note ● For complete syntax and usage information for the commands used in this chapter, see the Cisco IOS Master Command List, at this URL:

http://www.cisco.com/en/US/docs/ios/mcl/allreleasemcl/all_book.html

• Optimized ACL logging (OAL) and VACL capture are incompatible. Do not configure both features on the switch. With OAL configured (see the “Optimized ACL Logging” section), use SPAN to capture traffic.
• Port ACLs do not support the access-list keywords log or reflexive. These keywords in the access list are ignored. OAL does not support PACLs.
• PACLs are not supported on private VLANs.

 

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples and troubleshooting information), see the documents listed on this page:

http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

Participate in the Technical Documentation Ideas forum

 

This chapter consists of these sections:

The following sections describe ACLs in Cisco IOS Release 12.2SX:

Access control lists (ACLs) provide the ability to filter ingress and egress traffic based on conditions specified in the ACL.

Cisco IOS Release 12.2SX supports the following types of ACLs:

• Cisco IOS ACLs are applied to Layer 3 interfaces. They filter traffic routed between VLANs. For more information about Cisco IOS ACLs, see Chapter49, “Understanding Cisco IOS ACL Support”
• VACLs control access to the VLAN of all packets (bridged and routed). Packets can either enter the VLAN through a Layer 2 port or through a Layer 3 port after being routed. You can also use VACLs to filter traffic between devices in the same VLAN.
• Port ACLs perform access control on all traffic entering the specified Layer 2 port.

PACLs and VACLs can provide access control based on the Layer 3 addresses (for IP protocols) or Layer 2 MAC addresses (for non-IP protocols).

You can apply only one IP access list and one MAC access list to a Layer 2 interface.

VLAN ACLs (VACLs) can provide access control for all packet s that are bridged within a VLAN or that are routed into or out of a VLAN or a WAN interface for VACL capture. Unlike Cisco IOS ACLs that are applied on routed packets only, VACLs apply to all packets and can be applied to any VLAN or WAN interface. VACLs are processed in the ACL TCAM hardware. VACLs ignore any Cisco IOS ACL fields that are not supported in hardware.

You can configure VACLs for IP and MAC-layer traffic. VACLs applied to WAN interfaces support only IP traffic for VACL capture.

If a VACL is configured for a packet type, and a packet of that type does not match the VACL, the default action is to deny the packet.

Note IGMP packets are not checked against VACLs.

Cisco IOS Release 12.2(33)SXI and later releases support MAC Policy-Based Forwarding (PBF), a type of MAC-based VACL by which packets can be bridged between VLANs. MAC PBF forwards packets based solely on the source and destination MAC addresses, ignoring any information above Layer 2. Unlike other VACLs, which are processed in the ACL TCAM hardware, MAC PBF is performed in software, with optional rate limiters to control CPU usage. Also, PBF is applied only to incoming packets.

Note Layer 2 port ACLs (PACLs) take precedence over MAC PBF.

The port ACL (PACL) feature provides the ability to perform access control on specific Layer 2 ports. A Layer 2 port is a physical LAN or trunk port that belongs to a VLAN. Port ACLs are applied only on the ingress traffic. The port ACL feature is supported only in hardware (port ACLs are not applied to any packets routed in software).

When you create a port ACL, an entry is created in the ACL TCAM. You can use the show tcam counts command to see how much TCAM space is available.

The PACL feature does not affect Layer 2 control packets received on the port.

You can use the access-group mode command to change the way that PACLs interact with other ACLs.

PACLs use the following modes:

• Prefer port mode—If a PACL is configured on a Layer 2 interface, the PACL takes effect and overwrites the effect of other ACLs (Cisco IOS ACL and VACL). If no PACL feature is configured on the Layer 2 interface, other features applicable to the interface are merged and are applied on the interface.
• Merge mode—In this mode, the PACL, VACL, and Cisco IOS ACLs are merged in the ingress direction following the logical serial model shown in Figure 51-2. This is the default access group mode.

You configure the access-group mode command on each interface. The default is merge mode.

Note If we set access-group mode prefer port, it will not only overwrite the effect of other ACLs, but also other features like Netflow (applied to SVI interface) will be affected.

Note A PACL can be configured on a trunk port only after prefer port mode has been selected. Trunk ports do not support merge mode.

To illustrate access group mode, assume a physical port belongs to VLAN100, and the following ACLs are configured:

• Cisco IOS ACL R1 is applied on routed interface VLAN100.
• VACL (VLAN filter) V1 is applied on VLAN100.
• PACL P1 is applied on the physical port.

In this situation, the following ACL interactions occur:

• In prefer port mode, Cisco IOS ACL R1 and VACL V1 are ignored.
• In merge mode, Cisco IOS ACL R1, VACL V1 and PACL P1 are merged and applied on the port.

Note The CLI syntax for creating a PACL is identical to the syntax for creating a Cisco IOS ACL. An instance of an ACL that is mapped to a Layer 2 port is called a PACL. An instance of an ACL that is mapped to a Layer 3 interface is called a Cisco IOS ACL. The same ACL can be mapped to both a Layer 2 port and a Layer 3 interface.

The PACL feature supports MAC ACLs and IPv4 ACLs. The PACL feature does not support ACLs for IPV6, ARP, or Multiprotocol Label Switching (MPLS) traffic.

PACLs are explained in more detail in the following sections:

This section describes the guidelines for the EtherChannel and PACL interactions:

• PACLs are supported on the main Layer 2 channel interface but not on the port members. A port that has a PACL configured on it may not be configured as an EtherChannel member port. The EtherChannel configuration commands are unavailable on ports that are configured with a PACL.
• Changing the configuration on the logical port affects all the ports in the channel. When an ACL is mapped to the logical port belonging to a channel, it is mapped to all ports in the channel.

Dynamic ACLs are VLAN-based and are used by GWIP. The merge mode does not support the merging of the dynamic ACLs with the PACLs. In merge mode, the following configurations are not allowed:

• Attempting to apply a PACL on a port where its corresponding VLAN has a dynamic ACL mapped. In this case, the PACL is not applied to traffic on the port.
• Configuring a dynamic ACL on a VLAN where one of its constituent ports has a PACL installed. In this case, the dynamic ACL is not applied.

To configure a PACL on a trunk port, you must first configure port prefer mode. The configuration commands to apply a PACL on a trunk or dynamic port will not be available until you configure the port in port prefer mode by entering the access-group mode prefer port interface command. Trunk ports do not support merge mode.

If you reconfigure a port from Layer 2 to Layer 3, any PACL configured on the port becomes inactive but remains in the configuration. If you subsequently configure the port as Layer 2, any PACL configured on the port becomes active again.

You can enter port configuration commands that alter the port-VLAN association, which triggers an ACL remerge.

Unmapping and then mapping a PACL, VACL, or Cisco IOS ACL automatically triggers a remerge.

In merge mode, online insertion or removal of a switching module also triggers a remerge, if ports on the module have PACLs configured.

The following sections describe interactions between the different types of ACL:

This section describes the guidelines for the PACL interaction with the VACLs and Cisco IOS ACLs.

For an incoming packet on a physical port, the PACL is applied first. If the packet is permitted by the PACL, the VACL on the ingress VLAN is applied next. If the packet is Layer 3 forwarded and is permitted by the VACL, it is filtered by the Cisco IOS ACL on the same VLAN. The same process happens in reverse in the egress direction. However, there is currently no hardware support for output PACLs.

The PACLs override both the VACLs and Cisco IOS ACLs when the port is configured in prefer port mode. The one exception to this rule is when the packets are forwarded in the software by the route processor (RP). The RP applies the ingress Cisco IOS ACL regardless of the PACL mode. Two examples where the packets are forwarded in the software are as follows:

• Packets that are egress bridged (due to logging or features such as NAT)
• Packets with IP options

Figure 51-1 shows a PACL and a VACL applied to bridged packets. In merge mode, the ACLs are applied in the following order:

1. PACL for the ingress port

2. VACL for the ingress VLAN

3. VACL for the egress VLAN

Figure 51-1 Applying ACLs on Bridged Packets

In prefer port mode, only the PACL is applied to the ingress packets (the input VACL is not applied).

Figure 51-2 shows how ACLs are applied on routed and Layer 3-switched packets. In merge mode, the ACLs are applied in the following order:

1. PACL for the ingress port

2. VACL for the ingress VLAN

3. Input Cisco IOS ACL

4. Output Cisco IOS ACL

5. VACL for the egress VLAN

In prefer port mode, only the PACL is applied to the ingress packets (the input VACL and Cisco IOS ACL are not applied).

Figure 51-2 Applying ACLs on Routed Packets

Figure 51-3 shows how ACLs are applied on packets that need multicast expansion. For packets that need multicast expansion, the ACLs are applied in the following order:

1. Packets that need multicast expansion:

a. PACL for the ingress port

b. VACL for the ingress VLAN

c. Input Cisco IOS ACL

2. Packets after multicast expansion:

a. Output Cisco IOS ACL

b. VACL for the egress VLAN

3. Packets originating from router:

a. Output Cisco IOS ACL

b. VACL for the egress VLAN

In prefer port mode, only the PACL is applied to the ingress packets (the input VACL and Cisco IOS ACL are not applied).

Figure 51-3 Applying ACLs on Multicast Packets

Cisco IOS Release 12.2(33)SXH and later releases support PACLs. This section describes how to configure PACLs. PACLs filter incoming traffic on Layer 2 interfaces, using Layer 3 information, Layer 4 header information, or non-IP Layer 2 information.

The PACL feature uses existing Cisco IOS access-list commands to create the standard or extended IP ACLs or named MAC-extended ACLs that you want to apply to the port.

Use the ip access-group or mac access-group interface command to apply an IP ACL or MAC ACL to one or more Layer 2 interfaces.

Note PACLs cannot filter Physical Link Protocols and Logical Link Protocols, such as CDP, VTP, DTP, PAgP, UDLD, and STP, because the protocols are redirected to the switch processor (SP) before the ACL takes effect.

This section contains the following topics:

Consider the following guidelines when configuring PACLs:

• There can be at most one IP access list and one MAC access list applied to the same Layer 2 interface per direction.
• PACLs are not applied to IPv6, MPLS, or ARP messages.
• An IP access list filters only IPv4 packets, For IP access lists, you can define a standard, extended, or named access-list.
• A MAC access list filters ingress packets that are of an unsupported type (not IP, IPv6, ARP, or MPLS packets) based on the fields of the Ethernet datagram. A MAC access list is not applied to IP, IPv6, MPLS, or ARP messages. You can define only named MAC access lists.
• The number of ACLs and ACEs that can be configured as part of a PACL are bounded by the hardware resources on the switch. Those hardware resources are shared by various ACL features (such as VACLs) that are configured on the system. If there are insufficient hardware resources to program a PACL in hardware, the PACL is not applied.
• PACL does not support the access-list log and reflect/evaluate keywords. These keywords are ignored if you add them to the access list for a PACL.
• OAL does not support PACLs.
• The access group mode can change the way PACLs interact with other ACLs. To maintain consistent behavior across Cisco platforms, use the default access group mode (merge mode).

IP and MAC ACLs can be applied to Layer 2 physical interfaces. Standard (numbered, named) and Extended (numbered, named) IP ACLs, and Extended Named MAC ACLs are supported.

To apply IP or MAC ACLs on a Layer 2 interface, perform this task:

	Command	Purpose
Step 1	Switch# configure terminal	Enters global configuration mode.
Step 2	Switch(config)# interface interface	Enters interface configuration mode for a Layer 2 port.
Step 3	Switch(config-if)# { ip | mac } access-group { name | number | in | out }	Applies a numbered or named ACL to the Layer 2 interface.
Step 4	Switch(config)# show running-config	Displays the access list configuration.

This example shows how to configure the Extended Named IP ACL simple-ip-acl to permit all TCP traffic and implicitly deny all other IP traffic:

Switch(config)# ip access-list extended simple-ip-acl

Switch(config-ext-nacl)# permit tcp any any

Switch(config-ext-nacl)# end

 

This example shows how to configure the Extended Named MAC ACL simple-mac-acl to permit source host 000.000.011 to any destination host:

Switch(config)# mac access-list extended simple-mac-acl

Switch(config-ext-macl)# permit host 000.000.011 any

Switch(config-ext-macl)# end

To configure the access mode on a Layer 2 interface, perform this task:

	Command	Purpose
Step 1	Switch# configure terminal	Enters global configuration mode.
Step 2	Switch(config)# interface interface	Enters interface configuration mode for a Layer 2 port.
Step 3	Switch(config-if)# [ no ] access-group mode { prefer port | merge }	Sets the mode for this Layer 2 interface. The no prefix sets the mode to the default value (which is merge).
Step 4	Switch(config)# show running-config	Displays the access list configuration.

This example shows how to configure an interface to use prefer port mode:

Switch# configure terminal

Switch(config)# interface gigabitEthernet 6/1

Switch(config-if)# access-group mode prefer port

 

This example shows how to configure an interface to use merge mode:

Switch# configure terminal

Switch(config)# interface gigabitEthernet 6/1

Switch(config-if)# access-group mode merge

To apply IP and MAC ACLs to a Layer 2 interface, perform one of these tasks:

Command	Purpose
Switch(config-if)# ip access-group ip-acl in	Applies an IP ACL to the Layer 2 interface.
Switch(config-if)# mac access-group mac-acl in	Applies a MAC ACL to the Layer 2 interface.

This example applies the extended named IP ACL simple-ip-acl to interface GigabitEthernet 6/1 ingress traffic:

Switch# configure t

Switch(config)# interface gigabitEthernet 6/1

Switch(config-if)# ip access-group simple-ip-acl in

 

This example applies the extended named MAC ACL simple-mac-acl to interface GigabitEthernet 6/1 ingress traffic:

Switch# configure t

Switch(config)# interface gigabitEthernet 6/1

Switch(config-if)# mac access-group simple-mac-acl in

To apply IP and MAC ACLs to a port channel logical interface, perform this task:

Command	Purpose
Switch(config-if)# interface port-channel number	Enters configuration mode for the port channel.
Switch(config-if)# ip access-group ip-acl {in | out}	Applies an IP ACL to the port channel interface.
Switch(config-if)# mac access-group mac-acl {in | out}	Applies a MAC ACL to the port channel interface.

This example applies the extended named IP ACL simple-ip-acl to port channel 3 ingress traffic:

Switch# configure t

Switch(config)# interface port-channel 3

Switch(config-if)# ip access-group simple-ip-acl in

To display information about an ACL configuration on Layer 2 interfaces, perform one of these tasks:

Command	Purpose
Switch# show ip access-lists [interface interface-name]	Shows the IP access group configuration on the interface.
Switch# show mac access-group [interface interface-name]	Shows the MAC access group configuration on the interface.
Switch# show access-group mode [interface interface-name]	Shows the access group mode configuration on the interface.

This example shows that the IP access group simple-ip-acl is configured on the inbound direction of interface fa6/1:

Switch# show ip interface fast 6/1

FastEthernet6/1 is up, line protocol is up

Inbound access list is simple-ip-acl

Outgoing access list is not set

 

This example shows that MAC access group simple-mac-acl is configured on the inbound direction of interface fa6/1:

Switch# show mac access-group interface fast 6/1

Interface FastEthernet6/1:

Inbound access-list is simple-mac-acl

Outbound access-list is not set

This example shows that access group merge is configured on interface fa6/1:

Switch# show access-group mode interface fast 6/1

Interface FastEthernet6/1:

Access group mode is: merge

These sections describe how to configure VACLs:

Consider the following guidelines when configuring VACLs:

• VACLs use standard and extended Cisco IOS IP and MAC layer-named ACLs (see the “Configuring MAC ACLs” section) and VLAN access maps.
• VLAN access maps can be applied to VLANs or to WAN interfaces for VACL capture. VACLs attached to WAN interfaces support only standard and extended Cisco IOS IP ACLs.
• Each VLAN access map can consist of one or more map sequences; each sequence has a match clause and an action clause. The match clause specifies IP or MAC ACLs for traffic filtering and the action clause specifies the action to be taken when a match occurs. When a flow matches a permit ACL entry, the associated action is taken and the flow is not checked against the remaining sequences. When a flow matches a deny ACL entry, it will be checked against the next ACL in the same sequence or the next sequence. If a flow does not match any ACL entry and at least one ACL is configured for that packet type, the packet is denied.
• To apply access control to both bridged and routed traffic, you can use VACLs alone or a combination of VACLs and ACLs. You can define ACLs on the VLAN interfaces to apply access control to both the ingress and egress routed traffic. You can define a VACL to apply access control to the bridged traffic.
• The following caveats apply to ACLs when used with VACLs:

– Packets that require logging on the outbound ACLs are not logged if they are denied by a VACL.

– VACLs are applied on packets before NAT translation. If the translated flow is not subject to access control, the flow might be subject to access control after the translation because of the VACL configuration.

• When VACL capture is configured with Policy Based Routing (PBR) on the same interface, do not select BDD as the ACL merge algorithm. We recommend using ODM, the default ACL merge algorithm for the Supervisor Engine 720.
• When VACL capture is configured on an egress interface together with another egress feature that requires software processing of the traffic, packets of the overlapping traffic may be captured twice.
• By default, software-switched WAN packets are not subjected to ACL lookup in the ACL TCAM and are therefore not affected by hardware-only features. As a result, VACL capture will fail for software-switched WAN packets. In Cisco IOS Release 12.2(33)SXI2 and later releases, you can allow ACLs to be applied to egress or ingress software-switched WAN packets by entering the platform cwan acl software-switched { egress | ingress } command in global configuration mode. To verify whether ACLs will be applied to software-switched WAN packets, enter the show platform acl software-switched command as shown in this example:

Router (config)# platform cwan acl software-switched ingress

Router (config)# exit

Router# show platform acl software-switched

CWAN: ACL treatment for software switched in INGRESS is enabled

CWAN: ACL treatment for software switched in EGRESS is disabled

 

• The action clause in a VACL can be forward, drop, capture, or redirect. Traffic can also be logged. VACLs applied to WAN interfaces do not support the redirect or log actions.
• VACLs cannot be applied to IGMP, MLD, or PIM traffic.
• When the WAN logical interface (Multilink or Multilink Frame Relay) is removed, the corresponding VACL filter applied to the WAN logical interface is also removed and the error message VACL-4-VLANFILTER_CWAN_DELETE appears. The following example displays an illustration of this behavior:

Router (config)# do show vlan filter

VLAN Map capture_all:

Configured on VLANs: 100

Active on VLANs: 100

 

Configured on Interfaces: Multilink100

Active on Interfaces:

 

Router (config)# no interface multilink 100

% Please 'shutdown' this interface before trying to delete it

Router (config)# interface multilink 100

Router (config-if)# show

Router (config-if)# exit

Router (config)# no interface multilink 100

Router (config)#

%VACL-4-VLANFILTER_CWAN_DELETE: VLAN ACCESS-MAP capture_all applied on Multilink100 will be removed.

Router (config)# do show vlan filter

VLAN Map capture_all:

Configured on VLANs: 100

Active on VLANs: 100

 

Router (config)#

Note ● VACLs have an implicit deny at the end of the map; a packet is denied if it does not match any ACL entry, and at least one ACL is configured for the packet type.

• If an empty or undefined ACL is specified in a VACL, any packets will match the ACL, and the associated action is taken.

 

To define a VLAN access map, perform this task:

Command	Purpose
Router(config)# vlan access-map map_name [ 0-65535 ]	Defines the VLAN access map. Optionally, you can specify the VLAN access map sequence number.
Router(config)# no vlan access-map map_name 0-65535	Deletes a map sequence from the VLAN access map.
Router(config)# no vlan access-map map_name	Deletes the VLAN access map.

When defining a VLAN access map, note the following information:

• To insert or modify an entry, specify the map sequence number.
• If you do not specify the map sequence number, a number is automatically assigned.
• You can specify only one match clause and one action clause per map sequence.
• Use the no keyword with a sequence number to remove a map sequence.
• Use the no keyword without a sequence number to remove the map.

See the “VLAN Access Map Configuration and Verification Examples” section.

To configure a match clause in a VLAN access map sequence, perform this task:

Command	Purpose
Router(config-access-map)# match { ip address { 1-199 | 1300-2699 | acl_name } | { mac address acl_name }}	Configures the match clause in a VLAN access map sequence.
Router(config-access-map)# no match { ip address { 1-199 | 1300-2699 | acl_name } | { mac address acl_name }}	Deletes the match clause in a VLAN access map sequence.

When configuring a match clause in a VLAN access map sequence, note the following information:

• You can select one or more ACLs.
• VACLs attached to WAN interfaces support only standard and extended Cisco IOS IP ACLs.
• Use the no keyword to remove a match clause or specified ACLs in the clause.
• For information about named MAC-Layer ACLs, see the “Configuring MAC ACLs” section.
• For information about Cisco IOS ACLs, see the “Traffic Filtering and Firewalls” section of the Cisco IOS Security Configuration Guide, Release 12.2, at this URL:

http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/fsecur_c.html

See the “VLAN Access Map Configuration and Verification Examples” section.

To configure an action clause in a VLAN access map sequence, perform this task:

Command	Purpose
Router(config-access-map)# action { drop [ log ]} | { forward [ capture | vlan vlan_ID ]} | { redirect {{ethernet | fastethernet | gigabitethernet | tengigabitethernet} slot/port} | {port-channel channel_id}}	Configures the action clause in a VLAN access map sequence.
Router(config-access-map)# no action { drop [ log ]} | { forward [ capture | vlan vlan_ID ]} | { redirect {{ethernet | fastethernet | gigabitethernet | tengigabitethernet} slot/port} | {port-channel channel_id}}	Deletes the action clause in from the VLAN access map sequence.

When configuring an action clause in a VLAN access map sequence, note the following information:

• You can set the action to drop, forward, forward capture, or redirect packets.
• VACLs applied to WAN interfaces support only the forward capture action. VACLs applied to WAN interfaces do not support the drop, forward, or redirect actions.
• Forwarded packets are still subject to any configured Cisco IOS security ACLs.
• The capture action sets the capture bit for the forwarded packets so that ports with the capture function enabled can receive the packets. Only forwarded packets can be captured. For more information about the capture action, see the “Configuring a Capture Port” section.
• The forward vlan action implements Policy-Based Forwarding (PBF), bridging between VLANs.
• VACLs applied to WAN interfaces do not support the log action.
• When the log action is specified, dropped packets are logged in software. Only dropped IP packets can be logged.
• The redirect action allows you to specify up to five interfaces, which can be physical interfaces or EtherChannels. You cannot specify packets to be redirected to an EtherChannel member or a VLAN interface.
• The redirect interface must be in the VLAN for which the VACL access map is configured.
• If a VACL is redirecting traffic to an egress SPAN source port, SPAN does not copy the VACL-redirected traffic.
• SPAN and RSPAN destination ports transmit VACL-redirected traffic.
• Use the no keyword to remove an action clause or specified redirect interfaces.

See the “VLAN Access Map Configuration and Verification Examples” section.

To apply a VLAN access map, perform this task:

Command	Purpose
Router(config)# vlan filter map_name { vlan-list vlan_list | interface type 1 number 2 }	Applies the VLAN access map to the specified VLANs or WAN interfaces.

When applying a VLAN access map, note the following information:

• You can apply the VLAN access map to one or more VLANs or WAN interfaces.
• The vlan_list parameter can be a single VLAN ID or a comma-separated list of VLAN IDs or VLAN ID ranges ( vlan_ID – vlan_ID).
• If you delete a WAN interface that has a VACL applied, the VACL configuration on the interface is also removed.
• You can apply only one VLAN access map to each VLAN or WAN interface.
• VACLs applied to VLANs are active only for VLANs with a Layer 3 VLAN interface configured. Applying a VLAN access map to a VLAN without a Layer 3 VLAN interface creates an administratively down Layer 3 VLAN interface to support the VLAN access map.
• VACLs applied to VLANs are inactive if the Layer 2 VLAN does not exist or is not operational.
• You cannot apply a VACL to a secondary private VLAN. VACLs applied to primary private VLANs also apply to secondary private VLANs.
• Use the no keyword to clear VLAN access maps from VLANs or WAN interfaces.

See the “VLAN Access Map Configuration and Verification Examples” section.

To verify VLAN access map configuration, perform this task:

Command	Purpose
Router# show vlan access-map [ map_name ]	Verifies VLAN access map configuration by displaying the content of a VLAN access map.
Router# show vlan filter [ access-map map_name | vlan vlan_id | interface type 3 number 4 ]	Verifies VLAN access map configuration by displaying the mappings between VACLs and VLANs.

Assume IP-named ACL net_10 and any_host are defined as follows:

Router# show ip access-lists net_10

Extended IP access list net_10

permit ip 10.0.0.0 0.255.255.255 any

 

Router# show ip access-lists any_host

Standard IP access list any_host

permit any

 

This example shows how to define and apply a VLAN access map to forward IP packets. In this example, IP traffic matching net_10 is forwarded and all other IP packets are dropped due to the default drop action. The map is applied to VLAN 12 to 16.

Router(config)# vlan access-map thor 10

Router(config-access-map)# match ip address net_10

Router(config-access-map)# action forward

Router(config-access-map)# exit

Router(config)# vlan filter thor vlan-list 12-16

 

This example shows how to define and apply a VLAN access map to drop and log IP packets. In this example, IP traffic matching net_10 is dropped and logged and all other IP packets are forwarded:

Router(config)# vlan access-map ganymede 10

Router(config-access-map)# match ip address net_10

Router(config-access-map)# action drop log

Router(config-access-map)# exit

Router(config)# vlan access-map ganymede 20

Router(config-access-map)# match ip address any_host

Router(config-access-map)# action forward

Router(config-access-map)# exit

Router(config)# vlan filter ganymede vlan-list 7-9

 

This example shows how to define and apply a VLAN access map to forward and capture IP packets. In this example, IP traffic matching net_10 is forwarded and captured and all other IP packets are dropped:

Router(config)# vlan access-map mordred 10

Router(config-access-map)# match ip address net_10

Router(config-access-map)# action forward capture

Router(config-access-map)# exit

Router(config)# vlan filter mordred vlan-list 2, 4-6

A port configured to capture VACL-filtered traffic is called a capture port.

Note To apply IEEE 802.1Q or ISL tags to the captured traffic, configure the capture port to trunk unconditionally (see the “Configuring the Layer 2 Switching Port as an ISL or 802.1Q Trunk” section and the “Configuring the Layer 2 Trunk Not to Use DTP” section).

To configure a capture port, perform this task:

	Command	Purpose
Step 1	Router(config)# interface {{ type 5 slot/port }	Specifies the interface to configure.
Step 2	Router(config-if)# switchport capture allowed vlan { add | all | except | remove } vlan_list	(Optional) Filters the captured traffic on a per-destination-VLAN basis. The default is all.
Step 3	Router(config-if)# switchport capture	Configures the port to capture VACL-filtered traffic.

When configuring a capture port, note the following information:

• You can configure any port as a capture port.
• The vlan_list parameter can be a single VLAN ID or a comma-separated list of VLAN IDs or VLAN ID ranges ( vlan_ID – vlan_ID).
• To encapsulate captured traffic, configure the capture port with the switchport trunk encapsulation command (see the “Configuring a Layer 2 Switching Port as a Trunk” section) before you enter the switchport capture command.
• For unencapsulated captured traffic, configure the capture port with the switchport mode access command (see the “Configuring a LAN Interface as a Layer 2 Access Port” section) before you enter the switchport capture command.
• The capture port supports only egress traffic. No traffic can enter the switch through a capture port.

This example shows how to configure a Fast Ethernet interface 5/1 as a capture port:

Router(config)# interface gigabitEthernet 5/1

Router(config-if)# switchport capture

Router(config-if)# end

 

This example shows how to display VLAN access map information:

Router# show vlan access-map mymap

Vlan access-map "mymap" 10

match: ip address net_10

action: forward capture

Router#

 

This example shows how to display mappings between VACLs and VLANs. For each VACL map, there is information about the VLANs that the map is configured on and the VLANs that the map is active on. A VACL is not active if the VLAN does not have an interface.

Router# show vlan filter

VLAN Map mordred:

Configured on VLANs: 2,4-6

Active on VLANs: 2,4-6

Router#

 

To configure MAC policy-based forwarding (PBF), perform this task on each source VLAN:

	Command	Purpose
Step 1	Router(config)# mac host my_host mac_addr	(Optional) Assigns a name to the MAC address of the source host.
Step 2	Router(config)# mac access-list extended macl_name	Configures a MAC ACL.
Step 3	Router(config-ext-macl)# permit host my_host any	Configures an access control entry (ACE) to permit traffic from the named host to any other address. Hosts can be specified by a name or by a MAC address.
Router(config-ext-macl)# permit host my_host host other_host	Configures an ACE to permit traffic from the named host to one other host.
Step 4	Router(config-ext-macl)# exit	Exits ACL configuration.
Step 5	Router(config)# vlan access-map map_name	Defines a VLAN access map.
Step 6	Router(config-access-map)# match mac address macl_name	Applies the MAC ACL to this VLAN access map.
Step 7	Router(config-access-map)# action forward vlan other_vlan_ID [ local ]	Forwards matching traffic to the other VLAN. Note By default, PBF-specified devices on the same VLAN cannot communicate with each other. To allow local communication by the host, use the local keyword.
Step 8	Router(config-access-map)# exit	Exits access map configuration.
Step 9	Router(config)# vlan filter map_name vlan-list my_vlan_ID	Applies the VLAN access map to the specified VLAN.
Step 10	Router(config)# interface vlan my_vlan_ID	Enters interface configuration mode for the VLAN.
Step 11	Router(config-if)# mac packet-classify	Classifies incoming or outgoing Layer 3 packets on this VLAN as Layer 2 packets.
Step 12	Router(config-if)# exit	Exits interface configuration.
Step 13	Router(config)# mls rate-limit unicast acl mac-pbf pps [ burst_size ]	(Optional) Sets a rate limit on PBF packets. pps —Maximum number of packets per second. The range is 10 to 1000000 packets per second. burst_siz e—Maximum number of packets in a burst. The range is 1 to 255 packets.
Step 14	Router(config)# exit	Exits global configuration mode.
Step 15	Router# show vlan mac-pbf config	Displays MAC PBF configuration and statistics.
Step 16	Router# clear vlan mac-pbf counters	(Optional) Clears MAC PBF packet counters.

When configuring MAC PBF, note the following information:

• To allow traffic in both directions between two VLANs, you must configure MAC PBF in both VLANs.
• You can configure MAC PBF between hosts in different switches.
• By default, MAC PBF hosts in the same VLAN cannot communicate with each other. To allow local communication, use the local keyword.
• When configuring the vlan filter command, specify only one VLAN after the vlan-list keyword. If you specify more than one VLAN, MAC PBF will ignore all but the last VLAN in the list.
• The output of the show vlan mac-pbf config command displays the following fields for configured PBF paths:

– Rcv Vlan — The number of the VLAN to which packets are forwarded by PBF.

– Snd Vlan — The number of the VLAN which will forward packets by PBF.

– DMAC — The MAC address of the destination host on the receiving VLAN.

– SMAC — The MAC address of the source host on the sending VLAN.

– (Local) — Displays 1 if the local keyword is configured in the action forward vlan command on the sending VLAN; displays 0 if the local keyword is not configured.

– (Packet counter) — The number of packets that have been forwarded from the sending VLAN to the receiving VLAN. To clear this counter, enter the clear vlan mac-pbf counters command.

– Pkts dropped — The number of packets that have been dropped by the sending VLAN. To clear this counter, enter the clear vlan mac-pbf counters command.

• If the sending VLAN is shut down, MAC PBF will still function. Shutting down a VLAN disables Layer 3 functionality, but MAC PBF is a Layer 2 function.

This example shows how to configure and display MAC PBF to allow two hosts in separate VLANs (“red” VLAN 100 and “blue” VLAN 200) on the same switch to exchange packets:

Router(config)# mac host host_red3 0001.0002.0003

Router(config)# mac access-list extended macl_red

Router(config-ext-macl)# permit host host_red host host_blue

Router(config-ext-macl)# exit

Router(config)# vlan access-map red_to_blue

Router(config-access-map)# match mac address macl_red

Router(config-access-map)# action forward vlan 200 local

Router(config-access-map)# exit

Router(config)# vlan filter red_to_blue vlan-list 100

Router(config)# interface vlan 100

Router(config-if)# mac packet-classify

Router(config-if)# exit

Router(config)#

Router(config)# mac host host_blue5 0001.0002.0005

Router(config)# mac access-list extended macl_blue

Router(config-ext-macl)# permit host host_blue host host_red

Router(config-ext-macl)# exit

Router(config)# vlan access-map blue_to_red

Router(config-access-map)# match mac address macl_blue

Router(config-access-map)# action forward vlan 100

Router(config-access-map)# exit

Router(config)# vlan filter blue_to_red vlan-list 200

Router(config)# interface vlan 200

Router(config-if)# mac packet-classify

Router(config-if)# exit

Router#

Router# show vlan mac-pbf config

Rcv Vlan 100, Snd Vlan 200, DMAC 0001.0002.0003, SMAC 0001.0002.0005 1 15

Rcv Vlan 200, Snd Vlan 100, DMAC 0001.0002.0005, SMAC 0001.0002.0003 0 23

Pkts Dropped 0

Router#

 

Page 2

This chapter describes Cisco IOS access control list (ACL) support in Cisco IOS Release 12.2SX:

•ACL Support in Hardware and Software

•Cisco IOS ACL Configuration Guidelines and Restrictions

•Policy-Based ACLs

•Configuring IPv6 Address Compression

•Optimized ACL Logging

•Guidelines and Restrictions for Using Layer 4 Operators in ACLs

Note For complete information about configuring Cisco IOS ACLs, see the Cisco IOS Security Configuration Guide, Release 12.2, "Traffic Filtering and Firewalls," at this URL:

http://www.cisco.com/en/US/docs/ios-xml/ios/sec_data_acl/configuration/12-2sx/sec-data-acl-12-2sx-book.html

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples and troubleshooting information), see the documents listed on this page:

http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

Participate in the Technical Documentation Ideas forum

ACLs can be processed in hardware by the Policy Feature Card (PFC), a Distributed Forwarding Card (DFC), or in software by the route processor (RP):

•ACL flows that match a "deny" statement in standard and extended ACLs (input and output) are dropped in hardware if "ip unreachables" is disabled.

•ACL flows that match a "permit" statement in standard and extended ACLs (input and output) are processed in hardware.

•VLAN ACL (VACL) and port ACL (PACL) flows are processed in hardware. If a field that is specified in a VACL or PACL is not supported by hardware processing, then that field is ignored (for example, the log keyword in an ACL), or the whole configuration is rejected (for example, a VACL containing IPX ACL parameters).

•VACL logging is processed in software.

•Dynamic ACL flows are processed in hardware.

•Idle timeout is processed in software.

Note Idle timeout is not configurable. Cisco IOS Release 12.2SX does not support the access-enable host timeout command.

•Except on MPLS interfaces, reflexive ACL flows are processed in hardware after the first packet in a session is processed in software on the RP.

•IP accounting for an ACL access violation on a given port is supported by forwarding all denied packets for that port to the RP for software processing without impacting other flows.

•The PFC does not provide hardware support for Cisco IOS IPX ACLs. Cisco IOS IPX ACLs are supported in software on the RP.

•Extended name-based MAC address ACLs are supported in hardware.

•The following ACL types are processed in software:

–Internetwork Packet Exchange (IPX) access lists

–Standard XNS access list

–Extended XNS access list

–DECnet access list

–Extended MAC address access list

–Protocol type-code access list

Note IP packets with a header length of less than five will not be access controlled.

•Unless you configure optimized ACL logging (OAL), flows that require logging are processed in software without impacting nonlogged flow processing in hardware (see the "Optimized ACL Logging" section).

•The forwarding rate for software-processed flows is substantially less than for hardware-processed flows.

•When you enter the show ip access-list command, the match count displayed does not include packets processed in hardware.

•Hardware-supported counters for hardware-supported ACLs, displayed by the show tcam interface command (not supported in PFC3A mode). See this publication:

http://www.cisco.com/en/US/docs/ios-xml/ios/interface/command/ir-s6.html#GUID-1D17939B-1C8F-422C-83CE-64B096DAD13D

•When you enter the show policy-map interface command, sometimes the counters that are displayed do not include all of the hardware switching platform counters.

The following guidelines and restrictions apply to Cisco IOS ACLs configured for use with any feature:

•You can apply Cisco IOS ACLs directly to Layer 3 ports and to VLAN interfaces.

•You can apply VLAN ACLs and port ACLs to Layer 2 interfaces (see Chapter 51 "Configuring Port ACLs and VLAN ACLs").

•Each type of ACL (IP, IPX, and MAC) filters only traffic of the corresponding type. A Cisco IOS MAC ACL never matches IP or IPX traffic.

•The PFC does not provide hardware support for Cisco IOS IPX ACLs. Cisco IOS IPX ACLs are supported in software on the route processor (RP).

•By default, the RP sends Internet Control Message Protocol (ICMP) unreachable messages when a packet is denied by an access group.

With the ip unreachables command enabled (which is the default), the switch processor (SP) drops most of the denied packets in hardware and sends only a small number of packets to the RP to be dropped (10 packets per second, maximum), which generates ICMP-unreachable messages.

To eliminate the load imposed on the RP CPU by the task of dropping denied packets and generating ICMP-unreachable messages, you can enter the no ip unreachables interface configuration command to disable ICMP unreachable messages, which allows all access group-denied packets to be dropped in hardware.

•ICMP unreachable messages are not sent if a packet is denied by a VACL or a PACL.

•Use named ACLs (instead of numbered ACLs) because this causes less CPU usage when creating or modifying ACL configurations and during system restarts. When you create ACL entries (or modify existing ACL entries), the software performs a CPU-intensive operation called an ACL merge to load the ACL configurations into the PFC hardware. An ACL merge also occurs when the startup configuration is applied during a system restart.

With named ACLs, the ACL merge is triggered only when the user exits the named-acl configuration mode. However, with numbered ACLs, the ACL merge is triggered for every ACE definition and results in a number of intermediate merges during ACL configuration.

Release 12.2(33)SXH and later releases support policy-based ACLs (PBACLs). The following sections describe PBACLs:

•Understanding PBACLs

•PBACL Guidelines and Restrictions

•Configuring PBACL

PBACLs provide the capability to apply access control policies across object groups. An object group is a group of users or servers.

You define an object group as a group of IP addresses or as a group of protocol ports. You then create access control entries (ACEs) that apply a policy (such as permit or deny) to the object group. For example, a policy-based ACE can permit a group of users to access a group of servers.

An ACE defined using a group name is equivalent to multiple ACEs (one applied to each entry in the object group). The system expands the PBACL ACE into multiple Cisco IOS ACEs (one ACE for each entry in the group) and populates the ACEs in the TCAM. Therefore, the PBACL feature reduces the number of entries you need to configure but does not reduce TCAM usage.

If you make changes in group membership, or change the contents of an ACE that uses an access group, the system updates the ACEs in the TCAM. The following types of changes trigger the update:

•Adding a member to a group

•Deleting a member from a group

•Modifying the policy statements in an ACE that uses an access group

You configure a PBACL using extended Cisco IOS ACL configuration commands. As with regular ACEs, you can associate the same access policy with one or more interfaces.

When you configure an ACE, you can use an object group to define the source, the destination, or both.

When configuring PBACLs, note the following guidelines and restrictions:

•PBACLs are supported on Layer 3 interfaces (such as routed interfaces and VLAN interfaces).

•The PBACL feature only supports IPv4 ACEs.

•The PBACL feature supports only Cisco IOS ACLs. It is not supported with any other features. The keywords reflexive and evaluate are not supported.

•The PBACL feature supports only named Cisco IOS ACLs. It does not support numbered ACLs.

•Feature interactions for policy-based ACLs are the same as for Cisco IOS ACLs.

Configure PBACLs using the following tasks:

•Configuring a PBACL IP Address Object Group

•Configuring a PBACL Protocol Port Object Group

•Configuring ACLs with PBACL Object Groups

•Configuring PBACL on an Interface

To create or modify a PBACL IP address object group, perform this task:

The following example creates an object group with three hosts and a network address:

To create or modify a PBACL protocol port object group, perform this task:

The following example creates a port object group that matches protocol port 100 and any port greater than 200, except 300:

To configure an ACL to use a PBACL object group, perform this task:

The following example creates an access list that permits packets from the users in myAG if the protocol ports match the ports specified in myPG:

To configure a PBACL on an interface, use the ip access-group command. The command syntax and usage is the same as for Cisco IOS ACLs. For additional information, see the "Cisco IOS ACL Configuration Guidelines and Restrictions" section.

The following example shows how to associate access list my-pbacl-policy with VLAN 100:

ACLs are implemented in hardware in the Policy Feature Card (PFC), which uses the source or destination IP address and port number in the packet to index the ACL table. The index has a maximum address length of 128 bits.

The IP address field in an IPv6 packet is 128 bits, and the port field is 16 bits. To use full IPv6 addresses in the ACL hardware table, you can turn on compression of IPv6 addresses using the mls ipv6 acl compress address unicast command. This feature compresses the IPv6 address (including port) into 128 bits by removing 16 unused bits from the IPv6 address. Compressible address types can be compressed without losing any information. See Table 49-1 for details about the compression methods.

By default, the command is set for no compression.

To turn on the compression of IPv6 addresses, enter the mls ipv6 acl compress address unicast command. To turn off the compression of IPv6 addresses, enter the no form of this command.

This example shows how to turn on address compression for IPv6 addresses:

This example shows how to turn off address compression for IPv6 addresses:

These sections describe optimized ACL logging (OAL):

•Understanding OAL

•OAL Guidelines and Restrictions

•Configuring OAL

OAL provides hardware support for ACL logging. Unless you configure OAL, packets that require logging are processed completely in software on the RP. OAL permits or drops packets in hardware on the PFC3 and uses an optimized routine to send information to the RP to generate the logging messages.

The following guidelines and restrictions apply to OAL:

•OAL and VACL capture are incompatible. Do not configure both features on the switch. With OAL configured, use SPAN to capture traffic.

•OAL is supported only on the PFC3.

•OAL supports only IPv4 unicast packets.

•OAL supports VACL logging of permitted ingress traffic.

•OAL does not support port ACLs (PACLs).

•OAL does not provide hardware support for the following:

–Reflexive ACLs

–ACLs used to filter traffic for other features (for example, QoS)

–ACLs for unicast reverse path forwarding (uRPF) check exceptions

–Exception packets (for example, TTL failure and MTU failure)

–Packets with IP options

–Packets addressed at Layer 3 to the router

–Packets sent to the RP to generate ICMP unreachable messages

–Packets being processed by features not accelerated in hardware

•To provide OAL support for denied packets, enter the mls rate-limit unicast ip icmp unreachable acl-drop 0 command.

•OAL and the mls verify ip length minimum command are incompatible. Do not configure both.

These sections describe how to configure OAL:

•Configuring OAL Global Parameters

•Configuring OAL on an Interface

•Displaying OAL Information

•Clearing Cached OAL Entries

Note•For complete syntax and usage information for the commands used in this section, see the Cisco IOS Master Command List.

•To provide OAL support for denied packets, enter the mls rate-limit unicast ip icmp unreachable acl-drop 0 command.

To configure global OAL parameters, perform this task:

When configuring OAL global parameters, note the following information:

•entries number_of_entries

–Sets the maximum number of entries cached.

–Range: 0-1,048,576 (entered without commas).

–Default: 8192.

•interval seconds

–Sets the maximum time interval before an entry is sent to be logged. Also if the entry is inactive for this duration it is removed from the cache.

–Range: 5-86,400 (1440 minutes or 24 hours, entered without commas).

–Default: 300 seconds (5 minutes).

•rate-limit number_of_packets

–Sets the number of packets logged per second in software.

–Range: 10-1,000,000 (entered without commas).

–Default: 0 (rate limiting is off and all packets are logged).

•threshold number_of_packets

–Sets the number of packet matches before an entry is logged.

–Range: 1-1,000,000 (entered without commas).

–Default: 0 (logging is not triggered by the number of packet matches).

To configure OAL on an interface, perform this task:

To display OAL information, perform this task:

To clear cached OAL entries, perform this task:

These sections describe guidelines and restrictions when configuring ACLs that include Layer 4 port operations:

•Determining Layer 4 Operation Usage

•Determining Logical Operation Unit Usage

You can specify these types of operations:

•gt (greater than)

•lt (less than)

•neq (not equal)

•eq (equal)

•range (inclusive range)

We recommend that you do not specify more than nine different operations on the same ACL. If you exceed this number, each new operation might cause the affected ACE to be translated into more than one ACE.

Use the following two guidelines to determine Layer 4 operation usage:

•Layer 4 operations are considered different if the operator or the operand differ. For example, in this ACL there are three different Layer 4 operations ("gt 10" and "gt 11" are considered two different Layer 4 operations):

Note There is no limit to the use of "eq" operators as the "eq" operator does not use a logical operator unit (LOU) or a Layer 4 operation bit. See the "Determining Logical Operation Unit Usage" section for a description of LOUs.

•Layer 4 operations are considered different if the same operator/operand couple applies once to a source port and once to a destination port. For example, in this ACL there are two different Layer 4 operations because one ACE applies to the source port and one applies to the destination port.

Logical operation units (LOUs) are registers that store operator-operand couples. All ACLs use LOUs. There can be up to 32 LOUs; each LOU can store two different operator-operand couples with the exception of the range operator. LOU usage per Layer 4 operation is as follows:

•gt uses 1/2 LOU

•lt uses 1/2 LOU

•neq uses 1/2 LOU

•range uses 1 LOU

•eq does not require a LOU

For example, this ACL would use a single LOU to store two different operator-operand couples:

A more detailed example follows:

The Layer 4 operations and LOU usage is as follows:

•ACL1 Layer 4 operations: 5

•ACL2 Layer 4 operations: 4

•LOUs: 4

An explanation of the LOU usage follows:

•LOU 1 stores "gt 10" and "lt 9"

•LOU 2 stores "gt 11" and "neq 6"

•LOU 3 stores "gt 20" (with space for one more)

•LOU 4 stores "range 11 13" (range needs the entire LOU)

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples and troubleshooting information), see the documents listed on this page:

http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

Participate in the Technical Documentation Ideas forum

Page 3

This chapter describes the command-line interfaces (CLIs) you use to configure the switches supported by Cisco IOS Release 12.2SX.

Note For complete syntax and usage information for the commands used in this chapter, see these publications:

•The Cisco IOS Master Command List, at this URL:

http://www.cisco.com/en/US/docs/ios/mcl/allreleasemcl/all_book.html

•The Release 12.2 publications at this URL:

http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_installation_and_configuration_guides_list.html

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples and troubleshooting information), see the documents listed on this page:

http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

Participate in the Technical Documentation Ideas forum

This chapter consists of these sections:

•Accessing the CLI

•Performing Command Line Processing

•Performing History Substitution

•Cisco IOS Command Modes

•Displaying a List of Cisco IOS Commands and Syntax

•Securing the CLI

•ROM-Monitor Command-Line Interface

These sections describe accessing the CLI:

•Accessing the CLI through the EIA/TIA-232 Console Interface

•Accessing the CLI through Telnet

Note EIA/TIA-232 was known as recommended standard 232 (RS-232) before its acceptance as a standard by the Electronic Industries Alliance (EIA) and Telecommunications Industry Association (TIA).

Perform initial configuration over a connection to the EIA/TIA-232 console interface. See the Catalyst 6500 Series Switch Module Installation Guide for console interface cable connection procedures.

To make a console connection, perform this task:

After making a console connection, you see this display:

Note Before you can make a Telnet connection to the switch, you must configure an IP address (see the "Configuring IPv4 Routing and Addresses" section).

The switch supports up to eight simultaneous Telnet sessions. Telnet sessions disconnect automatically after remaining idle for the period specified with the exec-timeout command.

To make a Telnet connection to the switch, perform this task:

This example shows how to open a Telnet session to the switch:

Commands are not case sensitive. You can abbreviate commands and parameters if the abbreviations contain enough letters to be different from any other currently available commands or parameters. You can scroll through the last 20 commands stored in the history buffer, and enter or edit the command at the prompt. Table 2-1 lists the keyboard shortcuts for entering and editing commands.

The history buffer stores the last 20 commands you entered. History substitution allows you to access these commands without retyping them, by using special abbreviated commands. Table 2-2 lists the history substitution commands.

Note For complete information about Cisco IOS command modes, see the Cisco IOS Configuration Fundamentals Configuration Guide at this URL:

http://www.cisco.com/en/US/docs/ios/12_2/configfun/configuration/guide/ffun_c.html

The Cisco IOS user interface is divided into many different modes. The commands available to you depend on which mode you are currently in. To get a list of the commands in a given mode, type a question mark (?) at the system prompt. See the "Displaying a List of Cisco IOS Commands and Syntax" section.

When you start a session on the switch, you begin in user mode, often called user EXEC mode. Only a limited subset of the commands are available in EXEC mode. To have access to all commands, you must enter privileged EXEC mode. Normally, you must type in a password to access privileged EXEC mode. From privileged EXEC mode, you can type in any EXEC command or access global configuration mode.

The configuration modes allow you to make changes to the running configuration. If you later save the configuration, these commands are stored across reboots. You must start at global configuration mode. From global configuration mode, you can enter interface configuration mode, subinterface configuration mode, and a variety of protocol-specific modes.

Note With Release 12.1(11b)E and later, when you are in configuration mode you can enter EXEC mode-level commands by entering the do keyword before the EXEC mode-level command.

ROM-monitor mode is a separate mode used when the switch cannot boot properly. For example, the switch might enter ROM-monitor mode if it does not find a valid system image when it is booting, or if its configuration file is corrupted at startup. See the "ROM-Monitor Command-Line Interface" section.

Table 2-3 lists and describes frequently used Cisco IOS modes.

The Cisco IOS command interpreter, called the EXEC, interprets and executes the commands you enter. You can abbreviate commands and keywords by entering just enough characters to make the command unique from other commands. For example, you can abbreviate the show command to sh and the configure terminal command to config t.

When you type exit, the switch backs out one level. To exit configuration mode completely and return to privileged EXEC mode, press Ctrl-Z.

In any command mode, you can display a list of available commands by entering a question mark (?).

To display a list of commands that begin with a particular character sequence, type in those characters followed by the question mark (?). Do not include a space. This form of help is called word help because it completes a word for you.

To display keywords or arguments, enter a question mark in place of a keyword or argument. Include a space before the question mark. This form of help is called command syntax help because it reminds you which keywords or arguments are applicable based on the command, keywords, and arguments you have already entered.

For example:

To redisplay a command you previously entered, press the up arrow key or Ctrl-P. You can continue to press the up arrow key to see the last 20 commands you entered.

Tip If you are having trouble entering a command, check the system prompt, and enter the question mark (?) for a list of available commands. You might be in the wrong command mode or using incorrect syntax.

Enter exit to return to the previous mode. Press Ctrl-Z or enter the end command in any mode to immediately return to privileged EXEC mode.

Securing access to the CLI prevents unauthorized users from viewing configuration settings or making configuration changes that can disrupt the stability of your network or compromise your network security. You can create a strong and flexible security scheme for your switch by configuring one or more of these security features:

•Protecting access to privileged EXEC commands

At a minimum, you should configure separate passwords for the user EXEC and privileged EXEC (enable) IOS command modes. You can further increase the level of security by configuring username and password pairs to limit access to CLI sessions to specific users. For more information, see "Configuring Security with Passwords, Privilege Levels, and Login Usernames for CLI Sessions on Networking Devices" at this URL:

http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_cfg_sec_4cli.html

•Controlling switch access with RADIUS, TACACS+, or Kerberos

For a centralized and scalable security scheme, you can require users to be authenticated and authorized by an external security server running either Remote Authentication Dial-In User Service (RADIUS), Terminal Access Controller Access-Control System Plus (TACACS+), or Kerberos.

For more information about RADIUS, see "Configuring RADIUS" at this URL:

http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfrad.html

For more information about TACACS+, see "Configuring TACACS+" at this URL:

http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scftplus.html

For more information about Kerberos, see "Configuring Kerberos" at this URL:

http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfkerb.html

•Configuring a secure connection with SSH or HTTPS

To prevent eavesdropping of your configuration session, you can use a Secure Shell (SSH) client or a browser that supports HTTP over Secure Socket Layer (HTTPS) to make an encrypted connection to the switch.

For more information about SSH, see "Configuring Secure Shell" at this URL:

http://www.cisco.com/en/US/docs/ios-xml/ios/sec_usr_ssh/configuration/12-2sx/sec-secure-copy.html

For more information about HTTPS, see "HTTPS - HTTP Server and Client with SSL 3.0" at this URL:

http://www.cisco.com/en/US/docs/ios/sec_user_services/configuration/guide/sec_cfg_sec_4cli.html

•Copying configuration files securely with SCP

To prevent eavesdropping when copying configuration files or image files to or from the switch, you can use the Secure Copy Protocol (SCP) to perform an encrypted file transfer. For more information about SCP, see "Secure Copy" at this URL:

http://www.cisco.com/en/US/docs/ios-xml/ios/sec_usr_ssh/configuration/12-2sy/sec-usr-ssh-sec-copy.html

For additional information about securing the CLI, see "Cisco IOS Security Configuration Guide: Securing User Services, Release 12.2SX" at this URL:

http://www.cisco.com/en/US/docs/ios-xml/ios/security/config_library/12-2sx/secuser-12-2sx-library.html

The ROM-monitor is a ROM-based program that executes upon platform power-up, reset, or when a fatal exception occurs. The switch enters ROM-monitor mode if it does not find a valid software image, if the NVRAM configuration is corrupted, or if the configuration register is set to enter ROM-monitor mode. From the ROM-monitor mode, you can load a software image manually from flash memory, from a network server file, or from bootflash.

You can also enter ROM-monitor mode by restarting and pressing the Break key during the first 60 seconds of startup.

Note The Break key is always enabled for 60 seconds after rebooting, regardless of whether the Break key is configured to be off by configuration register settings.

To access the ROM-monitor mode through a terminal server, you can escape to the Telnet prompt and enter the send break command for your terminal emulation program to break into ROM-monitor mode.

Once you are in ROM-monitor mode, the prompt changes to rommon 1>. Enter a question mark (?) to see the available ROM-monitor commands.

For more information about the ROM-monitor commands, see the Cisco IOS Master Command List.

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples and troubleshooting information), see the documents listed on this page:

http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

Participate in the Technical Documentation Ideas forum

Page 4

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Page 5

This chapter describes how to use the Mini Protocol Analyzer on the Catalyst 6500 series switches. Release 12.2(33)SXI and later releases support the Mini Protocol Analyzer feature.

Note For complete syntax and usage information for the commands used in this chapter, see the Cisco IOS Master Command List, at this URL:

http://www.cisco.com/en/US/docs/ios/mcl/allreleasemcl/all_book.html

 

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples and troubleshooting information), see the documents listed on this page:

http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

Participate in the Technical Documentation Ideas forum

 

This chapter consists of these sections:

To configure a capture session using the Mini Protocol Analyzer, perform this task:

	Command	Purpose
Step 1	Router# configure terminal	Enters global configuration mode.
Step 2	Router(config)# [ no ] monitor session number type capture	Configures a SPAN session number with packets directed to the processor for capture. Enters capture session configuration mode. The session number range is 1 to 80. The no prefix removes the session.
Step 3	Router(config-mon-capture)# buffer-size buf_size	(Optional) Sets the size in KB of the capture buffer. The range is 32-65535 KB; the default is 2048 KB.
Step 4	Router(config-mon-capture)# description session_description	(Optional) Describes the capture session. The description can be up to 240 characters and cannot contain special characters. If the description contains spaces, it must be enclosed in quotation marks(“”).
Step 5	Router(config-mon-capture)# rate-limit pps	(Optional) Sets a limit on the number of packets per second ( pps) that can be captured. The range is 10-100000 packets per seconds; the default is 10000 packets per second.
Step 6	Router(config-mon-capture)# source {{ interface { single_interface | interface_list | interface_range | mixed_interface_list } | port-channel channel_id }} | { vlan { vlan_ID | vlan_list | vlan_range | mixed_vlan_list }}[ rx | tx | both ]	Associates the capture session with source ports or VLANs, and selects the traffic direction to be monitored. The default traffic direction is both.
Step 7	Router(config-mon-capture)# exit	Exits the capture session configuration mode.

When configuring a capture session, note the following information:

• Only one capture session is supported; multiple simultaneous capture sessions cannot be configured.
• The source interface command argument is either a single interface, or a range of interfaces described by two interface numbers (the lesser one first, separated by a dash), or a comma-separated list of interfaces and ranges.

Note When configuring a source interface list, you must enter a space before and after the comma. When configuring a source interface range, you must enter a space before and after the dash.

• The source vlan command argument is either a single VLAN number from 1 through 4094 (except reserved VLANs), or a range of VLANs described by two VLAN numbers (the lesser one first, separated by a dash), or a list of VLANs and ranges.

Note When configuring a source VLAN list, do not enter a space before or after the comma. When configuring a source VLAN range, do not enter a space before or after the dash. Note that this requirement differs from the requirement for source interface lists and ranges.

• Data capture does not begin when the capture session is configured. The capture is started by the monitor capture start or monitor capture schedule command described in the “Starting and Stopping a Capture” section.
• Although the capture buffer is linear by default, it can be made circular as a run-time option in the monitor capture start or monitor capture schedule command.
• When no hardware rate limit registers are available, the capture session is disabled.
• For releases earlier than 12.2(33)SXI4, when the fabric switching mode is truncated, you cannot enter an MPA configuration, because the truncated fabric switching mode does not support the MPA rate limiter.
• From release 12.2(33)SXI4 and later, when the fabric switching mode is truncated, you can enter an MPA configuration, but the default rate limiter and, if configured, the MPA rate limiter are not active.
• When the switching mode is truncated on a supervisor without a DFC, MPA does not capture all the packets.

Note Ignore the Rate-limiter is not configurable system message.

• The source VLAN cannot be changed if a VLAN filter is configured. Remove any VLAN filters before changing the source VLAN.

Several options are provided for filtering the packets to be captured. Filtering by ACL and VLAN is performed in hardware before any rate-limiting is applied; all other filters are executed in software. Software filtering can decrease the capture rate.

To filter the packets to be captured by the Mini Protocol Analyzer, perform this task in capture session configuration mode:

	Command	Purpose
Step 1	Router(config-mon-capture)# filter access-group { acl_number | acl_name }	(Optional) Captures only packets from the specified ACL.
Step 2	Router(config-mon-capture)# filter vlan { vlan_ID | vlan_list | vlan_range | mixed_vlan_list }	(Optional) Captures only packets from the specified source VLAN or VLANs.
Step 3	Router(config-mon-capture)# filter ethertype type	(Optional) Captures only packets of the specified EtherType. The type can be specified in decimal, hex, or octal.
Step 4	Router(config-mon-capture)# filter length min_len [ max_len ]	(Optional) Captures only packets whose size is between min_len and max_len, inclusive. If max_len is not specified, only packets of exactly size min_len will be captured. The range for min_len is 0 to 9216 bytes and the range for max_len is 1 to 9216 bytes.
Step 5	Router(config-mon-capture)# filter mac-address mac_addr	(Optional) Captures only packets from the specified MAC address.
Step 6	Router(config-mon-capture)# end	Exits the configuration mode.

When configuring capture filtering, note the following information:

• The filter vlan argument is either a single VLAN number from 1 through 4094 (except reserved VLANs), or a range of VLANs described by two VLAN numbers (the lesser one first, separated by a dash), or a list of VLANs and ranges.

Note When configuring a filter VLAN list, you must enter a space before and after the comma. When configuring a filter VLAN range, you must enter a space before and after the dash. Note that this requirement differs from the requirement for source VLAN lists and ranges described in the preceding section.

• To enter an EtherType as a decimal number, enter the number (1 to 65535) with no leading zero. To enter a hexadecimal number, precede four hexadecimal characters with the prefix 0x. To enter an octal number, enter numeric digits (0 to 7) with a leading zero. For example, the 802.1Q EtherType can be entered in decimal notation as 33024, in hexadecimal as 0x8100, or in octal as 0100400.
• Enter a MAC address as three 2-byte values in dotted hexadecimal format. An example is 0123.4567.89ab.
• The no keyword removes the filter.

Note After removing a VLAN filter using the no keyword, you must exit configuration mode, reenter the capture configuration mode, and issue the source vlan command before making other capture configuration changes.

• When you configure a VLAN filter, the capture source or destination must be a VLAN. When you configure a port filter, the capture source or destination must be a port.

Page 6

This chapter describes how to configure local Switched Port Analyzer (SPAN), remote SPAN (RSPAN), and Encapsulated RSPAN (ERSPAN) in Cisco IOS Release 12.2SX.

Note•For complete syntax and usage information for the commands used in this chapter, see the Cisco IOS Master Command List, at this URL:

http://www.cisco.com/en/US/docs/ios/mcl/allreleasemcl/all_book.html

•SPA ports and FlexWAN ports do not support SPAN, RSPAN, or ERSPAN.

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples and troubleshooting information), see the documents listed on this page:

http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

Participate in the Technical Documentation Ideas forum

This chapter consists of these sections:

•Understanding Local SPAN, RSPAN, and ERSPAN

•Local SPAN, RSPAN, and ERSPAN Configuration Guidelines and Restrictions

•Configuring Local SPAN, RSPAN, and ERSPAN

These sections describe how local SPAN, RSPAN, and ERSPAN work:

•Local SPAN, RSPAN, and ERSPAN Overview

•Local SPAN, RSPAN, and ERSPAN Sources

•Local SPAN, RSPAN, and ERSPAN Destinations

SPAN copies traffic from one or more CPUs, one or more ports, one or more EtherChannels, or one or more VLANs, and sends the copied traffic to one or more destinations for analysis by a network analyzer such as a SwitchProbe device or other Remote Monitoring (RMON) probe. Traffic can also be sent to the processor for packet capture by the Mini Protocol Analyzer, as described in Chapter 72 "Using the Mini Protocol Analyzer."

SPAN does not affect the switching of traffic on sources. You must dedicate the destination for SPAN use. The SPAN-generated copies of traffic compete with user traffic for switch resources.

These sections provide an overview of local SPAN, RSPAN, and ERSPAN:

•Local SPAN Overview

•RSPAN Overview

•ERSPAN Overview

•Understanding the Traffic Monitored at SPAN Sources

A local SPAN session is an association of source ports and source VLANs with one or more destinations. You configure a local SPAN session on a single switch. Local SPAN does not have separate source and destination sessions.

Local SPAN sessions do not copy locally sourced RSPAN VLAN traffic from source trunk ports that carry RSPAN VLANs. Local SPAN sessions do not copy locally sourced RSPAN GRE-encapsulated traffic from source ports.

Each local SPAN session can have either ports or VLANs as sources, but not both.

Local SPAN copies traffic from one or more source ports in any VLAN or from one or more VLANs to a destination for analysis (see Figure 68-1). For example, as shown in Figure 68-1, all traffic on Ethernet port 5 (the source port) is copied to Ethernet port 10. A network analyzer on Ethernet port 10 receives all traffic from Ethernet port 5 without being physically attached to Ethernet port 5.

Figure 68-1 Example SPAN Configuration

RSPAN supports source ports, source VLANs, and destinations on different switches, which provides remote monitoring of multiple switches across your network (see Figure 68-2). RSPAN uses a Layer 2 VLAN to carry SPAN traffic between switches.

RSPAN consists of an RSPAN source session, an RSPAN VLAN, and an RSPAN destination session. You separately configure RSPAN source sessions and destination sessions on different switches. To configure an RSPAN source session on one switch, you associate a set of source ports or VLANs with an RSPAN VLAN. To configure an RSPAN destination session on another switch, you associate the destinations with the RSPAN VLAN.

The traffic for each RSPAN session is carried as Layer 2 nonroutable traffic over a user-specified RSPAN VLAN that is dedicated for that RSPAN session in all participating switches. All participating switches must be trunk-connected at Layer 2.

RSPAN source sessions do not copy locally sourced RSPAN VLAN traffic from source trunk ports that carry RSPAN VLANs. RSPAN source sessions do not copy locally sourced RSPAN GRE-encapsulated traffic from source ports.

Each RSPAN source session can have either ports or VLANs as sources, but not both.

The RSPAN source session copies traffic from the source ports or source VLANs and switches the traffic over the RSPAN VLAN to the RSPAN destination session. The RSPAN destination session switches the traffic to the destinations.

Figure 68-2 RSPAN Configuration

ERSPAN supports source ports, source VLANs, and destinations on different switches, which provides remote monitoring of multiple switches across your network (see Figure 68-3). ERSPAN uses a GRE tunnel to carry traffic between switches.

ERSPAN consists of an ERSPAN source session, routable ERSPAN GRE-encapsulated traffic, and an ERSPAN destination session. You separately configure ERSPAN source sessions and destination sessions on different switches.

To configure an ERSPAN source session on one switch, you associate a set of source ports or VLANs with a destination IP address, ERSPAN ID number, and optionally with a VRF name. To configure an ERSPAN destination session on another switch, you associate the destinations with the source IP address, ERSPAN ID number, and optionally with a VRF name.

ERSPAN source sessions do not copy locally sourced RSPAN VLAN traffic from source trunk ports that carry RSPAN VLANs. ERSPAN source sessions do not copy locally sourced ERSPAN GRE-encapsulated traffic from source ports.

Each ERSPAN source session can have either ports or VLANs as sources, but not both.

The ERSPAN source session copies traffic from the source ports or source VLANs and forwards the traffic using routable GRE-encapsulated packets to the ERSPAN destination session. The ERSPAN destination session switches the traffic to the destinations.

Figure 68-3 ERSPAN Configuration

These sections describe the traffic that local SPAN, RSPAN, and ERSPAN sources can monitor:

•Monitored Traffic Direction

•Monitored Traffic Type

•Duplicate Traffic

You can configure local SPAN sessions, RSPAN source sessions, and ERSPAN source sessions to monitor the following traffic:

•Ingress traffic

–Called ingress SPAN.

–Copies traffic received by the sources (ingress traffic).

–Ingress traffic is sent to the supervisor engine SPAN ASIC to be copied.

•Egress traffic

–Called egress SPAN.

–Copies traffic transmitted from the sources (egress traffic).

–Distributed egress SPAN mode—With Release 12.2(33)SXH and later releases, on some fabric-enabled switching modules, egress traffic can be copied locally by the switching module SPAN ASIC and then sent to the SPAN destinations. See the "Distributed Egress SPAN Mode Guidelines and Restrictions" section for information about switching modules that support distributed egress SPAN mode.

–Centralized egress SPAN mode—On all other switching modules, egress traffic is sent to the supervisor engine SPAN ASIC to be copied and is then sent to the SPAN destinations.

•Both

–Copies both the received traffic and the transmitted traffic (ingress and egress traffic).

–Both ingress traffic and egress traffic is sent to the supervisor engine SPAN ASIC to be copied.

By default, local SPAN and ERSPAN monitor all traffic, including multicast and bridge protocol data unit (BPDU) frames. RSPAN does not support BPDU monitoring.

In some configurations, SPAN sends multiple copies of the same source traffic to the destination. For example, in a configuration with a bidirectional SPAN session (both ingress and egress) for two SPAN sources, called s1 and s2, to a SPAN destination, called d1, if a packet enters the switch through s1 and is sent for egress from the switch to s2, ingress SPAN at s1 sends a copy of the packet to SPAN destination d1 and egress SPAN at s2 sends a copy of the packet to SPAN destination d1. If the packet was Layer 2 switched from s1 to s2, both SPAN packets would be the same. If the packet was Layer 3 switched from s1 to s2, the Layer 3 rewrite would alter the source and destination Layer 2 addresses, in which case the SPAN packets would be different.

These sections describe local SPAN, RSPAN, and ERSPAN sources:

•Source CPUs

•Source Ports and EtherChannels

•Source VLANs

A source CPU is a CPU monitored for traffic analysis. With Release 12.2(33)SXH and later releases, you can configure both the SP CPU and the RP CPU as SPAN sources. These are examples of what you can do with the data generated by CPU monitoring:

•Develop baseline information about CPU traffic.

•Develop information to use when creating control plane policing (CoPP) policies.

•Troubleshoot CPU-related issues (for example, high CPU utilization).

Note•CPU SPAN monitors CPU traffic from the perspective of the ASICs that send and receive the CPU traffic, rather than from onboard the CPUs themselves.

•Traffic to and from the CPU is tagged with VLAN IDs. You can configure source VLAN filtering of the CPU traffic.

A source port or EtherChannel is a port or EtherChannel monitored for traffic analysis. You can configure both Layer 2 and Layer 3 ports and EtherChannels as SPAN sources. SPAN can monitor one or more source ports or EtherChannels in a single SPAN session. You can configure ports or EtherChannels in any VLAN as SPAN sources. Trunk ports or EtherChannels can be configured as sources and mixed with nontrunk sources.

Note SPAN does not copy the encapsulation from trunk sources. You can configure SPAN destinations as trunks to tag the monitored traffic before it is transmitted for analysis.

A source VLAN is a VLAN monitored for traffic analysis. VLAN-based SPAN (VSPAN) uses a VLAN as the SPAN source. All the ports and EtherChannels in the source VLANs become sources of SPAN traffic.

Note Layer 3 VLAN interfaces on source VLANs are not sources of SPAN traffic. Traffic that enters a VLAN through a Layer 3 VLAN interface is monitored when it is transmitted from the switch through an egress port or EtherChannel that is in the source VLAN.

A SPAN destination is a Layer 2 or Layer 3 port or, with Release 12.2(33)SXH and later releases, an EtherChannel, to which local SPAN, RSPAN, or ERSPAN sends traffic for analysis. When you configure a port or EtherChannel as a SPAN destination, it is dedicated for use only by the SPAN feature.

Destination EtherChannels do not support the Port Aggregation Control Protocol (PAgP) or Link Aggregation Control Protocol (LACP) EtherChannel protocols; only the on mode is supported, with all EtherChannel protocol support disabled.

There is no requirement that the member links of a destination EtherChannel be connected to a device that supports EtherChannels. For example, you can connect the member links to separate network analyzers. See Chapter 19 "Configuring EtherChannels," for more information about EtherChannel.

Destinations, by default, cannot receive any traffic. With Release 12.2(33)SXH and later releases, you can configure Layer 2 destinations to receive traffic from any attached devices.

Destinations, by default, do not transmit anything except SPAN traffic. Layer 2 destinations that you have configured to receive traffic can be configured to learn the Layer 2 address of any devices attached to the destination and transmit traffic that is addressed to the devices.

You can configure trunks as destinations, which allows trunk destinations to transmit encapsulated traffic. You can use allowed VLAN lists to configure destination trunk VLAN filtering.

These sections describe local SPAN, RSPAN, and ERSPAN configuration guidelines and restrictions:

•General Guidelines and Restrictions

•Feature Incompatibilities

•Local SPAN, RSPAN, and ERSPAN Session Limits

•Local SPAN, RSPAN, and ERSPAN Interface Limits

•Local SPAN, RSPAN, and ERSPAN Guidelines and Restrictions

•VSPAN Guidelines and Restrictions

•RSPAN Guidelines and Restrictions

•ERSPAN Guidelines and Restrictions

•Distributed Egress SPAN Mode Guidelines and Restrictions

Use SPAN for troubleshooting. Except in carefully planned topologies, SPAN consumes too many switch and network resources to enable permanently.

Exercise all possible care when enabling and configuring SPAN. The traffic copied by SPAN can impose a significant load on the switch and the network.

To minimize the load, configure SPAN to copy only the specific traffic that you want to analyze. Select sources that carry as little unwanted traffic as possible. For example, a port as a SPAN source might carry less unwanted traffic than a VLAN.

Note To monitor traffic that can be matched with an ACL, consider using VACL capture.

Before enabling SPAN, carefully evaluate the SPAN source traffic rates, and consider the performance implications and possible oversubscription points, which include these:

•SPAN destination

•Fabric channel

•Rewrite/replication engine

•Forwarding engine (PFC/DFC)

To avoid disrupting traffic, do not oversubscribe any of these points in your SPAN topology. Some oversubscription and performance considerations are:

•SPAN doubles traffic internally

•SPAN adds to the traffic being processed by the switch fabric

•SPAN doubles forwarding engine load

•The supervisor engine handles the entire load imposed by egress SPAN (also called transmit SPAN).

Note Egress SPAN should only be enabled for short periods of time during active troubleshooting.

Release 12.2(33)SXH and later releases support distributed egress SPAN, which reduces the load on the supervisor engine.

•The ingress modules handle the load imposed by ingress SPAN sources (also called receive SPAN) on each module. Ingress SPAN adds to rewrite/replication engine load.

These feature incompatibilities exist with local SPAN, RSPAN, and ERSPAN:

•In releases where CSCth62957 is not resolved, in PFC3B mode or PFC3BXL mode, the xconnect target_ip_address vc_value encapsulation mpls command might cause traffic to loop continuously with these SPAN configurations:

–If the xconnect target_ip_address vc_value encapsulation mpls command is configured on a physical interface, the CLI prevents configuration of that port as part of a SPAN session.

–If a SPAN session is configured on a physical port and you attempt to configure the xconnect target_ip_address vc_value encapsulation mpls command, the CLI prints a warning that recommends against the configuration.

–If the xconnect target_ip_address vc_value encapsulation mpls command is configured on a physical interface, you should not configure source cpu {rp | sp} in any SPAN session, but the CLI does not enforce any restriction.

–If a SPAN session is configured with source cpu {rp | sp} and you attempt to configure the xconnect target_ip_address vc_value encapsulation mpls command, the CLI does not enforce any restriction.

•In releases where CSCth62957 is resolved, to avoid a configuration that might cause traffic to loop continuously, the CLI enforces these restrictions in PFC3B mode or PFC3BXL mode:

–If the xconnect target_ip_address vc_value encapsulation mpls command is configured on a physical interface, the CLI prevents configuration of that port as part of a SPAN session.

–If a SPAN session is configured on a physical port and you attempt to configure the the xconnect target_ip_address vc_value encapsulation mpls command command on that port, the CLI prints a warning that recommends against the configuration.

–If the the xconnect target_ip_address vc_value encapsulation mpls command command is configured on a physical interface, you cannot configure source cpu {rp | sp} in any SPAN session.

–If a SPAN session is configured with source cpu {rp | sp} and you attempt to configure the xconnect target_ip_address vc_value encapsulation mpls command, the CLI prints a warning that recommends against the configuration.

•Egress SPAN is not supported in egress multicast mode. (CSCsa95965)

•Unknown unicast flood blocking (UUFB) ports cannot be RSPAN or local SPAN egress-only destinations. (CSCsj27695)

•Except in PFC3C mode or PFC3CXL mode, Ethernet over MultiProtocol Label Switching (EoMPLS) ports cannot be SPAN sources. (CSCed51245)

•A port-channel interface (an EtherChannel) can be a SPAN source, but you cannot configure active member ports of an EtherChannel as SPAN source ports. Inactive member ports of an EtherChannel can be configured as SPAN sources but they are put into the suspended state and carry no traffic.

•These features are incompatible with SPAN destinations:

–Private VLANs

–IEEE 802.1X port-based authentication

–Port security

–Spanning Tree Protocol (STP) and related features (PortFast, PortFast BPDU filtering, BPDU Guard, UplinkFast, BackboneFast, EtherChannel Guard, Root Guard, Loop Guard)

–VLAN trunk protocol (VTP)

–Dynamic trunking protocol (DTP)

–IEEE 802.1Q tunneling

Note•SPAN destinations can participate in IEEE 802.3Z flow control.

•IP multicast switching using egress packet replication is not compatible with SPAN. In some cases, egress replication can result in multicast packets not being sent to the SPAN destination port. If you are using SPAN and your switching modules are capable of egress replication, enter the mls ip multicast replication-mode ingress command to force ingress replication.

With Release 12.2(33)SXH and later releases, these are the PFC3 local SPAN, RSPAN, and ERSPAN session limits:

With Release 12.2(33)SXH and later releases, these are the PFC3 local SPAN, RSPAN, and ERSPAN source and destination interface limits:

These guidelines and restrictions apply to local SPAN, RSPAN, and ERSPAN:

•A SPAN destination that is copying traffic from a single egress SPAN source port sends only egress traffic to the network analyzer. If you configure more than one egress SPAN source port, the traffic that is sent to the network analyzer also includes these types of ingress traffic that were received from the egress SPAN source ports:

–Any unicast traffic that is flooded on the VLAN

–Broadcast and multicast traffic

This situation occurs because an egress SPAN source port receives these types of traffic from the VLAN but then recognizes itself as the source of the traffic and drops it instead of sending it back to the source from which it was received. Before the traffic is dropped, SPAN copies the traffic and sends it to the SPAN destination. (CSCds22021)

•Entering additional monitor session commands does not clear previously configured SPAN parameters. You must enter the no monitor session command to clear configured SPAN parameters.

•Connect a network analyzer to the SPAN destinations.

•Within a SPAN session, all of the SPAN destinations receive all of the traffic from all of the SPAN sources, except when source-VLAN filtering is configured on the SPAN source.

•You can configure destination trunk VLAN filtering to select which traffic is transmitted from the SPAN destination.

•You can configure both Layer 2 LAN ports (LAN ports configured with the switchport command) and Layer 3 LAN ports (LAN ports not configured with the switchport command) as sources or destinations.

•You cannot mix individual source ports and source VLANs within a single session.

•If you specify multiple ingress source ports, the ports can belong to different VLANs.

•Within a session, you cannot configure both VLANs as SPAN sources and do source VLAN filtering. You can configure VLANs as SPAN sources or you can do source VLAN filtering of traffic from source ports and EtherChannels, but not both in the same session.

•You cannot configure source VLAN filtering for internal VLANs.

•When enabled, local SPAN, RSPAN, and ERSPAN use any previously entered configuration.

•When you specify sources and do not specify a traffic direction (ingress, egress, or both), "both" is used by default.

•SPAN copies Layer 2 Ethernet frames, but SPAN does not copy source trunk port ISL or 802.1Q tags. You can configure destinations as trunks to send locally tagged traffic to the traffic analyzer.

Note A destination configured as a trunk tags traffic from a Layer 3 LAN source with the internal VLAN used by the Layer 3 LAN source.

•Local SPAN sessions, RSPAN source sessions, and ERSPAN source sessions do not copy locally sourced RSPAN VLAN traffic from source trunk ports that carry RSPAN VLANs.

•Local SPAN sessions, RSPAN source sessions, and ERSPAN source sessions do not copy locally sourced ERSPAN GRE-encapsulated traffic from source ports.

•With Release 12.2(33)SXH and later, SPAN sessions can share destinations.

•SPAN destinations cannot be SPAN sources.

•Destinations never participate in any spanning tree instance. Local SPAN includes BPDUs in the monitored traffic, so any BPDUs seen on the destination are from the source. RSPAN does not support BPDU monitoring.

•All packets forwarded through the switch for transmission from a port that is configured as an egress SPAN source are copied to the SPAN destination, including packets that do not exit the switch through the egress port because STP has put the egress port into the blocking state, or on an egress trunk port because STP has put the VLAN into the blocking state on the trunk port.

Note Local SPAN, RSPAN, and ERSPAN all support VSPAN.

These are VSPAN guidelines and restrictions:

•VSPAN sessions do not support source VLAN filtering.

•For VSPAN sessions with both ingress and egress configured, two packets are forwarded from the destination to the analyzer if the packets get switched on the same VLAN (one as ingress traffic from the ingress port and one as egress traffic from the egress port).

•VSPAN only monitors traffic that leaves or enters Layer 2 ports in the VLAN.

–If you configure a VLAN as an ingress source and traffic gets routed into the monitored VLAN, the routed traffic is not monitored because it never appears as ingress traffic entering a Layer 2 port in the VLAN.

–If you configure a VLAN as an egress source and traffic gets routed out of the monitored VLAN, the routed traffic is not monitored because it never appears as egress traffic leaving a Layer 2 port in the VLAN.

These are RSPAN guidelines and restrictions:

•All participating switches must be connected by Layer 2 trunks.

•Any network device that supports RSPAN VLANs can be an RSPAN intermediate device.

•Networks impose no limit on the number of RSPAN VLANs that the networks carry.

•Intermediate network devices might impose limits on the number of RSPAN VLANs that they can support.

•You must configure the RSPAN VLANs in all source, intermediate, and destination network devices. If enabled, the VLAN Trunking Protocol (VTP) can propagate configuration of VLANs numbered 1 through 1024 as RSPAN VLANs. You must manually configure VLANs numbered higher than 1024 as RSPAN VLANs on all source, intermediate, and destination network devices.

•If you enable VTP and VTP pruning, RSPAN traffic is pruned in the trunks to prevent the unwanted flooding of RSPAN traffic across the network.

•RSPAN VLANs can be used only for RSPAN traffic.

•Do not configure a VLAN used to carry management traffic as an RSPAN VLAN.

•Do not assign access ports to RSPAN VLANs. RSPAN puts access ports in an RSPAN VLAN into the suspended state.

•Do not configure any ports in an RSPAN VLAN except trunk ports selected to carry RSPAN traffic.

•MAC address learning is disabled in the RSPAN VLAN.

•You can use output access control lists (ACLs) on the RSPAN VLAN in the RSPAN source switch to filter the traffic sent to an RSPAN destination.

•RSPAN does not support BPDU monitoring.

•Do not configure RSPAN VLANs as sources in VSPAN sessions.

•You can configure any VLAN as an RSPAN VLAN as long as all participating network devices support configuration of RSPAN VLANs and you use the same RSPAN VLAN for each RSPAN session in all participating network devices.

These are ERSPAN guidelines and restrictions:

•A WS-SUP720 (a Supervisor Engine 720 manufactured with a PFC3A) can only support ERSPAN if it has hardware version 3.2 or higher. Enter the show module version | include WS-SUP720-BASE command to display the hardware version. For example:

•For ERSPAN packets, the "protocol type" field value in the GRE header is 0x88BE.

•The payload of a Layer 3 ERSPAN packet is a copied Layer 2 Ethernet frame, excluding any ISL or 802.1Q tags.

•ERSPAN adds a 50-byte header to each copied Layer 2 Ethernet frame and replaces the 4-byte cyclic redundancy check (CRC) trailer.

•ERSPAN supports jumbo frames that contain Layer 3 packets of up to 9,202 bytes. If the length of the copied Layer 2 Ethernet frame is greater than 9,170 (9,152-byte Layer 3 packet), ERSPAN truncates the copied Layer 2 Ethernet frame to create a 9,202-byte ERSPAN Layer 3 packet.

Note The Layer 3 IP header in truncated packets retains the nontruncated Layer 3 packet size. The length consistency check between the Layer 2 frame and the Layer 3 packet on ERSPAN destinations that are 6500 switches drops truncated ERSPAN packets unless you configure the no mls verify ip length consistent global configuration command on the ERSPAN destination 6500 switch.

•Regardless of any configured MTU size, ERSPAN creates Layer 3 packets that can be as long as 9,202 bytes. ERSPAN traffic might be dropped by any interface in the network that enforces an MTU size smaller than 9,202 bytes.

•With the default MTU size (1,500 bytes), if the length of the copied Layer 2 Ethernet frame is greater than 1,468 bytes (1,450-byte Layer 3 packet), the ERSPAN traffic is dropped by any interface in the network that enforces the 1,500-byte MTU size.

Note The mtu interface command and the system jumbomtu command (see the "Configuring Jumbo Frame Support" section) set the maximum Layer 3 packet size (default is 1,500 bytes, maximum is 9,216 bytes).

•All participating switches must be connected at Layer 3 and the network path must support the size of the ERSPAN traffic.

•ERSPAN does not support packet fragmentation. The "do not fragment" bit is set in the IP header of ERSPAN packets. ERSPAN destination sessions cannot reassemble fragmented ERSPAN packets.

•ERSPAN traffic is subject to the traffic load conditions of the network. You can set the ERSPAN packet IP precedence or DSCP value to prioritize ERSPAN traffic for QoS.

•The only supported destination for ERSPAN traffic is an ERSPAN destination session on a PFC3.

•All ERSPAN source sessions on a switch must use the same origin IP address, configured with the origin ip address command (see the "Configuring ERSPAN Source Sessions" section).

•All ERSPAN destination sessions on a switch must use the same IP address on the same destination interface. You enter the destination interface IP address with the ip address command (see the "Configuring ERSPAN Destination Sessions" section).

•The ERSPAN source session's destination IP address, which must be configured on an interface on the destination switch, is the source of traffic that an ERSPAN destination session sends to the destinations. You configure the same address in both the source and destination sessions with the ip address command.

•The ERSPAN ID differentiates the ERSPAN traffic arriving at the same destination IP address from various different ERSPAN source sessions.

These are distributed egress SPAN mode guidelines and restrictions:

•These switching modules disable distributed egress SPAN mode:

–WS-X6502-10GE

–WS-X6816-GBIC

–WS-X6516-GBIC

–WS-X6516-GE-TX

–WS-X6524-100FX-MM

–WS-X6548-RJ-45

–WS-X6548-RJ-21

With any of these switching modules installed, the egress SPAN mode is centralized.

Enter the show monitor session egress replication-mode | include Operational|slot command to display any switching modules that disable distributed egress SPAN mode. If there are no modules installed that disable distributed egress SPAN mode, the command displays only the egress SPAN operational mode.

•Some switching modules have ASICs that do not support distributed egress SPAN mode for ERSPAN sources.

Enter the show monitor session egress replication-mode | include Distributed.*Distributed.*Centralized command to display the slot number of any switching modules that do not support distributed egress SPAN mode for ERSPAN sources.

Enter the show asic-version slot slot_number command to display the versions of the ASICs on the switching module in the slot where distributed egress SPAN mode is not supported for ERSPAN sources.

Hyperion ASIC revision levels 5.0 and higher and all versions of the Metropolis ASIC support distributed egress SPAN mode for ERSPAN sources. Switching modules with Hyperion ASIC revision levels lower than 5.0 do not support distributed egress SPAN mode for ERSPAN sources.

These sections describe how to configure local SPAN, RSPAN, and ERSPAN:

•Local SPAN, RSPAN, and ERSPAN Default Configuration

•Configuring a Destination as an Unconditional Trunk (Optional)

•Configuring Destination Trunk VLAN Filtering (Optional)

•Configuring Destination Port Permit Lists (Optional)

•Configuring the Egress SPAN Mode (Optional)

•Configuring Local SPAN

•Configuring RSPAN

•Configuring ERSPAN

•Configuring Source VLAN Filtering in Global Configuration Mode

•Verifying the Configuration

•Configuration Examples

This section describes the local SPAN, RSPAN, and ERSPAN default configuration:

To tag the monitored traffic as it leaves a destination, configure the destination as a trunk before you configure it as a destination.

To configure the destination as a trunk, perform this task:

This example shows how to configure a port as an unconditional IEEE 802.1Q trunk:

Note Releases earlier than Release 12.2(33)SXH required you to enter the switchport nonegotiate command when you configured a destination port as an unconditional trunk. This requirement has been removed in Release 12.2(33)SXH and later releases.

Note•In addition to filtering VLANs on a trunk, you can also apply the allowed VLAN list to access ports.

•Destination trunk VLAN filtering is applied at the destination. Destination trunk VLAN filtering does not reduce the amount of traffic being sent from the SPAN sources to the SPAN destinations.

When a destination is a trunk, you can use the list of VLANs allowed on the trunk to filter the traffic transmitted from the destination. (CSCeb01318)

Destination trunk VLAN filtering removes the restriction that, within a SPAN session, all destinations receive all the traffic from all the sources. Destination trunk VLAN filtering allows you to select, on a per-VLAN basis, the traffic that is transmitted from each destination trunk to the network analyzer.

To configure destination trunk VLAN filtering on a destination trunk, perform this task:

When configuring the list of VLANs allowed on a destination trunk port, note the following information:

•The vlan parameter is either a single VLAN number from 1 through 4094, or a range of VLANs described by two VLAN numbers, the lesser one first, separated by a dash. Do not enter any spaces between comma-separated vlan parameters or in dash-specified ranges.

•All VLANs are allowed by default.

•To remove all VLANs from the allowed list, enter the switchport trunk allowed vlan none command.

•To add VLANs to the allowed list, enter the switchport trunk allowed vlan add command.

•You can modify the allowed VLAN list without removing the SPAN configuration.

This example shows the configuration of a local SPAN session that has several VLANs as sources and several trunk ports as destinations, with destination trunk VLAN filtering that filters the SPAN traffic so that each destination trunk port transmits the traffic from one VLAN:

To prevent accidental configuration of ports as destinations, you can create a permit list of the ports that are valid for use as destinations. With a destination port permit list configured, you can only configure the ports in the permit list as destinations.

To configure a destination port permit list, perform this task:

This example shows how to configure a destination port permit list that includes Gigabit Ethernet ports 5/1 through 5/4 and 6/1:

This example shows how to verify the configuration:

With Release 12.2(33)SXH, Release 12.2(33)SXH1, and Release 12.2(33)SXH2, distributed egress SPAN mode is the default if there are no switching modules installed that disable it.

With Release 12.2(33)SXH2a and later releases, centralized egress SPAN mode is the default.

See the "Distributed Egress SPAN Mode Guidelines and Restrictions" section for information about switching modules that support distributed egress SPAN mode.

With Release 12.2(33)SXH2a and later releases, to configure the egress SPAN mode, perform this task:

This example shows how to enable distributed egress SPAN mode:

With Release 12.2(33)SXH, Release 12.2(33)SXH1, and Release 12.2(33)SXH2, to configure the egress SPAN mode, perform this task:

This example shows how to disable distributed egress SPAN mode:

This example shows how to display the configured egress SPAN mode:

These sections describe how to configure local SPAN sessions:

•Configuring Local SPAN (SPAN Configuration Mode)

•Configuring Local SPAN (Global Configuration Mode)

Note To tag the monitored traffic as it leaves a destination, you must configure the destination to trunk unconditionally before you configure it as a destination (see the "Configuring a Destination as an Unconditional Trunk (Optional)" section).

To configure a local SPAN session in SPAN configuration mode, perform this task:

When configuring monitor sessions, note the following information:

•session_description can be up to 240 characters and cannot contain special characters; with Release 12.2(33)SXH and later releases, the description can contain spaces.

Note You can enter 240 characters after the description command.

•local_span_session_number can range from 1 to 80.

•cpu rp is the route processor (RP).

•cpu sp is the switch processor (SP).

•single_interface is as follows:

–interface type slot/port; type is fastethernet, gigabitethernet, or tengigabitethernet.

–interface port-channel number

Note Destination port channel interfaces must be configured with the channel-group group_num mode on command and the no channel-protocol command. See the "Configuring EtherChannels" section.

•interface_list is single_interface , single_interface , single_interface ...

Note In lists, you must enter a space before and after the comma. In ranges, you must enter a space before and after the dash.

•interface_range is interface type slot/first_port - last_port.

•mixed_interface_list is, in any order, single_interface , interface_range , ...

•single_vlan is the ID number of a single VLAN.

•vlan_list is single_vlan , single_vlan , single_vlan ...

•vlan_range is first_vlan_ID - last_vlan_ID.

•mixed_vlan_list is, in any order, single_vlan , vlan_range , ...

•Enter the ingress keyword to configure destinations to receive traffic from attached devices.

•Enter the learning keyword to enable MAC address learning from the destinations, which allows the switch to transmit traffic that is addressed to devices attached to the destinations.

When configuring destinations with the ingress and learning keywords, note the following:

–Configure the destinations for Layer 2 switching. See the "Configuring LAN Interfaces for Layer 2 Switching" section.

–If the destination is a trunk and the attached device transmits tagged traffic back to the switch, you can use either ISL or 802.1Q trunking.

–If the destination is a trunk and the attached device transmits untagged traffic back to the switch, use 802.1Q trunking with the native VLAN configured to accept the traffic from the attached device.

–Do not configure the destinations with Layer 3 addresses. Use a VLAN interface to route traffic to and from devices attached to destinations.

–Destinations are held in the down state. To route the traffic to and from attached devices, configure an additional active Layer 2 port in the VLAN to keep the VLAN interface up.

This example shows how to configure session 1 to monitor ingress traffic from Gigabit Ethernet port 1/1 and configure Gigabit Ethernet port 1/2 as the destination:

For additional examples, see the "Configuration Examples" section.

Note•To tag the monitored traffic as it leaves a destination, you must configure the destination to trunk unconditionally before you configure it as a destination (see the "Configuring a Destination as an Unconditional Trunk (Optional)" section).

•You can configure up to two local SPAN sessions in global configuration mode.

•You can use SPAN configuration mode for all SPAN configuration tasks.

•You must use SPAN configuration mode to configure the supported maximum number of SPAN sessions.

Local SPAN does not use separate source and destination sessions. To configure a local SPAN session, configure local SPAN sources and destinations with the same session number. To configure a local SPAN session, perform this task:

When configuring local SPAN sessions, note the following information:

•local_span_session_number can range from 1 to 80.

•single_interface is as follows:

–interface type slot/port; type is fastethernet, gigabitethernet, or tengigabitethernet.

–interface port-channel number

Note Destination port channel interfaces must be configured with the channel-group group_num mode on command and the no channel-protocol command. See the "Configuring EtherChannels" section.

•interface_list is single_interface , single_interface , single_interface ...

Note In lists, you must enter a space before and after the comma. In ranges, you must enter a space before and after the dash.

•interface_range is interface type slot/first_port - last_port.

•mixed_interface_list is, in any order, single_interface , interface_range , ...

•single_vlan is the ID number of a single VLAN.

•vlan_list is single_vlan , single_vlan , single_vlan ...

•vlan_range is first_vlan_ID - last_vlan_ID.

•mixed_vlan_list is, in any order, single_vlan , vlan_range , ...

•Enter the ingress keyword to configure destinations to receive traffic from attached devices.

•Enter the learning keyword to enable MAC address learning from the destinations, which allows the switch to transmit traffic that is addressed to devices attached to the destinations.

When configuring destinations with the ingress and learning keywords, note the following:

–Configure the destinations for Layer 2 switching. See the "Configuring LAN Interfaces for Layer 2 Switching" section.

–If the destination is a trunk and the attached device transmits tagged traffic back to the switch, you can use either ISL or 802.1Q trunking.

–If the destination is a trunk and the attached device transmits untagged traffic back to the switch, use 802.1Q trunking with the native VLAN configured to accept the traffic from the attached device.

–Do not configure the destinations with Layer 3 addresses. Use a VLAN interface to route traffic to and from devices attached to destinations.

–Destinations are held in the down state. To route the traffic to and from attached devices, configure an additional active Layer 2 port in the VLAN to keep the VLAN interface up.

This example shows how to configure Fast Ethernet port 5/1 as a bidirectional source for session 1:

This example shows how to configure Fast Ethernet port 5/48 as the destination for SPAN session 1:

For additional examples, see the "Configuration Examples" section.

RSPAN uses a source session on one switch and a destination session on a different switch. These sections describe how to configure RSPAN sessions:

•Configuring RSPAN VLANs

•Configuring RSPAN Sessions (SPAN Configuration Mode)

•Configuring RSPAN Sessions (Global Configuration Mode)

To configure a VLAN as an RSPAN VLAN, perform this task:

These sections describe how to configure RSPAN sessions in SPAN configuration mode:

•Configuring RSPAN Source Sessions in SPAN Configuration Mode

•Configuring RSPAN Destination Sessions in SPAN Configuration Mode

To configure an RSPAN source session in SPAN configuration mode, perform this task:

When configuring RSPAN source sessions, note the following information:

•session_description can be up to 240 characters and cannot contain special characters; with Release 12.2(33)SXH and later releases, the description can contain spaces.

Note You can enter 240 characters after the description command.

•RSPAN_source_span_session_number can range from 1 to 80.

•cpu rp is the route processor (RP).

•cpu sp is the switch processor (SP).

•single_interface is as follows:

–interface type slot/port; type is fastethernet, gigabitethernet, or tengigabitethernet.

–interface port-channel number

•interface_list is single_interface , single_interface , single_interface ...

Note In lists, you must enter a space before and after the comma. In ranges, you must enter a space before and after the dash.

•interface_range is interface type slot/first_port - last_port.

•mixed_interface_list is, in any order, single_interface , interface_range , ...

•single_vlan is the ID number of a single VLAN.

•vlan_list is single_vlan , single_vlan , single_vlan ...

•vlan_range is first_vlan_ID - last_vlan_ID.

•mixed_vlan_list is, in any order, single_vlan , vlan_range , ...

•See the "Configuring RSPAN VLANs" section for information about the RSPAN VLAN ID.

This example shows how to configure session 1 to monitor bidirectional traffic from Gigabit Ethernet port 1/1:

For additional examples, see the "Configuration Examples" section.

Note•To tag the monitored traffic, you must configure the port to trunk unconditionally before you configure it as a destination (see the "Configuring a Destination as an Unconditional Trunk (Optional)" section).

•You can configure an RSPAN destination session on the RSPAN source session switch to monitor RSPAN traffic locally.

To configure an RSPAN destination session, perform this task:

When configuring RSPAN destination sessions, note the following information:

•RSPAN_destination_span_session_number can range from 1 to 80.

•single_interface is as follows:

–interface type slot/port; type is fastethernet, gigabitethernet, or tengigabitethernet.

–interface port-channel number

Note Destination port channel interfaces must be configured with the channel-group group_num mode on command and the no channel-protocol command. See the "Configuring EtherChannels" section.

•interface_list is single_interface , single_interface , single_interface ...

Note In lists, you must enter a space before and after the comma. In ranges, you must enter a space before and after the dash.

•interface_range is interface type slot/first_port - last_port.

•mixed_interface_list is, in any order, single_interface , interface_range , ...

•Enter the ingress keyword to configure destinations to receive traffic from attached devices.

•Enter the learning keyword to enable MAC address learning from the destinations, which allows the switch to transmit traffic that is addressed to devices attached to the destinations.

When configuring destinations with the ingress and learning keywords, note the following:

–Configure the destinations for Layer 2 switching. See the "Configuring LAN Interfaces for Layer 2 Switching" section.

–If the destination is a trunk and the attached device transmits tagged traffic back to the switch, you can use either ISL or 802.1Q trunking.

–If the destination is a trunk and the attached device transmits untagged traffic back to the switch, use 802.1Q trunking with the native VLAN configured to accept the traffic from the attached device.

–Do not configure the destinations with Layer 3 addresses. Use a VLAN interface to route traffic to and from devices attached to destinations.

–Destinations are held in the down state. To route the traffic to and from attached devices, configure an additional active Layer 2 port in the VLAN to keep the VLAN interface up.

•The no shutdown command and shutdown commands are not supported for RSPAN destination sessions.

This example shows how to configure RSPAN VLAN 2 as the source for session 1 and Gigabit Ethernet port 1/2 as the destination:

For additional examples, see the "Configuration Examples" section.

These sections describe how to configure RSPAN sessions in global configuration mode:

•Configuring RSPAN Source Sessions in Global Configuration Mode

•Configuring RSPAN Destination Sessions in Global Configuration Mode

To configure an RSPAN source session in global configuration mode, perform this task:

When configuring RSPAN source sessions, note the following information:

•To configure RSPAN VLANs, see the "Configuring RSPAN VLANs" section.

•RSPAN_source_span_session_number can range from 1 to 80.

•single_interface is as follows:

–interface type slot/port; type is fastethernet, gigabitethernet, or tengigabitethernet.

–interface port-channel number

•interface_list is single_interface , single_interface , single_interface ...

Note In lists, you must enter a space before and after the comma. In ranges, you must enter a space before and after the dash.

•interface_range is interface type slot/first_port - last_port.

•mixed_interface_list is, in any order, single_interface , interface_range , ...

•single_vlan is the ID number of a single VLAN.

•vlan_list is single_vlan , single_vlan , single_vlan ...

•vlan_range is first_vlan_ID - last_vlan_ID.

•mixed_vlan_list is, in any order, single_vlan , vlan_range , ...

•See the "Configuring RSPAN VLANs" section for information about the RSPAN VLAN ID.

This example shows how to configure Fast Ethernet port 5/2 as the source for session 2:

This example shows how to configure RSPAN VLAN 200 as the destination for session 2:

For additional examples, see the "Configuration Examples" section.

Note•To tag the monitored traffic, you must configure the port to trunk unconditionally before you configure it as a destination (see the "Configuring a Destination as an Unconditional Trunk (Optional)" section).

•You can configure an RSPAN destination session on the RSPAN source session switch to monitor RSPAN traffic locally.

To configure an RSPAN destination session in global configuration mode, perform this task:

When configuring monitor sessions, note the following information:

•RSPAN_destination_span_session_number can range from 1 to 80.

•See the "Configuring RSPAN VLANs" section for information about the RSPAN VLAN ID.

•single_interface is as follows:

–interface type slot/port; type is fastethernet, gigabitethernet, or tengigabitethernet.

–interface port-channel number

Note Destination port channel interfaces must be configured with the channel-group group_num mode on command and the no channel-protocol command. See the "Configuring EtherChannels" section.

•interface_list is single_interface , single_interface , single_interface ...

Note In lists, you must enter a space before and after the comma. In ranges, you must enter a space before and after the dash.

•interface_range is interface type slot/first_port - last_port.

•mixed_interface_list is, in any order, single_interface , interface_range , ...

•Enter the ingress keyword to configure destinations to receive traffic from attached devices.

•Enter the learning keyword to enable MAC address learning from the destinations, which allows the switch to transmit traffic that is addressed to devices attached to the destinations.

When configuring destinations with the ingress and learning keywords, note the following:

–Configure the destinations for Layer 2 switching. See the "Configuring LAN Interfaces for Layer 2 Switching" section.

–If the destination is a trunk and the attached device transmits tagged traffic back to the switch, you can use either ISL or 802.1Q trunking.

–If the destination is a trunk and the attached device transmits untagged traffic back to the switch, use 802.1Q trunking with the native VLAN configured to accept the traffic from the attached device.

–Do not configure the destinations with Layer 3 addresses. Use a VLAN interface to route traffic to and from devices attached to destinations.

–Destinations are held in the down state. To route the traffic to and from attached devices, configure an additional active Layer 2 port in the VLAN to keep the VLAN interface up.

This example shows how to configure RSPAN VLAN 200 as the source for session 3:

This example shows how to configure Fast Ethernet port 5/47 as the destination for session 3:

For additional examples, see the "Configuration Examples" section.

ERSPAN uses separate source and destination sessions. You configure the source and destination sessions on different switches. These sections describe how to configure ERSPAN sessions:

•Configuring ERSPAN Source Sessions

•Configuring ERSPAN Destination Sessions

To configure an ERSPAN source session, perform this task:

When configuring monitor sessions, note the following information:

•session_description can be up to 240 characters and cannot contain special characters; with Release 12.2(33)SXH and later releases, the description can contain spaces.

Note You can enter 240 characters after the description command.

•ERSPAN_source_span_session_number can range from 1 to 80.

•cpu rp is the route processor (RP).

•cpu sp is the switch processor (SP).

•single_interface is as follows:

–interface type slot/port; type is fastethernet, gigabitethernet, or tengigabitethernet.

–interface port-channel number

Note Port channel interfaces must be configured with the channel-group group_num mode on command and the no channel-protocol command. See the "Configuring EtherChannels" section.

•interface_list is single_interface , single_interface , single_interface ...

Note In lists, you must enter a space before and after the comma. In ranges, you must enter a space before and after the dash.

•interface_range is interface type slot/first_port - last_port.

•mixed_interface_list is, in any order, single_interface , interface_range , ...

•single_vlan is the ID number of a single VLAN.

•vlan_list is single_vlan , single_vlan , single_vlan ...

•vlan_range is first_vlan_ID - last_vlan_ID.

•mixed_vlan_list is, in any order, single_vlan , vlan_range , ...

•ERSPAN_flow_id can range from 1 to 1023.

•All ERSPAN source sessions on a switch must use the same source IP address. Enter the origin ip address ip_address force command to change the origin IP address configured in all ERSPAN source sessions on the switch.

•ttl_value can range from 1 to 255.

•ipp_value can range from 0 to 7.

•dscp_value can range from 0 to 63.

This example shows how to configure session 3 to monitor bidirectional traffic from Gigabit Ethernet port 4/1:

For additional examples, see the "Configuration Examples" section.

Note You cannot monitor ERSPAN traffic locally.

To configure an ERSPAN destination session, perform this task:

When configuring monitor sessions, note the following information:

•ERSPAN_destination_span_session_number can range from 1 to 80.

•single_interface is as follows:

–interface type slot/port; type is fastethernet, gigabitethernet, or tengigabitethernet.

–interface port-channel number

Note Destination port channel interfaces must be configured with the channel-group group_num mode on command and the no channel-protocol command. See the "Configuring EtherChannels" section.

•interface_list is single_interface , single_interface , single_interface ...

Note In lists, you must enter a space before and after the comma. In ranges, you must enter a space before and after the dash.

•interface_range is interface type slot/first_port - last_port.

•mixed_interface_list is, in any order, single_interface , interface_range , ...

•All ERSPAN destination sessions on a switch must use the same IP address on the same destination interface. Enter the ip address ip_address force command to change the IP address configured in all ERSPAN destination sessions on the switch.

Note You must also change all ERSPAN source session destination IP addresses (see the "Configuring ERSPAN Source Sessions" section, Step 7).

•ERSPAN_flow_id can range from 1 to 1023.

•Enter the ingress keyword to configure destinations to receive traffic from attached devices.

•Enter the learning keyword to enable MAC address learning from the destinations, which allows the switch to transmit traffic that is addressed to devices attached to the destinations.

When configuring destinations with the ingress and learning keywords, note the following:

–Configure the destinations for Layer 2 switching. See the "Configuring LAN Interfaces for Layer 2 Switching" section.

–If the destination is a trunk and the attached device transmits tagged traffic back to the switch, you can use either ISL or 802.1Q trunking.

–If the destination is a trunk and the attached device transmits untagged traffic back to the switch, use 802.1Q trunking with the native VLAN configured to accept the traffic from the attached device.

–Do not configure the destinations with Layer 3 addresses. Use a VLAN interface to route traffic to and from devices attached to destinations.

–Destinations are held in the down state. To route the traffic to and from attached devices, configure an additional active Layer 2 port in the VLAN to keep the VLAN interface up.

This example shows how to configure an ERSPAN destination session to send ERSPAN ID 101 traffic arriving at IP address 10.1.1.1 to Gigabit Ethernet port 2/1:

For additional examples, see the "Configuration Examples" section.

Note•To configure source VLAN filtering in SPAN configuration mode, see the following sections:

–Configuring Local SPAN (SPAN Configuration Mode)

–Configuring RSPAN Source Sessions in SPAN Configuration Mode

–Configuring ERSPAN

•Source VLAN filtering reduces the amount of traffic that is sent from SPAN sources to SPAN destinations.

Source VLAN filtering monitors specific VLANs when the source is a trunk port.

To configure source VLAN filtering when the local SPAN or RSPAN source is a trunk port, perform this task:

When configuring source VLAN filtering, note the following information:

•single_vlan is the ID number of a single VLAN.

•vlan_list is single_vlan , single_vlan , single_vlan ...

•vlan_range is first_vlan_ID - last_vlan_ID.

•mixed_vlan_list is, in any order, single_vlan , vlan_range , ...

This example shows how to monitor VLANs 1 through 5 and VLAN 9 when the source is a trunk port:

To verify the configuration, enter the show monitor session command.

This example shows how to verify the configuration of session 2:

This example shows how to display the full details of session 2:

This example shows the configuration of RSPAN source session 2:

This example shows how to clear the configuration for sessions 1 and 2:

This example shows the configuration of an RSPAN source session with multiple sources:

This example shows how to remove sources for a session:

This example shows how to remove options for sources for a session:

This example shows how to remove source VLAN filtering for a session:

This example shows the configuration of RSPAN destination session 8:

This example shows the configuration of ERSPAN source session 12:

This example shows the configuration of ERSPAN destination session 12:

This example shows the configuration of ERSPAN source session 13:

This example shows the configuration of ERSPAN destination session 13:

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples and troubleshooting information), see the documents listed on this page:

http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

Participate in the Technical Documentation Ideas forum

Page 7

This chapter describes how to configure private VLANs in Cisco IOS Release 12.2SX.

Note For complete syntax and usage information for the commands used in this chapter, see the Cisco IOS Master Command List, at this URL:

http://www.cisco.com/en/US/docs/ios/mcl/allreleasemcl/all_book.html

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples and troubleshooting information), see the documents listed on this page:

http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

Participate in the Technical Documentation Ideas forum

This chapter consists of these sections:

•Understanding Private VLANs

•Private VLAN Configuration Guidelines and Restrictions

•Configuring Private VLANs

•Monitoring Private VLANs

These sections describe how private VLANs work:

•Private VLAN Domains

•Private VLAN Ports

•Primary, Isolated, and Community VLANs

•Private VLAN Port Isolation

•IP Addressing Scheme with Private VLANs

•Private VLANs Across Multiple Switches

•Private VLAN Interaction with Other Features

The private VLAN feature addresses two problems that service providers encounter when using VLANs:

•The switch supports up to 4096 VLANs. If a service provider assigns one VLAN per customer, the number of customers that service provider can support is limited.

•To enable IP routing, each VLAN is assigned a subnet address space or a block of addresses, which can result in wasting the unused IP addresses and creating IP address management problems.

Using private VLANs solves the scalability problem and provides IP address management benefits for service providers and Layer 2 security for customers.

The private VLAN feature partitions the Layer 2 broadcast domain of a VLAN into subdomains. A subdomain is represented by a pair of private VLANs: a primary VLAN and a secondary VLAN. A private VLAN domain can have multiple private VLAN pairs, one pair for each subdomain. All VLAN pairs in a private VLAN domain share the same primary VLAN. The secondary VLAN ID differentiates one subdomain from another (see Figure 24-1).

Figure 24-1 Private VLAN Domain

A private VLAN domain has only one primary VLAN. Every port in a private VLAN domain is a member of the primary VLAN. In other words, the primary VLAN is the entire private VLAN domain.

Secondary VLANs provide Layer 2 isolation between ports within the same private VLAN domain. There are two types of secondary VLANs:

•Isolated VLANs—Ports within an isolated VLAN cannot communicate with each other at the Layer 2 level.

•Community VLANs—Ports within a community VLAN can communicate with each other but cannot communicate with ports in other communities at the Layer 2 level.

There are three types of private VLAN ports:

•Promiscuous—A promiscuous port belongs to the primary VLAN and can communicate with all interfaces, including the community and isolated host ports that belong to the secondary VLANs that are associated with the primary VLAN.

•Isolated—An isolated port is a host port that belongs to an isolated secondary VLAN. This port has complete Layer 2 isolation from other ports within the same private VLAN domain, except for the promiscuous ports. Private VLANs block all traffic to isolated ports except traffic from promiscuous ports. Traffic received from an isolated port is forwarded only to promiscuous ports.

•Community—A community port is a host port that belongs to a community secondary VLAN. Community ports communicate with other ports in the same community VLAN and with promiscuous ports. These interfaces are isolated at Layer 2 from all other interfaces in other communities and from isolated ports within their private VLAN domain.

Note Because trunks can support the VLANs carrying traffic between isolated, community, and promiscuous ports, isolated and community port traffic might enter or leave the switch through a trunk interface.

Primary VLANs and the two types of secondary VLANs, isolated VLANs and community VLANs, have these characteristics:

•Primary VLAN— The primary VLAN carries unidirectional traffic downstream from the promiscuous ports to the (isolated and community) host ports and to other promiscuous ports.

•Isolated VLAN —A private VLAN domain has only one isolated VLAN. An isolated VLAN is a secondary VLAN that carries unidirectional traffic upstream from the hosts toward the promiscuous ports and the gateway.

•Community VLAN—A community VLAN is a secondary VLAN that carries upstream traffic from the community ports to the promiscuous port gateways and to other host ports in the same community. You can configure multiple community VLANs in a private VLAN domain.

A promiscuous port can serve only one primary VLAN, one isolated VLAN, and multiple community VLANs. Layer 3 gateways are connected typically to the switch through a promiscuous port. With a promiscuous port, you can connect a wide range of devices as access points to a private VLAN. For example, you can use a promiscuous port to monitor or back up all the private VLAN servers from an administration workstation.

In a switched environment, you can assign an individual private VLAN and associated IP subnet to each individual or common group of end stations. The end stations need to communicate only with a default gateway to communicate outside the private VLAN.

You can use private VLANs to control access to end stations in these ways:

•Configure selected interfaces connected to end stations as isolated ports to prevent any communication at Layer 2. For example, if the end stations are servers, this configuration prevents Layer 2 communication between the servers.

•Configure interfaces connected to default gateways and selected end stations (for example, backup servers) as promiscuous ports to allow all end stations access to a default gateway.

You can extend private VLANs across multiple devices by trunking the primary, isolated, and community VLANs to other devices that support private VLANs. To maintain the security of your private VLAN configuration and to avoid other use of the VLANs configured as private VLANs, configure private VLANs on all intermediate devices, including devices that have no private VLAN ports.

When you assign a separate VLAN to each customer, an inefficient IP addressing scheme is created as follows:

•Assigning a block of addresses to a customer VLAN can result in unused IP addresses.

•If the number of devices in the VLAN increases, the number of assigned addresses might not be large enough to accommodate them.

These problems are reduced by using private VLANs, where all members in the private VLAN share a common address space, which is allocated to the primary VLAN. Hosts are connected to secondary VLANs, and the DHCP server assigns them IP addresses from the block of addresses allocated to the primary VLAN. Subsequent IP addresses can be assigned to customer devices in different secondary VLANs, but in the same primary VLAN. When new devices are added, the DHCP server assigns them the next available address from a large pool of subnet addresses.

As with regular VLANs, private VLANs can span multiple switches. A trunk port carries the primary VLAN and secondary VLANs to a neighboring switch. The trunk port deals with the private VLAN as any other VLAN. A feature of private VLANs across multiple switches is that traffic from an isolated port in switch A does not reach an isolated port on Switch B. (See Figure 24-2.)

Figure 24-2 Private VLANs Across Switches

Because VTP versions 1 and 2 do not support private VLANs, you must manually configure private VLANs on all switches in the Layer 2 network. If you do not configure the primary and secondary VLAN association in some switches in the network, the Layer 2 databases in these switches are not merged. This situation can result in unnecessary flooding of private VLAN traffic on those switches.

VTP version 3 does support private VLANs, so you do not need to manually configure private VLANs on all switches in the Layer 2 network.

These sections describe how private VLANs interact with some other features:

•Private VLANs and Unicast, Broadcast, and Multicast Traffic

•Private VLANs and SVIs

See also the "Private VLAN Configuration Guidelines and Restrictions" section.

In regular VLANs, devices in the same VLAN can communicate with each other at the Layer 2 level, but devices connected to interfaces in different VLANs must communicate at the Layer 3 level. In private VLANs, the promiscuous ports are members of the primary VLAN, while the host ports belong to secondary VLANs. Because the secondary VLAN is associated to the primary VLAN, members of the these VLANs can communicate with each other at the Layer 2 level.

In a regular VLAN, broadcasts are forwarded to all ports in that VLAN. Private VLAN broadcast forwarding depends on the port sending the broadcast:

•An isolated port sends a broadcast only to the promiscuous ports or trunk ports.

•A community port sends a broadcast to all promiscuous ports, trunk ports, and ports in the same community VLAN.

•A promiscuous port sends a broadcast to all ports in the private VLAN (other promiscuous ports, trunk ports, isolated ports, and community ports).

Multicast traffic is routed or bridged across private VLAN boundaries and within a single community VLAN. Multicast traffic is not forwarded between ports in the same isolated VLAN or between ports in different secondary VLANs.

A switch virtual interface (SVI) is the Layer 3 interface of a Layer 2 VLAN. Layer 3 devices communicate with a private VLAN only through the primary VLAN and not through secondary VLANs. Configure Layer 3 VLAN SVIs only for primary VLANs. Do not configure Layer 3 VLAN interfaces for secondary VLANs. SVIs for secondary VLANs are inactive while the VLAN is configured as a secondary VLAN.

•If you try to configure a VLAN with an active SVI as a secondary VLAN, the configuration is not allowed until you disable the SVI.

•If you try to create an SVI on a VLAN that is configured as a secondary VLAN, and the secondary VLAN is already mapped at Layer 3, the SVI is not created, and an error is returned. If the SVI is not mapped at Layer 3, the SVI is created, but it is automatically shut down.

When the primary VLAN is associated with and mapped to the secondary VLAN, any configuration on the primary VLAN is propagated to the secondary VLAN SVIs. For example, if you assign an IP subnet to the primary VLAN SVI, this subnet is the IP subnet address of the entire private VLAN.

The guidelines for configuring private VLANs are described in the following sections:

•Secondary and Primary VLAN Configuration

•Private VLAN Port Configuration

•Limitations with Other Features

When configuring private VLANs consider these guidelines:

•After you configure a private VLAN and set VTP to transparent mode, you are not allowed to change the VTP mode to client or server. For information about VTP, see Chapter 22 "Configuring VTP."

•You must use VLAN configuration (config-vlan) mode to configure private VLANs. You cannot configure private VLANs in VLAN database configuration mode. For more information about VLAN configuration, see "Configurable VLAN Parameters" section.

•After you have configured private VLANs, use the copy running-config startup config privileged EXEC command to save the VTP transparent mode configuration and private VLAN configuration in the startup-config file. If the switch resets it must default to VTP transparent mode to support private VLANs.

•In VTP versions 1 and 2, VTP does not propagate a private VLAN configuration and you must configure private VLANs on each device where you want private VLAN ports. In VTP version 3, VTP does propagate private VLAN configurations automatically.

•You cannot configure VLAN 1 or VLANs 1002 to 1005 as primary or secondary VLANs. Extended VLANs (VLAN IDs 1006 to 4094) cannot belong to private VLANs. Only Ethernet VLANs can be private VLANs.

•A primary VLAN can have one isolated VLAN and multiple community VLANs associated with it. An isolated or community VLAN can have only one primary VLAN associated with it.

•When a secondary VLAN is associated with the primary VLAN, the STP parameters of the primary VLAN, such as bridge priorities, are propagated to the secondary VLAN. However, STP parameters do not necessarily propagate to other devices. You should manually check the STP configuration to ensure that the primary, isolated, and community VLANs' spanning tree topologies match so that the VLANs can properly share the same forwarding database.

•If you enable MAC address reduction on the switch, we recommend that you enable MAC address reduction on all the devices in your network to ensure that the STP topologies of the private VLANs match.

•In a network where private VLANs are configured, if you enable MAC address reduction on some devices and disable it on others (mixed environment), use the default bridge priorities to make sure that the root bridge is common to the primary VLAN and to all its associated isolated and community VLANs. Be consistent with the ranges employed by the MAC address reduction feature regardless of whether it is enabled on the system. MAC address reduction allows only discrete levels and uses all intermediate values internally as a range. You should disable a root bridge with private VLANs and MAC address reduction, and configure the root bridge with any priority higher than the highest priority range used by any nonroot bridge.

•You cannot apply VACLs to secondary VLANs. (See Chapter 51 "Configuring Port ACLs and VLAN ACLs".)

•You can enable DHCP snooping on private VLANs. When you enable DHCP snooping on the primary VLAN, it is propagated to the secondary VLANs. If you configure DHCP on a secondary VLAN, the configuration does not take effect if the primary VLAN is already configured.

•We recommend that you prune the private VLANs from the trunks on devices that carry no traffic in the private VLANs.

•You can apply different quality of service (QoS) configurations to primary, isolated, and community VLANs. (See Chapter 43 "Configuring PFC QoS".)

•When you configure private VLANs, sticky Address Resolution Protocol (ARP) is enabled by default, and ARP entries learned on Layer 3 private VLAN interfaces are sticky ARP entries. For security reasons, private VLAN port sticky ARP entries do not age out. For information about configuring sticky ARP, see the "Configuring Sticky ARP" section.

•We recommend that you display and verify private VLAN interface ARP entries.

•Sticky ARP prevents MAC address spoofing by ensuring that ARP entries (IP address, MAC address, and source VLAN) do not age out. You can configure sticky ARP on a per-interface basis. For information about configuring sticky ARP, see the "Configuring Sticky ARP" section. The following guidelines and restrictions apply to private VLAN sticky ARP:

–ARP entries learned on Layer 3 private VLAN interfaces are sticky ARP entries.

–Connecting a device with a different MAC address but with the same IP address generates a message and the ARP entry is not created.

–Because the private VLAN port sticky ARP entries do not age out, you must manually remove private VLAN port ARP entries if a MAC address changes. You can add or remove private VLAN ARP entries manually as follows:

•You can configure VLAN maps on primary and secondary VLANs. (See the "Applying a VLAN Access Map" section.) However, we recommend that you configure the same VLAN maps on private VLAN primary and secondary VLANs.

•When a frame is Layer 2 forwarded within a private VLAN, the same VLAN map is applied at the ingress side and at the egress side. When a frame is routed from inside a private VLAN to an external port, the private VLAN map is applied at the ingress side.

–For frames going upstream from a host port to a promiscuous port, the VLAN map configured on the secondary VLAN is applied.

–For frames going downstream from a promiscuous port to a host port, the VLAN map configured on the primary VLAN is applied.

To filter out specific IP traffic for a private VLAN, you should apply the VLAN map to both the primary and secondary VLANs.

•To apply Cisco IOS output ACLs to all outgoing private VLAN traffic, configure them on the Layer 3 VLAN interface of the primary VLAN. (See Chapter 47 "Configuring Network Security".)

•Cisco IOS ACLs applied to the Layer 3 VLAN interface of a primary VLAN automatically apply to the associated isolated and community VLANs.

•Do not apply Cisco IOS ACLs to isolated or community VLANs. Cisco IOS ACL configuration applied to isolated and community VLANs is inactive while the VLANs are part of the private VLAN configuration.

•Although private VLANs provide host isolation at Layer 2, hosts can communicate with each other at Layer 3.

•Private VLANs support these Switched Port Analyzer (SPAN) features:

–You can configure a private VLAN port as a SPAN source port.

–You can use VLAN-based SPAN (VSPAN) on primary, isolated, and community VLANs or use SPAN on only one VLAN to separately monitor egress or ingress traffic.

–For more information about SPAN, see Chapter 68 "Configuring Local SPAN, RSPAN, and ERSPAN."

When configuring private VLAN ports follow these guidelines:

•Use only the private VLAN configuration commands to assign ports to primary, isolated, or community VLANs. Layer 2 access ports assigned to the VLANs that you configure as primary, isolated, or community VLANs are inactive while the VLAN is part of the private VLAN configuration. Layer 2 trunk interfaces remain in the STP forwarding state.

•Do not configure ports that belong to a PAgP or LACP EtherChannel as private VLAN ports. While a port is part of the private VLAN configuration, any EtherChannel configuration for it is inactive.

•Enable PortFast and BPDU guard on isolated and community host ports to prevent STP loops due to misconfigurations and to speed up STP convergence. (See Chapter 29 "Configuring Optional STP Features".) When enabled, STP applies the BPDU guard feature to all PortFast-configured Layer 2 LAN ports. Do not enable PortFast and BPDU guard on promiscuous ports.

•If you delete a VLAN used in the private VLAN configuration, the private VLAN ports associated with the VLAN become inactive.

•Private VLAN ports can be on different network devices if the devices are trunk-connected and the primary and secondary VLANs have not been removed from the trunk.

•All primary, isolated, and community VLANs associated within a private VLAN must maintain the same topology across trunks. You are highly recommended to configure the same STP bridge parameters and trunk port parameters on all associated VLANs in order to maintain the same topology.

When configuring private VLANs, consider these configuration limitations with other features:

Note In some cases, the configuration is accepted with no error messages, but the commands have no effect.

•VTP version 3 is not supported on private VLAN (PVLAN) ports.

•Do not configure fallback bridging on switches with private VLANs.

•A port is only affected by the private VLAN feature if it is currently in private VLAN mode and its private VLAN configuration indicates that it is a primary, isolated, or community port. If a port is in any other mode, such as Dynamic Trunking Protocol (DTP), it does not function as a private port.

•Do not configure private VLAN ports on interfaces configured for these other features:

–Port Aggregation Protocol (PAgP)

–Link Aggregation Control Protocol (LACP)

–Voice VLAN

•You can configure IEEE 802.1x port-based authentication on a private VLAN port, but do not configure 802.1x with port security, voice VLAN, or per-user ACL on private VLAN ports.

•IEEE 802.1q mapping works normally. Traffic is remapped to or from dot1Q ports as configured, as if received from the ISL VLANs.

•Do not configure a remote SPAN (RSPAN) VLAN as a private VLAN primary or secondary VLAN. For more information about SPAN, see Chapter 68 "Configuring Local SPAN, RSPAN, and ERSPAN."

•A private VLAN host or promiscuous port cannot be a SPAN destination port. If you configure a SPAN destination port as a private VLAN port, the port becomes inactive.

•A destination SPAN port should not be an isolated port. (However, a source SPAN port can be an isolated port.) VSPAN could be configured to span both primary and secondary VLANs or, alternatively, to span either one if the user is interested only in ingress or egress traffic.

•If using the shortcuts between different VLANs (if any of these VLANs is private) consider both primary and isolated and community VLANs. The primary VLAN should be used both as the destination and as the virtual source, because the secondary VLAN (the real source) is always remapped to the primary VLAN in the Layer 2 FID table.

•If you configure a static MAC address on a promiscuous port in the primary VLAN, you must add the same static address to all associated secondary VLANs. If you configure a static MAC address on a host port in a secondary VLAN, you must add the same static MAC address to the associated primary VLAN. When you delete a static MAC address from a private VLAN port, you must remove all instances of the configured MAC address from the private VLAN.

Note Dynamic MAC addresses learned in one VLAN of a private VLAN are replicated in the associated VLANs. For example, a MAC address learned in a secondary VLAN is replicated in the primary VLAN. When the original dynamic MAC address is deleted or aged out, the replicated addresses are removed from the MAC address table.

•Do not configure private VLAN ports as EtherChannels. A port can be part of the private VLAN configuration, but any EtherChannel configuration for the port is inactive.

•When you enter the shutdown or the no shutdown command on the primary VLAN, the corresponding secondary VLANs also are shutdown or brought up.

•These restrictions apply when you configure groups of 12 ports as secondary ports:

The 12-port restriction applies to these 10 Mb, 10/100 Mb, and 100 Mb Ethernet switching modules: WS-X6324-100FX, WS-X6348-RJ-45, WS-X6348-RJ-45V, WS-X6348-RJ-21V, WS-X6248-RJ-45, WS-X6248A-TEL, WS-X6248-TEL, WS-X6148-RJ-45, WS-X6148-RJ-45V, WS-X6148-45AF, WS-X6148-RJ-21, WS-X6148-RJ-21V, WS-X6148-21AF, WS-X6024-10FL-MT.

Within groups of 12 ports (1-12, 13-24, 25-36, and 37-48), do not configure ports as isolated ports or community VLAN ports when one port within the group of 12 ports is any of these:

–A trunk port

–A SPAN destination port

–A promiscuous private VLAN port

–In releases where CSCsb44185 is resolved, a port that has been configured with the switchport mode dynamic auto or switchport mode dynamic desirable command.

If one port within the group of 12 ports is one of these ports listed and has the above properties, any isolated or community VLAN configuration for other ports within the 12 ports is inactive. To reactivate the ports, remove the isolated or community VLAN port configuration and enter the shutdown and no shutdown commands.

•These restrictions apply when you configure groups of 24 ports as secondary ports:

In all releases, this 24-port restriction applies to the WS-X6548-GE-TX and WS-X6148-GE-TX 10/100/1000 Mb Ethernet switching modules.

Within groups of 24 ports (1-24, 25-48), do not configure ports as isolated ports or community VLAN ports when one port within the group of 24 ports is any of these:

–A trunk port

–A SPAN destination port

–A promiscuous private VLAN port

–In releases where CSCsb44185 is resolved, a port that has been configured with the switchport mode dynamic auto or switchport mode dynamic desirable command.

If one port within the group of 24 ports is one of these ports listed and has the above properties, any isolated or community VLAN configuration for other ports within the 24 ports is inactive. To reactivate the ports, remove the isolated or community VLAN port configuration and enter the shutdown and no shutdown commands.

These sections contain configuration information:

•Configuring a VLAN as a Private VLAN

•Associating Secondary VLANs with a Primary VLAN

•Mapping Secondary VLANs to the Layer 3 VLAN Interface of a Primary VLAN

•Configuring a Layer 2 Interface as a Private VLAN Host Port

•Configuring a Layer 2 Interface as a Private VLAN Promiscuous Port

Note If the VLAN is not defined already, the private VLAN configuration process defines it.

To configure a VLAN as a private VLAN, perform this task:

This example shows how to configure VLAN 202 as a primary VLAN and verify the configuration:

This example shows how to configure VLAN 303 as a community VLAN and verify the configuration:

This example shows how to configure VLAN 440 as an isolated VLAN and verify the configuration:

To associate secondary VLANs with a primary VLAN, perform this task:

When you associate secondary VLANs with a primary VLAN, note the following information:

•The secondary_vlan_list parameter cannot contain spaces. It can contain multiple comma-separated items. Each item can be a single private VLAN ID or a hyphenated range of private VLAN IDs.

•The secondary_vlan_list parameter can contain multiple community VLAN IDs.

•The secondary_vlan_list parameter can contain only one isolated VLAN ID.

•Enter a secondary_vlan_list or use the add keyword with a secondary_vlan_list to associate secondary VLANs with a primary VLAN.

•Use the remove keyword with a secondary_vlan_list to clear the association between secondary VLANs and a primary VLAN.

•The command does not take effect until you exit VLAN configuration submode.

•When you exit the VLAN configuration submode, only the last specified configuration takes effect.

This example shows how to associate community VLANs 303 through 307 and 309 and isolated VLAN 440 with primary VLAN 202 and verify the configuration:

Note Isolated and community VLANs are both called secondary VLANs.

To map secondary VLANs to the Layer 3 VLAN interface of a primary VLAN to allow Layer 3 switching of private VLAN ingress traffic, perform this task:

When you map secondary VLANs to the Layer 3 VLAN interface of a primary VLAN, note the following information:

•The private-vlan mapping interface configuration command only affects private VLAN ingress traffic that is Layer 3-switched.

•The secondary_vlan_list parameter cannot contain spaces. It can contain multiple comma-separated items. Each item can be a single private VLAN ID or a hyphenated range of private VLAN IDs.

•Enter a secondary_vlan_list parameter or use the add keyword with a secondary_vlan_list parameter to map the secondary VLANs to the primary VLAN.

•Use the remove keyword with a secondary_vlan_list parameter to clear the mapping between secondary VLANs and the primary VLAN.

This example shows how to permit routing of secondary VLAN ingress traffic from private VLANs 303 through 307, 309, and 440 and verify the configuration:

To configure a Layer 2 interface as a private VLAN host port, perform this task:

This example shows how to configure interface FastEthernet 5/1 as a private VLAN host port and verify the configuration:

Administrative Mode: private-vlan host

Administrative private-vlan host-association: 202 (VLAN0202) 303 (VLAN0303)

Operational private-vlan: none

To configure a Layer 2 interface as a private VLAN promiscuous port, perform this task:

When you configure a Layer 2 interface as a private VLAN promiscuous port, note the following information:

•The secondary_vlan_list parameter cannot contain spaces. It can contain multiple comma-separated items. Each item can be a single private VLAN ID or a hyphenated range of private VLAN IDs.

•If VLAN locking is enabled, enter VLAN names instead of VLAN numbers in the secondary_vlan_list. When entering a range of VLAN names, you must leave spaces between the VLAN names and the dash.

•Enter a secondary_vlan_list value or use the add keyword with a secondary_vlan_list value to map the secondary VLANs to the private VLAN promiscuous port.

•Use the remove keyword with a secondary_vlan_list value to clear the mapping between secondary VLANs and the private VLAN promiscuous port.

This example shows how to configure interface FastEthernet 5/2 as a private VLAN promiscuous port and map it to a private VLAN:

This example shows how to verify the configuration:

Administrative Mode: private-vlan promiscuous

Administrative private-vlan mapping: 202 (VLAN0202) 303 (VLAN0303) 440 (VLAN0440)

Operational private-vlan: none

Table 24-1 shows the privileged EXEC commands for monitoring private VLAN activity.

This is an example of the output from the show vlan private-vlan command:

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples and troubleshooting information), see the documents listed on this page:

http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

Participate in the Technical Documentation Ideas forum

Page 8

This chapter describes how to configure VLANs in Cisco IOS Release 12.2SX.

Note For complete syntax and usage information for the commands used in this chapter, see the Cisco IOS Master Command List, at this URL:

http://www.cisco.com/en/US/docs/ios/mcl/allreleasemcl/all_book.html

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples and troubleshooting information), see the documents listed on this page:

http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

Participate in the Technical Documentation Ideas forum

This chapter consists of these sections:

•Understanding VLANs

•VLAN Configuration Guidelines and Restrictions

•Configuring VLANs

The following sections describe how VLANs work:

•VLAN Overview

•VLAN Ranges

A VLAN is a group of end stations with a common set of requirements, independent of physical location. VLANs have the same attributes as a physical LAN but allow you to group end stations even if they are not located physically on the same LAN segment.

VLANs are usually associated with IP subnetworks. For example, all the end stations in a particular IP subnet belong to the same VLAN. Traffic between VLANs must be routed. LAN port VLAN membership is assigned manually on an port-by-port basis.

Note You must enable the extended system ID to use 4096 VLANs (see the "Understanding the Bridge ID" section).

Cisco IOS Release 12.2SX supports 4096 VLANs in accordance with the IEEE 802.1Q standard. These VLANs are organized into several ranges; you use each range slightly differently. Some of these VLANs are propagated to other switches in the network when you use the VLAN Trunking Protocol (VTP). The extended-range VLANs are not propagated, so you must configure extended-range VLANs manually on each network device.

Table 23-1 describes the VLAN ranges.

The following information applies to VLAN ranges:

•Layer 3 LAN ports, WAN interfaces and subinterfaces, and some software features use internal VLANs in the extended range. You cannot use an extended range VLAN that has been allocated for internal use.

•To display the VLANs used internally, enter the show vlan internal usage command. With earlier releases, enter the show vlan internal usage and show cwan vlans commands.

•You can configure ascending internal VLAN allocation (from 1006 and up) or descending internal VLAN allocation (from 4094 and down).

•You must enable the extended system ID to use extended range VLANs (see the "Understanding the Bridge ID" section).

When creating and modifying VLANs in your network, follow these guidelines and restrictions:

•VLANs support a number of parameters that are not discussed in detail in this section. For complete information, see the Cisco IOS Master Command List publication.

•If the switch is in VTP server or transparent mode (see the "Configuring VTP" section), you can configure VLANs in global and config-vlan configuration modes. When you configure VLANs in global and config-vlan configuration modes, the VLAN configuration is saved in the vlan.dat files. To display the VLAN configuration, enter the show vlan command.

If the switch is in VLAN transparent mode, use the copy running-config startup-config command to save the VLAN configuration to the startup-config file. After you save the running configuration as the startup configuration, use the show running-config and show startup-config commands to display the VLAN configuration.

•When the switch boots, if the VTP domain name and the VTP mode in the startup-config file and vlan.dat files do not match, the switch uses the configuration in the vlan.dat file.

•You can configure extended-range VLANs only in global configuration mode.

•Supervisor engine redundancy does not support nondefault VLAN data file names or locations. Do not enter the vtp file file_name command on a switch that has a redundant supervisor engine.

•Before installing a redundant supervisor engine, enter the no vtp file command to return to the default configuration.

•Before you can create a VLAN, the switch must be in VTP server mode or VTP transparent mode. For information on configuring VTP, see Chapter 22 "Configuring VTP."

•The VLAN configuration is stored in the vlan.dat file, which is stored in nonvolatile memory. You can cause inconsistency in the VLAN database if you manually delete the vlan.dat file. If you want to modify the VLAN configuration or VTP, use the commands described in this guide and in the Cisco IOS Master Command List, publication.

•To do a complete backup of your configuration, include the vlan.dat file in the backup.

These sections describe how to configure VLANs:

•Configurable VLAN Parameters

•Ethernet VLAN Default Parameters

•VLAN Locking

•Creating or Modifying an Ethernet VLAN

•Assigning a Layer 2 LAN Interface to a VLAN

•Configuring the Internal VLAN Allocation Policy

•Configuring VLAN Translation

•Mapping 802.1Q VLANs to ISL VLANs

•Saving VLAN Information

Note•Ethernet VLAN 1 uses only default values.

•Except for the VLAN name, Ethernet VLANs 1006 through 4094 use only default values.

•You can configure the VLAN name for Ethernet VLANs 1006 through 4094.

You can configure the following parameters for VLANs 2 through 1001:

•VLAN name

•VLAN type (Ethernet, FDDI, FDDI network entity title [NET], TrBRF, or TrCRF)

•VLAN state (active or suspended)

•Security Association Identifier (SAID)

•Bridge identification number for TrBRF VLANs

•Ring number for FDDI and TrCRF VLANs

•Parent VLAN number for TrCRF VLANs

•Spanning Tree Protocol (STP) type for TrCRF VLANs

•VLAN ID: 1; range: 1-4094

•VLAN name:

–VLAN 1: "default"

–Other VLANs: "VLANvlan_ID"

•802.10 SAID: 10vlan_ID; range: 100001-104094

•MTU size: 1500; range: 1500-18190

•Translational bridge 1: 0; range: 0-1005

•Translational bridge 2: 0; range: 0-1005

•VLAN state: active: active, suspend

•Pruning eligibility:

–VLANs 2-1001 are pruning eligible

–VLANs 1006-4094 are not pruning eligible

Release 12.2(33)SXH and later releases support the VLAN locking feature, which provides an extra level of verification to ensure that you have configured the intended VLAN.

When VLAN locking is enabled, you need to specify the VLAN name when you change a port from one VLAN to another. This feature affects switchport commands (in interface configuration mode) that specify the VLANs or private VLANs for access and trunk ports.

For additional information about how to configure access and trunk ports with VLAN locking enabled, see the "Configuring LAN Interfaces for Layer 2 Switching" section.

For additional information about how to configure ports in private VLANs with VLAN locking enabled, see the "Configuring Private VLANs" section.

By default, the VLAN locking is disabled. To enable VLAN locking, perform this task:

User-configured VLANs have unique IDs from 1 to 4094, except for reserved VLANs (see Table 23-1). Enter the vlan command with an unused ID to create a VLAN. Enter the vlan command for an existing VLAN to modify the VLAN (you cannot modify an existing VLAN that is being used by a Layer 3 port or a software feature).

See the "Ethernet VLAN Default Parameters" section for the list of default parameters that are assigned when you create a VLAN. If you do not specify the VLAN type with the media keyword, the VLAN is an Ethernet VLAN.

To create or modify a VLAN, perform this task:

When you create or modify an Ethernet VLAN, note the following information:

•Because Layer 3 ports and some software features require internal VLANs allocated from 1006 and up, configure extended-range VLANs starting with 4094.

•You can configure extended-range VLANs only in global configuration mode. You cannot configure extended-range VLANs in VLAN database mode.

•Layer 3 ports and some software features use extended-range VLANs. If the VLAN you are trying to create or modify is being used by a Layer 3 port or a software feature, the switch displays a message and does not modify the VLAN configuration.

When deleting VLANs, note the following information:

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

•When you delete a VLAN, any LAN ports configured as access ports assigned to that VLAN become inactive. The ports remain associated with the VLAN (and inactive) until you assign them to a new VLAN.

This example shows how to create an Ethernet VLAN in global configuration mode and verify the configuration:

This example shows how to create an Ethernet VLAN in VLAN database mode:

This example shows how to verify the configuration:

A VLAN created in a management domain remains unused until you assign one or more LAN ports to the VLAN.

Note Make sure you assign LAN ports to a VLAN of the appropriate type. Assign Ethernet ports to Ethernet-type VLANs.

To assign one or more LAN ports to a VLAN, complete the procedures in the "Configuring LAN Interfaces for Layer 2 Switching" section.

For more information about VLAN allocation, see the "VLAN Ranges" section.

Note The internal VLAN allocation policy is applied only following a reload.

To configure the internal VLAN allocation policy, perform this task:

	Command	Purpose
Step 1	Router(config)# vlan internal allocation policy {ascending | descending}	Configures the internal VLAN allocation policy.
Step 2	Router(config)# end	Exits configuration mode.
Step 3	Router# reload	Applies the new internal VLAN allocation policy. Caution You do not need to enter the reload command immediately. Enter the reload command during a planned maintenance window.

When you configure the internal VLAN allocation policy, note the following information:

•Enter the ascending keyword to allocate internal VLANs from 1006 and up.

•Enter the descending keyword to allocate internal VLAN from 4094 and down.

This example shows how to configure descending as the internal VLAN allocation policy:

On trunk ports, you can translate one VLAN number to another VLAN number, which transfers all traffic received in one VLAN to the other VLAN.

These sections describe VLAN translation:

•VLAN Translation Guidelines and Restrictions

•Configuring VLAN Translation on a Trunk Port

•Enabling VLAN Translation on Other Ports in a Port Group

Note To avoid spanning tree loops, be careful not to misconfigure the VLAN translation feature.

When translating VLANs, follow these guidelines and restrictions:

•A VLAN translation configuration is inactive if it is applied to ports that are not Layer 2 trunks.

•Do not configure translation of ingress native VLAN traffic on an 802.1Q trunk. Because 802.1Q native VLAN traffic is untagged, it cannot be recognized for translation. You can translate traffic from other VLANs to the native VLAN of an 802.1Q trunk.

•Do not remove the VLAN to which you are translating from the trunk.

•The VLAN translation configuration applies to all ports in a port group. VLAN translation is disabled by default on all ports in a port group. Enable VLAN translation on ports as needed.

•For the modules that support VLAN translation, Table 23-2 lists:

–The port groups to which VLAN translation configuration applies

–The number of VLAN translations supported by the port groups

–The trunk types supported by the modules

Note To configure a port as a trunk, see the "Configuring a Layer 2 Switching Port as a Trunk" section.

To translate VLANs on a trunk port, perform this task:

This example shows how to map VLAN 1649 to VLAN 755 Gigabit Ethernet port 5/2:

This example shows how to verify the configuration:

To enable VLAN translation on other ports in a port group, perform this task:

This example shows how to enable VLAN translation on a port:

The valid range of user-configurable ISL VLANs is 1 through 1001 and 1006 through 4094. The valid range of VLANs specified in the IEEE 802.1Q standard is 1 to 4094. You can map 802.1Q VLAN numbers to ISL VLAN numbers.

802.1Q VLANs in the range 1 through 1001 and 1006 through 4094 are automatically mapped to the corresponding ISL VLAN. 802.1Q VLAN numbers corresponding to reserved VLAN numbers must be mapped to an ISL VLAN in order to be recognized and forwarded by Cisco network devices.

These restrictions apply when mapping 802.1Q VLANs to ISL VLANs:

•You can configure up to eight 802.1Q-to-ISL VLAN mappings.

•You can only map 802.1Q VLANs to Ethernet-type ISL VLANs.

•Do not enter the native VLAN of any 802.1Q trunk in the mapping table.

•When you map an 802.1Q VLAN to an ISL VLAN, traffic on the 802.1Q VLAN corresponding to the mapped ISL VLAN is blocked. For example, if you map 802.1Q VLAN 1007 to ISL VLAN 200, traffic on 802.1Q VLAN 200 is blocked.

•VLAN mappings are local to each switch. Make sure that you configure the same VLAN mappings on all appropriate network devices.

To map an 802.1Q VLAN to an ISL VLAN, perform this task:

This example shows how to map 802.1Q VLAN 1003 to ISL VLAN 200:

This example shows how to verify the configuration:

The VLAN database is stored in the vlan.dat file. You should create a backup of the vlan.dat file in addition to backing up the running-config and startup-config files. If you replace the existing supervisor engine, copy the startup-config file as well as the vlan.dat file to restore the system. The vlan.dat file is read on bootup and you will have to reload the supervisor engine after uploading the file. To view the file location, use the dir vlan.dat command. To copy the file (binary), use the copy vlan.dat tftp command.

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples and troubleshooting information), see the documents listed on this page:

http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

Participate in the Technical Documentation Ideas forum

Page 9

This chapter describes how to configure the online diagnostics in Cisco IOS Release 12.2SX.

Note For complete syntax and usage information for the commands used in this chapter, see the Cisco IOS Master Command List, at this URL:

http://www.cisco.com/en/US/docs/ios/mcl/allreleasemcl/all_book.html

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples and troubleshooting information), see the documents listed on this page:

http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

Participate in the Technical Documentation Ideas forum

This chapter consists of these sections:

•Understanding Online Diagnostics

•Configuring Online Diagnostics

•Running Online Diagnostic Tests

•Performing Memory Tests

With online diagnostics, you can test and verify the hardware functionality of the switch while the switch is connected to a live network.

The online diagnostics contain packet switching tests that check different hardware components and verify the data path and control signals. Disruptive online diagnostic tests, such as the built-in self-test (BIST) and the disruptive loopback test, and nondisruptive online diagnostic tests, such as packet switching, run during bootup, module online insertion and removal (OIR), and system reset. The nondisruptive online diagnostic tests run as part of background health monitoring. Either disruptive or nondisruptive tests can be run at the user's request (on-demand).

The online diagnostics detect problems in the following areas:

•Hardware components

•Interfaces (GBICs, Ethernet ports, and so forth)

•Connectors (loose connectors, bent pins, and so forth)

•Solder joints

•Memory (failure over time)

Online diagnostics is one of the requirements for the high availability feature. High availability is a set of quality standards that seek to limit the impact of equipment failures on the network. A key part of high availability is detecting hardware failures and taking corrective action while the switch runs in a live network. Online diagnostics in high availability detect hardware failures and provide feedback to high availability software components to make switchover decisions.

Online diagnostics are categorized as bootup, on-demand, schedule, or health-monitoring diagnostics. Bootup diagnostics run during bootup; on-demand diagnostics run from the CLI; schedule diagnostics run at user-designated intervals or specified times when the switch is connected to a live network; and health-monitoring runs in the background.

These sections describe how to configure online diagnostics:

•Setting Bootup Online Diagnostics Level

•Configuring On-Demand Online Diagnostics

•Scheduling Online Diagnostics

You can set the bootup diagnostics level as minimal or complete or you can bypass the bootup diagnostics entirely. Enter the complete keyword to run all diagnostic tests; enter the minimal keyword to run only EARL tests and loopback tests for all ports in the switch. Enter the no form of the command to bypass all diagnostic tests. The default bootup diagnositcs level is minimal.

To set the bootup diagnostic level, perform this task:

This example shows how to set the bootup online diagnostic level:

This example shows how to display the bootup online diagnostic level:

You can run the on-demand online diagnostic tests from the CLI. You can set the execution action to either stop or continue the test when a failure is detected or to stop the test after a specific number of failures occur by using the failure count setting. You can configure a test to run multiple times using the iteration setting.

You should run packet-switching tests before memory tests.

Note Do not use the diagnostic start all command until all of the following steps are completed.

Because some on-demand online diagnostic tests can affect the outcome of other tests, you should perform the tests in the following order:

1. Run the nondisruptive tests.

2. Run all tests in the relevant functional area.

3. Run the TestTrafficStress test.

4. Run the TestEobcStressPing test.

5. Run the exhaustive-memory tests.

To run on-demand online diagnostic tests, perform this task:

Step 1 Run the nondisruptive tests.

To display the available tests and their attributes, and determine which commands are in the nondisruptive category, enter the show diagnostic content command.

Step 2 Run all tests in the relevant functional area.

Packet-switching tests fall into specific functional areas. When a problem is suspected in a particular functional area, run all tests in that functional area. If you are unsure about which functional area you need to test, or if you want to run all available tests, enter the complete keyword.

Step 3 Run the TestTrafficStress test.

This is a disruptive packet-switching test. This test switches packets between pairs of ports at line rate for the purpose of stress testing. During this test all of the ports are shut down, and you may see link flaps. The link flaps will recover after the test is complete. The test takes several minutes to complete.

Disable all health-monitoring tests f before running this test by using the no diagnostic monitor module number test all command.

Step 4 Run the TestEobcStressPing test.

This is a disruptive test and tests the Ethernet over backplane channel (EOBC) connection for the module. The test takes several minutes to complete. You cannot run any of the packet-switching tests described in previous steps after running this test. However, you can run tests described in subsequent steps after running this test.

Disable all health-monitoring tests before running this test by using the no diagnostic monitor module number test all command. The EOBC connection is disrupted during this test and will cause the health-monitoring tests to fail and take recovery action.

Step 5 Run the exhaustive-memory tests.

Before running the exhaustive-memory tests, all health-monitoring tests should be disabled because the tests will fail with health monitoring enabled and the switch will take recovery action. Disable the health-monitoring diagnostic tests by using the no diagnostic monitor module number test all command.

Perform the exhaustive-memory tests in the following order:

1. TestFibTcamSSRAM

2. TestAclQosTcam

3. TestNetFlowTcam

4. TestAsicMemory

5. TestAsicMemory

You must reboot the after running the exhaustive-memory tests before it is operational again. You cannot run any other tests on the switch after running the exhaustive-memory tests. Do not save the configuration when rebooting as it will have changed during the tests. After the reboot, reenable the health-monitoring tests using the diagnostic monitor module number test all command.

To set the bootup diagnostic level, perform this task:

This example shows how to set the on-demand testing iteration count:

This example shows how to set the execution action when an error is detected:

You can schedule online diagnostics to run at a designated time of day or on a daily, weekly, or monthly basis. You can schedule tests to run only once or to repeat at an interval. Use the no form of this command to remove the scheduling.

To schedule online diagnostics, perform this task:

This example shows how to schedule diagnostic testing on a specific date and time for a specific port on module 1:

This example shows how to schedule diagnostic testing to occur daily at a certain time for a specific port:

This example shows how to schedule diagnostic testing to occur weekly on a certain day for a specific port:

You can configure health-monitoring diagnostic testing while the switch is connected to a live network. You can configure the execution interval for each health-monitoring test, the generation of a system message upon test failure, or the enabling or disabling an individual test. Use the no form of this command to disable testing.

To configure health-monitoring diagnostic testing, perform this task:

This example shows how to configure the specified test to run every two minutes on module 1:

This example shows how to run the test if health monitoring has not previously been enabled:

This example shows how to enable the generation of a syslog message when any health-monitoring test fails:

After you configure online diagnostics, you can start or stop diagnostic tests or display the test results. You can also see which tests are configured and what diagnostic tests have already run.

These sections describe how to run online diagnostic tests after they have been configured:

•Starting and Stopping Online Diagnostic Tests

•Running All Online Diagnostic Tests

•Displaying Online Diagnostic Tests and Test Results

Note•We recommend that before you enable any online diagnostics tests that you enable the logging console/monitor to see all warning messages.

•We recommend that when you are running disruptive tests that you only run the tests when connected through the console. When disruptive tests are complete, a warning message on the console recommends that you reload the system to return to normal operation. Strictly follow this warning.

•While tests are running, all ports are shut down because a stress test is being performed with ports configured to loop internally; external traffic might alter the test results. The switch must be rebooted to bring the switch to normal operation. When you issue the command to reload the switch, the system will ask you if the configuration should be saved. Do not save the configuration.

•If you are running the tests on a supervisor engine, after the test is initiated and complete, you must reload or power down and then power up the entire system.

•If you are running the tests on a switching module, rather than the supervisor engine, after the test is initiated and complete, you must reset the switching module.

After you configure diagnostic tests to run, you can use the start and stop to begin or end a diagnostic test.

To start or stop an online diagnostic command, perform one of these tasks:

This example shows how to start a diagnostic test on module 1:

This example shows how to stop a diagnostic test:

You can run all diagnostic tests, disruptive and nondisruptive, at once with a single command. In this case, all test dependencies will be handled automatically.

Note•Running all online diagnostic tests will disrupt normal system operation. Reset the system after the diagnostic start system test all command has completed.

•Do not insert, remove, or power down modules or the supervisor while the system test is running.

•Do not issue any diagnostic command other than the diagnostic stop system test all command while the system test is running.

•Make sure no traffic is running in background.

To start or stop all online diagnostic tests, perform one of these tasks:

This example shows how to start all online diagnostic tests:

You can display the online diagnostic tests that are configured and check the results of the tests using the following show commands:

•show diagnostic content

•show diagnostic health

To display the diagnostic tests that are configured, perform this task:

This example shows how to display the online diagnostics that are configured on module 1:

This example shows how to display the online diagnostic results for module 1:

This example shows how to display the detailed online diagnostic results for module 1:

This example shows how to display the output for the health checks performed:

Most online diagnostic tests do not need any special setup or configuration. However, the memory tests, which include the TestFibTcamSSRAM and TestLinecardMemory tests, have some required tasks and some recommended tasks that you should complete before running them.

Before you run any of the online diagnostic memory tests, perform the following tasks:

•Required tasks

–Isolate network traffic by disabling all connected ports.

–Do not send test packets during a memory test.

–Reset the system before returning the system to normal operating mode.

•Turn off all background health-monitoring tests using the no diagnostic monitor module number test all command.

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples and troubleshooting information), see the documents listed on this page:

http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

Participate in the Technical Documentation Ideas forum

Page 10

•Global Health-Monitoring Tests

•Per-Port Tests

•PFC Layer 2 Tests

•DFC Layer 2 Tests

•PFC Layer 3 Tests

•DFC Layer 3 Tests

•Replication Engine Tests

•Fabric Tests

•Exhaustive Memory Tests

•Service Module Tests

•Stress Tests

•General Tests

•Critical Recovery Tests

•ViSN Tests

Note•For information about configuring online diagnostic tests see Chapter 12 "Configuring Online Diagnostics."

•Before you enable any online diagnostics tests, enable console logging to see all warning messages.

•We recommend that when you are running disruptive tests that you only run the tests when connected through console. When disruptive tests are complete a warning message on the console recommends that you reload the system to return to normal operation: strictly follow this warning.

•While tests are running, all ports are shut down as a stress test is being performed with looping ports internally and external traffic might affect the test results. The switch must be rebooted to bring the switch to normal operation. When you issue the command to reload the switch, the system will ask you if the configuration should be saved.

•Do not save the configuration.

•If you are running the tests on other modules, after the test is initiated and complete, you must reset the module.

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples and troubleshooting information), see the documents listed on this page:

http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

Participate in the Technical Documentation Ideas forum

•TestAsicSync

•TestEARLInternalTables

•TestErrorCounterMonitor

•TestIntPortLoopback

•TestLtlFpoeMemoryConsistency

•TestMacNotification

•TestPortTxMonitoring

•TestScratchRegister

•TestSnrMonitoring

•TestSPRPInbandPing

•TestUnusedPortIndexDirect

•TestUnusedPortLoopback

This test periodically verifies the status of bus and port synchronization ASICs.