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 selecting the processes, and their corresponding tasks, that make up your network
maintenance model, you next need to identify the tools required to carry out your maintenance
processes. These tools should be targeted toward your specific processes and tasks,
helping you focus your troubleshooting efforts without having to wade through reams of
irrelevant information. This section provides examples of a few indispensible elements you
should have in your network maintenance toolkit.
Basic Network Maintenance Tools
Network maintenance tools often range in expense from free to tens of thousands of dollars.
Similarly, these tools vary in their levels of complexity and usefulness for troubleshooting
specific issues. You need to select tools that balance your troubleshooting
needs and budgetary constraints.
Regardless of budget, nearly all network maintenance toolkits can contain the commandline
interface (CLI) commands executable from a router or switch prompt. Many network
devices have a graphical user interface (GUI) to assist network administrators in their configuration
and monitoring tasks. External servers (for example, backup servers, logging
servers, and time servers) can also collect, store, or provide information useful for day-today
network operation and for troubleshooting.
CLI Tools
Cisco IOS offers a wealth of CLI commands, which can be invaluable when troubleshooting
a network issue. For example, a show command can display router configuration information
and the routes that have been learned by a routing process. The debug command
can provide real-time information about router or switch processes. To illustrate, consider
Example 1-1, which shows router R2 receiving Open Shortest Path First (OSPF) link state
updates from its OSPF neighbors as those updates occur.
Example 1-1 Sample debug Output
R2# debug ip ospf events
OSPF events debugging is on
R2#
*Mar 1 00:06:06.679: OSPF: Rcv LS UPD from 10.4.4.4 on Serial1/0.2 length 124
LSA count 1
*Mar 1 00:06:06.691: OSPF: Rcv LS UPD from 10.3.3.3 on Serial1/0.1 length 124
LSA count 1
www.CareerCert.info
www.CareerCert.info
www - CareerCert - info
Chapter 1: Introduction to Network Maintenance 15
Figure 1-1 Cisco Security Device Manager
*Mar 1 00:06:06.999: OSPF: Rcv LS UPD from 10.4.4.4 on Serial1/0.2 length 124
LSA count 1
*Mar 1 00:06:07.067: OSPF: Rcv LS UPD from 10.3.3.3 on Serial1/0.1 length 156
LSA count 2
A newer Cisco IOS feature, which allows a router to monitor events and automatically respond
to a specific event (such as a defined threshold being reached) with a predefined action,
is called Cisco IOS Embedded Event Manager (EEM). EEM policies can be created
using Cisco’s tool command language (Tcl).
GUI Tools
Although Cisco has some GUI tools, such as CiscoWorks, that can manage large enterprise
networks, several device-based GUI tools are freely available. Examples of these free
tools from Cisco are the following:
■ Cisco Configuration Professional (CCP)
■ Cisco Configuration Assistant (CCA)
■ Cisco Network Assistant (CNA)
■ Cisco Security Device Manager (SDM)
Figure 1-1 shows the home screen of Cisco SDM.
www.CareerCert.info
www.CareerCert.info
www - CareerCert - info
16 CCNP TSHOOT 642-832 Official Certification Guide
Backup Tools
External servers are often used to store archival backups of a device’s operating system
(for example, a Cisco IOS image) and configuration information. Depending on your network
device, you might be able to back up your operating system and configuration information
to a TFTP, FTP, HTTP, or SCP server. To illustrate, consider Example 1-2.
Example 1-2 Backing Up a Router’s Startup Configuration to an FTP Server
R1# copy startup-config ftp://kevin:cisco@192.168.1.74
Address or name of remote host [192.168.1.74]?
Destination filename [r1-confg]?
Writing r1-confg !
1446 bytes copied in 3.349 secs (432 bytes/sec)
In Example 1-2, router R1’s startup configuration is being copied to an FTP server with an
IP address of 192.168.1.74. Notice that the login credentials (that is, username=kevin and
password=cisco) for the FTP server are specified in the copy command.
If you intend to routinely copy backups to an FTP server, you can avoid specifying the login
credentials each time (for security purposes), by adding those credentials to the
router’s configuration. Example 1-3 shows how to add username and password credentials
to the router’s configuration, and Example 1-4 shows how the startup configuration can
be copied to an FTP server without explicitly specifying those credentials in the copy
command.
Example 1-3 Adding FTP Server Login Credentials to a Router’s Configuration
R1# conf term
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# ip ftp username kevin
R1(config)# ip ftp password cisco
R1(config)# end
Example 1-4 Backing Up a Router’s Startup Configuration to an FTP Server Without
Specifying Login Credentials
R1# copy startup-config ftp://192.168.1.74
Address or name of remote host [192.168.1.74]?
Destination filename [r1-confg]?
Writing r1-confg !
1446 bytes copied in 3.389 secs (427 bytes/sec)
The process of backing up a router’s configuration can be automated using an archiving
feature, which is part of the Cisco IOS Configuration Replace and Configuration Rollback
feature. Specifically, you can configure a Cisco IOS router to periodically (that is, at intervals
specified in minutes) back up a copy of the startup configuration to a specified location
(for example, the router’s flash or an FTP server). Also, the archive feature can be
configured to create an archive every time you copy a router’s running configuration to
the startup configuration.
Example 1-5 illustrates a router configured to back up its startup configuration every day
(that is, every 1440 minutes) to an FTP server (with an IP address of 192.168.1.74, where
the login credentials have already been configured in the router’s configuration). In addition
to regular daily backups, the write-memory command causes the router to archive a
copy of the startup configuration whenever the router’s running configuration is copied to
the startup configuration.
Example 1-5 Automatic Archive Configuration
R1#show run
Building configuration...
...OUTPUT OMITTED...
ip ftp username kevin
ip ftp password cisco
!
archive
path ftp://192.168.1.74/R1-config
write-memory
time-period 1440
...OUTPUT OMITTED...
You can view the files stored in a configuration archive by issuing the show archive command,
as demonstrated in Example 1-6.
Example 1-6 Viewing a Configuration Archive
R1# show archive
The next archive file will be named ftp://192.168.1.74/R1-config-3
Archive # Name
0
1 ftp://192.168.1.74/R1-config-1
2 ftp://192.168.1.74/R1-config-2 <- Most Recent
3
4
5
6
7
8
9
10
11
12
13
14
Example 1-7 shows the execution of the copy run start command, which copies a router’s
running configuration to the router’s startup configuration. The show archive command is
then reissued, and the output confirms that an additional configuration archive (named
R1-config-3) has been created on the FTP server.
Example 1-7 Confirming Automated Backups
R1# copy run start
Destination filename [startup-config]?
Building configuration...
[OK]
Writing R1-config-3 !
R1# show archive
The next archive file will be named ftp://192.168.1.74/R1-config-4
Archive # Name
0
1 ftp://192.168.1.74/R1-config-1
2 ftp://192.168.1.74/R1-config-2
3 ftp://192.168.1.74/R1-config-3 <- Most Recent
4
5
6
7
8
9
10
11
12
13
14
You can restore a previously archived configuration using the configure replace command.
This command does not merge the archived configuration with the running configuration,
but rather completely replaces the running configuration with the archived
configuration. Example 1-8 shows the restoration of an archived configuration to a router.
Notice that the router’s hostname changes after the configuration restoration.
Example 1-8 Restoring an Archived Configuration
Router# configure replace ftp://192.168.1.74/R1-config-3
This will apply all necessary additions and deletions
to replace the current running configuration with the
contents of the specified configuration file, which is
assumed to be a complete configuration, not a partial
configuration. Enter Y if you are sure you want to proceed. ? [no]: Y
Loading R1-config-3 !
[OK - 3113/4096 bytes]
Table 1-3 Severity Levels
Severity Level Name
0 Emergencies
1 Alerts
2 Critical
3 Errors
4 Warnings
5 Notifications
6 Informational
7 Debugging
Key
Topic
Total number of passes: 1
Rollback Done
R1#
Logging Tools
Device logs often offer valuable information when troubleshooting a network issue. Many
events that occur on a router are automatically reported to the router’s console. For example,
if a router interface goes down, a message is written to the console. However, this
feedback is not provided to you, by default, if you are connected to a router via Telnet. If
you are connected to a router via Telnet and want to see console messages, you can enter
the command terminal monitor.
A downside of solely relying on console messages is that those messages can scroll off
the screen, or you might close your terminal emulator, after which those messages would
no longer be visible. Therefore, a step beyond console messages is logging those messages
to a router’s buffer (that is, in the router’s RAM). To cause messages to be written to a
router’s buffer, you can issue the logging buffered command. As part of that command,
you can specify how much of the router’s RAM can be dedicated to logging. After the
buffer fills to capacity, older entries will be deleted to make room for newer entries. This
buffer can be viewed by issuing the show logging history command.
You might only want to log messages that have a certain level of severity. Severity levels
range from 0–7, with corresponding names, as shown in Table 1-3. Notice that lower severity
levels produce less logging output.
You might want to log messages of one severity level to a router’s console and messages
of another severity level to the router’s buffer. That is possible, by using the logging console
severity_level and logging buffered severity_level commands.
Another logging option is to log messages to an external syslog server. By sending log
messages to an external server, you are able to keep a longer history of logging messages.
You can direct your router’s log output to a syslog server’s IP address using the logging
ip_address command.
Example 1-9 illustrates several of the logging configurations discussed here.
Example 1-9 Logging Configuration
R1# show run
...OUTPIT OMITTED...
Building configuration...
!
logging buffered 4096 warnings
logging console warnings
!
logging 192.168.1.50
...OUTPUT OMITTED...
In Example 1-9, events with a severity level of warning (that is, 4) or less (that is, 0–2) are
logged to the router’s buffer. This buffer can be viewed with the show logging history
command. The router can use a maximum of 4096 bytes of RAM for the buffered logging.
The console is configured for logging events of the same severity level. Additionally,
the router is configured to log messages to a syslog server with an IP address 192.168.1.50.
Figure 1-2 shows logging messages being collected by a Kiwi Syslog Server (available from
www.kiwisyslog.com).
Network Time Protocol
Imagine that you are reviewing device logs collected in a router’s buffer and are attempting
to correlate the events in the device logs with an issue you are troubleshooting. To
make that correlation, the logged events need to have accurate timestamps.
Although you could individually set the clock on each of your routers, those clocks might
drift over time and not agree. You might have heard the saying that a man with one watch
always knows what time it is, whereas a man with two watches is never sure. This implies
that devices need to have a common point of reference for their time. Such a reference
point is made possible by Network Time Protocol (NTP), which allows routers to point to
a device acting as an NTP server. Because the NTP server might be referenced by devices
in different time zones, each device has its own time zone configuration, which indicates
how many hours its time zone differs from Greenwich Mean Time (GMT).
Example 1-10 shows an NTP configuration entered on a router located in the Eastern time
zone, which is five hours behind GMT when daylight savings time is not in effect. The
clock summer-time command defines when daylight savings time begins and ends. In this
example, daylight savings time begins at 2:00 AM on the second Sunday in March and
ends at 2:00 AM on the first Sunday in November. The ntp server command is used to
point to an NTP server. Note that a configuration can have more than one ntp server command,
for redundancy.
Example 1-10 Configuring a Router to Point to an NTP Server
R1# conf term
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# clock timezone EST -5
R1(config)# clock summer-time EDT recurring 2 Sun Mar 2:00 1 Sun Nov 2:00
R1(config)# ntp server 192.168.1.150
R1(config)# end
Cisco Support Tools
Cisco has several other troubleshooting and maintenance tools available on its website:
http://www.cisco.com/en/US/support/tsd_most_requested_tools.html
Some of the tools available at this website require login credentials with appropriate privilege
levels.
Network Documentation Tools
Earlier, we discussed the importance of network documentation. For this documentation
to truly add value, however, it should be easy to retrieve and be current. To keep the documentation
current, it should be easy to update.
A couple of documentation management system examples are as follows:
■ Trouble ticket reporting system: Several software applications are available for
recording, tracking, and archiving trouble reports (that is, trouble tickets). These applications
are often referred to as help desk applications. However, their usefulness
extends beyond the help desk environment.
■ Wiki: A wiki can act as a web-based collaborative documentation platform. A popular
example of a wiki is Wikipedia (www.wikipedia.com), an Internet-based encyclopedia
that can be updated by users. This type of wiki technology can also be used on
your local network to maintain a central repository for documentation that is both
easy to access and easy to update.
Incident Recovery Tools
This section demonstrated how to automatically archive and manually restore router configurations
using Cisco IOS commands. However, higher-end tools are available for automating
backups, tracking configuration or hardware changes, and pushing out a
centralized configuration to multiple devices. An example of such an application is
CiscoWorks Resource Manager Essentials (RME). RME is a component of CiscoWorks
LAN Management Solutions (LMS).
Monitoring and Measuring Tools
Keeping an eye on network traffic patterns and performance metrics can help you anticipate
problems before they occur. As a result, you can address those issues proactively,
rather than taking a reactive stance where you continually respond to problem reports.
Beyond basic show and debug commands, more advanced utilities are available for traffic and
performance monitoring. For example, Cisco IOS Netflow can provide you with tremendous
insight into your network traffic patterns. Several companies market Netflow collectors, which
are software applications that can take the Netflow information reported from a Cisco router
and convert that raw data into useful graphs, charts, and tables reflecting traffic patterns.
Simple Network Management Protocol (SNMP) allows a monitored device (for example, a
router or a switch) to run an SNMP agent. An SNMP server can then query the SNMP
agent running on a monitored device to collect data such as utilization statistics or device
configuration information.
Reasons to monitor network performance include the following:
■ Assuring compliance with an SLA: If you work for a service provider or are a customer
of a service provider, you might want to confirm that performance levels to and
from the service provider’s cloud are conforming to the agreed-upon SLA.
■ Trend monitoring:Monitoring resource utilization on your network (for example,
bandwidth utilization and router CPU utilization) can help you recognize trends and
forecast when upgrades will be required.
■ Troubleshooting performance issues: Performance issues can be difficult to
troubleshoot in the absence of a baseline. By routinely monitoring network performance,
you have a reference point (that is, a baseline) against which you can compare
performance metrics collected after a user reports a performance issue.
No comments:
Post a Comment