-
Catalyst 6500 Series Software Configuration Guide, 6.3 and 6.4
-
Product Overview
-
Command-Line Interfaces
-
Configuring the Switch IP Address and Default Gateway
-
Configuring Ethernet, Fast Ethernet, and Gigabit Ethernet Switching
-
Configuring Ethernet VLAN Trunks
-
Configuring EtherChannel
-
Configuring IEEE 802.1Q Tunneling
-
Configuring Spanning Tree
-
Configuring Spanning Tree PortFast, UplinkFast, BackboneFast, and Loop Guard
-
Configuring VTP
-
Configuring VLANs
-
Configuring InterVLAN Routing
-
Configuring CEF for PFC2
-
Configuring MLS
-
Configuring NDE
-
Configuring Access Control
-
Configuring GVRP
-
Configuring Dynamic Port VLAN Membership with VMPS
-
Checking Port Status and Connectivity
-
Administering the Switch
-
Configuring Switch Access Using AAA
-
Configuring Redundancy
-
Modifying the Switch Boot Configuration
-
Working With the Flash File System
-
Working with System Software Images
-
Working with Configuration Files
-
Configuring System Message Logging
-
Configuring DNS
-
Configuring CDP
-
Configuring UDLD
-
Configuring NTP
-
Configuring Broadcast Suppression
-
Configuring Layer 3 Protocol Filtering
-
Configuring the IP Permit List
-
Configuring Port Security
-
Configuring SNMP
-
Configuring RMON
-
Configuring SPAN and RSPAN
-
Using Switch TopN Reports
-
Configuring Multicast Services
-
Configuring QoS
-
Configuring a VoIP Network
-
Configuring ASLB
-
Configuring the Switch Fabric Modules
-
Table Of Contents
Handling Fragmented and Unfragmented Traffic
Applying Cisco IOS ACLs and VACLs on VLANs
Using Cisco IOS ACLs in your Network
Hardware and Software Handling of Cisco IOS ACLs with PFC
Hardware and Software Handling of Cisco IOS ACLs with PFC2
Using VACLs with Cisco IOS ACLs
Guidelines for Configuring Cisco IOS ACLs and VACLs on the Same VLAN Interface
Using the Implicit Deny Action
Limiting the Number of Actions
Avoiding Layer 4 Port Information
Guidelines for Using Layer 4 Operations
Determining Layer 4 Operation Usage
Determining Logical Operation Unit Usage
Redirecting Broadcast Traffic to a Specific Server Port
Restricting the DHCP Response for a Specific Server
Denying Access to a Server on Another VLAN
Configuring ACLs on Private VLANs
Configuring VACLs From the CLI
Creating an IP VACL and Adding ACEs
Creating an IPX VACL and Adding ACEs
Creating a Non-IP Version 4/Non-IPX VACL (MAC VACL) and Adding ACEs
Showing the Contents of a VACL
Removing ACEs from Security ACLs
Displaying VACL Management Information
Capturing Traffic Flows on Specified Ports
Configuring and Storing VACLs and QoS ACLs in Flash Memory
Automatically Moving the VACL and QoS ACL Configuration to Flash Memory
Manually Moving the VACL and QoS ACL Configuration to Flash Memory
Running with the VACL and QoS ACL Configuration in Flash Memory
Moving the VACL and QoS ACL Configuration Back to NVRAM
Redundancy Synchronization Support
Interacting with High Availability
Configuring Policy-Based Forwarding
Understanding How Policy-Based Forwarding Works
Hardware and Software Requirements
Configuring Policy-Based Forwarding
Enabling PBF and Specifying a MAC Address for the PFC2
Rolling Back Adjacency Table Entries in the Edit Buffer
Policy-Based Forwarding Configuration Example
Configuring Access Control
This chapter describes how to configure access control lists (ACLs) on the Catalyst 6000 family switches. Configuration of the ACLs depends on the type of hardware you install on your supervisor engine. See the "Hardware Requirements" section for details.
Note
For complete syntax and usage information for the commands used in this chapter, refer to the Catalyst 6000 Family Command Reference publication.
This chapter consists of these sections:
•
•
•
•
•
Note
Understanding How ACLs Work
Traditionally, switches operated at Layer 2 only; switches switched traffic within a VLAN and routers routed traffic between VLANs. Catalyst 6000 family switches with the Multilayer Switch Feature Card (MSFC) can accelerate packet routing between VLANs by using Layer 3 switching (Multilayer Switching [MLS]). The switch first bridges the packet, the packet is then routed internally without going to the router, and then the packet is bridged again to send it to its destination. During this process, the switch can access control all packets it switches, including packets bridged within a VLAN.
Cisco IOS ACLs provide access control for routed traffic between VLANs, and VLAN ACLs (VACLs) provide access control for all packets.
Standard and extended Cisco IOS ACLs are used to classify packets. Classified packets can be subject to a number of features such as access control (security), encryption, policy-based routing, and so on. Standard and extended Cisco IOS ACLs are only configured on router interfaces and applied on routed packets.
VACLs can provide access control based on Layer 3 addresses for IP and IPX protocols. Unsupported protocols are access controlled through MAC addresses. A VACL is applied to all packets (bridged and routed) and can be configured on any VLAN interface. Once a VACL is configured on a VLAN, all packets (routed or bridged) entering the VLAN are checked against the VACL. Packets can either enter the VLAN through a switch port or through a router port after being routed.
Hardware Requirements
The hardware that is required to configure ACLs on Catalyst 6000 family switches is as follows:
•
–
–
•
–
–
Note
Supported ACLs
These sections describe the ACLs supported by the Catalyst 6000 family switches:
QoS ACLs
You can configure QoS ACLs on the switch; see Chapter 41, "Configuring QoS."
Cisco IOS ACLs
Cisco IOS ACLs are configured on the MSFC VLAN interfaces. An ACL provides access control and consists of an ordered set of access control entries (ACEs). Many other features in Cisco IOS software also use ACLs for specifying flows. For example, Web Cache Redirect (through the Web Cache Coordination Protocol [WCCP]) uses ACLs to specify HTTP flows that can be redirected to a Web cache engine.
Most Cisco IOS features are applied on interfaces for specific directions (inbound versus outbound). However, some features use ACLs globally. For such features, ACLs are applied on all interfaces for a given direction. As an example, TCP intercept uses a global ACL that is applied on all interfaces for outbound direction.
One Cisco IOS ACL can be used with multiple features for a given interface, and one feature can use multiple ACLs. When a single ACL is used by multiple features, Cisco IOS software examines it multiple times.
Cisco IOS software examines ACLs that are associated with features that are configured on a given interface and a direction. As packets enter the router on a given interface, Cisco IOS software examines ACLs that are associated with all inbound features that are configured on that interface for the following:
•
•
•
•
After packets are routed and before they are forwarded out to the next hop, Cisco IOS examines all ACLs that are associated with the outbound features that are configured on the egress interface for the following:
•
•
•
•
•
VACLs
The following sections describe VACLs:
•
VACL Overview
VACLs can access control all traffic. You can configure VACLs on the switch to apply to all packets that are routed into or out of a VLAN or are bridged within a VLAN. VACLs are strictly for security packet filtering and redirecting traffic to specific physical switch ports. Unlike Cisco IOS ACLs, VACLs are not defined by direction (input or output).
You can configure VACLs on Layer 3 addresses for IP and IPX. All other protocols are access controlled through MAC addresses and Ethertype using MAC VACLs.
Caution
You can enforce VACLs only on packets going through the Catalyst 6000 family switch; you cannot enforce VACLs on traffic between hosts on a hub or another switch connected to the Catalyst 6000 family switch.
ACEs Supported in VACLs
A VACL contains an ordered list of access control entries (ACEs). Each VACL can contain ACEs of only one type. Each ACE contains a number of fields that are matched against the contents of a packet. Each field can have an associated bit mask to indicate which bits are relevant. An action is associated with each ACE that describes what the system should do with the packet when a match occurs. The action is feature dependent. Catalyst 6000 family switches support three types of ACEs in the hardware:
•
•
•
Table 16-1 lists the parameters associated with each ACE type.
Table 16-1 ACE Types and Parameters
Layer 4 parameters
Source port
Source port operator
Destination port
Destination port operator
ICMP code1
N/A
ICMP type
N/A
Layer 3 parameters
IP ToS byte
IP ToS byte
IP ToS byte
IP source address
IP source address
IP source address
IPX source network
IP destination address
IP destination address
IP destination address
IPX destination network
IPX destination node
TCP or UDP
ICMP
Other protocol
IPX packet type
Layer 2 parameters
Ethertype
Ethernet source address
Ethernet destination address
1 IP ACEs.
2 For Ethernet packets that are not IP version 4 or IPX.
Handling Fragmented and Unfragmented Traffic
TCP/UDP or any Layer 4 protocol traffic, when fragmented, loses the Layer 4 information (Layer 4 source/destination ports). This situation makes it difficult to enforce security based on the application. However, you can identify fragments and distinguish them from the rest of the TCP/UDP traffic.
Layer 4 parameters of ACEs can filter unfragmented traffic and fragmented traffic with fragments that have offset 0. IP fragments that have an offset other than 0 miss the Layer 4 port information and cannot be filtered. The following examples show how ACEs handle packet fragmentation.
This example shows that if the traffic from 1.1.1.1 port 68 is fragmented, only the first fragment goes to port 4/3, and the rest of the traffic from port 68 does not hit this entry.
redirect 4/3 tcp host 1.1.1.1 eq 68 host 255.255.255.255This example shows that the traffic coming from 1.1.1.1 port 68 and going to 2.2.2.2 port 34 is permitted. If packets are fragmented, the first fragment hits this entry and is permitted; fragments that have an offset other than 0 are also permitted as a default result for fragments.
permit tcp host 1.1.1.1 eq 68 host 2.2.2.2 eq 34This example shows that the fragment that has offset 0 of the traffic from 1.1.1.1 port 68 going to 2.2.2.2 port 34 is denied. The fragments that have an offset other than 0 are permitted as a default.
deny tcp host 1.1.1.1 eq 68 host 2.2.2.2 eq 34In releases prior to software release 6.1(1), the fragment filtering was completely transparent; you would type an ACE such as permit tcp .... port eq port_number and the software would implicitly install the following ACE at the top of the ACL: permit tcp any any fragments.
In software release 6.1(1) and later releases, there is a fragment option. If you do not specify the fragment keyword, the behavior is the same as in previous releases. If you specify the fragment keyword, the system does not automatically install a global permit statement for fragments. This keyword allows you to control how fragments are handled.
In this example, 10.1.1.2 is configured to serve HTTP connections. If you do not use a fragment ACE, all the fragments for TCP traffic are permitted as the permit tcp any any fragments ACE is added automatically at the top of the ACL as follows:
permit tcp any any fragments1.
2.
3.
In the above example if you change entry 1 as follows:
1. deny tcp any host 10.1.1.2 eq www
there will not be a permit tcp any any fragments ACE added at the top of ACL. If the entry is a deny statement, the next access-list entry is processed.
Note
When you specify the fragment keyword, the system does not install the global permit TCP or UDP fragments statement. When you specify the fragment keyword for at least one ACE, the software implicitly installs ACEs to permit flows to a specific IP address (or subnet) that you specify.
In this ACL example, the deny tcp any host 10.1.1.2 fragment entry stops fragmented traffic going to all TCP ports on host 10.1.1.2. Later in the ACL, the permit udp any host 10.1.1.2 eq 69 entry allows clients to connect to the TFTP server 10.1.1.2. The system automatically installs a permit for all fragments of udp traffic to host 10.1.1.2 ACE; otherwise, fragments would be denied by the entry deny ip any host 10.1.1.2.
1.
2.
3.
4.
5.
6.
If you explicitly want to stop fragmented UDP traffic to host 10.1.1.2, enter deny udp any host 10.1.1.2 fragment before entry number 3 as shown in this example:
[...]
3.
4.
5.
[...]
Applying Cisco IOS ACLs and VACLs on VLANs
This section describes how to apply Cisco IOS ACLs and VACLs to the VLAN for bridged packets, routed packets, and multicast packets.
These sections show how ACLs and VACLs are applied:
Bridged Packets
Figure 16-1 shows how an ACL is applied on bridged packets. For bridged packets, only Layer 2 ACLs are applied to the input VLAN.
Figure 16-1 Applying ACLs on Bridged Packets
Routed Packets
Figure 16-2 shows how ACLs are applied on routed/Layer 3-switched packets. For routed/Layer 3-switched packets, the ACLs are applied in the following order:
1.
2.
3.
4.
Figure 16-2 Applying ACLs on Routed Packets
Multicast Packets
Figure 16-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.
a.
b.
2.
a.
b.
3.
a.
Figure 16-3 Applying ACLs on Multicast Packets
Using Cisco IOS ACLs in your Network
Note
When a feature is configured on the router to process traffic (such as NAT), the Cisco IOS ACL associated with the feature determines the specific traffic that is bridged to the router instead of being Layer 3 switched. The router then applies the feature and routes the packet normally. Note that there are some exceptions to this process as described in the "Hardware and Software Handling of Cisco IOS ACLs with PFC" section.
Note
Caution
For PFC2: If IP unreachables or IP redirect is enabled on an interface, the deny is performed in hardware although a small number of packets are sent to the MSFC2 to generate the appropriate ICMP-unreachable messages.
These sections describe hardware and software handling of ACLs with PFC and PFC2:
•
•
Hardware and Software Handling of Cisco IOS ACLs with PFC
This section describes hardware and software handling of Cisco IOS ACLs with the PFC.
Note
ACL feature processing requires forwarding of some flows by the software. The forwarding rate for software-forwarded flows is substantially less than for hardware-forwarded flows. Flows that require logging as specified by the ACL are handled in the software without impacting non-log flow forwarding in the hardware.
Note
Note
These sections describe how different types of ACLs and traffic flows are handled by the hardware and the software:
•
•
Security Cisco IOS ACLs
The IP and IPX security Cisco IOS ACLs with PFC are as follows:
•
•
•
•
•
•
•
Reflexive ACLs
Up to 512 simultaneous reflexive sessions are supported in the hardware. Note that when reflexive ACLs are applied, the flow mask is changed to VLAN-full flow.
TCP Intercept
The TCP intercept feature implements software to protect TCP servers from TCP SYN-flooding attacks, which are a type of denial-of-service attack. The TCP intercept feature helps prevent SYN-flooding attacks by intercepting and validating TCP connection requests. In intercept mode, the TCP intercept software intercepts TCP synchronization (SYN) packets from clients to servers that match an extended access list. The software establishes a connection with the client on behalf of the destination server, and if successful, establishes the connection with the server on behalf of the client and binds the two half-connections together transparently. This process ensures that connection attempts from unreachable hosts never reach the server. The software continues to intercept and forward packets throughout the duration of the connection.
Policy Routing
Policy routing-required flows are handled in the software without impacting non-policy routed flow forwarding in the hardware. When a route map contains multiple "match" clauses, all conditions imposed by these match clauses must be met before a packet is policy routed. However, for route maps containing both "match ip address" and "match length," all traffic matching the ACL in the "match ip address" clause is forwarded to the software regardless of the match length criteria. For route maps that only contain match length clauses, all packets received on the interface are forwarded to the software.
When you enable hardware policy routing using the mls ip pbr global command, all policy routing occurs in the hardware.
Caution
WCCP
HTTP requests subject to Web Cache Coordination Protocol (WCCP) redirection are handled in the software; HTTP replies from the server and the Cache Engine are handled in the hardware.
NAT
NAT-required flows are handled in the software without impacting non-NAT flow forwarding in the hardware.
Unicast RPF Check
The unicast RPF feature is supported in hardware on the PFC. For ACL-based RPF checks, traffic denied by the unicast RPF ACL is forwarded to the MSFC for RPF validation.
Caution
Note
Bridge-Groups
Cisco IOS bridge-group ACLs are handled in the software.
Hardware and Software Handling of Cisco IOS ACLs with PFC2
This section describes hardware and software handling of Cisco IOS ACLs with the PFC2.
ACL feature processing requires forwarding some flows to the software. The forwarding rate for software-forwarded flows is substantially less than for hardware-forwarded flows. Flows that require logging as specified by the ACL, are handled in the software without impacting non-log flow forwarding in the hardware.
Note
Note
These sections describe how different types of ACLs and traffic flows are handled by the hardware and the software in systems with PFC2:
•
•
Security Cisco IOS ACLs
The IP and IPX security Cisco IOS ACLs with PFC2 are as follows:
•
•
•
•
•
•
•
Reflexive ACLs
ICMP packets are handled in the software. For TCP/UDP flows, once the flow is established, they are handled in hardware. Note that when reflexive ACLs are applied, the flow mask is changed to VLAN-full flow.
TCP Intercept
The TCP intercept feature implements software to protect TCP servers from TCP SYN-flooding attacks, which are a type of denial-of-service attack. The TCP intercept feature helps prevent SYN-flooding attacks by intercepting and validating TCP connection requests. In intercept mode, the TCP intercept software intercepts TCP synchronization (SYN) packets from clients to servers that match an extended access list. The software establishes a connection with the client on behalf of the destination server, and if successful, establishes the connection with the server on behalf of the client and binds the two half-connections together transparently. This process ensures that connection attempts from unreachable hosts never reach the server. The software continues to intercept and forward packets throughout the duration of the connection.
The hardware support for TCP intercept on a PFC2 is as follows:
1.
2.
a.
b.
3.
Policy Routing
Policy routing-required flows are handled in hardware or software depending on the route map. If the route map contains only a "match ip address" and the "set" clause contains the "next hop" and the next hop is reachable, then the packet is forwarded in hardware. When a route map contains multiple "match" clauses, all conditions imposed by these match clauses must be met before a packet is policy routed. However, for route maps containing both a match ip address and match length, all traffic matching the ACL in the match ip address clause is forwarded to the software regardless of the match length criteria. For route maps that only contain match length clauses, all packets received on the interface are forwarded to the software.
Note
WCCP
HTTP requests subject to WCCP redirection are handled in the software; HTTP replies from the server and the Cache Engine are handled in the hardware.
NAT
NAT-required flows are handled in the software without impacting non-NAT flow forwarding in the hardware.
Unicast RPF Check
The unicast RPF feature is supported in hardware on the PFC2. For ACL-based RPF checks, traffic denied by the unicast RPF ACL is forwarded to the MSFC2 for RPF validation.
Caution
Note
Bridge-Groups
Cisco IOS bridge-group ACLs are handled in the software.
Using VACLs with Cisco IOS ACLs
To access control both bridged and routed traffic, you can use VACLs only or a combination of Cisco IOS ACLs and VACLs. You can define Cisco IOS ACLs on both input and output routed-VLAN interfaces, and you can define a VACL to access control the bridged traffic.
If a flow matches a VACL deny or redirect clause in the ACL, irrespective of the IOS ACL configuration, the flow is denied or redirected. The following caveats apply to IOS ACLs when used with VACLs:
•
•
Note
These sections describe Cisco IOS ACL and VACL configuration guidelines and guidelines for Layer 4 operations:
•
•
Guidelines for Configuring Cisco IOS ACLs and VACLs on the Same VLAN Interface
Follow these guidelines when you need to configure a Cisco IOS ACL and a VACL on the same VLAN. These guidelines do not apply to configurations where you are mapping Cisco IOS ACLs and VACLs on different VLANs.
The Catalyst 6000 family switch hardware provides one lookup for security ACLs for each direction (input and output); you must merge a Cisco IOS ACL and a VACL when they are configured on the same VLAN. Merging the Cisco IOS ACL with the VACL might significantly increase the number of ACEs.
If you must configure a Cisco IOS ACL and a VACL on the same VLAN, use the following guidelines for both Cisco IOS ACL and VACL configuration.
Note
These sections provide Cisco IOS ACL and VACL configuration guidelines and examples:
•
•
•
Using the Implicit Deny Action
If possible, use the implicit deny action at the end of an ACL (deny any any) and define ACEs to permit only allowed traffic. You can achieve this same effect by defining all the deny entries, and at the end of the list specifying permit ip any any (see Example 1).
Grouping Actions Together
To define multiple actions in an ACL (permit, deny, redirect), group each action type together. Example 3 shows what can happen when you do not group each type together. In the example, the deny action in line 6 was grouped with permit actions. If this deny action is removed, the result of merging would be 53 entries, instead of 329.
Limiting the Number of Actions
An ACL with only permit ACEs has two actions: permit and deny (because of the implicit deny at the end of the list). An ACL with permit and redirect has three actions: permit, redirect, and deny (because of the implicit deny at the end of the list).
When configuring an ACL, the best merge results are obtained when you specify only two different actions: permit and deny, redirect and permit, or redirect and deny.
To specify a redirect and deny ACL, do not use any permit ACEs. To specify a redirect and permit ACL, use permit ACEs, redirect ACEs, and for the last ACE, specify permit ip any any. If you specify permit ip any any, you will override the implicit deny ip any at the end of the list (see Example 4).
Avoiding Layer 4 Port Information
Avoid including Layer 4 information in an ACL; adding this information will complicate the merging process. You will obtain the best merge results if the ACLs are filtered based on IP addresses (source and destination) and not on the full flow (source IP address, destination IP address, protocol, and protocol ports).
If you need to specify the full flow, see the recommendations in the "Using the Implicit Deny Action" section, "Grouping Actions Together" section, and Example 6. If you cannot follow the recommendations because the ACL has both IP and TCP/UDP/ICMP ACEs with Layer 4 information, put the Layer 4 ACEs at the end of the list to prioritize the traffic filtering based on IP addresses.
Estimating Merge Results
If you follow the ACL guidelines when configuring ACLs, you can get a rough estimate of the merge results for ACLs.
The following example uses ACL A, ACL B, and ACL C. If ACL C is the result of merging ACL A and ACL B, and you know the size of ACL A and ACL B, you can estimate the upper limit of the size of ACL C when no Layer 4 port information has been specified on ACL A and ACL B, as follows:
size of ACL C = (size of ACL A) x (size of ACL B) x (2)
If Layer 4 port information was specified, the upper limit could be higher.
Examples
These examples show the merge results for various Cisco IOS ACL and VACL configurations. Note that in these examples, one VACL and one Cisco IOS ACL are configured on the same VLAN.
Example 1
This example shows that the VACL does not follow the recommended guidelines (see line 9) and the resultant merge increases the number of ACEs:
******** VACL ***********1 permit udp host 194.72.72.33 194.72.6.160 0.0.0.152 permit udp host 147.150.213.94 194.72.6.64 0.0.0.15 eq bootps3 permit udp 194.73.74.0 0.0.0.255 host 194.72.6.205 eq syslog4 permit udp host 167.221.23.1 host 194.72.6.198 eq tacacs5 permit udp 194.72.136.1 0.0.3.128 194.72.6.64 0.0.0.15 eq tftp6 permit udp host 193.6.65.17 host 194.72.6.205 gt 10237 permit tcp any host 194.72.6.528 permit tcp any host 194.72.6.52 eq 1139 deny tcp any host 194.72.6.51 eq ftp10 permit tcp any host 194.72.6.51 eq ftp-data11 permit tcp any host 194.72.6.5112 permit tcp any eq domain host 194.72.6.5113 permit tcp any host 194.72.6.51 gt 102314 permit ip any host 1.1.1.1******** IOS ACL ************1 deny ip any host 239.255.255.2552 permit ip any any******** MERGE **********has 91 entries entriesExample 2
In Example 1, if you follow the guidelines and remove line 9 and modify lines 11 and 12, you get the following equivalent ACL with improved merge results (note that a deny ACE is not specified):
******** VACL **********1 permit udp host 194.72.72.33 194.72.6.160 0.0.0.152 permit udp host 147.150.213.94 194.72.6.64 0.0.0.15 eq bootps3 permit udp 194.73.74.0 0.0.0.255 host 194.72.6.205 eq syslog4 permit udp host 167.221.23.1 host 194.72.6.198 eq tacacs5 permit udp 194.72.136.1 0.0.3.128 194.72.6.64 0.0.0.15 eq tftp6 permit udp host 193.6.65.17 host 194.72.6.205 gt 10237 permit tcp any host 194.72.6.528 permit tcp any host 194.72.6.52 eq 1139 permit tcp any host 194.72.6.51 eq ftp-data10 permit tcp any host 194.72.6.51 neq ftp11 permit tcp any eq domain host 194.72.6.51 neq ftp12 permit tcp any host 194.72.6.51 gt 102313 permit ip any host 1.1.1.1******** IOS ACL ************1 deny ip any host 239.255.255.2552 permit ip any any******** MERGE ***********has 78 entriesExample 3
This example shows the VACL does not follow the recommended guidelines, and the resultant merge significantly increases the number of ACEs:
******** VACL ***********1 deny ip 0.0.0.0 255.255.255.0 any2 deny ip 0.0.0.255 255.255.255.0 any3 deny ip any 0.0.0.0 255.255.255.04 permit ip any host 239.255.255.2555 permit ip any host 255.255.255.2556 deny ip any 0.0.0.255 255.255.255.07 permit tcp any range 0 65534 any range 0 655348 permit udp any range 0 65534 any range 0 655349 permit icmp any any10 permit ip any any******** IOS ACL **********1 deny ip any host 239.255.255.2552 permit ip any any******** MERGE **********has 329 entriesExample 4
This example shows that the VACL does not follow the recommended guidelines (three different actions are specified), and the resultant merge significantly increases the number of ACEs:
******** VACL ***********1 redirect 4/25 tcp host 192.168.1.67 host 255.255.255.2552 redirect 4/25 udp host 192.168.1.67 host 255.255.255.2553 deny tcp any any lt 304 deny udp any any lt 305 permit ip any any******* IOS ACL ***********1 deny ip any host 239.255.255.2552 permit ip any any******* MERGE **********has 142 entriesExample 5
This example shows the VACL has two different actions specified and the merge results are significantly improved:
******** VACL ***********1 redirect 4/25 tcp host 192.168.1.67 host 255.255.255.2552 redirect 4/25 udp host 192.168.1.67 host 255.255.255.2553 permit ip any any******* IOS ACL ***********1 deny ip any host 239.255.255.2552 permit ip any any******* MERGE **********has 4 entriesExample 6
This example shows that applying the merging guidelines on a large Cisco IOS ACL (no Layer 4 port information is specified on the Cisco IOS ACL), produces a merge result of 801 entries:
******** VACL **********1 redirect 4/25 tcp host 192.168.1.67 255.255.255.255 0.0.0.02 redirect 4/25 udp host 192.168.1.67 255.255.255.255 0.0.0.03 redirect 4/25 icmp host 192.168.1.67 host 255.255.255.2554 redirect 4/25 ip host 192.168.1.67 host 255.255.255.2555 deny tcp any any lt 306 deny udp any any lt 307 permit ip any any******** IOS ACL ***********1 permit ip 147.150.213.64 0.0.0.31 194.72.6.64 0.0.0.152 permit ip 147.150.213.64 0.0.0.31 194.72.6.160 0.0.0.153 permit ip 147.150.213.64 0.0.0.31 host 194.72.6.2054 permit ip 147.151.77.0 0.0.0.255 194.72.6.64 0.0.0.155 permit ip 147.151.77.0 0.0.0.255 194.72.6.160 0.0.0.156 permit ip 147.151.77.0 0.0.0.255 194.72.6.208 0.0.0.157 permit ip 147.151.77.0 0.0.0.255 host 194.72.6.2058 permit ip host 193.37.169.121 194.72.6.64 0.0.0.15[...] total 62 entries without L4 information******** MERGE **********has 801 ACEsExample 7
This example shows that the same Cisco IOS ACL that was used in Example 6 is merged with a VACL with Layer 4 port information. Following the guidelines in the "Using the Implicit Deny Action" section, the merge results are good.
******** VACL *********1 permit tcp host 193.131.248.24 194.73.73.0 0.0.0.15 gt 10232 permit tcp host 158.43.128.8 194.72.6.224 0.0.0.7 gt 10233 permit udp any 194.72.6.224 0.0.0.7 eq time4 permit udp any 194.73.73.0 0.0.0.15 eq time5 permit udp 194.72.7.128 0.0.0.7 194.72.6.224 0.0.0.7 eq 16456 permit udp 194.72.7.128 0.0.0.7 194.73.73.0 0.0.0.15 eq 16457 permit udp host 158.152.1.65 194.72.6.224 0.0.0.7 gt 10238 permit udp host 158.152.1.65 194.73.73.0 0.0.0.15 gt 1023[...] total 168 entries******** IOS ACL *********1 permit ip 147.150.213.64 0.0.0.31 194.72.6.64 0.0.0.152 permit ip 147.150.213.64 0.0.0.31 194.72.6.160 0.0.0.153 permit ip 147.150.213.64 0.0.0.31 host 194.72.6.2054 permit ip 147.151.77.0 0.0.0.255 194.72.6.64 0.0.0.155 permit ip 147.151.77.0 0.0.0.255 194.72.6.160 0.0.0.156 permit ip 147.151.77.0 0.0.0.255 194.72.6.208 0.0.0.157 permit ip 147.151.77.0 0.0.0.255 host 194.72.6.2058 permit ip host 193.37.169.121 194.72.6.64 0.0.0.15[...] total 62 entries without L4 information******* MERGE ********has 1259 ACEs.Guidelines for Using Layer 4 Operations
Follow these guidelines for configurations where you need to specify Layer 4 port operations.
These sections provide guidelines for specifying Layer 4 port operations:
•
•
Determining Layer 4 Operation Usage
The switch hardware allows you to specify these types of operations:
•
•
•
•
•
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.
Note
Use the following two guidelines to determine Layer 4 operation usage:
1.
... gt 10 permit... lt 9 deny... gt 11 deny... neq 6 redirect
Note
2.
... Src gt 10 ...... Dst gt 10
Note
Determining Logical Operation Unit Usage
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:
•
•
•
•
•
For example, this ACL would use a single LOU to store two different operator/operand couples:
... Src gt 10 ...... Dst gt 10A more detailed example follows:
ACL1... (dst port) gt 10 permit... (dst port) lt 9 deny... (dst port) gt 11 deny... (dst port) neq 6 redirect... (src port) neq 6 redirect... (dst port) gt 10 denyACL2... (dst port) gt 20 deny... (src port) lt 9 deny... (src port) range 11 13 permit... (dst port) neq 6 redirectThe Layer 4 operations and LOU usage is as follows:
•
•
•
An explanation of the LOU usage follows:
•
•
•
•
Using VACLs in your Network
This section describes some typical uses for VACLs and includes the following:
•
•
•
•
Wiring Closet Configuration
In a wiring closet configuration, Catalyst 6000 family switches might not be equipped with MSFCs (routers). In this configuration, the switch can still support a VACL and a QoS ACL. Suppose Host X and Host Y are in different VLANs and are connected to wiring closet Switch A and Switch C (see Figure 16-4). Traffic from Host X to Host Y is eventually being routed by the switch equipped with the MSFC. Traffic from Host X to Host Y can be access controlled at the traffic entry point, Switch A.
If you do not want HTTP traffic switched from Host X to Host Y, you can configure a VACL on Switch A. All HTTP traffic from Host X to Host Y would be dropped at Switch A and not be bridged to the switch with the MSFC.
Figure 16-4 Wiring Closet Configuration
Redirecting Broadcast Traffic to a Specific Server Port
Some application traffic uses broadcast packets that reach every host in a VLAN. With VACLs, you can redirect these broadcast packets to the intended application server port.
Figure 16-5 shows an application broadcast packet from Host A being redirected to the target application server port and preventing other ports from receiving the packet.
To redirect broadcast traffic to a specific server port, perform this task in privileged mode (TCP port 5000 is the intended server application port):
Note
Figure 16-5 Redirecting Broadcast Traffic to a Specific Server Port
Restricting the DHCP Response for a Specific Server
When Dynamic Host Configuration Protocol (DHCP) requests are broadcast, they reach every DHCP server in the VLAN and multiple responses are returned. With VACLs, you can restrict the response from a specific DHCP server and drop the other responses.
To restrict DHCP responses for a specific server, perform this task in privileged mode (the target DHCP server IP address is 1.2.3.4):
Figure 16-6 shows that only the target server returns a DHCP response from the DHCP request.
Figure 16-6 Redirect DHCP Response for a Specific Server
Denying Access to a Server on Another VLAN
You can restrict access to a server on another VLAN. For example, server 10.1.1.100 in VLAN 10 needs to have access restricted as follows (see Figure 16-7):
•
•
To deny access to a server on another VLAN, perform this task in privileged mode:
Figure 16-7 Deny Access to a Server on Another VLAN
Restricting ARP Traffic
Note
ARP traffic is permitted on each VLAN by default. You can disallow ARP traffic on a per VLAN basis using the set security acl ip acl_name deny arp command. When you enter this command, ARP traffic is disallowed on the VLAN that the ACL is mapped to. To allow ARP traffic on a VLAN that has had ARP traffic disallowed, enter the set security acl ip acl_name permit arp command.
Configuring ACLs on Private VLANs
Private VLANs allow you to split a primary VLAN into sub-VLANs (secondary VLANs) that can be either community VLANs or isolated VLANs. In releases prior to software release 6.1(1), you could configure ACLs on a primary VLAN only and the ACL would then be applied to all the secondary VLANs. In software release 6.1(1) and later releases, ACLs can be applied as follows:
•
•
•
•
•
If you map a VACL to a primary VLAN, it filters the traffic from the router to the host and if you map a VACL to a secondary VLAN, it filters the traffic from the host to the router.
Note
Note
Capturing Traffic Flows
See the "Capturing Traffic Flows on Specified Ports" section for complete configuration details.
Unsupported Features
This section lists ACL-related features that are not supported or have limited support on the Catalyst 6000 family switches.
•
–
–
–
–
–
–
–
–
–
–
•
•
Configuring VACLs
This section describes how to configure VACLs. Prior to performing any configuration tasks, see the "VACL Configuration Guidelines" section.
These sections provide guidelines and a summary for configuring VACLs:
•
VACL Configuration Guidelines
Follow these guidelines when configuring VACLs:
Caution
Note
•
•
•
•
•
•
•
•
•
•
•
•
–
–
–
–
–
VACL Configuration Summary
To create a VACL and map it to a VLAN, perform these steps:
Step 1
Step 2
Step 3
Note
Note
Configuring VACLs From the CLI
This section describes how to create and activate VACLs on the Catalyst 6000 family switches. These tasks are listed in the order that they should be performed.
This section describes the following tasks:
•
•
•
•
•
•
•
•
Creating an IP VACL and Adding ACEs
To create a new IP VACL and add ACEs, or to add ACEs to an existing IP VACL, perform these tasks in privileged mode:
•
•
set security acl ip {acl_name} {permit | deny} {src_ip_spec} [capture]
[before editbuffer_index | modify editbuffer_index] [log1 ]
set security acl ip {acl_name} {permit | deny | redirect mod_num/
port_num} {protocol} {src_ip_spec} {dest_ip_spec} [precedence precedence] [tos tos] [capture] [before editbuffer_index | modify editbuffer_index] [log1]
1 The log keyword provides logging messages for denied IP VACLs only.
This example shows how to create an ACE for IPACL1 to allow traffic from source address 172.20.53.4:
Console> (enable) set security acl ip IPACL1 permit host 172.20.53.4 0.0.0.0IPACL1 editbuffer modified. Use `commit' command to apply changes.Console> (enable)
Note
This example shows how to create an ACE for IPACL1 to allow traffic from all source addresses:
Console> (enable) set security acl ip IPACL1 permit anyIPACL1 editbuffer modified. Use `commit' command to apply changes.Console> (enable)This example shows how to create an ACE for IPACL1 to block traffic from source address 171.3.8.2:
Console> (enable) set security acl ip IPACL1 deny host 171.3.8.2IPACL1 editbuffer modified. Use `commit' command to apply changes.Console> (enable)This example shows how to display the contents of the edit buffer:
Console> (enable) show security acl info IPACL1 editbufferset security acl ip IPACL1-----------------------------------------------------------------1. permit ip host 172.20.53.4 any2. permit ip any any3. deny ip host 171.3.8.2 anyConsole> (enable)This example shows how to commit the ACEs to NVRAM:
Console> (enable) commit security acl allACL commit in progress.ACL IPACL1 is committed to hardware.Console> (enable)
Note
Enter the show security acl info IPACL1 command to verify that the changes were committed. If this VACL has not been mapped to a VLAN, enter the set security acl map command to map it to a VLAN.
This example shows how to create an ACE for IPACL2 to block traffic from source address 172.20.3.2 and place this ACE before ACE number 2 in the VACL. Optionally, you can use the modify keyword to replace an existing ACE with a new ACE. Enter the show security acl info acl_name [editbuffer] command to see the current ACE listing stored in NVRAM (enter the editbuffer keyword to see edit buffer contents).
Console> (enable) set security acl ip IPACL2 deny host 172.20.3.2 before 2IPACL2 editbuffer modified. Use `commit' command to apply changes.Console> (enable)This example shows how to create an ACE for IPACL2 to redirect IP traffic to port 3/1 from source address 1.2.3.4 with the destination address of 255.255.255.255. Note that host can be used as an abbreviation for a source and source-wildcard of 0.0.0.0. This ACE also specifies the following:
•
•
Note
Console> (enable) set security acl ip IPACL2 redirect 3/1 ip 1.2.3.4 0.0.0.255 host 255.255.255.255 precedence 1 tos min-delayIPACL2 editbuffer modified. Use `commit' command to apply changes.Console> (enable)This example shows how to display the contents of the edit buffer:
Console> (enable) show security acl info IPACL2 editbufferset security acl ip IPACL2-----------------------------------------------------------------1. deny 172.20.3.22. redirect 1.2.3.4Console> (enable)
Note
This example shows how to commit the ACEs to NVRAM:
Console> (enable) commit security acl allACL commit in progress.ACL IPACL2 is committed to hardware.Console> (enable)
Note
Enter the show security acl info IPACL2 command to verify that the changes were committed. If this VACL has not been mapped to a VLAN, enter the set security acl map command to map it to a VLAN.
Creating an IPX VACL and Adding ACEs
To create a new IPX VACL and add ACEs, or to add ACEs to an existing IPX VACL, perform this task in privileged mode:
This example shows how to create an ACE for IPXACL1 to block all traffic from source network 1234:
Console> (enable) set security acl ipx IPXACL1 deny any 1234IPXACL1 editbuffer modified. Use `commit' command to apply changes.Console> (enable)This example shows how to create an ACE for IPXACL1 to block all traffic with destination address 1.A.3.4:
Console> (enable) set security acl ipx IPXACL1 deny any any 1.A.3.4IPXACL1 editbuffer modified. Use `commit' command to apply changes.Console> (enable)This example shows how to create an ACE for IPXACL1 to redirect broadcast traffic to port 4/1 from source network 3456:
Console> (enable) set security acl ipx IPXACL1 redirect 4/1 any 3456IPXACL1 editbuffer modified. Use `commit' command to apply changes.Console> (enable)This example shows how to display the contents of the edit buffer:
Console> (enable) show security acl info IPXACL1 editbufferset security acl ipx IPXACL1-----------------------------------------------------------------1. deny any 12342. deny any any 1.A.3.43. redirect 4/1 any 3456Console> (enable)
Note
This example shows how to commit the ACEs to NVRAM:
Console> (enable) commit security acl allACL commit in progress.ACL IPXACL1 is committed to hardware.Console> (enable)Enter the show security acl info IPXACL1 command to verify that the changes were committed. If this VACL has not been mapped to a VLAN, enter the set security acl map command to map it to a VLAN.
This example shows how to create an ACE for IPXACL1 to allow all traffic from source network 1 and insert this ACE before ACE number 2:
Console> (enable) set security acl ipx IPXACL1 permit any 1 before 2IPXACL1 editbuffer modified. Use `commit' command to apply changes.Console> (enable)This example shows how to create an ACE for IPXACL1 to allow traffic from all source addresses:
Console> (enable) set security acl ipx IPXACL1 permit any anyIPXACL1 editbuffer modified. Use `commit' command to apply changes.Console> (enable)This example shows how to display the contents of the edit buffer:
Console> (enable) show security acl info IPXACL1 editbufferset security acl ipx IPXACL1-----------------------------------------------------------------1. deny any 12342. permit any 13. deny any any 1.A.3.44. redirect 4/1 any 34565. permit any anyACL IPXACL1 Status: Not CommittedConsole> (enable)This example shows how to commit the ACEs to NVRAM:
Console> (enable) commit security acl allACL commit in progress.ACL IPXACL1 is committed to hardware.Console> (enable)
Note
Enter the show security acl info IPXACL1 command to verify that the changes were committed. If this VACL has not been mapped to a VLAN, enter the set security acl map command to map it to a VLAN.
Creating a Non-IP Version 4/Non-IPX VACL (MAC VACL) and Adding ACEs
Caution
To create a new non-IP version 4/non-IPX VACL and add ACEs, or to add ACEs to an existing non-IP version 4/non-IPX VACL, perform this task in privileged mode:
This example shows how to create an ACE for MACACL1 to block all traffic from 8-2-3-4-7-A:
Console> (enable) set security acl mac MACACL1 deny host 8-2-3-4-7-A anyMACACL1 editbuffer modified. Use `commit' command to apply changes.Console> (enable)This example shows how to create an ACE for MACACL1 to block all traffic to A-B-C-D-1-2:
Console> (enable) set security acl mac MACACL1 deny any host A-B-C-D-1-2MACACL1 editbuffer modified. Use `commit' command to apply changes.Console> (enable)This example shows how to create an ACE for MACACL1 to allow traffic from all sources:
Console> (enable) set security acl mac MACACL1 permit any anyMACACL1 editbuffer modified. Use `commit' command to apply changes.Console> (enable)This example shows how to display the contents of the edit buffer:
Console> (enable) show security acl info MACACL1 editbufferset security acl mac MACACL1-----------------------------------------------------------------1. deny 8-2-3-4-7-A any2. deny any A-B-C-D-1-23. permit any anyConsole> (enable)
Note
This example shows how to commit the ACEs to NVRAM:
Console> (enable) commit security acl allACL commit in progress.ACL MACACL1 is committed to hardware.Console> (enable)
Note
Enter the show security acl info MACACL1 command to verify that the changes were committed. If this VACL has not been mapped to a VLAN, enter the set security acl map command to map it to a VLAN.
Committing ACLs
You can commit all ACLs or a specific ACL to NVRAM with the commit command. Any committed ACL with no ACEs will be deleted.
To commit an ACL to NVRAM, perform this task in privileged mode:
This example shows how to commit a specific security ACL to NVRAM:
Console> (enable) commit security acl IPACL2ACL commit in progress.ACL IPACL2 is committed to hardware.Console> (enable)Mapping a VACL to a VLAN
You can map a VACL to a VLAN with the set security acl map command. Note that there is no default ACL-to-VLAN mapping; all VACLs need to be mapped to a VLAN.
To map a VACL to a VLAN, perform this task in privileged mode:
This example shows how to map IPACL1 to VLAN 10:
Console> (enable) set security acl map IPACL1 10ACL IPACL1 mapped to vlan 10Console> (enable)This example shows the output if you try to map an ACL that has not been committed:
Console> (enable) set security acl map IPACL1 10Commit ACL IPACL1 before mapping.Console> (enable)Showing the Contents of a VACL
You can display the contents of a VACL with the show security acl info command.
To show the contents of a VACL, perform this task in privileged mode:
Show the contents of a VACL.
show security acl info {acl_name | all} [editbuffer [editbuffer_index]]
This example shows how to show the contents of a VACL that has been saved in NVRAM:
Console> (enable) show security acl info IPACL1set security acl ip IPACL1------------------------------------------------------------------1. deny A2. deny ip B any3. deny c4. permit anyThis example shows how to show the contents of a VACL that is still in the edit buffer:
Console> (enable) show security acl info IPACL1 editbufferset security acl ip IPACL1-----------------------------------------------------------------1. deny A2. deny ip B any3. deny C4. deny D5. permit anyConsole> (enable)Showing VACL-to-VLAN Mapping
You can display VACL-to-VLAN mapping for a specified ACL or VLAN with the show security acl map command.
To show VACL-to-VLAN mapping, perform this task in privileged mode:
This example shows how to show the mappings of a specific VACL:
Console> (enable) show security acl map IPACL1ACL IPACL1 is mapped to VLANs:1Console> (enable)This example shows how to show the mappings of a specific VLAN:
Console> (enable) show security acl map 1VLAN 1 is mapped to IP ACL IPACL1.VLAN 1 is mapped to IPX ACL IPXACL1.VLAN 1 is mapped to MAC ACL MACACL1.Console> (enable)Clearing the Edit Buffer
You can clear changes made to the ACL edit buffer since its last save with the rollback command. The ACL is rolled back to its state at the last commit command.
To clear the ACL edit buffer, perform this task in privileged mode:
This example shows how to clear the edit buffer of a specific security ACL:
Console> (enable) rollback security acl IPACL1Editbuffer for `IPACL1' rolled back to last commit state.Console> (enable)Removing ACEs from Security ACLs
You can remove a specific ACE or all ACEs from an ACL with the clear security acl command. This command deletes the ACEs from the edit buffer.
To remove an ACE from a security ACL, perform this task in privileged mode:
Remove an ACE from a security ACL.
clear security acl all
clear security acl acl_name
clear security acl acl_name editbuffer_index
This example shows how to remove ACEs from all the ACLs:
Console> (enable) clear security acl allAll editbuffers modified. Use `commit' command to apply changes.Console> (enable)This example shows how to remove a specific ACE from a specific ACL:
Console> (enable) clear security acl IPACL1 2IPACL1 editbuffer modified. Use `commit' command to apply changes.Console> (enable)Clearing the Security ACL Map
You can remove a VACL-to-VLAN mapping with the clear security acl map command.
To clear the security ACL map, perform this task in privileged mode:
Clear the security ACL map.
clear security acl map all
clear security acl map acl_name
clear security acl map vlan
clear security acl map acl_name vlan
This example shows how to clear all VACL-to-VLAN mappings:
Console> (enable) clear security acl map allMap deletion in progress.Successfully cleared mapping between ACL ip1 and VLAN 10.Successfully cleared mapping between ACL ipx1 and VLAN 10..... display text omittedConsole> (enable)This example shows how to clear the mapping for a specific VACL on a specific VLAN:
Console> (enable) clear security acl map IPACL1 50Map deletion in progress.Successfully cleared mapping between ACL ipacl1 and VLAN 50.Console> (enable)Displaying VACL Management Information
You can display VACL management information with the show security acl resource-usage command.
To display VACL management information, perform this task in privileged mode:
This example shows how to display VACL management information:
Console> (enable) show security acl resource-usageACL resource usage:ACL storage (mask/value): 0.29%/0.10%ACL to switch interface mapping table: 0.39%ACL layer 4 port operators: 0.0%Console (enable)Capturing Traffic Flows on Specified Ports
You can use the capture option in the set security acl (ip, ipx, and mac) commands to specify that packets that match the specified flows are captured and transmitted out of capture ports. You can specify capture ports using the set security acl capture-ports mod/ports... command. When you use the capture option, the packets that match the specified flows are captured in parallel and transmitted out of the capture ports. Capture ports do not send out all the captured traffic; they send out only the traffic belonging to the VLANs of the captured port.
Configuration Guidelines
Follow these guidelines when configuring capture ports:
•
•
•
•
•
•
For routed traffic, capture ports transmit packets only after they are Layer 3 switched; packets are transmitted out of a port only if the output VLAN of the Layer 3 switched flow is the same as the capture port VLAN. For example, assume you have flows from VLAN 10 to VLAN 20 and you add a VACL (on one of the VLANs) permitting these flows and you specify a capture port. This traffic gets transmitted out of the capture port only if it belongs to VLAN 20 or if the port is a trunk carrying VLAN 20. If the capture port is in VLAN 10, it does not transmit any traffic. Whether a capture port transmits the traffic or not is independent of the VLAN on which you placed the VACL.
If you want to capture traffic from one VLAN going to many VLANs, the capture port has to be a trunk carrying all output VLANs.
For bridged traffic, because all the traffic remains in the same VLAN, ensure that the capture port is in the same VLAN as the bridged traffic.
•
To capture traffic flows, perform these steps:
Note
Step 1
Step 2
Step 3
Step 4
Configuration Examples
This example shows how to create an ACE for my_cap and specify that the allowed traffic be captured:
Console> (enable) set security acl ip my_cap permit ip host 60.1.1.1 host 60.1.1.98 capturemy_cap editbuffer modified. Use 'commit' command to apply changes.Console> (enable)This example shows how to commit the my_cap ACL to NVRAM:
Console> (enable) commit security acl my_capACL commit in progress.ACL my_cap successfully committed.Console> (enable)This example shows how to map my_cap to VLAN 10:
Console> (enable) set security acl map my_cap 10Mapping in progress.VLAN 10 successfully mapped to ACL my_cap.The old mapping with ACL captest was replaced with the new one.Console> (enable)This example shows how to specify capture ports:
Console> (enable) set security acl capture-ports 1/1-2,2/1-2Successfully set the following ports to capture ACL traffic:1/1-2,2/1-2Console> (enable)This example shows how to display ports that have been specified as capture ports:
Console> (enable) show security acl capture-portsACL Capture Ports: 1/1-2,2/1-2Console> (enable)This example shows how to clear capture ports:
Console> (enable) clear security acl capture-ports 1/1,2/1Successfully cleared the following ports:1/1,2/1Console> (enable)This example shows that ports 1/1 and 2/1 were cleared:
Console> (enable) show security acl capture-portsACL Capture Ports:1/2,2/2Console> (enable)Configuring VACL Logging
Note
You can log messages about denied packets for the standard IP access list by entering the log keyword for deny VACLs. That is, any packet that matches the access list will cause an informational logging message about the packet to be sent to the console. The level of messages logged to the console is controlled by the set logging level acl severity command.
The first packet that triggers the access list causes a logging message right away, and subsequent packets are collected over 5-minute intervals before they are displayed or logged. The logging message includes the flow pattern and number of packets received in the prior 5-minute interval.
By default, system logging messages are sent to the console. You can configure the switch to send system logging messages to a syslog server. For information on configuring system message logging, see Chapter 27, "Configuring System Message Logging."
Configuration Guidelines
Follow these guidelines when configuring VACL logging:
•
•
To enable VACL logging, perform these steps:
Step 1
Step 2
Note
Step 3
Note
Step 4
Step 5
Step 6
Configuration Examples
This example shows how to set the logging level:
Console> (enable) set logging level acl 6System logging facility <acl> for this session set to severity 6(information)This example shows how to allocate a new log table based on the maximum flow:
Console> (enable) set security acl log maxflow 512Set VACL Log table to 512 flow patterns.This example shows how to set the redirect rate:
Console> (enable) set security acl log ratelimit 1000Set Redirect Rate to 1000 pps.This example shows how to display the VACL log configuration:
Console> (enable) show security acl log configVACL LOG Configration-------------------------------------------------------------Max Flow Pattern : 512Redirect Rate (pps) : 1000This example shows how to create an ACE for my_cap and specify that denied traffic be logged:
Console> (enable) set security acl ip my_cap deny ip host 21.0.0.1 logmy_cap editbuffer modified. Use 'commit' command to apply changes.Console> (enable)This example shows how to commit the my_cap ACL to NVRAM:
Console> (enable) commit security acl my_capACL commit in progress.ACL my_cap successfully committed.Console> (enable)This example shows how to map the VACL to a VLAN:
Console> (enable) set security acl map my_cap 1Mapping in progress.ACL my_cap successfully mapped to VLAN 1.::2000 Jul 19 01:14:06 %ACL-6-VACLLOG:VLAN 1(Port 2/1) denied ip tcp 21.0.0.1(2000) -> 255.255.255.255(3000), 1 packet2000 Jul 19 01:19:06 %ACL-6-VACLLOG:VLAN 1(Port 2/1) denied ip tcp 21.0.0.1(2000) -> 255.255.255.255(3000), 7 packets2000 Jul 19 01:25:06 %ACL-6-VACLLOG:VLAN 1(Port 2/2) denied ip tcp 21.0.0.1(2000) -> 255.255.255.255(3000), 1 packetsThis example shows how to display the flow information in the log table:
Console> (enable) show security acl log flow ip any anyTotal matched entry number = 1Entry No. #1, IP Packet----------------------------------------Vlan Number : 1Mod/Port Number : 2/1Source IP address : 21.0.0.1Destination IP address : 255.255.255.255TCP Source port : 2000TCP Destination port : 3000Received Packet Number : 10This example shows how to clear the log table:
Console> (enable) clear security acl log flowLog table is cleared.Console> (enable)Configuring and Storing VACLs and QoS ACLs in Flash Memory
This section describes how to configure and store VACLs and QoS ACLs in Flash memory instead of NVRAM. Prior to this feature, all configuration information was stored in NVRAM. With the addition of QoS and security ACLs (VACLs), NVRAM could become full. In addition to limiting ACL configuration, filling up NVRAM can cause problems when you attempt to upgrade from one software version to another.
Note
This section describes the following tasks:
•
•
•
•
•
•
Note
Automatically Moving the VACL and QoS ACL Configuration to Flash Memory
Moving the VACL and QoS ACL configuration to Flash memory is done automatically only during system software upgrades and then only if there is not sufficient NVRAM for the upgrade. If there is not enough NVRAM to perform a software upgrade, the QoS ACL and VACL configuration is deleted from NVRAM and the ACL configuration is automatically moved to Flash memory. When this occurs, these syslog messages display:
1999 Sep 01 17:00:00 %SYS-1-CFG_FLASH:ACL configuration moved to bootflash:switchapp.cfg1999 Sep 01 17:00:00 %SYS-1-CFG_ACL_DEALLOC:NVRAM full. Qos/Security ACL configuration deleted from NVRAM.The VACL and QoS ACL configuration has now been successfully moved to Flash memory. During this process, the system also does the following:
•
•
If an error occurs during the upgrade, these syslog messages display:
1999 Sep 01 17:00:00 %SYS-1-CFG_FLASH_ERR:Failed to write ACL configuration to bootflash:switchapp.cfg1999 Sep 01 17:00:00 %SYS-1-CFG_ACL_DEALLOC:NVRAM full. Qos/Security ACL configuration deleted from NVRAM.If you receive these error messages, the VACL and QoS ACL configuration is stored in DRAM only. You need to make more space available in Flash memory and then save the configuration to Flash memory (as described in the "Moving the VACL and QoS ACL Configuration Back to NVRAM" section). Alternatively, you might try to delete unneeded VACLs and QoS ACLs and save the ACL configuration to NVRAM using the set config acl nvram command.
Manually Moving the VACL and QoS ACL Configuration to Flash Memory
If your VACL and QoS ACL configuration requirements require more memory than the 512-KB NVRAM, you can manually move the VACL and QoS ACL configuration to Flash memory as follows:
Step 1
Console> (enable) set boot auto-config bootflash:switchapp.cfgCONFIG_FILE variable = bootflash:switchapp.cfgConsole> (enable)Step 2
Console> (enable) set boot config-register auto-config recurringConfiguration register is 0x12Fignore-config: disabledauto-config: recurring, overwrite, sync disabledconsole baud: 9600boot: image specified by the boot system commandsConsole> (enable)Step 3
Console> (enable) set boot config-register auto-config appendConfiguration register is 0x12Fignore-config: disabledauto-config: recurring, append, sync disabledconsole baud: 9600boot: image specified by the boot system commandsConsole> (enable)Step 4
Console> (enable) set boot config-register auto-config sync enableConfiguration register is 0x12Fignore-config: disabledauto-config: recurring, append, sync enabledconsole baud: 9600boot: image specified by the boot system commandsConsole> (enable)Step 5
Console> (enable) copy acl-config bootflash:switchapp.cfgUpload ACL configuration to bootflash:switchapp.cfg2843644 bytes available on device bootflash, proceed (y/n) [n]? yACL configuration has been copied successfully.Console> (enable)Step 6
Console> (enable) clear config acl nvramACL configuration has been deleted from NVRAM.Warning: Use the copy commands to save the ACL configuration to a file andthe 'set boot config-register auto-config' commands to configure theauto-config feature.
Note
At this point, the VACL and QoS ACL configuration is no longer in NVRAM, it is saved in the auto-config file bootflash:switchapp.cfg and will be appended to the NVRAM configuration at system startup.
After making any additional changes to the VACL and QoS ACL configuration and committing those changes, you must enter the copy acl-config bootflash:switchapp.cfg command to save the configuration to the auto-config file.
The auto-config file is synchronized automatically to the standby supervisor engine because synchronization was enabled.
If you cannot write the VACL and QoS ACL configuration to Flash memory, it is removed from NVRAM. At this point, the VACL and QoS ACL configuration exists in DRAM only. A system reset for any reason can cause the VACL and QoS ACL configuration to revert to the default.
Note
At system startup, if the VACL and QoS ACL configuration location is set to Flash memory but either the CONFIG_FILE variable is not set or none of the files specified exist, the following syslog message displays:
1999 Sep 01 17:00:00 %SYS-0-CFG_FLASH_ERR:ACL configuration set to flash but no ACL configuration file found.Running with the VACL and QoS ACL Configuration in Flash Memory
After you move the VACL and QoS ACL configuration to Flash memory, QoS ACLs and VACL commit operations are no longer written to NVRAM. You have to copy the configuration to the Flash file manually as follows:
•
•
Moving the VACL and QoS ACL Configuration Back to NVRAM
This example shows how to move the VACL and QoS ACL configuration back to NVRAM:
Console> (enable) set config acl nvramACL configuration copied to NVRAM.Console> (enable)Console> (enable) clear boot auto-configCONFIG_FILE variable =Console> (enable)Redundancy Synchronization Support
The set boot commands contain an option to synchronize the auto-config file automatically.
When you enable the auto-config option, if the VACL and QoS ACL configuration resides in Flash memory, the auto-config file on the active supervisor engine is automatically synchronized to the standby supervisor engine whenever a change is made; for example, deleting the auto-config file on the active supervisor engine causes the file to be deleted on the standby supervisor engine. Similarly, if you insert a new standby supervisor engine, the active supervisor engine automatically synchronizes the auto-config file.
Interacting with High Availability
After a supervisor engine switchover, the VACL and QoS ACL configuration on the standby supervisor engine is consistent with what was on the active supervisor engine, just as in the case where the VACL and QoS ACL configuration is saved in NVRAM. The only difference is that the data is stored in DRAM, but the functional behavior of a switchover does not change.
Configuring Policy-Based Forwarding
The policy-based forwarding (PBF) feature is an extension of VACL redirection supported by the Policy Feature Card 2 (PFC2). It can prove to be particularly beneficial in any flat Layer 2 network used for transparent bridging where a limited amount of inter-VLAN communication is required. This feature can also be used in server farms or DMZs where bridging devices like server load balancing appliances are involved, or where firewall load balancing is performed.
Note
Note
Note
PBF is described in these sections:
•
•
•
•
Understanding How Policy-Based Forwarding Works
PBF configuration involves these steps:
•
•
•
Note
When a router is not present in the network, you need to specify static ARP entries on participating hosts.
Hardware and Software Requirements
PBF hardware and software requirements are as follows:
•
•
If you try to configure PBF with an MSFC2 present and booted, the system responds with a message indicating the feature is not supported with an MSFC2.
If an MSFC2 is present but has not booted, you can configure PBF.
•
Configuring Policy-Based Forwarding
This section provides guidelines and configuration examples for PBF. The configuration examples use the example configuration shown in Figure 16-8. The Catalyst 6000 family switch redirects all the traffic coming from Host A on VLAN 10 to Host B on VLAN 11, and redirects traffic from Host B to Host A. This section contains the following example procedures:
•
•
•
Figure 16-8 Policy-Based Forwarding
Enabling PBF and Specifying a MAC Address for the PFC2
Note
We recommend that you use the default MAC address provided by the MAC address PROM. When you specify your own MAC address using the set pbf mac command, if the MAC address is a duplicate of a MAC address already in use, packets might get dropped.To display PBF status and MAC address, perform this task in privileged mode:
To enable PBF, perform one of these tasks in privileged mode:
Enable PBF with a default MAC address.
set pbf
Enable PBF with a specific MAC address.
set pbf [mac mac address]
This example shows how to check PBF status and MAC address, enable PBF with a default MAC address, and verify the change:
Console> (enable) show pbfPbf status Mac address----------- ------------------not set 00-00-00-00-00-00Console> (enable)Console> (enable) set pbfPBF committed successfully.Operation successful.Console> (enable)Console> (enable) show pbfPbf status Mac address----------- ------------------ok 00-01-64-61-39-c2Console> (enable)This example shows how to enable PBF with a specific MAC address:
Console> (enable) set pbf mac 00-11-11-11-11-11PBF committed successfully.Operation successful.Console> (enable)Console> (enable) show pbfPbf status Mac address----------- ------------------ok 00-11-11-11-11-11Console> (enable)To disable PBF and clear the PBF MAC address, perform this task in privileged mode:
This example shows how to clear the PBF MAC address:
Console> (enable) clear pbfPBF cleared.Console> (enable)Console> (enable) show pbfPbf status Mac address----------- ------------------not set 00-00-00-00-00-00Console> (enable)Configuring VACLs for PBF
Note
Note that the source MAC address is optional. If you do not specify the source MAC address, the system defaults to the PBF MAC address.
Note
Note
1.
2.
3.
4.
5.
Note
Note
To specify an adjacency table entry for the PFC2, perform this task in privileged mode:
Specify an adjacency table entry for the PFC2.
set security acl adjacency adjacency_name dest_vlan dest_mac [[source_mac] | [source_mac mtu mtu_size] | [ mtu mtu_size]]
This example shows how to specify the adjacency table entry:
Console> (enable) set security acl adjacency ADJ1 11 00-00-00-00-00-0BADJ1 editbuffer modified. Use 'commit' command to apply changes.Console> (enable)This example shows how to create the PBF VACL for VLAN 10 (shown in Figure 16-8):
Console> (enable) set security acl adjacency ADJ1 11 00-00-00-00-00-0BADJ1 editbuffer modified. Use 'commit' command to apply changes.Console> (enable) set security acl ip IPACL1 redirect ADJ1 ip host 10.0.0.1 host 11.0.0.1IPACL1 editbuffer modified. Use 'commit' command to apply changes.Console> (enable) set security acl ip IPACL1 permit anyIPACL1 editbuffer modified. Use 'commit' command to apply changes.Console> (enable) commit security acl adjacencyCommit operation in progress.Adjacency successfully committed.Console> (enable) commit security acl IPACL1ACL commit in progress.ACL 'IPACL1' successfully committed.Console> (enable) set security acl map IPACL1 10Mapping in progress.ACL IPACL1 successfully mapped to VLAN 10.Console> (enable)Console> (enable) set security acl adjacency ADJ2 10 00-00-00-00-00-0AADJ2 editbuffer modified. Use 'commit' command to apply changes.Console> (enable) set security acl ip IPACL2 redirect ADJ2 ip host 11.0.0.1 host 10.0.0.1IPACL2 editbuffer modified. Use 'commit' command to apply changes.Console> (enable) set security acl ip IPACL2 permit anyIPACL2 editbuffer modified. Use 'commit' command to apply changes.Console> (enable) commit security acl adjacencyCommit operation in progress.Adjacency successfully committed.Console> (enable) commit security acl IPACL2ACL commit in progress.ACL 'IPACL2' successfully committed.Console> (enable) set security acl map IPACL2 11Mapping in progress.ACL IPACL2 successfully mapped to VLAN 11.Console> (enable)Displaying PBF Information
This section describes how to display PBF-related information.
To display adjacency table entries, perform these tasks in normal mode:
Console> show security acl info adjacencyset security acl adjacency ADJ1---------------------------------------------------1. 11 00-00-00-00-00-0bset security acl adjacency ADJ2---------------------------------------------------1. 10 00-00-00-00-00-0aConsole> show pbf adjacencyIndex DstVlan DstMac SrcMac Name------------------------------------------------------------------1 11 00-00-00-00-00-0a 00-00-00-00-00-0b ADJ12 10 00-00-00-00-00-0a 00-00-00-00-00-0b ADJ2Console> show pbf statisticsIndex DstVlan DstMac SrcMac HitCount(hex) Name-------------------------------------------------------------------------1 11 00-00-00-00-00-0a 00-00-00-00-00-0b 0x00000000 ADJ12 10 00-00-00-00-00-0a 00-00-00-00-00-0b 0x00000000 ADJ2Console> show pbf mapAdjacency ACL------------------ --------------------ADJ1 IPACL1ADJ2 IPACL2Console> (enable)Clearing Entries in PBF VACLs
The adjacency table entry cannot be cleared before the redirect ACE. You should clear the redirect ACE and the adjacency table entry in PBF VACLs in the following order:
1.
2.
3.
4.
To clear a PBF adjacency table entry, perform this task in privileged mode:
This example shows how to clear a PBF adjacency table entry:
Console> (enable) clear security acl adjacency ADJ1Adj is in use by a VACL, clear the VACL first then clear adj.Console> (enable) clear security acl IPACL1IPACL1 editbuffer modified. Use 'commit' command to save changes.Console> (enable) commit security acl IPACL1ACL commit in progress.ACL 'IPACL1' successfully deleted.Console> (enable) clear security acl adjacency ADJ1ADJ1 editbuffer modified. Use 'commit' command to apply changes.Console> (enable) commit security acl adjacencyConsole> (enable) Adjacency committed successfullyCommit operation in progress.Console> (enable)Rolling Back Adjacency Table Entries in the Edit Buffer
You can clear adjacency table entries in the edit buffer that were made prior to the last commit by using the rollback command. The adjacency table entries are rolled back to their state at the last commit.
To roll back the adjacency table entries in the edit buffer, perform this task in privileged mode:
Roll back adjacency table entries in the edit buffer.
rollback security acl {acl_name | all | adjacency}
This example shows how to roll back adjacency table entries in the edit buffer:
Console> (enable) rollback security acl adjacencyEditbuffer for adjacency info rolled back to last commit state.Console> (enable)Configuring Hosts for PBF
This section provides host configuration procedures for the following platforms and operating systems:
Note
Note
Linux
These examples show how to configure the ARP table for hosts running the Linux operating system.
This example shows how to configure Host A:
arp -s 11.0.0.1 00:11:11:11:11:11 -i eth0route add 11.0.0.1 eth0arp -s 10.0.0.1 00:11:11:11:11:11 -i eth1route add 10.0.0.1 eth1Sun Workstation
When using PBF to enable forwarding between two VLANs with Sun Workstation end hosts, note that there are limitations you must take into account when configuring the hosts.
PBF Limitations
PBF does not support ARP; you must set a static ARP entry on each Sun Workstation that participates in PBF. Each static ARP entry must point to the PBF MAC address that is mapped to the destination host.
You must also configure the Sun Workstation to have a gateway. If the Sun Workstation needs to communicate to a different network, you must define the host routes for all networks that go through PBF, and if required, you must define a default gateway.
For example, if host 10.0.0.1 on VLAN 40 needs to communicate with host 11.0.0.1 on VLAN 50, and assuming the PBF MAC address is 00-11-11-11-11-11, the static ARP entry would be as follows:
arp -s 11.0.0.1 00:11:11:11:11:11where 00-11-11-11-11-11 is the PBF MAC address, and 11.0.0.1 is the IP address of the destination host.
Sun Workstation Limitations
Sun Workstations do not allow you to set a static ARP entry if the destination is part of a different network (11.x.x.x in this example). This is a limitation of ARP in all Sun Workstations. To overcome this problem, you need to define a dummy gateway, which is a host route, and set a static ARP entry pointing to the PBF MAC address mapped to the destination host.
Using the example above, you need to first define a dummy static ARP entry for the gateway. The IP address of the gateway is one of the host addresses within that network as follows:
(A) Kubera# arp -s 10.0.0.2 00:11:11:11:11:11(B) Kubera# route add host 11.0.0.1 10.0.0.2You need to set only one dummy ARP entry for PBF-related traffic and the host routes for each destination host.
If the number of hosts increase, you need to set the host route entries for each destination host. You can set up a startup file in /etc/rc2.d which has host route entries for each of the destination hosts. Setting up this file prevents you from having to key in all the host route entries after the Workstation is reset or rebooted.
Entries in the file should use this form:
Route add host <destination Host IP Address> <dummy gateway IP Address>The file that contains the host route entries needs to be started as one of the startup scripts. You can create the file in a directory that has full permissions for the root/superuser, set a soft link pointing to that file in /etc/rc2.d, or create the file in the /etc/rc2.d directory itself.
MS-Windows/NT/2000 Hosts
Similar to Sun Workstations setup, you must also set static ARP entries on Windows-based PCs. For Windows-based PCs, you do not need to set up any dummy gateways for switching between VLANs with PBF.
This example shows how to configure static ARP entries in Windows-based platforms:
C:\> arp -s 11.0.0.1 00-11-11-11-11-11In this example, 00-11-11-11-11-11 is the PBF MAC address and 11.0.0.1 is the IP address of the destination host.
If you need to configure more hosts, you can create a batch file with ARP entries to each destination host and specify that Windows use this file at startup.
Policy-Based Forwarding Configuration Example
This section provides example configurations to enable PBF between hosts on VLAN 1 and hosts on VLAN 2 (see Figure 16-9).
Figure 16-9 Policy-Based Forwarding Configuration Example
This example shows the switch configuration file that was created to enable PBF between the hosts on VLAN 1 and VLAN 2. Only the first four hosts from each VLAN are shown in the example (44.0.0.1 through 44.0.0.4 and 43.0.0.1 through 43.0.0.4).
#security ACLsclear security acl all#adj setset security acl adjacency a_1 2 00-0a-0a-0a-0a-0aset security acl adjacency a_2 2 00-0a-0a-0a-0a-0bset security acl adjacency a_3 2 00-0a-0a-0a-0a-0cset security acl adjacency a_4 2 00-0a-0a-0a-0a-0dset security acl adjacency b_1 1 00-20-20-20-20-20set security acl adjacency b_2 1 00-20-20-20-20-21set security acl adjacency b_3 1 00-20-20-20-20-22set security acl adjacency b_4 1 00-20-20-20-20-23#ip1set security acl ip ip1 permit arpset security acl ip ip1 redirect a_1 ip host 44.0.0.1 host 43.0.0.1set security acl ip ip1 redirect a_2 ip host 44.0.0.2 host 43.0.0.2set security acl ip ip1 redirect a_3 ip host 44.0.0.3 host 43.0.0.3set security acl ip ip1 redirect a_4 ip host 44.0.0.4 host 43.0.0.4set security acl ip ip1 permit ip any any#ip2set security acl ip ip2 permit arpset security acl ip ip2 redirect b_1 ip host 43.0.0.1 host 44.0.0.1set security acl ip ip2 redirect b_2 ip host 43.0.0.2 host 44.0.0.2set security acl ip ip2 redirect b_3 ip host 43.0.0.3 host 44.0.0.3set security acl ip ip2 redirect b_4 ip host 43.0.0.4 host 44.0.0.4set security acl ip ip2 permit ip any any#pbf setset pbf mac 00-11-22-33-44-55#commit security acl allset security acl map ip1 1set security acl map ip2 2This example shows how to display MAC addresses learned by the switch for port 6/17 on VLAN 1:
Console> (enable) show cam dynamic 6/17* = Static Entry. + = Permanent Entry. # = System Entry. R = Router Entry.X = Port Security Entry $ = Dot1x Security EntryVLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type]---- ------------------ ----- -------------------------------------------1 00-20-20-20-20-23 6/17 [ALL]1 00-20-20-20-20-22 6/17 [ALL]1 00-20-20-20-20-21 6/17 [ALL]1 00-20-20-20-20-20 6/17 [ALL]1 00-20-20-20-20-27 6/17 [ALL]1 00-20-20-20-20-26 6/17 [ALL]1 00-20-20-20-20-25 6/17 [ALL]1 00-20-20-20-20-24 6/17 [ALL]1 00-20-20-20-20-2b 6/17 [ALL]1 00-20-20-20-20-2a 6/17 [ALL]1 00-20-20-20-20-29 6/17 [ALL]1 00-20-20-20-20-28 6/17 [ALL]1 00-20-20-20-20-2f 6/17 [ALL]1 00-20-20-20-20-2e 6/17 [ALL]1 00-20-20-20-20-2d 6/17 [ALL]1 00-20-20-20-20-2c 6/17 [ALL]Total Matching CAM Entries Displayed for 6/17 = 16 for port 6/9, vlan 2This example shows how to display MAC addresses learned by the switch for port 6/9 on VLAN 2:
Console> (enable) show cam dynamic 6/9* = Static Entry. + = Permanent Entry. # = System Entry. R = Router Entry.X = Port Security Entry $ = Dot1x Security EntryVLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type]---- ------------------ ----- -------------------------------------------2 00-0a-0a-0a-0a-0e 6/9 [ALL]2 00-0a-0a-0a-0a-0f 6/9 [ALL]2 00-0a-0a-0a-0a-0c 6/9 [ALL]2 00-0a-0a-0a-0a-0d 6/9 [ALL]2 00-0a-0a-0a-0a-0a 6/9 [ALL]2 00-0a-0a-0a-0a-0b 6/9 [ALL]2 00-0a-0a-0a-0a-19 6/9 [ALL]2 00-0a-0a-0a-0a-18 6/9 [ALL]2 00-0a-0a-0a-0a-17 6/9 [ALL]2 00-0a-0a-0a-0a-16 6/9 [ALL]2 00-0a-0a-0a-0a-15 6/9 [ALL]2 00-0a-0a-0a-0a-14 6/9 [ALL]2 00-0a-0a-0a-0a-13 6/9 [ALL]2 00-0a-0a-0a-0a-12 6/9 [ALL]2 00-0a-0a-0a-0a-11 6/9 [ALL]2 00-0a-0a-0a-0a-10 6/9 [ALL]Total Matching CAM Entries Displayed for 6/9 = 16This example shows how to display the PBF status and the PFC2 MAC address:
Console> (enable) show pbfPbf status Mac address----------- ------------------ok 00-11-22-33-44-55This example shows how to display the PBF statistics:
Console> (enable) show pbf statisticsIndex DstVlan DstMac SrcMac HitCount(hex) Name-------------------------------------------------------------------------1 2 00-0a-0a-0a-0a-0a 00-11-22-33-44-55 0x00026d7c a_12 2 00-0a-0a-0a-0a-0b 00-11-22-33-44-55 0x00026d83 a_23 2 00-0a-0a-0a-0a-0c 00-11-22-33-44-55 0x00026d89 a_34 2 00-0a-0a-0a-0a-0d 00-11-22-33-44-55 0x00026d90 a_45 1 00-20-20-20-20-20 00-11-22-33-44-55 0x000260e3 b_16 1 00-20-20-20-20-21 00-11-22-33-44-55 0x000260ea b_27 1 00-20-20-20-20-22 00-11-22-33-44-55 0x000260f1 b_38 1 00-20-20-20-20-23 00-11-22-33-44-55 0x000260f8 b_4
