• TCAM Programming and ACLs
  • Layer 4 Operators in ACLs
  • Configuring Unicast MAC Address Filtering
  • Configuring Named MAC Extended ACLs
  • Configuring EtherType Matching
  • Configuring Named IPv6 ACLs
  • Applying IPv6 ACLs to Layer 2 and 3 Interface
  • Configuring VLAN Maps
  • Displaying VLAN Access Map Information
  • Using VLAN Maps with Router ACLs
  • Configuring PACLs
  • Using PACL with VLAN Maps and Router ACLs
  • Configuring RA Guard

  • Configuring Network Security with ACLs


    This chapter describes how to use access control lists (ACLs) to configure network security on the Catalyst 4500 series switches.


    Note The Catalyst 4500 series switch supports time-based ACLs.


    This chapter consists of the following major sections:

    About ACLs

    Hardware and Software ACL Support

    Troubleshooting High CPU Due to ACLs

    TCAM Programming and ACLs

    Layer 4 Operators in ACLs

    Configuring Unicast MAC Address Filtering

    Configuring Named MAC Extended ACLs

    Configuring EtherType Matching

    Configuring Named IPv6 ACLs

    Applying IPv6 ACLs to Layer 2 and 3 Interface

    Configuring VLAN Maps

    Displaying VLAN Access Map Information

    Using VLAN Maps with Router ACLs

    Configuring PACLs

    Using PACL with VLAN Maps and Router ACLs

    Configuring RA Guard


    Note For complete syntax and usage information for the switch commands used in this chapter, first look at the Cisco Catalyst 4500 Series Switch Command Reference and related publications at this location:
    http://www.cisco.com/en/US/products/hw/switches/ps4324/index.html
    If the command is not found in the Catalyst 4500 Series Switch Command Reference, it will be found in the larger Cisco IOS library. Refer to the Cisco IOS Command Reference and related publications at this location:
    http://www.cisco.com/en/US/products/ps6350/index.html


    About ACLs

    This section includes these topics:

    Overview

    Supported Features That Use ACLs

    Router ACLs

    Port ACLs

    Dynamic ACLs

    VLAN Maps

    Overview

    An ACL is a collection of sequential permit and deny conditions that applies to packets. When a packet is received on an interface, the switch compares the fields in the packet against any applied ACLs to verify that the packet has the permissions required to be forwarded, based on the conditions specified in the access lists. It tests the packets against the conditions in an access list one-by-one. The first match determines whether the switch accepts or rejects the packets. Because the switch stops testing conditions after the first match, the order of conditions in the list is critical. If no conditions match, the switch drops the packet. If no restrictions exist, the switch forwards the packet; otherwise, the switch drops the packet.

    Switches traditionally operate at Layer 2, switching traffic within a VLAN. Routers route traffic between VLANs at Layer 3. The Catalyst 4500 series switch can accelerate packet routing between VLANs by using Layer 3 switching. The Layer 3 switch bridges the packet, and then routes the packet internally without going to an external router. The packet is then bridged again and sent to its destination. During this process, the switch can control all packets, including packets bridged within a VLAN.

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

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

    The Catalyst 4500 series switch supports three types of ACLs:

    IP ACLs, which filter IP traffic, including TCP, the User Datagram Protocol (UDP), Internet Group Management Protocol (IGMP), and Internet Control Message Protocol (ICMP)

    IPv6 ACLs

    MAC ACLs which match based on Ethernet addresses and Ether Type

    Supported Features That Use ACLs

    The switch supports three applications of ACLs to filter traffic:

    Router ACLs are applied to Layer 3 interfaces. They control the access of routed traffic between VLANs. All Catalyst 4500 series switches can create router ACLs, but you must have a Cisco IOS software image on your switch to apply an ACL to a Layer 3 interface and filter packets routed between VLANs.

    Port ACLs perform access control on traffic entering a Layer 2 interface. If insufficient hardware CAM entries exist, the output port ACL is not applied to the port and a warning message is given to user. (This restriction applies to all access group modes for output port ACLs.) When sufficient CAM entries exist, the output port ACL may be reapplied.

    If there is any output port ACL configured on a Layer 2 port, then no VACL or router ACL can be configured on the VLANs that the Layer 2 port belongs to. Also, the reverse is true: port ACLs and VLAN-based ACLs (VACLs and router ACLs) are mutually exclusive on a Layer 2 port. This restriction applies to all access group modes. On the input direction, port ACLs, VLAN-based ACLs, and router ACLs can co-exist.

    You can apply one IPv4 access list, one IPv6 access list and one MAC access list for a Layer 2 interface.

    You can use VLAN maps to filter traffic between devices in the same VLAN. You do not need the enhanced image to create or apply VLAN maps. VLAN maps are configured to control access based on Layer 3 addresses for IP. MAC addresses using Ethernet ACEs control the access of unsupported protocols. After you apply a VLAN map to a VLAN, all packets (routed or bridged) entering the VLAN are checked against that map. Packets can either enter the VLAN through a switch port or through a routed port after being routed.

    You can use both router ACLs and VLAN maps on the same switch.

    Router ACLs

    You can apply one access list of each supported type to an interface.


    Note Catalyst 4500 series switches running Cisco IOS Release 12.2(40)SG do not support IPv6 port ACLs (PACLs).


    Multiple features can use one ACL for a given interface, and one feature can use multiple ACLs. When a single router ACL is used by multiple features, it is examined multiple times. The access list type determines the input to the matching operation:

    Standard IP access lists use source addresses for matching operations.

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

    The switch examines ACLs associated with features configured on a given interface and a direction. As packets enter the switch on an interface, ACLs associated with all inbound features configured on that interface are examined. After packets are routed and before they are forwarded to the next hop, all ACLs associated with outbound features configured on the egress interface are examined.

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

    Figure 51-1 Using ACLs to Control Traffic to a Network

    Port ACLs

    You can also apply ACLs to Layer 2 interfaces on a switch. Port ACLs are supported on physical interfaces and EtherChannel interfaces.

    The following access lists are supported on Layer 2 interfaces:

    Standard IP access lists using source addresses

    Extended IP access lists using source and destination addresses and optional protocol type information

    IPv6 access lists using source and destination addresses and optional protocol type information

    MAC extended access lists using source and destination MAC addresses and optional protocol type information

    As with router ACLs, the switch examines ACLs associated with features configured on a given interface and permits or denies packet forwarding based on how the packet matches the entries in the ACL. In the example in Figure 51-1, if all workstations were in the same VLAN, ACLs applied at the Layer 2 input would allow Host A to access the Human Resources network, but prevent Host B from accessing the same network.

    When you apply a port ACL to a trunk port, the ACL filters traffic on all VLANs present on the trunk port. When you apply a port ACL to a port with voice VLAN, the ACL filters traffic on both data and voice VLANs.

    With port ACLs, you can filter IP traffic by using IP access lists and non-IP traffic by using MAC addresses. You can filter both IP and non-IP traffic on the same Layer 2 interface by applying both an IP access list and a MAC access list to the interface.

    With port ACLs, you can filter IPv4 traffic with IPv4 access lists, IPv6 traffic with IPv6 access lists, and non-IP traffic with MAC access lists. You can filter multiple types of traffic simultaneously by applying ACLs of the appropriate type to the Layer 2 interface simultaneously.


    Note You cannot simultaneously apply more than one access list of a given type to a Layer 2 interface. If an IPv4, IPv6, or MAC access list is already configured on a Layer 2 interface, and you apply a new IPv4, IPv6 or MAC access list to the interface, the new ACL replaces the previously configured ACL of the same type.


    Dynamic ACLs

    Various security features, such as 802.1X, NAC and Web Authentication, are capable of downloading ACLs from a central server and applying them to interfaces. Prior to Cisco IOS Release 12.2(54)SG, these features required the explicit configuration of a standard port ACL

    Starting with Cisco IOS Release 12.2(54)SG, a port ACL does not require configuration. For more details refer to the "Removing the Requirement for a Port ACL" section.

    VLAN Maps

    VLAN maps can control the access of all traffic in a VLAN. You can apply VLAN maps on the switch to all packets that are routed into or out of a VLAN or are bridged within a VLAN. VLAN maps are not defined by direction (input or output).

    You can configure VLAN maps to match Layer 3 addresses for IP traffic. Access of all non-IP protocols is controlled with a MAC address and an Ethertype using MAC ACLs in VLAN maps. (IP traffic is not controlled by MAC ACLs in VLAN maps.) You can enforce VLAN maps only on packets heading to the switch; you cannot enforce VLAN maps on traffic between hosts on a hub or on another switch connected to this switch.

    With VLAN maps, forwarding packets is permitted or denied, based on the action specified in the map. Figure 51-2 illustrates how a VLAN map is applied to deny a specific type of traffic from Host A in VLAN 10 from being forwarded.

    Figure 51-2 Using VLAN Maps to Control Traffic

    Hardware and Software ACL Support

    This section describes how to determine whether ACLs are processed in hardware or in software:

    Flows that match a deny statement in standard and extended ACLs are dropped in hardware if ICMP unreachable messages are disabled.

    Flows that match a permit statement in standard ACLs are processed in hardware.

    The following ACL types are not supported in software:

    Standard Xerox Network Systems (XNS) Protocol access list

    Extended XNS access list

    DECnet access list

    Protocol type-code access list

    Standard Internet Packet Exchange (IPX) access list

    Extended IPX access list


    Note Packets that require logging are processed in software. A copy of the packets is sent to the CPU for logging while the actual packets are forwarded in hardware so that non-logged packet processing is not impacted.


    By default, the Catalyst 4500 series switch sends ICMP unreachable messages when a packet is denied by an access list; these packets are not dropped in hardware but are forwarded to the switch so that it can generate the ICMP unreachable message.

    To drop access list denied packets in hardware on the input interface, you must disable ICMP unreachable messages using the no ip unreachables interface configuration command. The
    ip unreachables command is enabled by default.


    Note Cisco IOS Release 12.2(40)SG does not support disabling IP unreachables on interfaces routing IPv6 traffic.



    Note If you set the no ip unreachable command on all Layer 3 interfaces, output ACL denied packets do not come to the CPU.


    Troubleshooting High CPU Due to ACLs

    Packets that match entries in fully programmed ACLs are processed in hardware.


    Note Large ACL and IPSG configurations may exhaust TCAM masks on the Catalyst 4948E Ethernet Switch before the ACLs are fully programmed.


    Packets that match entries in partially programmed ACLs are processed in software using the CPU. This may cause high CPU utilization and packets to be dropped. To determine whether packets are being dropped due to high CPU utilization, reference the following:

    http://www.cisco.com/en/US/products/hw/switches/ps663/products_tech_note09186a00804cef15.shtml

    If the ACL and/or IPSG configuration is partially programmed in hardware, upgrading to
    Cisco IOS Release 12.2(31)SGA or later and resizing the TCAM regions may enable the ACLs to be fully programmed.


    Note Removal of obsolete TCAM entries can take several CPU process review cycles to complete. This process may cause some packets to be switched in software if the TCAM entry or mask utilization is at or near 100 percent.


    Selecting Mode of Capturing Control Packets

    In some deployments, you might want to bridge control packets in hardware rather than globally capture and forward them in software (at the expense of the CPU). The per-VLAN capture mode feature allows a Catalyst 4500 series switch to capture control packets only on selected VLANs and bridge traffic in hardware on all other VLANs.

    When you use per-VLAN capture mode on your switch, it partially disables the global TCAM capture entries internally and attaches feature-specific capture ACLs on those VLANs that are enabled for snooping features. (All IP capture entries, and other non-IP entries are still captured through global TCAM.)

    Because this feature controls specific control packets, they are captured only on the VLANs on which the internal ACLs are installed. On all other VLANs, the control traffic is bridged in hardware rather than forwarded to CPU.

    The per-VLAN capture mode allows you to apply user-defined ACLs and QoS policers (in hardware) on control packets. You can also subject the aggregate control traffic ingressing the CPU to control plane policing.

    When you use per-VLAN capture mode, the following four protocol groups are selectable per-VLAN. The breakdown of protocols intercepted by each group is as follows:

    IGMP Snooping—Cgmp, Ospf, Igmp, RipV2, Pim, 224.0.0.1, 224.0.0.2, 224.0.0.*

    DHCP Snooping—Client to Server, Server to Client, Server to Server

    Because some of the groups have multiple overlapping ACEs (for example, 224.0.0.* is present in all the groups except for DHCP Snooping), turning on a certain group will also trigger the interception of some protocols from other groups.

    Following are the programming triggers for the four protocol groups per-VLAN:

    IGMP Snooping should be enabled globally on a given VLAN.

    DHCP Snooping should be enabled globally on a given VLAN.

    Guidelines and Restrictions


    Note Before configuring per-VLAN capture mode, you should examine your configuration to ensure that only the necessary features are enabled on the desired VLANs.


    The following guidelines and restrictions apply to per-VLAN capture mode:

    Starting with Cisco IOS Release 15.0(2)SG, for Supervisor Engine 6-E and Supervisor Engine 6L-E, (with Cisco IOS XE Release 3.2.0, for Supervisor Engine 7-E; with Cisco IOS XE Release 3.2.0XO, for Supervisor Engine 7L-E), globally reserved static ACL entries in the TCAM region for Layer 3 control packets are removed. The per-VLAN CTI command is not needed and does not apply for Layer 3 control packets because these packets are captured in per-VLAN fashion by default.

    The following still function:

    Global static capture and CTI commands for IGMP or PIM packets (both use MAC addresses 224.0.0.1 and 224.0.0.2)

    Global and per-VLAN CTI for DHCP packets

    With Cisco IOS Release 15.0(2)SG, per-VLAN capture of Layer 3 control packets is driven by SVI configuration. Except for IGMP, PIM, or DHCP, no special configuration is required.

    Enabling per-VLAN capture mode consumes additional entries in the ACL/feature TCAM.

    The number of available TCAM entries depends on the type of supervisor engine. The entry and mask count further limits the utilization of the ACL/feature TCAM.

    Certain configurations can exhaust TCAM resource earlier in per-VLAN capture mode than in global capture mode (such as, when IP Source Guard is enabled on several interfaces or on a user-configured PACL).

    You can resize TCAM regions to make more entries available to the PortAndVlan or PortOrVlan region based on the configuration. This allows more entries to be programmed in hardware before reaching the limit. When TCAM resources are exhausted, the packets are forwarded in software.

    In per-VLAN capture mode, you can configure ACLs to permit or deny control traffic on a VLAN or port.

    Because security ACLs are terminated by an implicit deny, you must ensure that the ACLs are configured to permit the control packets necessary for the feature (protocol) to operate. However, this rule does not differ from the default behavior.

    Selecting Control Packet Capture

    To select the mode of capturing control packets, perform this task:

     
    Command
    Purpose

    Step 1 

    Switch# conf terminal

    Enters configuration mode.

    Step 2 

    Switch(config)# [no] access-list hardware capture mode [vlan | global]

    Selects mode of capturing control packets.

    The no form of the access-list hardware capture mode command restores the capture mode to the default, which is global.

    Step 3 

    Switch(config)# end

    Returns to enable mode.

    This example shows how to configure a Catalyst 4500 series switch to capture control packets only on VLANs where features are enabled:

    Switch# configure terminal
    
    Enter configuration commands, one per line. End with CNTL/Z.
    
    Switch(config)# access-list hardware capture mode vlan
    
    Switch(config)# end
    
    Switch#
    
     
       

    This example shows how to configure a Catalyst 4500 series switch to capture control packets globally across all VLANs (using static ACL, the default mode):

    Switch# configure terminal
    
    Enter configuration commands, one per line. End with CNTL/Z.
    
    Switch(config)# access-list hardware capture mode global
    
    Switch(config)# end
    
    Switch#
    
     
       

    When the capture mode changes from global to VLAN, the static CAM entries are invalidated. This creates a window during which control packets may pass through a Catalyst 4500 series switch without being intercepted to the CPU. This temporary situation is restored when the new per-VLAN capture entries are programmed in the hardware.

    When you configure per-VLAN capture mode, you should examine the show commands for individual features to verify the appropriate behavior. In per-VLAN capture mode, the invalidated static CAM entries will appear as inactive in the output of the show platform hardware acl input entries static command. For example, the hit count for inactive entries will remain frozen because those entries are invalidated and applied per-VLAN where the feature is enabled. The following table lists the CamIndex entry types and the Cam regions.

    CamIndex Entry Type
    Active
    Hit Count
    CamRegion

    50 PermitSharedStp

    Y

    3344

    ControlPktsTwo

    51 PermitLoopbackTest

    Y

    0

    ControlPktsTwo

    52 PermitProtTunnel

    Y

    0

    ControlPktsTwo

    53 CaptureCgmp

    N

    440

    ControlPktsTwo

    55 CaptureIgmp

    N

    0

    ControlPktsTwo

    0 IgmpPimv1ToCpu

    N

    N/A

    0 (estimate)

    0 IgmpGeneralQueryToCpu

    N

    N/A

    0 (estimate)

    2 IgmpToCpu

    N

    N/A

    0 (estimate)

    3 IgmpPimv2ToCpu

    N

    N/A

    0 (estimate)

    2048 Ipv6MldGeneralQueryCopyToCpu

    N

    N/A

    0 (estimate)

    2050 Ipv6MldGeneralQueryCopyToCpu

    N

    N/A

    0 (estimate)

    2052 Ipv6MldQueryOrReportV1ToCpu

    N

    N/A

    0 (estimate)

    2054 Ipv6MldQueryOrReportV1ToCpu

    N

    N/A

    0 (estimate)

    2056 Ipv6MldReportV2ToCpu

    N

    N/A

    0 (estimate)

    2058 Ipv6MldReportV2ToCpu

    N

    N/A

    0 (estimate)

    2060 Ipv6MldDoneToCpu

    N

    N/A

    0 (estimate)

    2064 Ipv6MldPimv2ToCpu

    N

    N/A

    0 (estimate)


    TCAM Programming and ACLs

    You apply three types of hardware resources when you program ACLs and ACL-based features: mapping table entries (MTEs), profiles, and TCAM value/mask entries. If any of these resources are exhausted, packets are sent to the CPU for software-based processing.


    Note Supervisor Engine 6-E, Supervisor Engine 6L-E, Supervisor Engine 7-E, and Supervisor Engine 7L-E automatically manage the available resources. Because masks are not shared on the supervisor engines, only one programming algorithm exists. No regions exist so region resizing is not needed.


    If you exhaust resources on the supervisor engine, you should consider reducing the complexity of your configuration.


    Note When an interface is in down state, TCAMs are not consumed for RACLs, but are for PACLs.


    Layer 4 Operators in ACLs

    The following sections provide guidelines and restrictions for configuring ACLs that include Layer 4 port operations:

    Restrictions for Layer 4 Operations

    Configuration Guidelines for Layer 4 Operations

    How ACL Processing Impacts CPU

    Restrictions for Layer 4 Operations

    You can specify these operator types, each of which uses one Layer 4 operation in the hardware:

    gt (greater than)

    lt (less than)

    neq (not equal)

    range (inclusive range)

    The limits on the number of Layer 4 operations differ for each type of ACL, and can also vary based on other factors: whether an ACL is applied to incoming or outgoing traffic, whether the ACL is a security ACL or is used as a match condition for a QoS policy, and whether IPv6 ACLs are being programmed using the compressed flow label format.


    Note The IPv6 compressed flow label format uses the Layer 2 Address Table to compress a portion of the IPv6 source address of each ACE in the ACL. The extra space freed in the flow label can then be used to support more Layer 4 operations. For this compression to be used, the IPv6 ACL cannot contain any ACEs that mask in only a portion of the bottom 48 bits of the source IPv6 address.


    Generally, you will receive at most the following number of Layer 4 operations on the same ACL:

    Direction  Protocol           Type      Operations
    
    ------------------------------------------------
    
    Input      IPv4               Security  16
    
    Input      IPv6 Compressed    Security  16
    
    Input      IPv6 Uncompressed  Security   7
    
    Input      IPv4               QoS        5
    
    Input      IPv6 Compressed    QoS       12
    
    Input      IPv6 Uncompressed  QoS        8
    
    Output     IPv4               Security  17
    
    Output     IPv6 Compressed    Security  17
    
    Output     IPv6 Uncompressed  Security   8
    
    Output     IPv4               QoS        5
    
    Output     IPv6 Compressed    QoS       12
    
    Output     IPv6 Uncompressed  QoS        8
    

    Note Where up to 16 operations are supported, the seventeenth will trigger an expansion.


    If you exceed the number of available Layer 4 operations, each new operation might cause the affected ACE to be translated into multiple ACEs in the hardware. If this translation fails, packets are sent to the CPU for software processing.

    Configuration Guidelines for Layer 4 Operations

    When using Layer 4 operators, consider these guidelines:

    Layer 4 operations are considered different if the operator or operand differ. For example, the following ACL contains three different Layer 4 operations because gt 10 and gt 11 are considered two different Layer 4 operations:

    ... gt 10 permit
    
    ... lt 9 deny
    
    ... gt 11 deny
    
     
       

    Note The eq operator can be used an unlimited number of times because eq does not use a Layer 4 operation in hardware.


    Layer 4 operations are considered different if the same operator/operand couple applies once to a source port and once to a destination port, as in the following example:

    ... Src gt 10....
    
    ... Dst gt 10
    
     
       

    A more detailed example follows:

    access-list 101
    
    ... (dst port) gt 10 permit
    
    ... (dst port) lt 9 deny
    
    ... (dst port) gt 11 deny
    
    ... (dst port) neq 6 permit
    
    ... (src port) neq 6 deny
    
    ... (dst port) gt 10 deny
    
     
       
    access-list 102
    
    ... (dst port) gt 20 deny
    
    ... (src port) lt 9 deny
    
    ... (src port) range 11 13 deny
    
    ... (dst port) neq 6 permit
    
     
       

    Access lists 101 and 102 use the following Layer 4 operations:

    Access list 101 Layer 4 operations: 5

    gt 10 permit and gt 10 deny both use the same operation because they are identical and both operate on the destination port.

    Access list 102 Layer 4 operations: 4

    Total Layer 4 operations: 8 (due to sharing between the two access lists)

    neq6 permit is shared between the two ACLs because they are identical and both operate on the same destination port.

    A description of the Layer 4 operations usage is as follows:

    Layer 4 operation 1 stores gt 10 permit and gt 10 deny from ACL 101

    Layer 4 operation 2 stores lt 9 deny from ACL 101

    Layer 4 operation 3 stores gt 11 deny from ACL 101

    Layer 4 operation 4 stores neg 6 permit from ACL 101 and 102

    Layer 4 operation 5 stores neg 6 deny from ACL 101

    Layer 4 operation 6 stores gt 20 deny from ACL 102

    Layer 4 operation 7 stores lt 9 deny from ACL 102

    Layer 4 operation 8 stores range 11 13 deny from ACL 102

    How ACL Processing Impacts CPU

    ACL processing can impact the CPU in two ways:

    For some packets, when the hardware runs out of resources, the software must perform the ACL matches:

    The TCP flag combinations rst ack, syn fin rst, urg and psh are processed in hardware. rst ack is equivalent to the keyword established. Other TCP flag combinations are supported in software.

    If the total number of Layer 4 operations in an ACL is less than six, you can distribute the operations in any way you choose.

    Examples

    The following access lists are processed completely in hardware:

    access-list 104 permit tcp any any established
    
    access-list 105 permit tcp any any rst ack
    
    access-list 107 permit tcp any synfin rst
    
     
       

    Access lists 104 and 105 are identical; established is shorthand for rst and ack.

    Access list 101, is processed completely in software:

    access-list 101 permit tcp any any syn
    
     
       

    Because four source and two destination operations exist, access list 106 is processed in hardware:

    access-list 106 permit tcp any range 100 120 any range 120 140
    
    access-list 106 permit tcp any range 140 160 any range 180 200
    
    access-list 106 permit tcp any range 200 220
    
    access-list 106 deny tcp any range 220 240
    
     
       

    In the following code, the Layer 4 operations for the third ACE trigger an attempt to translate dst lt 1023 into multiple ACEs in hardware, because three source and three destination operations exist. If the translation attempt fails, the third ACE is processed in software.

    access-list 102 permit tcp any lt 80 any gt 100             
    
    access-list 102 permit tcp any range 100 120 any range 120 1024
    
    access-list 102 permit tcp any gt 1024 any lt 1023
    
     
       

    Similarly, for access list 103, the third ACE triggers an attempt to translate dst gt 1023 into multiple ACEs in hardware. If the attempt fails, the third ACE is processed in software. Although the operations for source and destination ports look similar, they are considered different Layer 4 operations.

    access-list 103 permit tcp any lt 80 any lt 80 
    
    access-list 103 permit tcp any range 100 120 any range 100 120
    
    access-list 103 permit tcp any gt 1024 any gt 1023
    
     
       

    Note Remember that source port lt 80 and destination port lt 80 are considered different operations.


    Some packets must be sent to the CPU for accounting purposes, but the action is still performed by the hardware. For example, if a packet must be logged, a copy is sent to the CPU for logging, but the forwarding (or dropping) is performed in the hardware. Although logging slows the CPU, it does not affect the forwarding rate. This sequence of events would happen under the following conditions:

    When a log keyword is used

    When an output ACL denies a packet

    When an input ACL denies a packet, and on the interface where the ACL is applied,
    ip unreachable is enabled (ip unreachable is enabled by default on all the interfaces)

    Configuring Unicast MAC Address Filtering

    To block all unicast traffic to or from a MAC address in a specified VLAN, perform this task:

    Command
    Purpose
    Switch(config)# mac-address-table static mac_address 
    vlan vlan_ID drop 
    

    Blocks all traffic to or from the configured unicast MAC address in the specified VLAN.

    To clear MAC address-based blocking, use the no form of this command without the drop keyword.


    This example shows how to block all unicast traffic to or from MAC address 0050.3e8d.6400 in VLAN 12:

    Switch# configure terminal 
    
    Switch(config)# mac-address-table static 0050.3e8d.6400 vlan 12 drop 
    

    Configuring Named MAC Extended ACLs

    You can filter non-IPv4, non-IPv6 traffic on a VLAN and on a physical Layer 2 port by using MAC addresses and named MAC extended ACLs. The procedure is similar to that of configuring other extended named ACLs. You can use a number to name the access list, but MAC access list numbers from 700 to 799 are not supported.


    Note Named MAC extended ACLs cannot be applied to Layer 3 interfaces.


    For more information about the supported non-IP protocols in the mac access-list extended command, refer to the Catalyst 4500 Series Switch Cisco IOS Command Reference.

    To create a named MAC extended ACL, perform this task:

     
    Command
    Purpose

    Step 1 

    Switch# configure terminal
    

    Enters global configuration mode.

    Step 2 

    Switch(config)# [no] mac access-list 
    extended name 
    

    Defines an extended MAC access list using a name.

    To delete the entire ACL, use the no mac access-list extended name global configuration command. You can also delete individual ACEs from named MAC extended ACLs.

    Step 3 

    Switch(config-ext-macl)# {deny | permit} 
    {any | host source MAC address | source 
    MAC address mask} {any | host destination 
    MAC address | destination MAC address 
    mask} [protocol-family {appletalk | 
    arp-non-ipv4 | decnet | ipx | ipv6 (not 
    supported on Sup 6-E and 6L-E)| rarp-ipv4 
    | rarp-non-ipv4 | vines | xns]
    

    In extended MAC access-list configuration mode, specify to permit or deny any source MAC address, a source MAC address with a mask, or a specific host source MAC address and any destination MAC address, destination MAC address with a mask, or a specific destination MAC address.

    Note IPv6 packets do not generate Layer 2 ACL lookup keys.

    Step 4 

    Switch(config-ext-macl)# end 
    

    Returns to privileged EXEC mode.

    Step 5 

    Switch# show access-lists [number | name]
    

    Shows the access list configuration.

    Step 6 

    Switch(config)# copy running-config 
    startup-config 
    

    (Optional) Saves your entries in the configuration file.

    This example shows how to create and display an access list named mac1, denying only EtherType DECnet Phase IV traffic, but permitting all other types of traffic:

    Switch(config)# mac access-list extended mac1
    
    Switch(config-ext-macl)# deny any any decnet-iv (old) protocol-family decnet (new)
    
    Switch(config-ext-macl)# permit any any
    
    Switch(config-ext-macl)# end
    
    Switch # show access-lists
    
    Extended MAC access list mac1
    
        deny   any any decnet-iv (old) protocol-family decnet (new)
    
        permit any any 
    
     
       

    The following example shows how to enable or disable hardware statistics while configuring ACEs in the access list:

    Switch# config t
    
    Enter configuration commands, one per line.  End with CNTL/Z. 
    
    Switch(config)# mac access-list extended mac1
    
    Switch(config-ext-nacl)# hardware statistics
    
    Switch(config-ext-nacl)# end
    
    Switch# show access-lists
    
    Extended MAC access list macl
    
        deny   any any decnet-iv (old) protocol-family decnet (new)
    
        permit any any 
    
    	hardware statistics
    

    Configuring EtherType Matching

    You can classify non-IP traffic based on the EtherType value using the existing MAC access list commands. When you classify non-IP traffic by EtherType, you can apply security ACLs and QoS policies to traffic that carry the same EtherType.

    EtherType matching allows you to classify tagged and untagged IP packets based on the EtherType value. Tagged packets present a potential operation problem:

    While single-tagged packets are supported on the access and trunk ports, double-tagged packets are not.

    Single and double-tagged packets are not supported if the port mode is dot1qtunnel.

    For more information about the mac access-list extended command, refer to the Catalyst 4500 Series Switch Cisco IOS Command Reference.

    To create a named MAC extended ACL, perform this task:

     
    Command
    Purpose

    Step 1 

    Switch# configure terminal
    

    Enters global configuration mode.

    Step 2 

    Switch(config)# [no] mac access-list 
    extended name 
    

    Defines an extended MAC access list using a name.

    To delete the entire ACL, use the no mac access-list extended name global configuration command. You can also delete individual ACEs from named MAC extended ACLs.

    Step 3 

    Switch(config-ext-macl)# {deny | permit} 
    {any | host source MAC address | source 
    MAC address mask} {any | host destination 
    MAC address | destination MAC address 
    mask} [protocol-family {appletalk | 
    arp-non-ipv4 | decnet | ipx | ipv6 (not 
    supported on Sup 6-E and 6L-E)| rarp-ipv4 
    | rarp-non-ipv4 | vines | xns} | 
    ethertype] 
    

    In extended MAC access-list configuration mode, specify to permit or deny any based upon the EtherTypes value, valid values are 15636-65535.

    Note You can specify matching by either EtherType or protocol family but not both.

    Step 4 

    Switch(config-ext-macl)# end 
    

    Returns to privileged EXEC mode.

    Step 5 

    Switch# show access-lists [number | name]
    

    Shows the access list configuration.

    Step 6 

    Switch(config)# copy running-config 
    startup-config 
    

    (Optional) Saves your entries in the configuration file.

    This example shows how to create and display an access list named matching, permitting the 0x8863 and 0x8040 EtherType values:

    Switch(config)# mac access-list extended matching
    
    Switch(config-ext-macl)# permit any any 0x8863
    
    Switch(config-ext-macl)# permit any any 0x8040
    
    Switch(config-ext-macl)# end
    
    Switch # show access-lists matching
    
      Extended MAC access list matching
    
        permit any any 0x8863
    
        permit any any netbios
    
    Switch # 
    

    Configuring Named IPv6 ACLs

    Supervisor Engine 6-E, Supervisor Engine 6L-E, Supervisor Engine 7-E, and Supervisor Engine 7L-E also support hardware-based IPv6 ACLs to filter unicast, multicast and broadcast IPv6 traffic on Layer 2 and Layer 3 interfaces. You can only configure such access lists on Layer 3 interfaces that are configured with an IPv6 address.

    To create a named IPv6 ACLs, perform this task:

     
    Command
    Purpose

    Step 1 

    Switch# configure terminal
    

    Enters global configuration mode.

    Step 2 

    Switch(config)# ipv6 access-list name
    

    Defines an IPv6 access list using a name.

    To delete the IPv6 ACL, use the no form of the command. You can also delete individual ACEs from the IPv6 access list.

    Step 3 

    Switch(config-ipv6-acl)# {deny | permit} 
    {any | proto} {host ipv6-addr | 
    ipv6-prefix} host ipv6-addr | 
    ipv6-prefix}
    

    Specifies each IPv6 ACE.

    Note Repeat this step to define multiple ACEs in the ACL.

    Step 4 

    Switch(config-ipv6-acl)#  
    hardware statistics
    

    (Optional) Enables hardware statistics for the IPv6 ACL.

    Step 5 

    Switch(config-ipv6-acl)# end
    

    Returns to privileged EXEC mode.

    Step 6 

    Switch# show ipv6 access-list
    

    Display the IPv6 access list configuration.

    The following example shows how to create and display an IPv6 access list named v6test, denying only one IPv6 traffic with one particular source and destination address, but permitting all other types of IPv6 traffic:

        Switch(config)# ipv6 access-list v6test
    
        Switch(config-ipv6-acl)# deny ipv6 host 2020::10 host 2040::10
    
        Switch(config-ipv6-acl)# permit any any
    
        Switch(config-ipv6-acl)# end
    
        Switch# show ipv6 access-list
    
        IPv6 access list v6test
    
            deny ipv6 host 2020::10 host 2040::10 sequence 10
    
            permit ipv6 any any sequence 20
    
     
       

    To enable hardware statistics, enter the following commands while configuring ACEs in the access list:

        Switch(config)# ipv6 access-list v6test
    
        Switch(config-ipv6-acl)# hardware statistics
    
        Switch(config-ipv6-acl)# end
    

    Note Hardware statistics is disabled by default.


    Applying IPv6 ACLs to Layer 2 and 3 Interface

    To apply an IPv6 ACL to a Layer 3 interface, perform the following task:

     
    Command
    Purpose

    Step 1 

    Switch# configure terminal
    

    Enters global configuration mode.

    Step 2 

    Switch(config)# interface interface-type 
    slot/interface
    

    Specifies the interface to be configured.

    Note interface-type must be a Layer 3 interface.

    Step 3 

    Switch(config-if)# ipv6 traffic-filter 
    ipv6-acl {in|out}
    

    Applies the IPv6 ACL to a Layer 3 interface.


    Note IPv6 ACLs are supported on Layer 3 interfaces and on Layer 2 ports using the ipv6 traffic-filter command.


    The following example applies the extended-named IPv6 ACL simple-ipv6-acl to SVI 300 routed ingress traffic:

    Switch# configure terminal
    
    Switch(config)# interface vlan 300
    
    Switch(config-if)# ipv6 traffic-filter simple-ipv6-acl in
    

    Note Output IPv6 ACLs with ACE to match on the ICMP option fail on a switch.


    The following conditions may cause a RACL to malfunction (no workaround):

    ACLs are applied on the output direction of the interface.

    IPv6 ACL contain Ace to match on the ICMP option fields (ICMP Type or ICMP Code).

    The following examples of nonfunctioning RACLs:

    IPv6 access list a1
    
        permit icmp any any nd-ns sequence 10
    
        deny ipv6 any any sequence 20
    
     
       
    IPv6 access list a2
    
       permit icmp 2020::/96 any nd-ns sequence 10
    
        deny ipv6 any any sequence 20
    

    Configuring VLAN Maps

    This section includes these topics:

    VLAN Map Configuration Guidelines

    Creating and Deleting VLAN Maps

    Applying a VLAN Map to a VLAN

    Using VLAN Maps in Your Network

    This section describes how to configure VLAN maps, which is the only way to control filtering within a VLAN. VLAN maps have no direction. To filter traffic in a specific direction by using a VLAN map, you need to include an ACL with specific source or destination addresses. If there is a match clause for that type of packet (IP or MAC) in the VLAN map, the default action is to drop the packet if the packet does not match any of the entries within the map. If there is no match clause for that type of packet, the default is to forward the packet.

    To create a VLAN map and apply it to one or more VLANs, follow these steps:


    Step 1 Create the standard or extended IP ACLs or named MAC extended ACLs that you want to apply to the VLAN.

    Step 2 Enter the vlan access-map global configuration command to create a VLAN ACL map entry.

    In access map configuration mode, you have the option to enter an action (forward [the default] or drop) and enter the match command to specify an IP packet or a non-IP packet and to match the packet against one or more ACLs (standard or extended). If a match clause is not specified, the action is applied to all packets. The match clause can be used to match against multiple ACLs. If a packet matches any of the specified ACLs, the action is applied.


    Note If the VLAN map has a match clause for the type of packet (IP or MAC) and the packet does not match the type, the default is to drop the packet. If there is no match clause in the VLAN map for that type of packet, and no action specified, the packet is forwarded.


    Step 3 Use the vlan filter global configuration command to apply a VLAN map to one or more VLANs.



    Note You cannot apply a VLAN map to a VLAN on a switch that has ACLs applied to Layer 2 interfaces (port ACLs).


    VLAN Map Configuration Guidelines

    When configuring VLAN maps, consider these guidelines:

    VLAN maps do not filter IPv4 ARP packets.

    If there is no router ACL configured to deny traffic on a routed VLAN interface (input or output), and no VLAN map configured, all traffic is permitted.

    Each VLAN map consists of a series of entries. The order of entries in a VLAN map is important. A packet that comes into the switch is tested against the first entry in the VLAN map. If it matches, the action specified for that part of the VLAN map is taken. If there is no match, the packet is tested against the next entry in the map.

    If the VLAN map has at least one match clause for the type of packet (IP or MAC) and the packet does not match any of these match clauses, the default is to drop the packet. If there is no match clause for that type of packet in the VLAN map, the default is to forward the packet.

    The system might take longer to boot if you have configured a very large number of ACLs.

    Creating and Deleting VLAN Maps

    Each VLAN map consists of an ordered series of entries. To create, add to, or delete a VLAN map entry, perform this task:

     
    Command
    Purpose

    Step 1 

    Switch# configure terminal
    

    Enters global configuration mode.

    Step 2 

    Switch(config)# vlan access-map name 
    [number]
    

    Creates a VLAN map, and give it a name and (optionally) a number. The number is the sequence number of the entry within the map.

    When you create VLAN maps with the same name, numbers are assigned sequentially in increments of 10. When modifying or deleting maps, you can enter the number of the map entry that you want to modify or delete.

    This command enables access-map configuration mode.

    Step 3 

    Switch(config-access-map)# action {drop | 
    forward} 
    

    (Optional) Sets the action for the map entry. The default is to forward.

    Step 4 

    Switch(config-access-map)# match {ip | 
    mac} address {name | number} [name | 
    number]
    

    Matches the packet (using either the IP or MAC address) against one or more standard or extended access lists. Note that packets are matched only against access lists of the correct protocol type. IP packets are compared with standard or extended IP access lists. Non-IP packets are only compared with named MAC extended access lists. If a match clause is not specified, the action is taken on all packets.

    Step 5 

    Switch(config-access-map)# end 
    

    Returns to global configuration mode.

    Step 6 

    Switch(config)# show running-config
    

    Displays the access list configuration.

    Step 7 

    Switch(config)# copy running-config 
    startup-config 
    

    (Optional) Saves your entries in the configuration file.

    You can use the no vlan access-map name global configuration command to delete a map. You can use the no vlan access-map name number global configuration command to delete a single sequence entry from within the map. You can use the no action access-map configuration command to enforce the default action, which is to forward.

    VLAN maps do not use the specific permit or deny keywords. To deny a packet by using VLAN maps, create an ACL that would match the packet, and then set the action to drop. A permit in the ACL is the same as a match. A deny in the ACL means no match.

    Examples of ACLs and VLAN Maps

    These examples show how to create ACLs and VLAN maps for specific purposes.

    Example 1

    This example shows how to create an ACL and a VLAN map to deny a packet. In the first map, any packets that match the ip1 ACL (TCP packets) would be dropped. You first create the ip1 ACL to permit any TCP packet and no other packets. Because there is a match clause for IP packets in the VLAN map, the default action is to drop any IP packet that does not match any of the match clauses.

    Switch(config)# ip access-list extended ip1
    
    Switch(config-ext-nacl)# permit tcp any any 
    
    Switch(config-ext-nacl)# exit
    
     
       
    Switch(config)# vlan access-map map_1 10
    
    Switch(config-access-map)# match ip address ip1
    
    Switch(config-access-map)# action drop
    
     
       

    This example shows how to create a VLAN map to permit a packet. ACL ip2 permits UDP packets; and any packets that match the ip2 ACL are forwarded.

    Switch(config)# ip access-list extended ip2
    
    Switch(config-ext-nacl)# permit udp any any 
    
    Switch(config-ext-nacl)# exit
    
    Switch(config)# vlan access-map map_1 20
    
    Switch(config-access-map)# match ip address ip2
    
    Switch(config-access-map)# action forward
    
     
       

    In this map, any IP packets that did not match any of the previous ACLs (that is, packets that are not TCP packets or UDP packets) would get dropped.

    Example 2

    In this example, the VLAN map is configured to drop IP packets and to forward MAC packets by default. By applying standard ACL 101 and the extended named access lists igmp-match and tcp-match, the VLAN map is configured to do the following:

    Forward all UDP packets

    Drop all IGMP packets

    Forward all TCP packets

    Drop all other IP packets

    Forward all non-IP packets

    Switch(config)# access-list 101 permit udp any any
    
    Switch(config)# ip access-list extended igmp-match
    
    Switch(config-ext-nacl)# permit igmp any any
    
    Switch(config)# ip access-list extended tcp-match
    
    Switch(config-ext-nacl)# permit tcp any any
    
    Switch(config-ext-nacl)# exit
    
    Switch(config)# vlan access-map drop-ip-default 10
    
    Switch(config-access-map)# match ip address 101
    
    Switch(config-access-map)# action forward
    
    Switch(config-access-map)# exit
    
    Switch(config)# vlan access-map drop-ip-default 20
    
    Switch(config-access-map)# match ip address igmp-match
    
    Switch(config-access-map)# action drop
    
    Switch(config-access-map)# exit
    
    Switch(config)# vlan access-map drop-ip-default 30
    
    Switch(config-access-map)# match ip address tcp-match
    
    Switch(config-access-map)# action forward
    

    Example 3

    In this example, the VLAN map is configured to drop MAC packets and forward IP packets by default. By applying MAC extended access lists, good-hosts and good-protocols, the VLAN map is configured to do the following:

    Forward MAC packets from hosts 0000.0c00.0111 and 0000.0c00.0211

    Forward MAC packets of DECnet or VINES (Virtual Integrated Network Service) protocol-family

    Drop all other non-IP packets

    Forward all IP packets

    Switch(config)# mac access-list extended good-hosts
    
    Switch(config-ext-macl)# permit host 000.0c00.0111 any
    
    Switch(config-ext-macl)# permit host 000.0c00.0211 any
    
    Switch(config-ext-nacl)# exit
    
    Switch(config)# mac access-list extended good-protocols
    
    Switch(config-ext-macl)# permit any any protocol-family decnet
    
    Switch(config-ext-macl)# permit any any protocol-family vines
    
    Switch(config-ext-nacl)# exit
    
    Switch(config)# vlan access-map drop-mac-default 10
    
    Switch(config-access-map)# match mac address good-hosts
    
    Switch(config-access-map)# action forward
    
    Switch(config-access-map)# exit
    
    Switch(config)# vlan access-map drop-mac-default 20
    
    Switch(config-access-map)# match mac address good-protocols
    
    Switch(config-access-map)# action forward
    

    Example 4

    In this example, the VLAN map is configured to drop all packets (IP and non-IP). By applying access lists tcp-match and good-hosts, the VLAN map is configured to do the following:

    Forward all TCP packets

    Forward MAC packets from hosts 0000.0c00.0111 and 0000.0c00.0211

    Drop all other IP packets

    Drop all other MAC packets

    Switch(config)# vlan access-map drop-all-default 10
    
    Switch(config-access-map)# match ip address tcp-match
    
    Switch(config-access-map)# action forward
    
    Switch(config-access-map)# exit
    
    Switch(config)# vlan access-map drop-all-default 20
    
    Switch(config-access-map)# match mac address good-hosts
    
    Switch(config-access-map)# action forward
    

    Applying a VLAN Map to a VLAN

    To apply a VLAN map to one or more VLANs, perform this task:

     
    Command
    Purpose

    Step 1 

    Switch# configure terminal
    

    Enters global configuration mode.

    Step 2 

    Switch(config)# vlan filter mapname 
    vlan-list list
    

    Applies the VLAN map to one or more VLAN IDs.

    The list can be a single VLAN ID (22), a consecutive list (10-22), or a string of VLAN IDs (12, 22, 30). Spaces around comma, and dash, are optional.

    Step 3 

    Switch(config)# show running-config
    

    Displays the access list configuration.

    Step 4 

    Switch(config)# copy running-config 
    startup-config 
    

    (Optional) Saves your entries in the configuration file.


    Note You cannot apply a VLAN map to a VLAN on a switch that has ACLs applied to Layer 2 interfaces (port ACLs).


    This example shows how to apply VLAN map 1 to VLANs 20 through 22:

    Switch(config)# vlan filter map 1 vlan-list 20-22
    

    Using VLAN Maps in Your Network

    Figure 51-3 shows a typical wiring closet configuration. Host X and Host Y are in different VLANs, connected to wiring closet switches A and C. Traffic moving from Host X to Host Y is routed by Switch B. Access to traffic moving from Host X to Host Y can be controlled at the entry point of Switch A. In the following configuration, the switch can support a VLAN map and a QoS classification ACL.

    Figure 51-3 Wiring Closet Configuration

    For example, if you do not want HTTP traffic to be switched from Host X to Host Y, you could apply a VLAN map on Switch A to drop all HTTP traffic moving from Host X (IP address 10.1.1.32) to Host Y (IP address 10.1.1.34) at Switch A and not bridge the traffic to Switch B. To configure this scenario, you would do the following.

    First, define an IP access list HTTP to permit (match) any TCP traffic on the HTTP port, as follows:

    Switch(config)# ip access-list extended http
    
    Switch(config-ext-nacl)# permit tcp host 10.1.1.32 host 10.1.1.34 eq www
    
    Switch(config-ext-nacl)# exit
    
     
       

    Next, create a VLAN access map named map2 so that traffic that matches the HTTP access list is dropped and all other IP traffic is forwarded, as follows:

    Switch(config)# vlan access-map map2 10
    
    Switch(config-access-map)# match ip address http
    
    Switch(config-access-map)# action drop
    
    Switch(config-access-map)# exit
    
     
       
    Switch(config)# ip access-list extended match_all
    
    Switch(config-ext-nacl)# permit ip any any
    
    Switch(config-ext-nacl)# exit
    
    Switch(config)# vlan access-map map2 20
    
    Switch(config-access-map)# match ip address match_all
    
    Switch(config-access-map)# action forward
    
     
       

    You then apply the VLAN access map named map2 to VLAN 1, as follows:

    Switch(config)# vlan filter map2 vlan 1
    

    Denying Access to a Server on Another VLAN

    Figure 51-4 shows how to restrict access to a server on another VLAN. In this example, server 10.1.1.100 in VLAN 10 has the following access restrictions:

    Hosts in subnet 10.1.2.0/8 in VLAN 20 should not have access.

    Hosts 10.1.1.4 and 10.1.1.8 in VLAN 10 should not have access.

    Figure 51-4 Deny Access to a Server on Another VLAN

    This procedure configures ACLs with VLAN maps to deny access to a server on another VLAN. The VLAN map SERVER 1_ACL denies access to hosts in subnet 10.1.2.0/8, host 10.1.1.4, and host 10.1.1.8. Then it permits all other IP traffic. In Step 3, VLAN map SERVER1 is applied to VLAN 10.

    To configure this scenario, follow these steps:


    Step 1 Define the IP ACL to match and permit the correct packets.

    Switch(config)# ip access-list extended SERVER1_ACL
    
    Switch(config-ext-nacl))# permit ip 10.1.2.0 0.0.0.255 host 10.1.1.100
    
    Switch(config-ext-nacl))# permit ip host 10.1.1.4 host 10.1.1.100
    
    Switch(config-ext-nacl))# permit ip host 10.1.1.8 host 10.1.1.100
    
    Switch(config-ext-nacl))# exit
    
     
       

    Step 2 Define a VLAN map using the ACL to drop IP packets that match SERVER1_ACL and forward IP packets that do not match the ACL.

    Switch(config)# vlan access-map SERVER1_MAP
    
    Switch(config-access-map)# match ip address SERVER1_ACL
    
    Switch(config-access-map)# action drop
    
    Switch(config)# vlan access-map SERVER1_MAP 20
    
    Switch(config-access-map)# action forward
    
    Switch(config-access-map)# exit
    
     
       

    Step 3 Apply the VLAN map to VLAN 10.

    Switch(config)# vlan filter SERVER1_MAP vlan-list 10.
    
     
       

    Displaying VLAN Access Map Information

    To display information about VLAN access maps or VLAN filters, perform one of these commands:

    Command
    Purpose
    Switch# show vlan access-map [mapname]
    

    Shows information about all VLAN access maps or the specified access map.

    Switch# show vlan filter [access-map name |  
    vlan vlan-id]
    

    Shows information about all VLAN filters or about a specified VLAN or VLAN access map.

    it is a sample output of the show vlan access-map command:

    Switch# show vlan access-map
    
    Vlan access-map "map_1" 10
    
      Match clauses:
    
         ip address: ip1
    
      Action:
    
         drop
    
    Vlan access-map "map_1" 20
    
      Match clauses:
    
         mac address: mac1
    
      Action:
    
         forward
    
    Vlan access-map "map_1" 30
    
      Match clauses:
    
      Action:
    
         drop
    

    Note Sequence 30 does not have a match clause. All packets (IP as well as non-IP) are matched against it and dropped.


    it is a sample output of the show vlan filter command:

    Switch# show vlan filter 
    
    VLAN Map map_1 is filtering VLANs:
    
      20-22
    

    Using VLAN Maps with Router ACLs

    If the VLAN map has a match clause for a packet type (IP or MAC) and the packet does not match the type, the default is to drop the packet. If there is no match clause in the VLAN map, and no action is specified, the packet is forwarded if it does not match any VLAN map entry.


    Note You cannot combine VLAN maps or input router ACLs with port ACLs on a switch.


    Topics include:

    Guidelines for Using Router ACLs and VLAN Maps on the Same VLAN

    Examples of Router ACLs and VLAN Maps Applied to VLANs

    Guidelines for Using Router ACLs and VLAN Maps on the Same VLAN

    Because the switch hardware performs one lookup for each direction (input and output), you must merge a router ACL and a VLAN map when they are configured on the same VLAN. Merging the router ACL with the VLAN map can significantly increase the number of ACEs.

    When possible, try to write the ACL so that all entries have a single action except for the final, default action. You should write the ACL using one of these two forms:

    permit...
    permit...
    permit...
    deny ip any any

    or

    deny...
    deny...
    deny...
    permit ip any any

    To define multiple permit or deny actions in an ACL, group each action type together to reduce the number of entries.

    If you need to specify the full-flow mode and the ACL contains both IP ACEs and TCP/UDP/ICMP ACEs with Layer 4 information, put the Layer 4 ACEs at the end of the list. Doing this gives priority to the filtering of traffic based on IP addresses.

    Examples of Router ACLs and VLAN Maps Applied to VLANs

    These examples show how router ACLs and VLAN maps are applied on a VLAN to control the access of switched, bridged, routed, and multicast packets. Although the following illustrations show packets being forwarded to their destination, each time a packet crosses a line indicating a VLAN map or an ACL, the packet could be dropped rather than forwarded.

    ACLs and Switched Packets

    Figure 51-5 shows how an ACL processes packets that are switched within a VLAN. Packets switched within the VLAN are not processed by router ACLs.

    Figure 51-5 Applying ACLs on Switched Packets

    ACLs and Routed Packets

    Figure 51-6 shows how ACLs are applied on routed packets. For routed packets, the ACLs are applied in this order:

    1. VLAN map for input VLAN

    2. Input router ACL

    3. Output router ACL

    4. VLAN map for output VLAN

    Figure 51-6 Applying ACLs on Routed Packets

    Configuring PACLs

    This section describes how to configure PACLs, which are used to control filtering on Layer 2 interfaces. PACLs can filter traffic to or from Layer 2 interfaces based on Layer 3 information, Layer 4 head information or non-IP Layer 2 information.

    This section includes these topics:

    Creating a PACL

    PACL Configuration Guidelines

    Removing the Requirement for a Port ACL

    Webauth Fallback

    Configuring IPv4, IPv6, and MAC ACLs on a Layer 2 Interface

    Using PACL with Access-Group Mode

    Configuring Access-group Mode on Layer 2 Interface

    Applying ACLs to a Layer 2 Interface

    Displaying an ACL Configuration on a Layer 2 Interface

    Creating a PACL

    To create a PACL and apply it to one or more interfaces, follow these steps:


    Step 1 Create the standard or extended IPv4 ACLs, IPv6 ACLs, or named MAC extended ACLs that you want to apply to the interface.

    Step 2 Use the IP access-group, IPv6 traffic-filter, or mac access-group interface command to apply IPv4, IPv6, or MAC ACLs to one or more Layer 2 interfaces.


    PACL Configuration Guidelines

    When configuring PACLs, consider these guidelines:

    There can be at most one IPv4, one IPv6, and one MAC access list applied to the same Layer 2 interface per direction.

    The IPv4 access list filters only IPv4 packets, the IPv6 access list filters only IPv6 packets, and the MAC access list filters only non-IP packets.

    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
    (for example, RACL, VACL) that are configured on the system. If insufficient hardware resources to program PACL exist in hardware, the actions for input and output PACLs differ:

    For input PACLs, some packets are sent to CPU for software forwarding.

    For output PACLs, the PACL is disabled on the port.

    If insufficient hardware resources exist to program the PACL, the output PACL is not applied to the port, and you receive a warning message.

    The input ACL logging option is supported, although logging is not supported for output ACLs.

    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.

    If a PACL is removed when there are active sessions on a port, a hole (permit ip any any) is installed on the port.

    Removing the Requirement for a Port ACL

    Prior to Cisco IOS Release 12.2(54)SG, a standard port ACL was necessary if you planned to download an ACL from a AAA server. This was because ACL infrastructure was insufficient to provide dynamic creation of access control entries without associating an ACL with the port.

    Starting with Cisco IOS Release 12.2(54)SG, configuring a port ACL is not mandatory. If a port ACL is not configured on the port (by entering the ip access-group number in command), a default ACL (AUTH-DEFAULT-ACL) is attached automatically to the port when an ACL is downloaded. It allows only DHCP traffic and consists of the following ACEs:

    permit udp any range bootps 65347 any range bootpc 65348
    
    permit udp any any range bootps 65347
    
    deny    ip    any any.
    
     
       

    AUTH-DEFAULT-ACL is automatically created. To modify it, enter the following command:

    ip access-list extended AUTH-DEFAULT-ACL
    
     
       

    This ACL is not nvgened. AUTH-DEFAULT-ACL is attached provided there are sessions applying dynamic ACLs (Per-user/Filter-Id/DACL). AUTH-DEFAULT-ACL is removed when the last authenticated session with policies is cleared. It remains attached to the port provided at least one session is applying dynamic policies.

    Configuration Restrictions

    The following restrictions apply:

    Starting with Cisco IOS Release 12.2(54)SG, the port ACL does not require configuration; the default ACL is created automatically.

    Even if AUTH-DEFAULT-ACL is modified, it is not nvgened.

    Debugging Considerations

    Syslog messages appear when AUTH-DEFAULT-ACL is attached or detached from an interface provided you enter the epm logging command in configuration mode.

    The following syslog displays when the default ACL is attached:

    %EPM-6-AUTH_ACL: POLICY Auth-Default-ACL| EVENT CREATE-ATTACH-SUCCESS
    
     
       

    The following syslog displays when the ACL is detached:

    %EPM-6-AUTH_ACL: POLICY Auth-Default-ACL| EVENT DETACH-SUCCESS
    
    %EPM-6-AUTH_ACL: POLICY Auth-Default-ACL| EVENT DELETE-SUCCESS
    

    Webauth Fallback

    Many authentication methods require specific capabilities on the end-point device to respond to the network authenticating device with its identity or credentials. If the end-point lacks the required capability, the authenticator must fallback to alternative methods to gather host or user credentials. If the 802.1X/MAB authentication mechanism fails, a fallback to webauth might occur.

    Prior to Cisco IOS Release 12.2(54)SG, webauth fallback implementation required a fallback profile configured on the authenticating device. As part of this profile, an admission rule must be configured along with the access policies (the fallback ACL).

    Consider a situation where no port ACL is configured on a port. The first few hosts authenticated through 802.1X/MAB do not download any ACLs. All traffic from these hosts is allowed through. Now, suppose a host connects to the port, and there is a fallback to webauth to authenticate the host. The fallback ACL will be installed on the port, and traffic from previously authenticated hosts will also be restricted by this fallback ACL.

    Starting with Cisco IOS Release 12.2(54)SG, Cisco uses a different approach to address this issue. When a host falls back to webauth for authentication, the ACE entries in the fallback ACL are converted into entries with Host IP insertion for a host that has fallen back and will be applied until the host authenticates. Once the host successfully authenticates, the fallback ACL is removed. The resultant host ACLS will be: dynamic ACLs and Port ACL/AUTH-DEFAULT-ACL. Refer to the previous section for an explanation of AUTH-DEFAULT -ACL.

    Configuring IPv4, IPv6, and MAC ACLs on a Layer 2 Interface


    Note Only IPv4, IPv6 and MAC ACLs can be applied to Layer 2 physical interfaces.


    Standard (numbered, named), Extended (numbered, named) IP ACLs, and Extended Named MAC ACLs are also supported.

    To apply IPv4 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.

    Step 3 

    Switch(config-if)# [no] {ip | mac} 
    access-group {name | number} {in | out}
    

    Applies numbered or named ACL to the Layer 2 interface. The no form deletes the IP or MAC ACL from the Layer 2 interface.

    Step 4 

    Switch(config)# show running-config
    

    Displays the access list configuration.

    To apply IPv6 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.

    Step 3 

    Switch(config-if)# [no] ipv6 traffic-filter 
    name {in | out}
    

    Applied the specified IPv6 ACL to the Layer 2 interface. The no form deletes the IPv6 ACL from the Layer 2 interface.

    Step 4 

    Switch(config)# show running-config
    

    Displays the access list configuration.

    The following 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)# interface Gi3/1
    
    Switch(config-if)# ip access-list extended simple-ip-acl 
    
    Switch(config-ext-nacl)# permit tcp any any
    
    Switch(config-ext-nacl)# end
    
     
       

    The following example shows how to configure the Extended Named MACL simple-mac-acl to permit source host 000.000.011 to any destination host:

    Switch(config)# interface Gi3/1
    
    Switch(config-if)# mac access-list extended simple-mac-acl
    
    Switch(config-ext-macl)# permit host 000.000.011 any
    
    Switch(config-ext-macl)# end
    

    Using PACL with Access-Group Mode

    You can use the access group mode to change the way PACLs interact with other ACLs. For example, if a Layer 2 interface belongs to VLAN100, VACL (VLAN filter) V1 is applied on VLAN100, and PACL P1 is applied on the Layer 2 interface. In this situation, you must specify how P1 and V1 impact the traffic with the Layer 2 interface on VLAN100. In a per-interface method, you can use the access-group mode command to specify one of the following desired modes:

    prefer port modeIf PACL is configured on a Layer 2 interface, then PACL takes effect and overwrites the effect of other ACLs (Router ACL and VACL). If no PACL feature is configured on the Layer 2 interface, other features applicable to the interface are merged and applied on the interface. it is the default access group mode.

    prefer VLAN modeVLAN-based ACL features take effect on the port if they have been applied on the port and no PACLs are in effect. If no VLAN-based ACL features are applicable to the Layer 2 interface, then the PACL feature already on the interface is applied.

    merge modeMerges applicable ACL features before they are programmed into the hardware.

    Configuring Access-group Mode on Layer 2 Interface

    To configure an 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.

    Step 3 

    Switch(config-if)# [no] access-group mode  
    {prefer {port | vlan} | merge}
    

    Applies numbered or named ACL to the Layer 2 interface. The no form deletes the IP or MAC ACL from the Layer 2 interface.

    Step 4 

    Switch(config)# show running-config
    

    Displays the access list configuration.

    This example shows how to merge and apply features other than PACL on the interface:

    Switch# configure terminal
    
    Switch(config)# interface fast 6/1
    
    Switch(config-if)# access-group mode prefer port
    
     
       

    This example shows how to merge applicable ACL features before they are programmed into hardware:

    Switch# configure terminal
    
    Switch(config)# interface fast 6/1
    
    Switch(config-if)# access-group mode merge
    

    Applying ACLs to a Layer 2 Interface

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

    Command
    Purpose
    Switch(config-if)# ip access-group ip-acl {in | out}
    

    Applies an IPv4 ACL to the Layer 2 interface.

    Switch(config-if)# ipv6 traffic-filter ipv6-acl {in | out}
    

    Applies an IPv6 ACL to the Layer 2 interface.

    Switch(config-if)# mac access-group mac-acl {in | out}
    

    Applies a MAC ACL to the Layer 2 interface.

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

    Switch# configure terminal
    
    Switch(config)# interface fast 6/1
    
    Switch(config-if)# ip access-group simple-ip-acl in
    
     
       

    This example applies the IPv6 ACL simple-ipv6-acl to interface FastEthernet 6/1 ingress traffic:

    Switch# configure terminal
    
    Switch(config)# interface fast 6/1
    
    Switch(config-if)# ipv6 traffic-filter simple-ipv6-acl in
    
     
       

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

    Switch# configure terminal
    
    Switch(config)# interface fast 6/1
    
    Switch(config-if)# mac access-group simple-mac-acl out
    

    Displaying an ACL Configuration on a Layer 2 Interface

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

    Command
    Purpose
    Switch# show ip 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
    

    Using PACL with VLAN Maps and Router ACLs

    For PACLs, the interaction with Router ACLs and VACLs depends on the interface access group mode as shown in Table 51-1.

    Table 51-1 Interaction between PACLs, VACLs, and Router ACLs

    ACL Type(s)
    Input PACL
     

    prefer port mode

    prefer vlan mode

    merge mode

    1. Input Router ACL

    PACL applied

    Input Router ACL applied

    PACL, Input Router ACL (merged) applied in order (ingress)

    2. VACL

    PACL applied

    VACL applied

    PACL, VACL (merged) applied in order (ingress)

    3. VACL + Input Router ACL

    PACL applied

    VACL + Input Router ACL applied

    PACL, VACL, Input Router ACL (merged) applied in order (ingress)


    Each ACL type listed in Table 51-1 corresponds with these scenarios:

    Scenario 1: Host A is connected to an interface in VLAN 20, which has an SVI configured. The interface has input PACL configured, and the SVI has input Router ACL configured as shown in Figure 51-7:

    Figure 51-7 Scenario 1: PACL Interaction with an Input Router ACL

    If the interface access group mode is prefer port, then only the input PACL is applied on the ingress traffic from Host A. If the mode is prefer VLAN, then only the input Router ACL is applied to ingress traffic from Host A that requires routing. If the mode is merge, then the input PACL is first applied to the ingress traffic from Host A, and the input Router ACL is applied on the traffic that requires routing.

    Scenario 2: Host A is connected to an interface in VLAN 10, which has a VACL (VLAN Map) configured and an input PACL configured as shown in Figure 51-8:

    Figure 51-8 Scenario 2: PACL Interaction with a VACL

    If the interface access group mode is prefer port, then only the input PACL is applied on the ingress traffic from Host A. If the mode is prefer VLAN, then only the VACL is applied to the ingress traffic from Host A. If the mode is merge, the input PACL is first applied to the ingress traffic from Host A, and the VACL is applied on the traffic.

    Scenario 3: Host A is connected to an interface in VLAN 10, which has a VACL and an SVI configured. The SVI has an input Router ACL configured and the interface has an input PACL configured, as shown in Figure 51-9:

    Figure 51-9 Scenario 3: VACL and Input Router ACL

    If the interface access group mode is prefer port, then only the input PACL is applied on the ingress traffic from Host A. If the mode is prefer VLAN, then the merged results of the VACL and the input Router ACL are applied to the ingress traffic from Host A. If the mode is merge, the input PACL is first applied to the ingress traffic from Host A, the VACL is applied on the traffic and finally, and the input Router ACL is applied to the traffic that needs routing. (that is, the merged results of the input PACL, VACL, and input Router ACL are applied to the traffic).

    Configuring RA Guard

    This section includes these topics:

    Introduction

    Deployment

    Configuring RA Guard

    Examples

    Usage Guidelines

    Introduction

    When deploying IPv6 networks, routers are configured to use IPv6 Router Advertisements to convey configuration information to hosts onlink. Router Advertisement is a critical part of the autoconfiguration process. The conveyed information includes the implied default router address obtained from the observed source address of the Router-Advertisement (RA) message. However, in some networks, invalid RAs are observed. This may happen because of misconfigurations or a malicious attacks on the network.

    Devices acting as rogue routers may send illegitimate RAs.When using IPv6 within a single Layer 2 network segment, you can enable Layer 2 devices to drop rogue RAs before they reach end-nodes.

    Beginning with Cisco IOS Release 54(SG)SG on Supervisor Engine 6-E (and 6L-E); Cisco IOS XE Release 3.3.0SG on Supervisor Engine 7-E; and Cisco IOS XE Release 3.2.0XO on Supervisor Engine 7L-E, Catalyst 4500 Series Switch supports RA Guard. This feature examines incoming Router-Advertisement and Router-Redirect packets and decides whether to switch or block them based solely on information found in the message and in the Layer 2 device configuration.

    You can configure RA Guard in two modes (host and router) based on the device connected to the port.

    Host mode—All the Router-Advertisement and Router-Redirect messages are disallowed on the port.

    Router mode—All messages (RA/RS/Redirect) are allowed on the port; only host mode is supported.

    You can configure Catalyst 4500 host ports to allow or disallow RA messages. Once a port is configured to disallow the Router-Advertisement and Router-Redirect packets, it filters the content of the received frames on that port and blocks Router-Advertisement or Router-Redirect frames.

    When RA Guard is configured on a port, the following packets are dropped in hardware:

    Router-Advertisement packets —IPv6 ICMP packets with ICMP type = 134

    Router-Redirect packets—IPv6 ICMP packets with ICMP type = 137

    Per port RA Guard ACL statistics are supported and displayed when you enter a show ipv6 snooping counters interface command. The statistics output displays the number of packets that have been dropped per port due to the RA Guard.


    Note Beginning with Cisco IOS Release 15.0(2)SG, per port RA Guard ACL statistics are supported and displayed when you enter a show ipv6 snooping counters interface command. (Previous to this release, you enter the show ipv6 first-hop counters interface command.)


    Deployment

    Figure 51-10 illustrates a deployment scenario for RA Guard. We drop RA packets from ports that are connected to hosts and permit RA packets from ports connected to the Router.

    Figure 51-10 Typical RA Guard Deployment

    Configuring RA Guard

    To configure RA Guard, perform this step:

     
    Command
    Purpose

    Step 1 

    Switch# configure terminal
    

    Enters global configuration mode.

    Step 1 

    Switch(config)# interface interface
    

    Enters interface mode.

    Step 2 

    Switch(config-if)# [no] ipv6 nd 
    raguard
    

    Enables RA Guard on the switch.

    Step 3 

    Switch(config-if)# end
    

    Returns to privileged EXEC mode.

    Step 4 

    Switch# show ipv6 first-hop 
    policies interface
    

    Shows the list of interfaces on which RA Guard has been enabled. The interface option allows you to determine whether RA Guard is configured on an interface.

    Step 5 

    Switch# show ipv6 first-hop 
    counters interface
    

    Shows the number of packets dropped per port due to RA Guard. The counters can be displayed for a particular interface by using the interface option.

    Note If counters are not enabled for the port, the counter value is zero.

    Step 6 

    Switch# clear ipv6 snooping 
    counters interface
    

    Clears RA Guard counters on a particular interface.

    The counters on all interfaces are cleared if the interface option is absent.

    Examples

    This examples shows how to enable RA Guard on the switch:

    Switch(config)# int gi1/1
    
    Switch(config-if)# ipv6 nd raguard
    
    Switch(config-if)# end
    
    Switch# show running-configuration interface gi1/1
    
     
       
    Building configuration...
    
     
       
    Current configuration : 53 bytes
    
     
       
    !
    
     
       
    interface GigabitEthernet1/1
    
     
       
     ipv6 nd raguard
    
     
       
    end
    
     
       

    The following example shows a sample output of the show ipv6 commands:

    Switch# show ipv6 snooping counters int gi 2/48
    
    Received messages on Gi2/48:
    
    Protocol        Protocol message
    
    ICMPv6          RS         RA         NS         NA         REDIR      CPS        CPA
    
                    0          0          0          0          0          0          0
    
     
       
    Bridged messages from Gi2/48:
    
    Protocol        Protocol message
    
    ICMPv6          RS         RA         NS         NA         REDIR      CPS        CPA
    
                    0          0          0          0          0          0          0
    
     
       
    Dropped messages on Gi2/48:
    
    Feature/Message RS         RA         NS         NA         REDIR      CPS        CPA
    
     
       
    Dropped reasons on Gi2/48:
    
    Switch#
    

    Note Beginning with Cisco IOS Release 15.0(2)SG, per port RA Guard ACL statistics are supported and displayed when you enter a show ipv6 snooping counters interface command. (Previous to this release, you enter the show ipv6 first-hop counters interface command.)



    Note Be aware that only RA (Router Advertisement) and REDIR (Router Redirected packets) counters are supported in 12.2(54)SG.


    Switch# show ipv6 first-hop policies
    
    RA guard policies configured: 
    
     
       
    Policy            Interface    Vlan 
    
    ------            ---------    ---- 
    
    default           Gi2/48       all 
    
     
       
    Switch#
    

    Usage Guidelines

    Observe the following restrictions:

    It is an ingress feature; only IPv6 Router-Advertisement and Router-Redirect packets entering through the port are filtered.

    RA Guard does not offer protection in environments where IPv6 traffic is tunneled.

    This feature is supported only in hardware; packets are not punted to software except under resource exhaustion (for example, TCAM memory exhaustion).

    RA Guard is purely an Layer 2 port based feature and can be configured only on switchports. It works irrespective of whether IPv6 routing is enabled. It is not supported on router interfaces and VLANs.

    RA Guard is supported on trunk ports; filtering is performed on packets arriving from all the allowed VLANs.

    RA Guard is supported on EtherChannel; the RA Guard configuration (whether present or not) on the EtherChannel overrides the RA Guard configuration on the member ports.

    RA Guard is supported on ports that belong to PVLANs (for example, isolated secondary host ports, community secondary host ports, promiscuous primary host ports, (primary/secondary) trunk ports. Primary VLAN features are inherited and merged with port features.

    Because of hardware limitations, it may not be possible for Catalyst 4900M, Catalyst 4948E, Catalyst 4948L-E, Supervisor Engine 6-E, Supervisor Engine 6L-E, Supervisor Engine 7-E and Supervisor Engine 7L-E to collect statistics for RA Guard in hardware. If so, an error message is displayed.

    The show ipv6 snooping counter interface command displays the estimated counters.


    Note Beginning with Cisco IOS Release 15.0(2)SG, per port RA Guard ACL statistics are supported and displayed when you enter a show ipv6 snooping counters interface command. (Previous to this release, you enter the show ipv6 first-hop counters interface command.)