CatOS is organized by function based on three main configuration commands: show, set, and clear.

CatOS function based allows for easy manipulation of adding and deleting ports from certain functions such as EtherChannel, LACPChannel, trunking, vlan membership, spanning tree function, etc.... CatOS is only for the Cisco Catalyst family of switch; it is only handling L2 manipulation. IOS was/is the original Cisco OS which is organized by port. All configuration is done at the port level rather than at the function level. Before IOS 11's introduction of the 'range' for interface configuration, individual ports configuration was a major pain. (like changing all 384 ports of a Catalyst switch running IOS to be all switchports in VLAN 5)

Multiple Spanning Tree (MST) to IEEE802.1w Rapid Spanning Tree (RST) algorithm to multiple spanning tree expansion, which is a virtual LANs (VLANs) environment provides a rapid convergence and load balancing features; MST converges faster than PVST + and 802.1D and , 802.1w Spanning Tree and PVST + compatible structure. Multi-spanning tree (MST), can trunk (trunks) to create multiple spanning tree, associated VLANs to spanning tree-related processes, each spanning tree process independent of other process topology; MST provides a number of data forwarding path and load balancing, and improves network fault tolerance, because a process (forwarding path) of the failure will not affect other processes (forwarding path). In large networks of different network parts to locate through the MST spanning different VLANs and the distribution process can more easily manage the network and use redundant paths; a spanning tree process can only exist in the same VLAN with the process of distribution of the bridge, must use the same MST configuration information to configure a bridge, which makes them able to participate in a group of bridges spanning the process, have the same MST configuration information form

the interconnection of multiple spanning tree bridge (MST) area. Multiple Spanning Tree (MST) uses modified Rapid Spanning Tree (RSTP) protocol - called the Multiple Spanning Tree Protocol (MSTP), MST has the following characteristics: MST constant running a spanning tree called internal spanning tree (IST), IST MST region with the increase of general internal information spanning tree information; MST area for the adjacent single spanning tree (SST) and MST Region as a separate bridge. A bridge running MST provides a single spanning tree bridge and interoperability: * MST bridges run the internal spanning tree (IST), IST MST region with the increase of general internal information spanning tree information. * Internal Spanning Tree (IST) to connect all the MST bridges in the area and is common spanning tree (CST) of a sub-tree, common spanning tree (CST) contains the whole of the bridge domain, MST area for the adjacent single spanning tree (SST ) Bridge and the MST area as a virtual bridge. * General and internal spanning tree (CIST) is within each MST region spanning tree (IST), a common interconnection MST area and single spanning tree bridge spanning a set, it and an MST region is the same as an IST , it and the CST outside an MST is the same; STP, RSTP and MSTP together to build a separate bridge to do for the common and internal spanning tree (CIST) roots. MST in each district to establish and maintain additional spanning tree, spanning tree is the MST of these processes (MSTIS), IST process number is 0, MSTIS process number 1,2,3, etc.; even if the MST area are interconnected, any MSTI also are local and independent in the MST area to another area MSTI; MST MST process and the IST in the border area together constitute CST:

* MSTI MSTP spanning tree information is contained in the records (Mrecord) in, M-record is always encapsulated in the MST's BPDUS in the original calculation by the MSTP spanning tree, called the M (M-tree), M tree only MST area active, M trees and IST in the MST region formed CST border merger through the generation of non-CST VLAN the PVST + BPDU, MST and PVST + to provide interoperability MST supports some of the PVST + extensions: * UplinkFast and BackboneFast invalid way in the MST, but they are included in RSTP in * Support PortFast * BPDUFilter and BPDUGuard supported in MST mode * LoopGuard and RootGuard supported in MST mode * For private VLANs (Pvlan), from the main VLANs VLANs must be mapped to the same spanning tree process.

Understanding Access Control List Logging

Contents Introduction The log and log-input Access Control Entry Options Configuring a Log Update Threshold Limiting ACL LoggingInduced Process Switching Rate Limiting Syslog Messages Configuration Example Optimized ACL Logging References

Introduction
Logging-enabled access control lists (ACLs) provide insight into traffic as it traverses the network or is dropped by network devices. Unfortunately, ACL logging can be CPU intensive and can negatively affect other functions of the network device. There are two primary factors that contribute to the CPU load increase from ACL logging: process switching of packets that match log-enabled access control entries (ACEs) and the generation and transmission of log messages. Using the configuration commands detailed in this document, administrators can strike a balance between traffic visibility and the corresponding impact on device CPU load.

The log and log-input Access Control Entry Options

The log and log-input options apply to an individual ACE and cause packets that match the ACE to be logged. The log-input option enables logging of the ingress interface and source MAC address in addition to the packet's

source and destination IP addresses and ports. The first packet logged via the log or log-input options will generate a syslog message. There are two scenarios in which subsequent log messages will not be sent immediately. If the log-enabled ACE matches another packet with identical characteristics to the packet that generated a log message, the number of packets matched is incremented and then reported at five-minute intervals. Similarly, if any log-enabled ACE in any ACL on any interface matches a packet within one second of the initial log message, the match or matches are counted for five minutes and then reported. These periodic updates will contain the number of packets matched since the previous message. The samples below illustrate the initial message and periodic updates sent by an IOS device with a default configuration using the log ACE option. In the following samples, the first log messages are representative of those created by an IPv4 ACL; the second log messages are representative of those created by an IPv6 ACL.

*May 1 22:12:13.243: %SEC-6-IPACCESSLOGP: list ACL-IPv4E0/0-IN permitted tcp 192.168.1.3(1024) -> 192.168.2.1(22), 1 packet *May 1 22:17:16.647: %SEC-6-IPACCESSLOGP: list ACL-IPv4E0/0-IN permitted tcp 192.168.1.3(1024) -> 192.168.2.1(22), 9 packets *May 3 19:05:38.183: %IPV6-6-ACCESSLOGP: list ACL-IPv6E0/0-IN/10 permitted tcp 2001:DB8::3(1027) -> 2001:DB8:1000::1(22), 1 packet *May 3 19:11:32.619: %IPV6-6-ACCESSLOGP: list ACL-IPv6E0/0-IN/10 permitted tcp 2001:DB8::3(1027) -> 2001:DB8:1000::1(22), 9 packets
Using the log-input ACE option causes additional information to be logged. The following log entries are similar to those shown above; however, they were created using the log-input option and contain the ingress interface and source MAC address information.

*May 1 22:33:38.799: %SEC-6-IPACCESSLOGP: list ACL-IPv4E0/0-IN permitted tcp 192.168.1.3(1025) (Ethernet0/0 000e.9b5a.9839) -> 192.168.2.1(22), 1 packet *May 1 22:39:15.075: %SEC-6-IPACCESSLOGP: list ACL-IPv4E0/0-IN permitted tcp 192.168.1.3(1025) (Ethernet0/0 000e.9b5a.9839) -> 192.168.2.1(22), 9 packets *May 3 19:08:23.027: %IPV6-6-ACCESSLOGP: list ACL-IPv6E0/0-IN/10 permitted tcp 2001:DB8::3(1028) (Ethernet0/0 000e.9b5a.9839) -> 2001:DB8:1000::1(22), 1 packet *May 3 19:13:32.619: %IPV6-6-ACCESSLOGP: list ACL-IPv6E0/0-IN/10 permitted tcp 2001:DB8::3(1028) (Ethernet0/0 000e.9b5a.9839) ->

2001:DB8:1000::1(22), 9 packets
The message identifiers shown above, %SEC-6-IPACCESSLOGP and %IPV6-6-ACCESSLOGP, may vary as a result of the packets being reported. This variation occurs because diverse types of network traffic have different characteristics. For example, TCP and UDP have Layer 4 port information and ICMP has type and code information. The valid identifiers are shown in the following table. Identifier %SEC-6IPACCESSLOGP %SEC-6IPACCESSLOGSP %SEC-6IPACCESSLOGRP %SEC-6IPACCESSLOGDP %SEC-6IPACCESSLOGNP %IPV6-6-ACCESSLOGP %IPV6-6ACCESSLOGSP %IPV6-6ACCESSLOGDP %IPV6-6ACCESSLOGNP IPv4 or IPv6 IPv4 IPv4 IPv4 IPv4 IPv4 IPv6 IPv6 IPv6 IPv6 Applicable Protocols TCP (6) and UDP (17) IGMP (2) IPinIP (4), GRE (47), EIGRP (88), OSPF (89), NOSIP (94), and PIM (103) ICMP (1) Used for all other IPv4 protocols TCP (6), UDP (17), and SCTP (132) TCP (6), UDP (17), SCTP (132), and ICMPv6 (58) with unknown Layer 4 information ICMPv6 (58) Used for all other IPv6 protocols

The list of IANA Assigned Internet Protocol Numbers is available at http://www.iana.org/assignments/protocolnumbers.

Configuring a Log Update Threshold

The ip access-list log-update threshold threshold-in-msgs and ipv6 access-list log-update threshold threshold-in-msgs commands can be used to configure how often syslog messages are generated and sent after the initial packet match. These commands use a threshold described as a number of packets, not as a time interval. This is in contrast to the periodic updates, which are sent every five minutes. A user configurable, timebased threshold does not presently exist. This configured threshold is applied per flow and does not disable the initial match log message or the fiveminute periodic update. The log messages in the following example illustrate the interaction of these functions. These messages were created on a router configured for ip access-list log-update threshold 10 and ipv6 accesslist log-update threshold 10 by a 15-packet IPv4 flow and a 15-packet IPv6 flow.

*May 1 23:02:27.143: %SEC-6-IPACCESSLOGP: list ACL-IPv4E0/0-IN permitted tcp 192.168.1.3(1026) -> 192.168.2.1(80), 1 packet *May 1 23:02:27.187: %SEC-6-IPACCESSLOGP: list ACL-IPv4E0/0-IN permitted tcp 192.168.1.3(1026) -> 192.168.2.1(80), 10 packets *May 1 23:08:16.127: %SEC-6-IPACCESSLOGP: list ACL-IPv4E0/0-IN permitted tcp 192.168.1.3(1026) -> 192.168.2.1(80), 4 packets *May 3 20:27:46.119: %IPV6-6-ACCESSLOGP: list ACL-IPv6E0/0-IN/10 permitted tcp 2001:DB8::3(1029) -> 2001:DB8:1000::1(80), 1 packet *May 3 20:27:47.183: %IPV6-6-ACCESSLOGP: list ACL-IPv6E0/0-IN/10 permitted tcp 2001:DB8::3(1029) -> 2001:DB8:1000::1(80), 10 packets *May 3 20:33:17.195: %IPV6-6-ACCESSLOGP: list ACL-IPv6E0/0-IN/10 permitted tcp 2001:DB8::3(1029) -> 2001:DB8:1000::1(80), 4 packets
The ip access-list log-update threshold threshold-in-msgs command was added to IOS in version 12.0(2)T. The ipv6 access-list log-update threshold threshold-in-msgs command was added to IOS in version 12.2(13)T.

Limiting ACL LoggingInduced Process Switching

The ip access-list logging interval interval-in-ms command was released in IOS version 11.3. This command limits the effects of ACL logginginduced process switching by providing a rate limit for process-switched packets. The interval configured in the command allows only one packet per interval to be process switched no matter how many log-enabled ACEs exist. The interval applies globally, and the process switching limit affects all log-enabled ACEs in all ACLs on all interfaces. Packets that are not process switched will not be examined and will not be accounted for in logging. This functionality requires Cisco Express Forwarding to be enabled using the ip cef global configuration command. The ip access-list logging interval interval-in-ms command does not apply to logging-enabled IPv6 ACLs and there is no IPv6 equivalent. As a result, all packets matching log-enabled ACEs in IPv6 ACLs are process switched. Administrators can determine the number of packets being process switched using the show interface switching EXEC command. Although log messages may not be comprehensive after enabling the ip access-list logging interval command, the counter values displayed using the show access-lists and show ip access-lists commands are updated properly regardless of the presence or configuration of the ip access-list logging interval command.

Rate Limiting Syslog Messages

The logging rate-limit message-rate [except severity-level] command limits the CPU impact of log generation and transmission. This command applies to all syslog messages and is not exclusive to those created through ACL logging. Although this command does limit the number of packets that must be generated and sent by the network device, it does nothing to reduce the number of input packets that are process switched by the device CPU. For this reason, it is imperative that the ip access-list logging interval command be used in conjunction

with the logging rate-limit command. The logging rate-limit command was introduced in IOS 12.1(3)T.

Configuration Example
The following configuration example illustrates the ip access-list logging interval and logging rate-limit commands as well as logging best practices. The ip access-list logging interval 10 command limits log-induced process switching to one packet per 10 milliseconds, or 100 packets per second. The logging rate-limit 100 except 4 command in the example limits log generation and transmission to 100 messages per second except for log levels 4 (warnings) through 0 (emergencies).

! !-- Configure timestamps for syslog messages with date, time, !-- milliseconds, and the time zone configured on the device. ! service timestamps log datetime msec show-timezone localtime ! !-- Enable logging to all enabled destinations. ! logging on ! !-- Disable CPU-intensive logging to the console and terminal. ! no logging console no logging monitor ! !-- Configure logging severity level, log buffer size, and rate !-- limiting. ! logging buffered informational logging buffered 16386 logging rate-limit 100 except 4 ! !-- Configure the host to which syslog messages will be sent. ! logging 192.168.1.10 ! !-- Configure the interval between process-switched

packets. ! ip access-list logging interval 10 ! Optimized ACL Logging

The Catalyst 6500 series switches and Cisco 7600 series routers include hardware support for ACL logging. This feature, known as optimized ACL logging (OAL), was added to Cisco IOS Software version 12.2(17d)SXB and is available on devices that include the Policy Feature Card 3 (PFC3). It should be noted that OAL applies only to unicast IPv4 packets. All other packet types will be logged in software on the Multilayer Switch Feature Card (MSFC).To allow OAL to function properly, the mls rate-limit unicast ip icmp unreachable acl-drop 0 global configuration command must be entered. More information about OAL is available at Optimized ACL Logging with a PFC3.

References
Logging System Messages http://www.cisco.com/en/US/docs/ios/netmgmt/configuration/guide/nm_troubleshooting_ps6350_TSD_Products _Configuration_Guide_Chapter.html#wp1054847 Configuring IP Access Lists http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_tech_note09186a00800a5b9a.shtml IANA Assigned Internet Protocol Numbers http://www.iana.org/assignments/protocol-numbers Optimized ACL Logging with a PFC3 http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/acl.html#w p1090858