Troubleshooting Performance and Connectivity
Cisco provides software and hardware tools to help perform complex troubleshooting and performance analyses. The ability to monitor and analyze the traffic on your network is the first step to optimizing performance. Traffic monitoring enables you to identify bottlenecks, underused resources, and places where you might implement improvements such as port aggregation (increasing link bandwidth by combining several physical ports into a single virtual link). Optimizing the performance of your Cisco multilayer switched network helps to maximize use of existing resources and reduces unnecessary duplication of network components. This ensures that the network runs efficiently and supports multiple solutions. The troubleshooting and monitoring tools also play a critical part in preventing or thwarting any security attacks. This section explains some of the most commonly used features to monitor and understand performance and aid in troubleshooting Cisco multilayer switched networks.
Techniques to Enhance Performance
Performance management includes maintaining internetwork performance at acceptable levels by measuring and managing various network performance variables. This section covers some of the techniques used to enhance network performance.
Critical performance-management issues are as follows:
- User/application performance: For most users, response time is the critical performance success factor. This variable might shape the perception of network success by both your users and application administrators.
- Capacity planning: The process of determining future network resource requirements to prevent a performance or availability impact on business-critical applications.
- Proactive fault management: Involves both responding to faults as they occur and implementing solutions that prevent faults from affecting performance.
The critical success tasks that need to be performed for performance management are
- Gather a baseline for both network and application data. This step aids in troubleshooting performance issues during network operations. A typical router or switch baseline report would include capacity issues related to CPU, memory, buffer management, link utilization, and throughput. In addition, other types of baseline data need to be included depending on your defined objectives. For instance, an availability baseline would demonstrate increased stability and availability of the network environment. Perform a baseline comparison between old and new environments to verify solution requirements. Develop a good network topology diagram as part of this step.
- Perform a what-if analysis on your network and applications. A what-if analysis involves modeling and verifying solutions. Before adding a new solution to the network, document some of the alternatives. The documentation for this analysis includes major questions, methodology, data sets, and configuration files. The essential what-if analysis should contain enough information for someone other than the author to re-create the solution.
- Perform exception reporting for capacity issues. If capacity requirements outstrip available resources, a mechanism should be in place to notify network administrators of that fact. This could include setting up periodical SNMP polling on some key parameters of the network devices, such as CPU and memory, and having the network management station alert the administrator if anomalous behavior occurs.
- Determine the network management overhead for all proposed or potential network management services. Network management services affect network and application performance. Make sure that the network measurement planning takes into account the additional resources required to perform measurement and management. For instance, SNMP polling of devices needs CPU cycles from the switch or router. If the device is already running at an above-average CPU utilization, the management services might further strain the device. In addition, the bandwidth required for these management functions should be considered if the links are heavily utilized to avoid oversubscription.
- Analyze the capacity information. Examine all the data you have gathered to determine capacity and management requirements. This is the most important task, forming the basis for the next step.
- Periodically review capacity information, baseline, and exceptions for the network and applications. Periodically repeat your analysis to identify changes in network use and growth patterns. The time interval chosen for measurement depends on the nature of the network measured and can vary over weekdays versus weekends and also on a monthly or yearly basis. Reviewing the capacity periodically is critical to avoid unexpected network or application downtime and to plan for future growth.
- Maintain upgrade or tuning procedures set up to handle capacity issues on both a reactive and longer-term basis.
Set up procedures to handle future capacity requirements. For instance, if you think that your network might need another link addition to a port channel based on certain thresholds, make sure that you plan for this change. Having the cabling and configuration procedure in place in advance minimizes the time required to make the change and ensures that the network runs smoothly without major downtime.
The remainder of this section focuses on the various Cisco Catalyst switches and modules that assist in performance management and troubleshooting network exceptions to ensure optimal performance through monitoring and preventing any security attacks.
Monitoring Performance with SPAN and VSPAN
The Switched Port Analyzer (SPAN) feature is an important aid in performance management and troubleshooting. SPAN copies network traffic from a VLAN or group of ports to a selected port. This port is usually connected to a network analyzer, such as a SwitchProbe device, a workstation running a packet-capturing application, or a remote monitoring (RMON) probe. SPAN does not affect the switching of network traffic on source ports or VLANs.
Local SPAN involves configuring source ports, source VLANs, and destination ports on the same Catalyst switch. Local SPAN, which involves configuring one or more VLANs as the source of the SPAN session, is also called VSPAN. All ports in the source VLANs become source ports in a VSPAN. Local SPAN copies traffic from one or more source ports in any VLAN or from one or more VLANs to a destination port for analysis. For example, as shown in Figure 6-33, the switch copies all traffic transmitted to and from Port 3/1 (the source port) to Port 3/5 (the destination port). A workstation running a packet-capturing application on Port 3/5 thus receives all network traffic received and transmitted on port 3/1.
SPAN sessions support the monitoring of only ingress network traffic (ingress SPAN), only egress network traffic (egress SPAN), or traffic flowing in both directions. Ingress SPAN copies network traffic received by the source ports and VLANs for analysis to the destination port. Egress SPAN copies network traffic transmitted from the source ports and VLANs to the destination port. When the both keyword is used, SPAN copies the network traffic received and transmitted by the source ports and VLANs to the destination port.
By default, local SPAN monitors all network traffic, including multicast and bridge protocol data unit (BPDU) frames.
SPAN supports the configuration of both switched and routed ports as SPAN source ports. SPAN can monitor one or more source ports in a single SPAN session. Configuring source ports in any VLAN is allowed. Trunk ports are valid source ports mixed with nontrunk source ports. However, trunk encapsulation (dot1q or ISL) configuration of the destination port determines the encapsulation of the packets forwarded to the destination port. If the destination port is not configured for trunk encapsulation, the ISL or dot1q is removed from the frame before egress transmission.
| Note |
|
The following additional guidelines or restrictions apply to local SPAN:
- Both Layer 2 switched ports (LAN ports configured with the switchport command) and Layer 3 ports (LAN ports configured with the no switchport command) can be configured as source or destination ports in Cisco IOS–based switches.
- A port can act as the destination port for only one SPAN session.
- A port cannot be configured as a destination port if it is a source port of a span session.
- Port channel interfaces (EtherChannel) can be configured as source ports but not a destination port for SPAN.
- SPAN supports configuration of source ports belonging to different VLANs.
- Traffic direction is “both” by default for SPAN sources.
- Destination ports never participate in a spanning-tree instance. Local SPAN includes BPDUs in the monitored traffic, so any BPDUs seen on the destination port are from the source port. As a result, SPAN destination ports should not be connected to another switch because this might cause a network loop.
- Destination ports get a copy of all packets switched through the switch regardless of whether the packets actually leave the switch due to STP blocking state on an egress port.
The following additional guidelines or restrictions apply to VSPAN:
- VSPAN sessions, with both ingress and egress options configured, forward duplicate packets from the source port only if the packets get switched in the same VLAN. One copy of the packet is from the ingress traffic on the ingress port, and the other copy of the packet is from the egress traffic on the egress port.
- VSPAN monitors only traffic that leaves or enters Layer 2 ports in the VLAN:
- Routed traffic that enters a monitored VLAN is not captured if the SPAN session is configured with that VLAN as an ingress source because traffic never appears as ingress traffic entering a Layer 2 port in the VLAN.
- Traffic that is routed out of a monitored VLAN, which is configured as an egress source in a SPAN session, is not captured because the traffic never appears as egress traffic leaving a Layer 2 port in that VLAN.
-
On Cisco IOS-based switches, use the following commands in configuration mode to configure local SPAN.
monitor session session-id source {interface interface-id | vlan vlan-id [,][-]
{rx | tx | both}
monitor session session-id destination interface interface-id [encapsulation
{dot1q | isl}] [ingress vlan vlan-id]
Example 6-23 shows the configuration and verification of a local SPAN session on a Cisco IOS–based switch for the topology in Figure 6-33. The source interface is FastEthernet 3/1, and the destination interface is FastEthernet 3/5.
Example 6-23: Local SPAN Configuration and Verification on Cisco IOS–Based Catalyst Switches
4506(config)# monitor session 1 destination interface FastEthernet 3/5
4506(config)# end
4506# show monitor session 1
Session 1
-----
Type : Local Session
Source Ports :
Both : Fa3/1
Destination Ports : Fa3/5
Encapsulation : Native
Ingress : Disable
Figure 6-34 shows a scenario in which the administrator needs to troubleshoot the traffic flow between a client in VLAN 10 and server in VLAN 20. Example 6-24 shows the configuration of a VSPAN session on a Cisco IOS–based Catalyst switch with rx-only traffic for VLAN 10 and tx-only traffic for VLAN 20 and destination port interface FastEthernet 3/4.
Example 6-24: VSPAN Configuration and Verification on Cisco IOS–Based Catalyst Switches
cat4k(config)# monitor session 1 source vlan 20 tx
cat4k(config)# monitor session 1 destination interface FastEthernet 3 /4
cat4k# show monitor session 1
Session 1
-----
Type : Local Session
Source VLANs :
RX Only : 10
TX Only : 20
Destination Ports : Fa3/4
Encapsulation : Native
Ingress : Disabled
Using SPAN to Monitor the CPU Interface of Switches
The ability to span the CPU comes in handy when you are trying to troubleshoot traffic destined to the CPU of the Supervisor Engine. Traffic destined to the Supervisor Engine includes the control traffic, such as BPDUs, SNMP traffic, and so on. Normal switch traffic is not forwarded to the CPU and is handled via hardware switching. Captured traffic also includes Telnet traffic and broadcast traffic seen in the same subnet as the Supervisor Engine. It could help to identify any DoS attack on the Switch CPU.
To configure a SPAN to monitor the CPU traffic on the Catalyst 4500 switches, use the keyword cpu in the monitor session source configuration, as shown in Example 6-25.
Example 6-25: Configuration and Verification of SPAN to Monitor the CPU Port on Catalyst 4500 Switches
both Monitor received and transmitted traffic
queue SPAN source CPU queue
rx Monitor received traffic only
tx Monitor transmitted traffic only
4506(config)# monitor session 1 destination interface fastEthernet 3/21
4506(config)# end
4506# show monitor session 1
Session 1
-----
Type : - Source Ports :
Both : CPU Destination Ports : Fa3/21
Encapsulation : Native
Ingress : Disabled
Monitoring Performance with RSPAN
Remote SPAN (RSPAN) is similar to SPAN, but it supports source ports, source VLANs, and destination ports on different switches, which provide remote monitoring of multiple switches across a switched network. Each RSPAN session carries the SPAN traffic over a user-specified RSPAN VLAN. This VLAN is dedicated for that RSPAN session in all participating switches.
The RSPAN source ports can be trunks carrying the RSPAN VLAN. Local SPAN and RSPAN do not monitor the RSPAN traffic in the RSPAN VLAN seen on a source trunk. For example, if the source port carries VLAN 1 through 10, with 10 being the RSPAN VLAN, the local span of that port does not mirror the RSPAN traffic to the destination port. However, the local SPAN correctly monitors traffic for the other VLANs 1 through 9. To receive the RSPAN traffic on a destination port, the port must be configured as the RSPAN destination port for that RSPAN VLAN.
The destination ports in the RSPAN VLAN receive RSPAN traffic from the source ports or source VLANs. The source ports or VLANs in an RSPAN session may be different on different source switches, but they must be the same for all sources on each RSPAN source switch. Each RSPAN source switch must have either ports or VLANs as RSPAN sources.
Figure 6-35 shows an RSPAN configuration across multiple switches. Access Switches A and B act as the RSPAN source, distribution Switch C acts as the intermediate switch, and data center Switch D acts as the RSPAN destination switch where the probe is connected. Without RSPAN, the user must go to each of the closet switches and manually configure local SPAN to monitor the traffic. For example, the administrator charged with monitoring Ports A1 and A2 needs to configure a local SPAN session on Switch A and then configure a separate local SPAN session to monitor /ports B1, B2, and B3. This type of configuration is obviously not scalable for geographically separated switch closets; RSPAN enables the administrator to monitor these remote ports from the data center switch. In this case, the trunks between the switches carry RSPAN VLAN traffic for the RSPAN to work correctly.
RSPAN consists of an RSPAN source session, an RSPAN VLAN, and an RSPAN destination session. It is advisable to configure separate RSPAN source sessions and destination sessions on different network devices. To configure an RSPAN source session on one network device, associate a set of source ports and VLANs with an RSPAN VLAN. To configure an RSPAN destination session on another device, associate the destination port with the RSPAN VLAN.
In addition to the guidelines and restrictions that apply to SPAN, these guidelines apply to RSPAN:
- Configure the RSPAN VLANs in all source, intermediate, and destination network devices. If enabled, the VLAN Trunking Protocol (VTP) can propagate configurations of VLANs numbered 1 through 1024 as RSPAN VLANs. Manually configure VLANs numbered higher than 1024 as RSPAN VLANs on all source, intermediate, and destination network devices.
- Switches impose no limit on the number of RSPAN VLANs configured.
- Configure any VLAN as an RSPAN VLAN as long as all participating network devices support configuration of RSPAN VLANs, and use the same RSPAN VLAN for each RSPAN session.
RSPAN configuration involves the following two steps:
On Cisco IOS–based Catalyst switches, use the following commands in configuration mode to configure RSPAN.
On the source switch:
monitor session session source {interface interface-id | vlan vlan-id} [,][-] {rx |
tx | both}
monitor session session destination remote vlan vlan-id
On the destination switch:
monitor session session source remote vlan vlan-id
monitor session session destination interface interface-id [encapsulation {dot1q
| isl}] [ingress vlan vlan-id]
Example 6-26 shows the configuration and verification of an RSPAN session between two Catalyst 2950 switches. Switch 2950-1 is the source switch for the RSPAN session, and 2950-2 is the destination switch with the network analyzer. Only the Catalyst 2950 and Catalyst 2955 series switches require an additional port to be designated as the reflector port. The reflector should be left unconnected and is used internally by the Catalyst 2950 for implementing RSPAN. In Example 6-26, the reflector port is interface FastEthernet 0/24. The reflector port is used on the Catalyst 2950 switches as a way to overcome the limitation of that switch architecture for SPAN. Figure 6-36 depicts the network scenario for this example.
Example 6-26: RSPAN Configuration and Verification on Cisco IOS–Based Catalyst Switches
2950-1(config-vlan)# remote-span
2950-1(config-vlan)# exit
2950-1(config)# monitor session 1 source interface FastEthernet 0/1
2950-1(config)# monitor session 1 destination remote vlan 100 reflector-port
FastEthernet 0/24
2950-1(config)# in FastEthernet 0/2
2950-1(config-if)# switchport mode trunk
2950-1(config-vlan)# end
2950-1#
2950-2(config)# monitor session 2 source remote vlan 100
2950-2(config)# monitor session 2 destination interface FastEthernet 0/3
2950-2(config)# in FastEthernet 0/2
2950-2(config-if)# switchport mode trunk
2950-2(config-vlan)# end
2950-2#
2950-1# show monitor
Session 1
-----
Type : Remote Source Session
Source Ports :
Both : Fa0/1
Reflector Port : fa0/24
Dest RSPAN VLAN : 100
2950-1# show interfaces trunk
Port Mode Encapsulation Status Native vlan
Fa0/2 on 802.1q trunking 1
Port Vlans allowed on trunk
Fa0/2 1-4094
Port Vlans allowed and active in management domain
Fa0/2 1-30,100
Port Vlans in spanning tree forwarding state and not pruned
Fa0/2 1-30,100
2950-2# show interfaces trunk
Port Mode Encapsulation Status Native vlan
Fa0/2 on 802.1q trunking 1
Port Vlans allowed on trunk
Fa0/2 1-4094
Port Vlans allowed and active in management domain
Fa0/2 1-30,100
Port Vlans in spanning tree forwarding state and not pruned
Fa0/2 1-30,100
2950-2# show monitor session 2
Session 2
-----
Type : Remote Destination Session
Source RSPAN VLAN : 100
Destination Ports : Fa0/3
Encapsulation: Native
Ingress: Disabled
Monitoring Performance with ERSPAN
Enhanced Remote SPAN (ERSPAN) is similar to RSPAN, but it supports source ports, source VLANs, and destination ports on different switches, even across the Layer 3 boundary, which provides remote monitoring of multiple switches across a switched or routed network. Each ERSPAN session carries the SPAN traffic over a GRE tunnel. The source and destination switches must support GRE in hardware. Currently, the ERSPAN feature is supported only on the Catalyst 6500 family of switches.
To configure an ERSPAN source session on one switch, you associate a set of source ports or VLANs with a destination IP address, ERSPAN ID number, and, optionally, a VRF name. To configure an ERSPAN destination session on another switch, you associate the destination ports with the source IP address, ERSPAN ID number, and, optionally, a VRF name.
ERSPAN source sessions do not copy locally sourced RSPAN VLAN traffic from source trunk ports that carry RSPAN VLANs. ERSPAN source sessions do not copy locally sourced ERSPAN GRE-encapsulated traffic from source ports.
Each ERSPAN source session can have either ports or VLANs as sources, but not both.
The ERSPAN source session copies traffic from the source ports or source VLANs and forwards the traffic using routable GRE-encapsulated packets to the ERSPAN destination session. The ERSPAN destination session switches the traffic to the destination ports, as shown in Figure 6-37.
The following guidelines and restrictions apply to ERSPAN:
- The payload of a Layer 3 ERSPAN packet is a copied Layer 2 Ethernet frame, excluding any ISL or 802.1Q tags.
- ERSPAN adds a 50-byte header to each copied Layer 2 Ethernet frame and replaces the 4-byte cyclic redundancy check (CRC) trailer.
- ERSPAN supports jumbo frames that contain Layer 3 packets of up to 9202 bytes. If the length of the copied Layer 2 Ethernet frame is greater than 9170 bytes (9152-byte Layer 3 packet), ERSPAN truncates the copied Layer 2 Ethernet frame to create a 9202-byte ERSPAN Layer 3 packet.
ERSPAN configuration involves the following two steps:
|
|
|
|
|
|
Example 6-27 shows the configuration and verification of ERSPAN on the source and destination switches for the scenario shown in Figure 6-38, where the IDS/NAM is connected to a switch that is separated from the source switch through a Layer 3 network.
Example 6-27: ERSPAN Configuration and Verification on a Catalyst 6500 Switch
Switch1(config-mon-erspan-src)# source interface gigabitethernet 6/1
Switch1(config-mon-erspan-src)# destination
Switch1(config-mon-erspan-src-dst)# ip address 10.10.10.10
Switch1(config-mon-erspan-src-dst)# origin ip address 20.20.20.200
Switch1(config-mon-erspan-src-dst)# erspan-id 111
Switch1# show monitor session 66
Session 66
-----
Type : ERSPAN Source Session
Status : Admin Enabled
Source Ports :
Both : Gi6/1
Destination IP Address : 10.10.10.10
Destination ERSPAN ID : 111
Origin IP Address : 20.20.20.200
Switch2(config)# monitor session 60 type erspan-destination
Switch2(config-erspan-dst)# destination interface gigabitethernet 8/2
Switch2(config-erspan-dst)# source
Switch2(config-erspan-dst-src)# ip address 10.10.10.10
Switch2(config-erspan-dst-src)# erspan-id 111
Switch2# show monitor session 60
Session 60
----------
Type : ERSPAN Destination Session
Status : Admin Enabled
Destination Ports : Gi8/2
Source IP Address : 10.10.10.10
Source ERSPAN ID : 111
Monitoring Performance Using VACLs with the Capture Option
The Catalyst 6500 family of switches offers an additional feature to monitor traffic flows through the switch. SPAN, VSPAN, and RSPAN configuration applies to all traffic on the source port or source VLAN in one or both directions. Using VACLs with the capture option, the network analyzer receives only a copy of traffic matching the configured ACL. Because the ACL might match Layers 2, 3, or 4 information, the VACL with the capture option offers a useful and powerful complementary value to the SPAN and RSPAN features.
The VACL with the capture option on the Catalyst 6500 family of switches also overcomes the session number limit. The VACL with the capture option works by a user setting up a VACL to match the interesting traffic and then configuring the capture port, which receives the copy of the matched traffic.
The following configuration guidelines apply to using the capture option in VACL:
- The capture port needs to be in the spanning-tree forwarding state for the VLAN.
- The switch has no restriction on the number of capture ports.
- The capture port captures only packets permitted by the configured ACL.
- Capture ports transmit only traffic belonging to the capture port VLAN. To capture traffic going to many VLANs, configure the capture port as a trunk carrying the required VLANs.
In Figure 6-39, a user is troubleshooting a session timeout between a server with IP address 10.1.1.1 and client with IP address 10.1.1.2.
Example 6-28 shows the VACL with the capture option configuration and verification for the troubleshooting scenario presented in Figure 6-39 on the Cisco IOS–based Catalyst 6500 family of switches. In Example 6-28, the bcmsnvacl defined by the access-map command is applied on VLAN 1. Example 6-28 also shows configuring the network analyzer port, GigabitEthernet 3/26, to receive the captured frames on VLAN 1 using the switchport capture command.
Example 6-28: Configuration and Verification of VACL with the Capture Option
cat6k(config)# access-list 101 permit ip host 10.1.1.2 host 10.1.1.1
cat6k(config)# vlan access-map bcmsnvacl
cat6k(config-access-map)# match ip address 101
cat6k(config-access-map)# action forward capture
cat6k(config-access-map)# exit
cat6k(config)# vlan filter bcmsnvacl vlan-list 1
cat6k(config)# in GigabitEthernet 3/26
cat6k(config-if)# switchport
cat6k(config-if)# switchport capture allowed vlan 1
cat6k(config-if)# switchport capture
cat6k(config-if)# end
cat6k# show vlan access-map
Vlan access-map "bcmsnvacl" 10
match: ip address 101
action: forward capture
cat6k# show vlan filter
VLAN Map bcmsnvacl:
Troubleshooting Using L2 Traceroute
Layer 2 (L2) traceroute is equivalent to the IP traceroute command except that this trace is for Layer 2 connectivity troubleshooting based on MAC addresses. L2 traceroute is a powerful tool for determining the path of a frame through the Layer 2 topology. The administrator needs to know only the source and destination MAC addresses of the devices in question. L2 traceroute also identifies the physical connection of any device in the network, freeing the administrator from having to manually check each switch.
To illustrate a typical troubleshooting scenario, consider a situation in which the connection between a server and client is slow. To troubleshoot this problem, identify the source and destination IP addresses of this session. When the IP addresses are determined, you can easily find the MAC address of these devices by consulting the ARP tables of the workstation, client, and adjacent routers. Next, you need to locate the ports where the actual client and server are connected in the Layer 2 infrastructure. If, however, the L2 topology is large, it might be difficult to find out where these two devices connect with just their IP addresses and MAC addresses unless the ports are clearly labeled and the network is clearly organized.
L2 traceroute is useful in these situations to trace the device connection into the network using just the MAC addresses. The L2 traceroute command also works with IP addresses specified as part of the command for directly connected subnet devices.
L2 traceroute requires the following conditions to function properly:
- All the switches and interfaces in the network require CDP to be running and functioning properly.
- All intermediate switches between the source and device in question must support the L2 traceroute feature.
In Figure 6-40, a user needs to identify the performance and path on a hop-by-hop basis for a specific server and client exhibiting slow file-transfer performance. Example 6-29 shows a user using the L2 traceroute feature with the source MAC address of the server, 0000.0000.0007, to the destination MAC address of the client, 0000.0000.0011. To perform L2 tracerouting, the user can choose any switch in the network as long as that switch has both the source and destination MAC addresses in the MAC address table. In this example, the user performed the L2 traceroute command on the Catalyst 2950 of Figure 6-40.
Example 6-29: L2 traceroute Output from Cisco IOS–Based Switches
Source 0000.0000.0007 found on 4503
4503 (14.18.2.132) : Fa3/48 => Fa3/2
6500 (14.18.2.145) : 3/40 => 3/24
2950G (14.18.2.176) : Fa0/24 => Fa0/23
2948G (14.18.2.91) : 2/2 => 2/24
Destination 0000.0000.0011 found on 2948G Layer 2 trace completed
Enhancing Troubleshooting and Recovery Using Cisco IOS Embedded Event Manager
The Embedded Event Manager (EEM) feature has the capability to monitor events happening in the switch using embedded event collectors. The events tracked could be a generation of a syslog message, incrementing of a certain counter, or the result of a Generic Online Diagnostic (GOLD) test. Based on the detection of these events, custom actions could be performed, including configuration changes, email notification, or paging the system administrator.
EEM greatly improves troubleshooting and recovery of network failures by providing the capability not only to detect a great variety of events in the switch but also to take immediate actions without user invention.
Table 6-10 shows a sample set of events and typical actions that can be automated with EEM. It is important to remember that actions based on an event are fully user configurable.
|
| |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Open table as spreadsheetThe EEM feature is configurable in the following two ways:
- EEM using applet CLI: Cisco IOS CLI–based configuration that provides a limited set of actions and detection
- EEM using Tool Command Language (TCL) script: Provides full flexibility in defining the events and the subsequent actions
EEM enables customers to define their own custom TCL script that can be executed on the Catalyst switch. For more information about EEM, refer to the following documentation on Cisco.com (requires a Cisco.com username and password): “Embedded Event Manager 2.0,” www.cisco.com/en/US/partner/products/sw/iosswrel/ps1838/products_feature_guide09186a008025951e.html.
Performance Monitoring Using the Network Analysis Module in the Catalyst 6500 Family of Switches
The Network Analysis Module (NAM) for the Cisco Catalyst 6500 family of switches is part of the end-to-end network management and monitoring solution. Network administrators need to collect statistics about voice, video, and data applications. The NAM gathers multilayer information about voice, video, and data flows up through the application layer, helping to simplify the task of managing multiservice switched LANs that support a variety of data, voice, and video applications.
The NAM monitors and analyzes network traffic using Remote Network MONitoring (RMON) Management Information Base (MIB). RMON MIB was developed by IETF to support monitoring and protocol analysis of LANs. The original version (sometimes referred to as RMON1) focused on OSI Layer 1 and Layer 2 information in Ethernet and Token Ring networks. It has been extended by RMON2, which adds support for network- and application layer monitoring and by SMON, which adds support for switched networks.
The embedded NAM Traffic Analyzer Software in the NAM gives any web browser access to the RMON1 (RFC 1757), RMON2 (RFC 2021), SMON (RFC 2613), DSMON (RFC 3287), and voice-monitoring features of the NAM. Furthermore, the NAM Software provides the ability to troubleshoot and monitor network availability and health.
In addition to extensive MIB support, the NAM can also monitor individual Ethernet VLANs, which enables the NAM to serve as an extension to the basic RMON support provided by the Catalyst Supervisor Engine.
The TrafficDirector application, or any other IETF-compliant RMON application, can access link, host, protocol, and response-time statistics for capacity planning and real-time application protocol monitoring. Filters and capture buffers are also available for troubleshooting the network.
The NAM supports having multiple data sources simultaneously. The NAM can use the following data sources for traffic analyses:
- Ethernet, Fast Ethernet, Gigabit Ethernet, trunk port, or Fast EtherChannel; SPAN or RSPAN source port; and VSPAN and VACL with the capture option.
- Locally generated NetFlow Data Export (NDE) records. The NDE feature collects individual flow statistics of the traffic switched through the switch. NDE can also export the collected information to external flow collectors such as the NetFlow FlowCollector application. The NAM is another example of such a flow collector.
Summary
Security is a primary concern in maintaining a secure, stable, and uninterrupted network. Network security goes far beyond the information in this chapter and includes topics such as intrusion detection, firewalls, virus protection, and operating system patching. Unless you recognize and understand the importance of network security, your network is at risk. The following list summarizes the aspects and recommended practices for avoiding, limiting, and minimizing network vulnerabilities strictly related to Catalyst switches as a single network entity:
- Layer 2 attacks vary in nature and include spoofing attacks, VLAN attacks, MAC flood attacks, and switch device attacks, among others.
- Use strong passwords with SSH access instead of Telnet exclusively to Cisco network devices.
- Disable unused services such as TCP and UDP small services where appropriate.
- Use AAA for centralized authentication, authorization, and accounting of network devices and remote access.
- Use an access control feature such as 802.1X or port security to restrict workstation access to Catalyst switches.
- Use DHCP snooping to prevent rogue DHCP servers on the network.
- Use IPSG and DAI with DHCP snooping to prevent IP address and ARP spoofing attacks.
- Apply management ACLs to limit remote access to Cisco network devices.
- Apply data plane security ACLs to filter unwarranted traffic in the network.
- Use private VLANs where appropriate to limit communication in specific VLANs.
- Use troubleshooting and monitoring tools such as SPAN, VSPAN, RSPAN, ERSPAN, L2 Traceroute, EEM, and NAM to ensure proper network performance.
0 comments
Post a Comment