Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
After a problem has been clearly defined, the first step in diagnosing that problem is
collecting information, as described in Chapter 2, “Introduction to Troubleshooting
Processes.” Because the collection of information can be one of the most time consuming
of the troubleshooting processes, the ability to quickly collect appropriate information
becomes a valuable troubleshooting skill. This section introduces a collection of basic
Cisco IOS commands useful in gathering information and discusses the filtering of irrelevant
information from the output of those commands. Also included in this section are
commands helpful in diagnosing connectivity and hardware issues.
Filtering the Output of show Commands
Cisco IOS offers multiple show commands useful for gathering information. However,
many of these show commands produce a large quantity of output.
Consider the output shown in Example 3-1. The output from the show processes cpu
command generated approximately 180 lines of output, making it challenging to pick out
a single process.
Example: show processes cpu Command
Example 3-1 show processes cpu Command Output
R1# show processes cpu
CPU utilization for five seconds: 0%/0%; one minute: 0%; five minutes: 0%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
1 4 3 1333 0.00% 0.00% 0.00% 0 Chunk Manager
2 7245 1802 4020 0.08% 0.08% 0.08% 0 Load Meter
3 56 2040 27 0.00% 0.00% 0.00% 0 OSPF Hello 1
4 4 1 4000 0.00% 0.00% 0.00% 0 EDDRI_MAIN
5 21998 1524 14434 0.00% 0.32% 0.25% 0 Check heaps
6 0 1 0 0.00% 0.00% 0.00% 0 Pool Manager
7 0 2 0 0.00% 0.00% 0.00% 0 Timers
8 0 1 0 0.00% 0.00% 0.00% 0 Crash writer
9 0 302 0 0.00% 0.00% 0.00% 0 Environmental mo
10 731 1880 388 0.00% 0.00% 0.00% 0 ARP Input
...OUTPUT OMITTED...
171 0 1 0 0.00% 0.00% 0.00% 0 lib_off_app
172 4 2 2000 0.00% 0.00% 0.00% 0 Voice Player
173 0 1 0 0.00% 0.00% 0.00% 0 Media Record
174 0 1 0 0.00% 0.00% 0.00% 0 Resource Measure
175 12 6 2000 0.00% 0.00% 0.00% 0 Session Applicat
176 12 151 79 0.00% 0.00% 0.00% 0 RTPSPI
54 CCNP TSHOOT 642-832 Official Certification Guide
177 4 17599 0 0.00% 0.00% 0.00% 0 IP NAT Ager
178 0 1 0 0.00% 0.00% 0.00% 0 IP NAT WLAN
179 8 314 25 0.00% 0.00% 0.00% 0 CEF Scanner
Perhaps you were only looking for CPU utilization statistics for the Check heaps process.
Because you know that the content of the one line you are looking for contains the text
Check heaps, you could take the output of the show processes cpu command and pipe
that output (that is, use the | character) to the include Check heaps statement. The piping
of the output causes the output to be filtered to only include lines that include the text
Check heaps, as demonstrated in Example 3-2. This type of filtering can help troubleshooters
more quickly find the data they are looking for.
Example 3-2 Filtering the show processes cpu Command Output
R1# show processes cpu | include Check heaps
5 24710 1708 14467 1.14% 0.26% 0.24% 0 Check heaps
Example: show ip interfaces brief Command
Similar to piping output to the include option, you could alternatively pipe output to the
exclude option. The exclude option can display all lines of the output except lines containing
the string you specify. For example, the show ip interfaces brief command can
display IP address and status information for all interfaces on a router, as shown in
Example 3-3.
Example 3-3 show ip interface brief Command Output
R1# show ip interface brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 192.168.1.11 YES NVRAM up up
Serial0/0 unassigned YES NVRAM administratively down down
FastEthernet0/1 192.168.0.11 YES NVRAM up up
Serial0/1 unassigned YES NVRAM administratively down down
NVI0 unassigned YES unset up up
Loopback0 10.1.1.1 YES NVRAM up up
Notice in Example 3-3 that some of the interfaces have an IP address of unassigned. If
you want to only view information pertaining to interfaces with assigned IP addresses,
you can pipe the output of the show ip interface brief command to exclude unassigned,
as illustrated in Example 3-4.
Example 3-4 Filtering Output from the show ip interface brief Command
R1# show ip interface brief | exclude unassigned
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 192.168.1.11 YES NVRAM up up
FastEthernet0/1 192.168.0.11 YES NVRAM up up
Loopback0 10.1.1.1 YES NVRAM up up
Example: Jumping to the First Occurrence of a String in show Command
Output
As another example, you might be troubleshooting a routing protocol issue and want to
see the section of your running configuration where the routing protocol configuration
begins. Piping the output of the show running-config command to begin router, as
shown in Example 3-5, skips the initial portion of the show running-config output and
begins displaying the output where the routing protocol configuration begins.
Example 3-5 Filtering the Output from the show running-config Command
R1# show running-config | begin router
router ospf 1
log-adjacency-changes
network 0.0.0.0 255.255.255.255 area 0
...OUTPUT OMITTED...
Example: The show ip route Command
Another command that often generates a lengthy output, especially in larger environments,
is the show ip route command. As an example, consider the show ip route output
presented in Example 3-6.
Example 3-6 Sample show ip route Command Output
R1# show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
172.16.0.0/30 is subnetted, 2 subnets
O 172.16.1.0 [110/65] via 192.168.0.22, 00:50:57, FastEthernet0/1
www.CareerCert.info
www.CareerCert.info
www - CareerCert - info
56 CCNP TSHOOT 642-832 Official Certification Guide
O 172.16.2.0 [110/65] via 192.168.0.22, 00:50:57, FastEthernet0/1
10.0.0.0/8 is variably subnetted, 6 subnets, 3 masks
O 10.2.2.2/32 [110/2] via 192.168.0.22, 00:50:57, FastEthernet0/1
O 10.1.3.0/30 [110/129] via 192.168.0.22, 00:50:57, FastEthernet0/1
O 10.3.3.3/32 [110/66] via 192.168.0.22, 00:50:57, FastEthernet0/1
O 10.1.2.0/24 [110/75] via 192.168.0.22, 00:50:58, FastEthernet0/1
C 10.1.1.1/32 is directly connected, Loopback0
O 10.4.4.4/32 [110/66] via 192.168.0.22, 00:50:58, FastEthernet0/1
C 192.168.0.0/24 is directly connected, FastEthernet0/1
C 192.168.1.0/24 is directly connected, FastEthernet0/0
Although the output shown in Example 3-6 is relatively small, some IP routing tables contain
hundreds or even thousands of entries. If, for example, you wanted to determine if a
route for network 172.16.1.0 were present in a routing table, you could issue the command
show ip route 172.16.1.0, as depicted in Example 3-7.
Perhaps you were looking for all subnets of the 172.16.0.0/16 address space. In that event,
you could specify the subnet mask and the longer-prefixes argument as part of your command.
Such a command, as demonstrated in Example 3-8, shows all subnets of network
172.16.0.0/16, including the major classful network of 172.16.0.0/16.
Example 3-7 Specifying a Specific Route with the show ip route Command
R1# show ip route 172.16.1.0
Routing entry for 172.16.1.0/30
Known via “ospf 1”, distance 110, metric 65, type intra area
Last update from 192.168.0.22 on FastEthernet0/1, 00:52:08 ago
Routing Descriptor Blocks:
* 192.168.0.22, from 10.2.2.2, 00:52:08 ago, via FastEthernet0/1
Route metric is 65, traffic share count is 1
Example 3-8 Filtering Output from the show ip route Command with the longer-prefixes
Option
R1#show ip route 172.16.0.0 255.255.0.0 longer-prefixes
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
172.16.0.0/30 is subnetted, 2 subnets
O 172.16.1.0 [110/65] via 192.168.0.22, 00:51:39, FastEthernet0/1
O 172.16.2.0 [110/65] via 192.168.0.22, 00:51:39, FastEthernet0/1
Redirecting show Command Output to a File
Imagine that you are working with Cisco Technical Assistance Center (TAC) to troubleshoot
an issue, and they want a file containing output from the show tech-support
command issued on your router. Example 3-9 shows how you can use the | redirect option
to send output from the show tech-support command to a file on a TFTP server.
Notice that directing output to a file suppresses the onscreen output. If you wanted both
(that is, for the output to be displayed onscreen and stored to a file), you could pipe the
output to the tee option, as demonstrated in Example 3-10.
Example 3-9 Redirecting Output to a TFTP Server
R1# show tech-support | redirect tftp://192.168.1.50/tshoot.txt
!
R1#
Example 3-10 Redirecting Output While Also Displaying the Output Onscreen
R1# show tech-support | tee tftp://192.168.1.50/tac.txt
!
---------------------show version---------------------
Cisco IOS Software, C2600 Software (C2600-IPVOICE_IVS-M), Version 12.4(3b), RELE
ASE SOFTWARE (fc3)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2005 by Cisco Systems, Inc.
Compiled Thu 08-Dec-05 17:35 by alnguyen
...OUTPUT OMITTED...
If you already have an output file created and you want to append the output of another
show command to your existing file, you can pipe the output of your show command to
the append option. Example 3-11 shows how to use the append option to append the
output of the show ip interface brief command to a file named baseline.txt.
Example 3-11 Appending Output to an Existing File
R1# show ip interface brief | append tftp://192.168.1.50/baseline.txt
!
R1#
Troubleshooting Connectivity
In addition to show command output, you can use many other Cisco IOS commands to
troubleshoot network conditions. A common command, which can be used to check network
connectivity, is the ping command. A basic ping command sends Internet Control
Message Protocol (ICMP) Echo messages to a specified destination; for every ICMP Echo
Reply received from that specified destination, an exclamation point appears in the output,
as shown in Example 3-12.
Example 3-12 Basic ping Command
R1# ping 10.4.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.4.4.4, timeout is 2 seconds:
!!!!!
The ping command does have several options that can prove useful during troubleshooting.
For example:
■ size: Specifies the number of bytes per datagram
■ repeat: Specifies the number of ICMP Echo messages sent (defaults to 5)
■ timeout: Specifies the number of seconds to wait for an ICMP Echo Reply
■ source: Specifies the source of the ICMP Echo datagrams
■ df-bit: Sets the do not fragment bit in the ICMP Echo datagram
Not only can a ping command indicate that a given IP address is reachable, but the response
to a ping command might provide insight into the nature of a problem. For example,
if the ping results indicate alternating failures and successes (that is, !.!.!), a
troubleshooter might conclude that traffic is being load-balanced between the source and
destination IP addresses. Traffic flowing across one path is successful, whereas traffic
flowing over the other path is failing.
You can also use the ping command to create a load on the network to troubleshoot the
network under heavy use. Specifically, you can specify a datagram size of 1500 bytes,
along with a large byte count and a timeout of zero seconds, as shown in Example 3-13.
Notice that all the pings failed. These failures occurred because of the zero-second timeout.
Specifically, the router did not wait for any amount of time before considering the
ping to have failed and sending another ICMP Echo message.
Example 3-13 Creating a Heavy Load on the Network
R1# ping 10.4.4.4 size 1500 repeat 9999 timeout 0
Type escape sequence to abort.
Sending 9999, 1500-byte ICMP Echos to 10.4.4.4, timeout is 0 seconds:
......................................................................
......................................................................
......................................................................
...OUTPUT OMITTED...
Perhaps you suspect that an interface has a nondefault maximum transmission unit (MTU)
size. You could send ICMP Echo messages across that interface using the df-bit and size
options of the ping command to specify the size of the datagram to be sent. The df-bit
option instructs a router to drop this datagram rather than fragmenting it if fragmentation
is required.
Example 3-14 shows the sending of pings with the do not fragment bit set. Notice the M
in the ping responses. An Mindicates that fragmentation was required but could not be
performed because the do not fragment bit was set. Therefore, you can conclude that a
link between the source and destination is using a nonstandard MTU (that is, an MTU less
than 1500 bytes).
Example 3-14 Pinging with the Do Not Fragment Bit Set
R1# ping 10.4.4.4 size 1500 df-bit
Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 10.4.4.4, timeout is 2 seconds:
Packet sent with the DF bit set
M.M.M
The challenge is how to determine the nondefault MTU size without multiple manual attempts.
An extended ping can help with such a scenario. Consider Example 3-15, which issues
the ping command without command-line parameters. This invokes the extended
ping feature. The extended ping feature allows you to granularly customize your pings.
For example, you could specify a range of datagram sizes to use in your pings to help determine
the size of a nondefault MTU. Specifically, in Example 3-15, you could determine
that the MTU across at least one of the links from the source to the destination IP address
was set to 1450 bytes, because the Mping responses begin after 51 ICMP Echo datagrams
were sent (with datagram sizes in the range of 1400 to 1450 bytes).
Example 3-15 Extended Ping Performing a Ping Sweep
R1# ping
Protocol [ip]:
Target IP address: 10.4.4.4
Repeat count [5]: 1
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]:
Set DF bit in IP header? [no]: yes
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]: y
Sweep min size [36]: 1400
Sweep max size [18024]: 1500
Sweep interval [1]:
Type escape sequence to abort.
Sending 101, [1400..1500]-byte ICMP Echos to 10.4.4.4, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!M.M.M.M.M.M.M.M.M.M
.M.M.M.M.M.M.M.M.M.M.M.M.M.M.M.
Success rate is 50 percent (51/101), round-trip min/avg/max = 60/125/232 ms
Although the ping command can be useful for testing Layer 3 (that is, the network layer)
connectivity, the telnet command is useful for troubleshooting Layer 4 (that is, the transport
layer). Specifically, although Telnet typically uses TCP port 23, you can specify an alternate
port number to see if a particular Layer 4 service is running on a destination IP
address. Such an approach might be useful if you are using a divide and conquer approach,
starting at Layer 3 (which was determined to be operational as a result of a successful
ping), or a bottom-up approach (which has also confirmed Layer 3 to be operational).
To illustrate, notice the telnet 192.168.1.50 80 command issued in Example 3-16. This
command causes router R1 to attempt a TCP connection with 192.168.1.50 using port 80
(that is, the HTTP port). The response of Open indicates that 192.168.1.50 is indeed running
a service on port 80.
Example 3-16 Using Telnet to Connect to a Nondefault Port
R1#telnet 192.168.1.50 80
Trying 192.168.1.50, 80 ... Open
Troubleshooting Hardware
In addition to software configurations, a network’s underlying hardware often becomes a
troubleshooting target. As a reference, Table 3-2 offers a collection of Cisco IOS commands
used to investigate hardware performance issues.
Table 3-2 Cisco IOS Commands for Hardware Troubleshooting
Command Description
show processes cpu Provides 5-second, 1-minute, and 5-minute CPU utilization statistics,
in addition to a listing of processes running on a platform along with
each process’s utilization statistics
show memory Displays summary information about processor and I/O memory, followed
by a more comprehensive report of memory utilization
show interfaces Shows Layer 1 and Layer 2 interface status, interface load information,
and error statistics including the following:
■ input queue drops: Indicates a router received information
faster than the information could be processed by the router
■ output queue drops: Indicates a router received information
faster than the information could be sent out of the outgoing
interface (perhaps because of an input/output speed mismatch)
■ input errors: Indicates frames were not received correctly (for
example, a cyclic redundancy check (CRC) error occurred),
perhaps indicating a cabling problem or a duplex mismatch
■ output errors: Indicates frames were not transmitted correctly,
perhaps due to a duplex mismatch
NOTE: Prior to collecting statistics, interface counters can be reset
using the clear counters command.
show controllers Displays statistical information for an interface (for example, error statistics),
where the information varies for different interface types (for
example, the type of connected cable might be displayed for a serial
interface)
show platform Provides detailed information about a router or switch hardware
platform
Specialized Diagnostic Tools
The collection of network information occurs not just as part of a structured troubleshooting
process but when gathering baseline data. Additionally, the occurrence of certain
network events (for example, processor utilization on a network server exceeding a
specified threshold) might be configured to trigger the writing of log information (for example,
to a syslog server). Cisco offers network maintenance and troubleshooting tools
targeted toward this type of data collection. This section introduces you to a sampling of
these specialized tools, which can supplement the Cisco IOS commands used for data collection
as discussed in the section “Cisco IOS Diagnostic Tools,” earlier in this chapter.
Using Specialized Tools in the Troubleshooting Process
Chapter 2 introduced you to a series of processes (and subprocesses) that can work
together in a structured troubleshooting process. Several of these processes involve the
collection of information:
■ Difficulty report: By proactively monitoring network devices, you might be alerted
to impending performance issues before users are impacted.
■ Collect information: The collection of information when troubleshooting a problem
can often be made more efficient through the use of specialized maintenance and
troubleshooting tools.
■ Examine collected information: As troubleshooters investigate the information
they collected while troubleshooting a problem, they need to know what normal network
behavior looks like. They can then contrast that normal (that is, baseline) behavior
against what they are observing in their collected data. Specialized maintenance
and troubleshooting tools can be used in a network to collect baseline data on an
ongoing basis.
■ Verify hypothesis: Specialized maintenance and troubleshooting tools help a troubleshooter
roll back an attempted fix, if that fix proves unsuccessful.
Most of the information collection tasks performed in the previous processes fall into one
of three categories:
■ Troubleshooting information collection: This information collection is conducted
as part of troubleshooting a reported problem.
■ Baseline information collection: This information collection is conducted when
the network is operating normally, to form a frame of reference against which other
data can be compared.
■ Network event information collection: Some network devices can be configured
to automatically generate alerts in response to specific conditions (for example, configured
utilization levels on a switch, router, or server being exceeded).
Performing Packet Captures
You can use dedicated appliances or PCs running packet capture software to collect and
store packets flowing across a network link. When troubleshooting, analysis of captured
packets can provide insight into how a network is treating traffic flow. For example, a
packet capture data file can show if packets are being dropped or if sessions are being reset.
You can also look inside Layer 2, 3, and 4 headers using a packet capture application.
For example, you can view a packet’s Layer 3 header to determine that packet’s Layer 3
quality of service (QoS) priority marking. An example of a popular and free packet capture
utility you can download is Wireshark (www.wireshark.org), as shown in Figure 3-1.
Capturing and analyzing packets, however, presents two major obstacles. First, the volume
of data collected as part of a packet capture can be so large that finding what you are
looking for can be a challenge. Therefore, you should understand how to use your packet
capture application’s filtering features.
Key
Topic
Key
Topic
www.CareerCert.info
www.CareerCert.info
www - CareerCert - info
Chapter 3: The Maintenance and Troubleshooting Toolbox 63
Figure 3-1 Wireshark Packet Capture Application
Gig 0/1 Gig 0/2
Gig 0/3
Server Copy of Traffic Client
Received By
Server
Copy of Traffic
Transmitted By
Server
Laptop Running
Packet Capture
Application
Figure 3-2 Cisco Catalyst Switch Configured for SPAN
A second challenge is that if you want to monitor, for example, traffic flow between two
network devices connected to a switch, the packets traveling between those two devices
will not appear on your packet capture device’s switch port. Fortunately, Cisco IOS supports
a feature known as SPAN. SPAN instructs a switch to send copies of packets seen on
one port (or one VLAN) to another port. You can connect your packet capture device to
this other port, as shown in Figure 3-2.
Notice that Figure 3-2 depicts a client (connected to Gigabit Ethernet 0/2) communicating
with a server (connected to Gigabit Ethernet 0/1). A troubleshooter inserts a packet capture
device into Gigabit Ethernet 0/3. However, a switch’s default behavior does not send
packets flowing between the client and server out the port connected to the packet capture
device. To cause port Gigabit Ethernet 0/3 to receive a copy of all packets sent or received
by the server, SPAN is configured on the switch, as shown in Example 3-17.
Notice that Example 3-17 uses the monitor session id source interface interface_id command
to indicate that a SPAN monitoring session with a locally significant identifier of 1
will copy packets crossing (that is, entering and exiting) port Gigabit Ethernet 0/1. Then
the monitor session id destination interface interface_id command is used to specify
port Gigabit Ethernet 0/3 as the destination port for those copied packets. A laptop running
packet capture software connected to port Gigabit Ethernet 0/3 will now receive a
copy of all traffic the server is sending or receiving.
Example 3-17 SPAN Configuration
Cat3550# conf term
Enter configuration commands, one per line. End with CNTL/Z.
Cat3550(config)# monitor session 1 source interface gig 0/1
Cat3550(config)# monitor session 1 destination interface gig 0/3
Cat3550(config)# end
Cat3550# show monitor
Session 1
------------
Type : Local Session
Source Ports :
Both : Gi0/1
Destination Ports : Gi0/3
Encapsulation : Native
Ingress : Disabled
In larger environments, a network capture device connected to one switch might need to
capture packets flowing through a different switch. Remote SPAN (RSPAN) makes such a
scenario possible. Consider Figure 3-3, where a troubleshooter has her laptop running a
packet capture application connected to port Fast Ethernet 5/2 on switch SW2. The traffic
that needs to be captured is traffic coming from and going to the server connected to port
Gigabit Ethernet 0/1 on switch SW1.
A VLAN is configured whose purpose is to carry captured traffic between the switches.
Therefore, a trunk exists between switches SW1 and SW2 to carry the SPAN VLAN in addition
to a VLAN carrying user data. Example 3-18 shows the configuration on switch
SW1 used to create the SPAN VLAN (that is, VLAN 20) and to specify that RSPAN
should monitor port Gigabit Ethernet 0/1 and send packets sent and received on that port
out of Gigabit Ethernet 0/3 on VLAN 20. The show monitor command is then used to
verify the RSPAN source and destination. Also, note that by default the monitor session
id source command monitors both incoming and outgoing traffic on the monitored port.
Gig 0/1 Gig 0/2
Gig 0/3
Trunk Carrying
SPAN VLAN
Server Client
Fa 5/1
Copy of Traffic
Received By
Server
Fa 5/2
Laptop Running
Packet Capture
Application
Copy of Traffic
Transmitted By
Server
SW1
SW2
Figure 3-3 Cisco Catalyst Switch Configured for RSPAN
Example 3-18 RSPAN Configuration on Switch SW1
SW1# conf term
SW1(config)# vlan 20
SW1(config-vlan)# name SPAN
SW1(config-vlan)# remote-span
SW1(config-vlan)# exit
SW1(config)# monitor session 1 source interface gig 0/1
SW1(config)# monitor session 1 destination remote vlan 20 reflector-port gig 0/3
SW1(config)# end
SW1#show monitor
Session 1
------------
Type : Remote Source Session
Source Ports :
Both : Gi0/1
Reflector Port : Gi0/3
Dest RSPAN VLAN : 20
Table 3-3 Comparing SNMP and NetFlow
Technology Characteristics
SNMP Collects device statistics (for example, platform resource utilization, traffic
counts, and error counts)
Uses a pull model (that is, statistics pulled from monitored device by a network
management station [NMS])
Available on nearly all enterprise network devices
NetFlow Collects detailed information about traffic flows
Uses a push model (that is, statistics pushed from the monitored device to a
NetFlow collector)
Available on routers and high-end switches
Example 3-19 shows the configuration on switch SW2 used to create the SPAN VLAN
(which is not necessary if the switches belong to the same VTP domain), to specify
that RSPAN should receive captured traffic from VLAN 20 and send it out port Fast
Ethernet 5/2.
No comments:
Post a Comment