Chapter 10
Network Management
Objectives
Upon completion of this chapter, you will be able to answer the following questions:
How do you use CDP to map a network topology?
How do you use LLDP to map a network topology?
How do you implement NTP between an NTP client and an NTP server?
How does SNMP operate?
How does syslog operate?
What commands are used to back up and restore an IOS configuration file?
How do you implement protocols to manage a network?
Key Terms
This chapter uses the following key terms. You can find the definitions in the Glossary.
Cisco Discovery Protocol (CDP) page 390
Link Layer Discovery Protocol (LLDP) page 396
Network Time Protocol (NTP) page 400
authoritative time source page 401
Simple Network Management Protocol (SNMP) page 405
Management Information Base (MIB) page 405
network management system (NMS) page 405
Introduction (10.0)
Imagine being at the helm of a spaceship. Many, many components work together to move this ship, and multiple systems manage these components. To get where you are going, you would need to have a full understanding of the components and the systems that manage them. You would probably appreciate any tools that would make managing your spaceship—while you are also flying it—simpler.
Like a complex spaceship, a network also needs to be managed. Happily, many tools are designed to make network management simpler. This chapter introduces you to several tools and protocols to help you manage your network—while your users are using it. It also includes many Packet Tracer activities and labs to test your skills. These are the tools of great network administrators, so you will definitely want to get started!
Device Discovery with CDP (10.1)
In this section, you will learn how to use CDP to map a network topology.
CDP Overview (10.1.1)
The first thing you want to know about your network is, what is in it? Where are the various components, and how are they connected? Basically, you need a map. This section explains how you can use Cisco Discovery Protocol (CDP) to create a map of a network.
CDP is a Cisco-proprietary Layer 2 protocol that is used to gather information about Cisco devices that share the same data link. CDP is media and protocol independent and runs on all Cisco devices, such as routers, switches, and access servers.
A device sends periodic CDP advertisements to connected devices, as shown in Figure 10-1. These advertisements share information about the type of device that is discovered, the name of the devices, and the number and type of the interfaces.
Figure 10-1 Devices Send CDP Advertisements
Most network devices are connected to other devices, and CDP can assist in network design decisions, troubleshooting, and making changes to equipment. CDP can also be used as a network discovery tool to determine information about the neighboring devices. This information gathered from CDP can help build a logical topology of a network when documentation is missing or lacking detail.
Configure and Verify CDP (10.1.2)
For Cisco devices, CDP is enabled by default. For security reasons, it may be desirable to disable CDP on a network device globally or per interface. With CDP, an attacker can gather valuable insight about the network layout, such as IP addresses, IOS versions, and types of devices.
To verify the status of CDP and display information about CDP, enter the show cdp command, as shown in Example 10-1.
Example 10-1 The show cdp Command
Router# show cdp
Global CDP information:
Sending CDP packets every 60 seconds
Sending a holdtime value of 180 seconds
Sending CDPv2 advertisements is enabled
Router#
To enable CDP globally for all the supported interfaces on the device, enter cdp run in global configuration mode. To disable CDP for all the interfaces on a device, use the no cdp run command in global configuration mode, as shown in Example 10-2.
Example 10-2 Disabling and Enabling CDP Globally
Router(config)# no cdp run Router(config)# exit Router# Router# show cdp CDP is not enabled Router# Router# configure terminal Router(config)# cdp run Router(config)#
To disable CDP on a specific interface, such as the interface facing an ISP, enter no cdp enable in interface configuration mode. CDP is still enabled on the device; however, no more CDP advertisements are sent out that interface. To enable CDP on the specific interface again, enter cdp enable, as shown in Example 10-3.
Example 10-3 Enabling CDP on an Interface
Switch(config)# interface gigabitethernet 0/0/1 Switch(config-if)# cdp enable Switch(config-if)#
To verify the status of CDP and display a list of neighbors, use the show cdp neighbors command in privileged EXEC mode. The show cdp neighbors command displays important information about the CDP neighbors. Currently, the device in Example 10-4 does not have any neighbors because it is not physically connected to any devices, as indicated by the output of the show cdp neighbors command.
Example 10-4 Displaying a List of CDP Neighbors
Router# show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
D - Remote, C - CVTA, M - Two-port Mac Relay
Device ID Local Intrfce Holdtme Capability Platform Port ID
Total cdp entries displayed : 0
Router#
Use the show cdp interface command to display the interfaces that are CDP enabled on a device. The status of each interface is also displayed. Example 10-5 shows that five interfaces are CDP enabled on the router, with only one active connection to another device.
Example 10-5 Displaying CPD Interface Information
Router# show cdp interface GigabitEthernet0/0/0 is administratively down, line protocol is down Encapsulation ARPA Sending CDP packets every 60 seconds Holdtime is 180 seconds GigabitEthernet0/0/1 is up, line protocol is up Encapsulation ARPA Sending CDP packets every 60 seconds Holdtime is 180 seconds GigabitEthernet0/0/2 is down, line protocol is down Encapsulation ARPA Sending CDP packets every 60 seconds Holdtime is 180 seconds Serial0/1/0 is administratively down, line protocol is down Encapsulation HDLC Sending CDP packets every 60 seconds Holdtime is 180 seconds Serial0/1/1 is administratively down, line protocol is down Encapsulation HDLC Sending CDP packets every 60 seconds Holdtime is 180 seconds GigabitEthernet0 is down, line protocol is down Encapsulation ARPA Sending CDP packets every 60 seconds Holdtime is 180 seconds cdp enabled interfaces : 6 interfaces up : 1 interfaces down : 5 Router#
Discover Devices by Using CDP (10.1.3)
Consider the lack of documentation in the topology shown in Figure 10-2. The network administrator only knows that R1 is connected to another device.
Figure 10-2 R1 Topology Before Discovery
With CDP enabled on the network, the show cdp neighbors command can be used to determine the network layout, as shown in Example 10-6.
Example 10-6 Discovering Connected CDP Neighbors for R1
R1# show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
D - Remote, C - CVTA, M - Two-port Mac Relay
Device ID Local Intrfce Holdtme Capability Platform Port ID
S1 Gig 0/0/1 179 S I WS-C3560- Fas 0/5
R1#
No information is available regarding the rest of the network. The show cdp neighbors command provides helpful information about each CDP neighbor device, including the following:
Device identifiers: This is the hostname of the neighbor device (S1).
Port identifier: This is the name of the local and remote ports (G0/0/1 and F0/5, respectively).
Capability list: This shows whether the device is a router or a switch (S for switch; I for IGMP [which is beyond the scope of this chapter]).
Platform: This is the hardware platform of the device (WS-C3560 for a Cisco 3560 switch).
The output shows that there is another Cisco device, S1, connected to the G0/0/1 interface on R1. Furthermore, S1 is connected through its F0/5, as shown in Figure 10-3.
Figure 10-3 Topology from S1
The network administrator uses show cdp neighbors detail to discover the IP address for S1. As shown in Example 10-7, the address for S1 is 192.168.1.2.
Example 10-7 Discovering Detailed Information About S1
R1# show cdp neighbors detail
-------------------------
Device ID: S1
Entry address(es):
IP address: 192.168.1.2
Platform: cisco WS-C3560-24TS, Capabilities: Switch IGMP
Interface: GigabitEthernet0/0/1, Port ID (outgoing port): FastEthernet0/5
Holdtime : 136 sec
Version :
Cisco IOS Software, C3560 Software (C3560-LANBASEK9-M), Version 15.0(2)SE7, R
RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2014 by Cisco Systems, Inc.
Compiled Thu 23-Oct-14 14:49 by prod_rel_team
advertisement version: 2
Protocol Hello: OUI=0x00000C, Protocol ID=0x0112; payload len=27,
value=00000000FFFFFFFF010221FF000000000000002291210380FF0000
VTP Management Domain: ''
Native VLAN: 1
Duplex: full
Management address(es):
IP address: 192.168.1.2
Total cdp entries displayed : 1
R1#
By accessing S1 either remotely through SSH or physically through the console port, the network administrator can determine what other devices are connected to S1, as shown in the output of the show cdp neighbors command in Example 10-8.
Example 10-8 Discovering Connected CDP Neighbors for S1
S1# show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
D - Remote, C - CVTA, M - Two-port Mac Relay
Device ID Local Intrfce Holdtme Capability Platform Port ID
S2 Fas 0/1 150 S I WS-C2960- Fas 0/1
R1 Fas 0/5 179 R S I ISR4331/K Gig 0/0/1
S1#
Another switch, S2, is revealed in the output. S2 is using F0/1 to connect to the F0/1 interface on S1, as shown in Figure 10-4.
Figure 10-4 Topology from S2
Again, the network administrator can use show cdp neighbors detail to discover the IP address for S2 and then remotely access it. After a successful login, the network administrator uses the show cdp neighbors command to discover if there are more devices, as shown in Example 10-9.
Example 10-9 Discovering Connected CDP Neighbors for S2
S2# show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
D - Remote, C - CVTA, M - Two-port Mac Relay
Device ID Local Intrfce Holdtme Capability Platform Port ID
S1 Fas 0/1 141 S I WS-C3560- Fas 0/1
S2#
The only device connected to S2 is S1. Therefore, there are no more devices to discover in the topology. The network administrator can now update the documentation to reflect the discovered devices.
Syntax Checker—Configure and Verify CDP (10.1.4)
Refer to the online course to complete this activity.
Packet Tracer—Use CDP to Map a Network (10.1.5)
A senior network administrator requires you to map the remote branch office network and discover the name of a recently installed switch that still needs to have an IPv4 address configured. Your task is to create a map of the branch office network. To map the network, you will use SSH for remote access and Cisco Discovery Protocol (CDP) to discover information about neighboring network devices, such as routers and switches.
Device Discovery with LLDP (10.2)
In this section, you will learn how to use LLDP to map a network topology.
LLDP Overview (10.2.1)
Link Layer Discovery Protocol (LLDP) does the same thing as CDP, but it is not specific to Cisco devices. Figure 10-5 shows LLDP-enabled devices sending each other LLDP advertisements.
Figure 10-5 Devices Sending LLDP Advertisements
LLDP is a vendor-neutral neighbor discovery protocol similar to CDP. LLDP works with network devices, such as routers, switches, and wireless LAN access points. This protocol advertises its identity and capabilities to other devices and receives the information from a physically connected Layer 2 device.
Configure and Verify LLDP (10.2.2)
Depending on the device, LLDP may be enabled by default. To enable LLDP globally on a Cisco network device, enter the lldp run command in global configuration mode. To disable LLDP, enter the no lldp run command in global configuration mode.
Much like CDP, LLDP can be configured on specific interfaces. However, LLDP must be configured separately to transmit and receive LLDP packets.
To verify that LLDP has been enabled on a device, enter the show lldp command in privileged EXEC mode, as shown in Example 10-10.
Example 10-10 Configuring and Verifying LLDP
S1(config)# lldp run
S1(config)#
S1(config)# interface gigabitethernet 0/1
S1(config-if)# lldp transmit
S1(config-if)# lldp receive
S1(config-if)# end
S1#
S1# show lldp
Global LLDP Information:
Status: ACTIVE
LLDP advertisements are sent every 30 seconds
LLDP hold time advertised is 120 seconds
LLDP interface reinitialisation delay is 2 seconds
S1#
Discover Devices by Using LLDP (10.2.3)
Consider the lack of documentation in the topology shown in Figure 10-6. The network administrator only knows that S1 is connected to two devices.
Figure 10-6 S1 Topology Before Discovery
With LLDP enabled, device neighbors can be discovered by using the show lldp neighbors command, as shown in Example 10-11.
Example 10-11 Discovering LLDP Neighbors for S1
S1# show lldp neighbors
Capability codes:
(R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
(W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other
Device ID Local Intf Hold-time Capability Port ID
R1 Fa0/5 117 R Gi0/0/1
S2 Fa0/1 112 B Fa0/1
Total entries displayed: 2
S1#
The network administrator discovers that S1 has a router and a switch as neighbors. For this output, the letter B for bridge also indicates a switch.
From the results of show lldp neighbors, a topology from S1 can be constructed, as displayed in Figure 10-7.
Figure 10-7 S1 Topology After Discovery
When more details about the neighbors are needed, the show lldp neighbors detail command can provide information, such as the neighbor IOS version, IP address, and device capability, as shown in Example 10-12.
Example 10-12 Discovering Detailed Information about R1 and S2
S1# show lldp neighbors detail
------------------------------------------------
Chassis id: 848a.8d44.49b0
Port id: Gi0/0/1
Port Description: GigabitEthernet0/0/1
System Name: R1
System Description:
Cisco IOS Software [Fuji], ISR Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version
16.9.4, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2019 by Cisco Systems, Inc.
Compiled Thu 22-Aug-19 18:09 by mcpre
Time remaining: 111 seconds
System Capabilities: B,R
Enabled Capabilities: R
Management Addresses - not advertised
Auto Negotiation - not supported
Physical media capabilities - not advertised
Media Attachment Unit type - not advertised
Vlan ID: - not advertised
------------------------------------------------
Chassis id: 0025.83e6.4b00
Port id: Fa0/1
Port Description: FastEthernet0/1
System Name: S2
System Description:
Cisco IOS Software, C2960 Software (C2960-LANBASEK9-M), Version 15.0(2)SE4,
RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2013 by Cisco Systems, Inc.
Compiled Wed 26-Jun-13 02:49 by prod_rel_team
Time remaining: 107 seconds
System Capabilities: B
Enabled Capabilities: B
Management Addresses - not advertised
Auto Negotiation - supported, enabled
Physical media capabilities:
100base-TX(FD)
100base-TX(HD)
10base-T(FD)
10base-T(HD)
Media Attachment Unit type: 16
Vlan ID: 1
Total entries displayed: 2
S1#
Syntax Checker—Configure and Verify LLDP (10.2.4)
Refer to the online course to complete this activity.
Check Your Understanding—Compare CDP and LLDP (10.2.5)
Refer to the online course to complete this activity.
Packet Tracer—Use LLDP to Map a Network (10.2.6)
In this Packet Tracer activity, you will complete the following objectives:
Build the network and configure basic device settings
Network discovery with CDP
Network discovery with LLDP
NTP (10.3)
In this section, you will learn how to implement Network Time Protocol (NTP) between an NTP client and an NTP server.
Time and Calendar Services (10.3.1)
Before you get really deep into network management, one thing that will help keep you on track is ensuring that all your components are set to the same time and date.
The software clock on a router or switch starts when the system boots. It is the primary source of time for the system. It is important to synchronize the time across all devices on a network because all aspects of managing, securing, troubleshooting, and planning networks require accurate timestamping. When the time is not synchronized between devices, it is impossible to determine the order of the events and the cause of an event.
Typically, the date and time settings on a router or switch can be set by using one of two methods. You can manually configure the date and time, as shown in Example 10-13, or configure Network Time Protocol (NTP).
Example 10-13 Manually Setting the Clock
R1# clock set 20:36:00 nov 15 2019 R1# *Nov 15 20:36:00.000: %SYS-6-CLOCKUPDATE: System clock has been updated from 21:32:31 UTC Fri Nov 15 2019 to 20:36:00 UTC Fri Nov 15 2019, configured from console by console. R1#
As a network grows, it becomes difficult to ensure that all infrastructure devices are operating with synchronized time. Even in a smaller network environment, the manual method is not ideal. If a router reboots, how will it get an accurate date and timestamp?
A better solution is to configure NTP on the network. This protocol allows routers on the network to synchronize their time settings with an NTP server. A group of NTP clients that obtain time and date information from a single source have more consistent time settings. When NTP is implemented in the network, it can be set up to synchronize to a private master clock, or it can synchronize to a publicly available NTP server on the internet.
NTP uses UDP port 123 and is documented in RFC 1305.
NTP Operation (10.3.2)
NTP networks use a hierarchical system of time sources. Each level in this hierarchical system is called a stratum. The stratum level is defined as the number of hop counts from the authoritative time source. The synchronized time is distributed across the network by using NTP. Figure 10-8 displays a sample NTP network.
Figure 10-8 NTP Strata
In the figure, NTP servers are arranged in three levels, showing the three strata. Stratum 1 is connected to the stratum 0 clocks.
Stratum 0
An NTP network gets the time from authoritative time sources. Stratum 0 devices such as atomic and GPS clocks are the most accurate authoritative time sources. Specifically, stratum 0 devices are non-network high-precision time-keeping devices assumed to be accurate and with little or no delay associated with them. In Figure 10-8, they are represented by the clock icon.
Stratum 1
The stratum 1 devices are network devices that are directly connected to the authoritative time sources. They function as the primary network time standard to stratum 2 devices using NTP.
Stratum 2 and Lower
The stratum 2 servers are connected to stratum 1 devices through network connections. Stratum 2 devices, such as NTP clients, synchronize their time by using the NTP packets from stratum 1 servers. They could also act as servers for stratum 3 devices.
Smaller stratum numbers indicate that the server is closer to the authorized time source than larger stratum numbers. The larger the stratum number, the lower the stratum level. The max hop count is 15. Stratum 16, the lowest stratum level, indicates that a device is unsynchronized. Time servers on the same stratum level can be configured to act as a peer with other time servers on the same stratum level for backup or verification of time.
Configure and Verify NTP (10.3.3)
Figure 10-9 shows the topology used to demonstrate NTP configuration and verification.
Figure 10-9 NTP Server and Client Topology
Before NTP is configured on the network, the show clock command displays the current time on the software clock, as shown in Example 10-14. With the detail option, notice that the time source is “user configuration.” This means the time was manually configured using the clock privileged EXEC command.
Example 10-14 Displaying the Clock Source
R1# show clock detail
20:55:10.207 UTC Fri Nov 15 2019
Time source is user configuration
R1#
The ntp server ip-address global configuration command is used to configure 209.165.200.225 as the NTP server for R1. To verify that the time source is set to NTP, use the show clock detail command. Notice that now the time source is NTP, as shown in Example 10-15.
Example 10-15 Configuring an NTP Server for R1
R1(config)# ntp server 209.165.200.225
R1(config)# end
R1#
R1# show clock detail
21:01:34.563 UTC Fri Nov 15 2019
Time source is NTP
R1#
In Example 10-16, the show ntp associations and show ntp status commands are used to verify that R1 is synchronized with the NTP server at 209.165.200.225.
Note
The highlighted st in Example 10-16 stands for stratum.
Example 10-16 Verifying NTP on R1
R1# show ntp associations address ref clock st when poll reach delay offset disp *~209.165.200.225 .GPS. 1 61 64 377 0.481 7.480 4.261 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured R1# R1# show ntp status Clock is synchronized, stratum 2, reference is 209.165.200.225 nominal freq is 250.0000 Hz, actual freq is 249.9995 Hz, precision is 2**19 ntp uptime is 589900 (1/100 of seconds), resolution is 4016 reference time is DA088DD3.C4E659D3 (13:21:23.769 PST Fri Nov 15 2019) clock offset is 7.0883 msec, root delay is 99.77 msec root dispersion is 13.43 msec, peer dispersion is 2.48 msec loopfilter state is 'CTRL' (Normal Controlled Loop), drift is 0.000001803 s/s system poll interval is 64, last update was 169 sec ago. R1#
Notice that R1 is synchronized with a stratum 1 NTP server at 209.165.200.225, which is synchronized with a GPS clock. The show ntp status command output indicates that R1 is now a stratum 2 device that is synchronized with the NTP server at 209.165.220.225.
Next, the clock on S1 is configured to synchronize to R1 with the ntp server global configuration command, and then the configuration is verified with the show ntp associations command, as shown in Example 10-17.
Example 10-17 Configuring an NTP Server for S1
S1(config)# ntp server 192.168.1.1
S1(config)# end
S1#
S1# show ntp associations
address ref clock st when poll reach delay offset disp
*~192.168.1.1 209.165.200.225 2 12 64 377 1.066 13.616 3.840
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
S1#
Output from the show ntp associations command in Example 10-18 verifies that the clock on S1 is now synchronized with R1 at 192.168.1.1 via NTP.
Example 10-18 Verifying NTP on S1
S1# show ntp status
Clock is synchronized, stratum 3, reference is 192.168.1.1
nominal freq is 119.2092 Hz, actual freq is 119.2088 Hz, precision is 2**17
reference time is DA08904B.3269C655 (13:31:55.196 PST Tue Nov 15 2019)
clock offset is 18.7764 msec, root delay is 102.42 msec
root dispersion is 38.03 msec, peer dispersion is 3.74 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is 0.000003925 s/s
system poll interval is 128, last update was 178 sec ago.
S1#
R1 is a stratum 2 device and NTP server to S1. Now S1 is a stratum 3 device that can provide NTP service to other devices in the network, such as end devices.
Packet Tracer—Configure and Verify NTP (10.3.4)
NTP synchronizes the time of day among a set of distributed time servers and clients. While there are a number of applications that require synchronized time, this lab focuses on the need to correlate events when listed in the system logs and other time-specific events from multiple network devices.
SNMP
Now that your network is mapped and all of your components are using the same clock, it is time to look at how you can manage your network by using Simple Network Management Protocol (SNMP). This section discusses how SNMP operates.
Introduction to SNMP (10.4.1)
SNMP was developed to allow administrators to manage nodes such as servers, workstations, routers, switches, and security appliances on an IP network. It enables network administrators to monitor and manage network performance, find and solve network problems, and plan for network growth.
SNMP is an application layer protocol that provides a message format for communication between managers and agents. The SNMP system consists of three elements:
SNMP agents (managed node)
To configure SNMP on a networking device, it is first necessary to define the relationship between the manager and the agent.
The SNMP manager is part of a network management system (NMS). The SNMP manager runs SNMP management software. As shown in Figure 10-10, the SNMP manager can collect information from an SNMP agent by using the “get” action and can change configurations on an agent by using the “set” action.
Figure 10-10 SNMP Manager and Nodes
In addition, SNMP agents can forward information directly to a network manager by using SNMP traps.
The SNMP agent and MIB reside on SNMP client devices. Network devices that must be managed, such as switches, routers, servers, firewalls, and workstations, are equipped with an SMNP agent software module. MIBs store data about the device and operational statistics and are meant to be available to authenticated remote users. The SNMP agent is responsible for providing access to the local MIB.
SNMP defines how management information is exchanged between network management applications and management agents. The SNMP manager polls the agents and queries the MIB for SNMP agents on UDP port 161. SNMP agents send any traps to the SNMP manager on UDP port 162.
SNMP Operation (10.4.2)
SNMP agents that reside on managed devices collect and store information about the device and its operation. The agent stores this information locally in the MIB. The SNMP manager then uses the SNMP agent to access information within the MIB.
There are two primary SNMP manager requests: get and set. An NMS uses a get request to query a device for data. An NMS uses a set request to change configuration variables in the agent device. A set request can also initiate actions within a device. For example, a set can cause a router to reboot, send a configuration file, or receive a configuration file. The SNMP manager uses the get and set actions to perform the operations described in Table 10-1.
Table 10-1 SNMP Get and Set Operations
Operation |
Description |
get-request |
Retrieves a value from a specific variable. |
get-next-request |
Retrieves a value from a variable within a table; the SNMP manager does not need to know the exact variable name. A sequential search is performed to find the needed variable from within a table. |
get-bulk-request |
Retrieves large blocks of data, such as multiple rows in a table, that would otherwise require the transmission of many small blocks of data. (Only works with SNMPv2 or later.) |
get-response |
Replies to a get-request, get-next-request, and set-request sent by an NMS. |
set-request |
Stores a value in a specific variable. |
The SNMP agent responds to SNMP manager requests as follows:
Getting an MIB variable: The SNMP agent performs this function in response to a GetRequest-PDU from the network manager. The agent retrieves the value of the requested MIB variable and responds to the network manager with that value.
Setting an MIB variable: The SNMP agent performs this function in response to a SetRequest-PDU from the network manager. The SNMP agent changes the value of the MIB variable to the value specified by the network manager. An SNMP agent reply to a set request includes the new settings in the device.
Figure 10-11 illustrates the use of an SNMP GetRequest to determine if interface G0/0/0 is up/up.
Figure 10-11 Example of an SNMP GetRequest
SNMP Agent Traps (10.4.3)
An NMS periodically polls the SNMP agents that are residing on managed devices by using the get request. The NMS queries a device for data. Using this process, a network management application can collect information to monitor traffic loads and to verify the device configurations of managed devices. The information can be displayed via a GUI on the NMS. Averages, minimums, or maximums can be calculated. The data can be graphed, or thresholds can be set to trigger a notification process when the thresholds are exceeded. For example, an NMS can monitor CPU utilization of a Cisco router. The SNMP manager samples the value periodically and presents this information in a graph for the network administrator to use in creating a network baseline, creating a report, or viewing real-time information.
Periodic SNMP polling does have disadvantages. First, there is a delay between the time when an event occurs and the time when it is noticed (via polling) by the NMS. Second, there is a trade-off between polling frequency and bandwidth usage. To mitigate these disadvantages, it is possible for SNMP agents to generate and send traps to immediately inform the NMS of certain events. Traps are unsolicited messages alerting the SNMP manager to a condition or an event on the network. Examples of trap conditions include, but are not limited to, improper user authentication, restarts, link status (up or down), MAC address tracking, closing of a TCP connection, loss of connection to a neighbor, and other significant events. Trap-directed notifications reduce network and agent resources by eliminating the need for some of SNMP polling requests.
Figure 10-12 illustrates the use of an SNMP trap to alert the network administrator that interface G0/0/0 has failed. The following steps occur in this figure:
Figure 10-12 SNMP Trap Example
Step 1. Interface G0/0/0 fails on R1.
Step 2. R1 sends a SNMP trap message to the NMS.
Step 3. The NMS takes necessary action.
The NMS software can send the network administrator a text message, pop up a window on the NMS software, or turn the router icon red in the NMS GUI.
The exchange of all SNMP messages is illustrated in Figure 10-13.
Figure 10-13 SNMP Messages
SNMP Versions (10.4.4)
There are several versions of SNMP:
SNMPv1: This is the Simple Network Management Protocol, a full internet standard, that is defined in RFC 1157.
SNMPv2c: This is defined in RFCs 1901 to 1908. It uses a community-string-based administrative framework.
SNMPv3: This is an interoperable standards-based protocol originally defined in RFCs 2273 to 2275. It provides secure access to devices by authenticating and encrypting packets over the network. It includes a number of security features: message integrity to ensure that a packet was not tampered with in transit, authentication to determine that the message is from a valid source, and encryption to prevent the contents of a message from being read by an unauthorized source.
All versions use SNMP managers, agents, and MIBs. Cisco IOS software supports all three versions. Version 1 is a legacy solution and is not often encountered in networks today; therefore, this book focuses on versions 2c and 3.
Both SNMPv1 and SNMPv2c use a community-based form of security. The community of managers that is able to access the MIB of the agent is defined by a community string.
Unlike SNMPv1, SNMPv2c includes a bulk retrieval mechanism and more detailed error message reporting to management stations. The bulk retrieval mechanism retrieves tables and large quantities of information, minimizing the number of round trips required. The improved error handling of SNMPv2c includes expanded error codes that distinguish different kinds of error conditions. These conditions are reported through a single error code in SNMPv1. Error return codes in SNMPv2c include the error type.
Note
SNMPv1 and SNMPv2c offer minimal security features. Specifically, SNMPv1 and SNMPv2c can neither authenticate the source of a management message nor provide encryption. SNMPv3 is most currently described in RFCs 3410 to 3415. It adds methods to ensure the secure transmission of critical data between managed devices.
SNMPv3 provides for both security models and security levels. A security model is an authentication strategy set up for a user and the group within which the user resides. A security level is the permitted level of security within a security model. A combination of the security level and the security model determine which security mechanism is used when handling an SNMP packet. Available security models are SNMPv1, SNMPv2c, and SNMPv3.
Tables 10-2 through 10-6 provide information about the characteristics of the different combinations of security models and levels.
Table 10-2 SNMPv1
Characteristic |
Setting |
Level |
noAuthNoPriv |
Authentication |
Community string |
Encryption |
No |
Result |
Uses a community string match for authentication |
Table 10-3 SNMPv2c
Characteristic |
Setting |
Level |
noAuthNoPriv |
Authentication |
Community string |
Encryption |
No |
Result |
Uses a community string match for authentication |
Table 10-4 SNMPv3 noAuthNoPriv
Characteristic |
Setting |
Level |
noAuthNoPriv |
Authentication |
Username |
Encryption |
No |
Result |
Uses a username match for authentication (an improvement over SNMPv2c) |
Table 10-5 SNMPv3 authNoPriv
Characteristic |
Setting |
Level |
authNoPriv |
Authentication |
Message Digest 5 (MD5) or Secure Hash Algorithm (SHA) |
Encryption |
No |
Result |
Provides authentication based on the HMAC-MD5 or HMAC-SHA algorithms |
Table 10-6 SNMPv3 authPriv
Characteristic |
Setting |
Level |
authPriv (requires the cryptographic software image) |
Authentication |
MD5 or SHA |
Encryption |
Data Encryption Standard (DES) or Advanced Encryption Standard (AES) |
Result |
Provides authentication based on the HMAC-MD5 or HMAC-SHA algorithms. Allows specifying the User-Based Security Model (USM) with these encryption algorithms:
|
A network administrator must configure the SNMP agent to use the SNMP version supported by the management station. Because an agent can communicate with multiple SNMP managers, it is possible to configure the software to support communications by using SNMPv1, SNMPv2c, or SNMPv3.
Check Your Understanding—SNMP Versions (10.4.5)
Refer to the online course to complete this activity.
Community Strings (10.4.6)
For SNMP to operate, the NMS must have access to the MIB. To ensure that access requests are valid, some form of authentication must be in place.
SNMPv1 and SNMPv2c use community strings that control access to the MIB. Community strings are plaintext passwords. SNMP community strings authenticate access to MIB objects.
There are two types of community strings:
Read-only (ro): This type provides access to the MIB variables but does not allow these variables to be changed; they can only be read. Because security is minimal in version 2c, many organizations use SNMPv2c in read-only mode.
Read-write (rw): This type provides read and write access to all objects in the MIB.
To view or set MIB variables, the user must specify the appropriate community string for read or write access.
Figures 10-14 through 10-17 demonstrate how SNMP operates with a community string. The figures illustrate the following steps:
Step 1. As shown in Figure 10-14, a customer calls to report that access to her web server is slow.
Figure 10-14 Community String Example: Step 1
Step 2. As shown in Figure 10-15, the administrator uses the NMS to send a get request to the web server SNMP agent (get 192.168.1.10) for its connection statistics. The get request also includes the community string (2#B7!9).
Figure 10-15 Community String Example: Step 2
Step 3. As shown in Figure 10-16, the SNMP agent verifies the received community string and IP address before replying to the get request.
Figure 10-16 Community String Example: Step 3
Step 4. As shown in Figure 10-17, the SNMP agent sends the requested statistics to the NMS with the connection variable, reporting that 10,000 users are currently connected to the web server.
Figure 10-17 Community String Example: Step 4
Note
Plaintext passwords are not considered a security mechanism. This is because plaintext passwords are highly vulnerable to man-in-the-middle attacks, in which they are compromised through the capture of packets.
MIB Object ID (10.4.7)
The MIB organizes variables hierarchically. MIB variables enable the management software to monitor and control the network device. Formally, the MIB defines each variable as an object ID (OID). OIDs uniquely identify managed objects in the MIB hierarchy. The MIB organizes the OIDs based on RFC standards into a hierarchy of OIDs, usually shown as a tree.
The MIB tree for any given device includes some branches with variables common to many networking devices and some branches with variables specific to a particular device or vendor.
RFCs define some common public variables. Most devices implement these MIB variables. In addition, networking equipment vendors, including Cisco, can define their own private branches of the tree to accommodate new variables specific to their devices.
Figure 10-18 shows portions of the MIB structure defined by Cisco.
Note that the OID can be described in words or numbers to help locate a particular variable in the tree. OIDs belonging to Cisco are numbered as follows: .iso (1), .org (3), .dod (6), .internet (1), .private (4), .enterprises (1), and .cisco (9). Therefore, the OID in this case is 1.3.6.1.4.1.9.
SNMP Polling Scenario (10.4.8)
SNMP can be used to observe CPU utilization over a period of time by polling devices. CPU statistics can then be compiled on the NMS and graphed. This creates a baseline for the network administrator. Threshold values can then be set relative to this baseline. When CPU utilization exceeds this threshold, notifications are sent. Figure 10-19 illustrates five-minute samples of router CPU utilization over the period of a few weeks.
Figure 10-18 Example of an SNMP MIB Object ID Structure
Figure 10-19 5-Minute CPU Utilization
The data is retrieved via the snmpget utility, issued on the NMS. By using the snmpget utility, you can manually retrieve real-time data or have the NMS run a report. This report would give you a period of time that you could use the data to get the average. The snmpget utility requires that the SNMP version, the correct community, the IP address of the network device to query, and the OID number be set. Figure 10-20 demonstrates the use of the freeware snmpget utility, which allows quick retrieval of information from the MIB.
Figure 10-20 Example of the snmpget Utility
The snmpget command has several parameters, including:
-v2c: This is the version of SNMP.
-c community: This is the SNMP password, called a community string.
10.250.250.14: This is the IP address of the monitored device.
1.3.6.1.4.1.9.2.1.58.0: This is the OID of the MIB variable.
The last line of output shows the response. The output in Figure 10-20 shows a shortened version of the MIB variable. It then lists the actual value in the MIB location. In this case, the 5-minute moving average of the CPU busy percentage is 11%.
SNMP Object Navigator (10.4.9)
The snmpget utility gives some insight into the basic mechanics of how SNMP works. However, working with long MIB variable names like 1.3.6.1.4.1.9.2.1.58.0 can be problematic for the average user. More commonly, network operations staff use a network management product with an easy-to-use GUI that makes the MIB data variable naming transparent to the user.
A search for “Cisco SNMP Object Navigator tool” on the http://www.cisco.com website provides a tool that allows a network administrator to research details about a particular OID. Figure 10-21 shows an example of using Cisco SNMP Object Navigator to research the OID information for the whyReload object.
Figure 10-21 The SNMP Object Navigator Website
Lab—Research Network Monitoring Software (10.4.10)
In this lab, you will complete the following objectives:
Part 1: Survey your understanding of network monitoring
Part 2: Research network monitoring tools
Part 3: Select a network monitoring tool
Syslog (10.5)
In this section, you will learn about the operation of syslog.
Introduction to Syslog (10.5.1)
Like a check engine light on your car dashboard, the components in your network can tell you if there is something wrong. The syslog protocol was designed to ensure that you can receive and understand such messages. When certain events occur on a network, networking devices have trusted mechanisms to notify the administrator with detailed system messages. These messages can be either non-critical or significant. Network administrators have a variety of options for storing, interpreting, and displaying these messages. They can also be alerted to the messages that could have the greatest impact on the network infrastructure.
The most common method of accessing system messages is to use a protocol called syslog.
Syslog is a term used to describe a standard. It is also used to describe the protocol developed for that standard. The syslog protocol was developed for UNIX systems in the 1980s but was first documented as RFC 3164 by the IETF in 2001. Syslog uses UDP port 514 to send event notification messages across IP networks to event message collectors, as shown in Figure 10-22.
Figure 10-22 Syslog Messages Sent to the Syslog Server
Many networking devices support syslog, including routers, switches, application servers, firewalls, and other network appliances. The syslog protocol allows networking devices to send their system messages across the network to syslog servers.
There are several different syslog server software packages for Windows and UNIX. Many of them are freeware.
The syslog logging service provides three primary functions:
The ability to gather logging information for monitoring and troubleshooting
The ability to select the type of logging information that is captured
The ability to specify the destinations of captured syslog messages
Syslog Operation (10.5.2)
On Cisco network devices, the syslog protocol starts by sending system messages and debug output to a local logging process that is internal to the device. How the logging process manages these messages and outputs depends on the device configurations. For example, syslog messages may be sent across the network to an external syslog server. These messages can be retrieved without needing to access the actual device. Log messages and outputs stored on the external server can be pulled into various reports for easier reading.
Alternatively, syslog messages may be sent to an internal buffer. Messages sent to the internal buffer are viewable only through the CLI of the device.
Finally, the network administrator may specify that only certain types of system messages be sent to various destinations. For example, a device may be configured to forward all system messages to an external syslog server. However, debug-level messages are forwarded to the internal buffer and are only accessible by the administrator from the CLI.
Figure 10-23 shows the common destinations for syslog messages
Figure 10-23 Destinations for Syslog Messages
It is possible to remotely monitor system messages by viewing the logs on a syslog server or by accessing the device through Telnet, SSH, or the console port.
Syslog Message Format (10.5.3)
Cisco devices produce syslog messages as a result of network events. Every syslog message contains a severity level and a facility.
The smaller numerical levels are the more critical syslog alarms. The severity levels of messages can be set to control where each type of message is displayed such as on the console or the other destinations). The complete list of syslog levels is shown in Table 10-7.
Table 10-7 Syslog Severity Levels
Severity Name |
Severity Level |
Explanation |
Emergency |
Level 0 |
System unusable |
Alert |
Level 1 |
Immediate action needed |
Critical |
Level 2 |
Critical condition |
Error |
Level 3 |
Error condition |
Warning |
Level 4 |
Warning condition |
Notification |
Level 5 |
Normal but significant condition |
Informational |
Level 6 |
Informational message |
Debugging |
Level 7 |
Debugging message |
Each syslog level has its own meaning:
Warning Level 4—Emergency Level 0: These messages are error messages about software or hardware malfunctions; these types of messages mean that the functionality of the device is affected. The severity of the issue determines the syslog level applied.
Notification Level 5: This notification level is for normal but significant events. For example, interface up or down transitions and system restart messages are displayed at the notifications level.
Informational Level 6: This is a normal information message that does not affect device functionality. For example, when a Cisco device is booting, you might see the following informational message: %LICENSE-6-EULA_ACCEPT_ALL: The Right to Use End User License Agreement is accepted.
Debugging Level 7: This level indicates that the messages are output generated from issuing various debug commands.
Syslog Facilities (10.5.4)
In addition to specifying the severity, syslog messages also contain information on the facility. Syslog facilities are service identifiers that identify and categorize system state data for error and event message reporting. The logging facility options that are available are specific to the networking device. For example, Cisco 2960 Series switches running Cisco IOS Release 15.0(2) and Cisco 1941 routers running Cisco IOS Release 15.2(4) support 24 facility options that are categorized into 12 facility types.
Some common syslog message facilities reported on Cisco IOS routers include
IF: Identifies that the syslog message was generated by an interface
IP: Identifies that the syslog message was generated by IP
OSPF: Identifies that the syslog message was generated by the OSPF routing protocol
SYS: Identifies that the syslog message was generated by the device operating system
IPSEC: Identifies that the syslog message was generated by the IPsec protocol
By default, the format of syslog messages on the Cisco IOS software is as follows:
%facility-severity-MNEMONIC: description
For example, sample output on a Cisco switch for an EtherChannel link changing state to up is:
%LINK-3-UPDOWN: Interface Port-channel1, changed state to up
Here the facility is LINK, and the severity level is 3, with a MNEMONIC of UPDOWN.
The most common messages are link up and link down messages and messages that a device produces when it exits configuration mode. If ACL logging is configured, the device generates syslog messages when packets match a parameter condition.
Configure Syslog Timestamp (10.5.5)
By default, log messages are not timestamped. In Example 10-19, the R1 GigabitEthernet 0/0/0 interface is shut down.
Example 10-19 Syslog Configuration
R1(config)# interface g0/0/0 R1(config-if)# shutdown %LINK-5-CHANGED: Interface GigabitEthernet0/0/0, changed state to administratively down %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0/0, changed state to down R1(config-if)# exit R1(config)# R1(config)# service timestamps log datetime R1(config)# R1(config)# interface g0/0/0 R1(config-if)# no shutdown *Mar 1 11:52:42: %LINK-3-UPDOWN: Interface GigabitEthernet0/0/0, changed state to down *Mar 1 11:52:45: %LINK-3-UPDOWN: Interface GigabitEthernet0/0/0, changed state to up *Mar 1 11:52:46: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0/0, changed state to up R1(config-if)#
The message logged to the console does not identify when the interface state was changed. Log messages should be timestamped so that when they are sent to another destination, such as a syslog server, there is a record of when a message was generated.
Use the service timestamps log datetime global configuration command to force logged events to display the date and time. As shown in the command output in Example 10-19, when the R1 GigabitEthernet 0/0/0 interface is reactivated, the log messages contain the date and time.
Note
When using the datetime keyword, the clock on the networking device must be set, either manually or through NTP, as previously discussed.
Check Your Understanding—Syslog Operation (10.5.6)
Refer to the online course to complete this activity.
Router and Switch File Maintenance (10.6)
In this section, you will use commands to back up and restore an IOS configuration file.
Router File Systems (10.6.1)
If you are thinking that you cannot possibly remember how you configured every device in your network, you are not alone. In a large network, it would not be possible to manually configure every device. Fortunately, there are many ways to copy or update your configurations and then simply paste them on other devices. To do this, you need to know how to view and manage your file systems.
Cisco IOS File System (IFS) allows an administrator to navigate to different directories and list the files in a directory. The administrator can also create subdirectories in flash memory or on a disk. The directories available depend on the device.
Example 10-20 shows the output of the show file systems command, which lists all the available file systems on a Cisco 4221 router.
Example 10-20 Displaying the File Systems on a Router
Router# show file systems
File Systems:
Size(b) Free(b) Type Flags Prefixes
- - opaque rw system:
- - opaque rw tmpsys:
* 7194652672 6294822912 disk rw bootflash: flash:
256589824 256573440 disk rw usb0:
1804468224 1723789312 disk ro webui:
- - opaque rw null:
- - opaque ro tar:
- - network rw tftp:
- - opaque wo syslog:
33554432 33539983 nvram rw nvram:
- - network rw rcp:
- - network rw ftp:
- - network rw http:
- - network rw scp:
- - network rw sftp:
- - network rw https:
- - opaque ro cns:
Router#
This command provides useful information, such as the amount of total and free memory, the type of file system, and its permissions. Permissions include read only (ro), write only (wo), and read and write (rw). The permissions are shown in the Flags column of the command output.
Although there are several file systems listed, the ones that are interesting at this point are the tftp, flash, and nvram file systems.
Notice that the flash file system has an asterisk preceding it. This indicates that flash is the current default file system. The bootable IOS is located in flash; therefore, the pound symbol (#) is appended to the flash listing, indicating that it is a bootable disk.
The Flash File System
Example 10-21 shows the output of the dir (directory) command.
Example 10-21 Displaying the Flash File System on a Router
Router# dir Directory of bootflash:/ 11 drwx 16384 Aug 2 2019 04:15:13 +00:00 lost+found 370945 drwx 4096 Oct 3 2019 15:12:10 +00:00 .installer 338689 drwx 4096 Aug 2 2019 04:15:55 +00:00 .ssh 217729 drwx 4096 Aug 2 2019 04:17:59 +00:00 core 379009 drwx 4096 Sep 26 2019 15:54:10 +00:00 .prst_sync 80641 drwx 4096 Aug 2 2019 04:16:09 +00:00 .rollback_timer 161281 drwx 4096 Aug 2 2019 04:16:11 +00:00 gs_script 112897 drwx 102400 Oct 3 2019 15:23:07 +00:00 tracelogs 362881 drwx 4096 Aug 23 2019 17:19:54 +00:00 .dbpersist 298369 drwx 4096 Aug 2 2019 04:16:41 +00:00 virtual-instance 12 -rw- 30 Oct 3 2019 15:14:11 +00:00 throughput_monitor_params 8065 drwx 4096 Aug 2 2019 04:17:55 +00:00 onep 13 -rw- 34 Oct 3 2019 15:19:30 +00:00 pnp-tech-time 249985 drwx 4096 Aug 20 2019 17:40:11 +00:00 Archives 14 -rw- 65037 Oct 3 2019 15:19:42 +00:00 pnp-tech-discovery-summary 17 -rw- 5032908 Sep 19 2019 14:16:23 +00:00 isr4200_4300_ rommon_1612_1r_SPA.pkg 18 -rw- 517153193 Sep 21 2019 04:24:04 +00:00 isr4200-universalk9_ias. 16.09.04.SPA.bin 7194652672 bytes total (6294822912 bytes free) Router#
Because flash is the default file system, in this example, the dir command lists the contents of flash. Several files are located in flash, but of specific interest is the last listing: the name of the current Cisco IOS file image that is running in RAM.
The NVRAM File System
To view the contents of NVRAM, you must change the current default file system by using the cd (change directory) command, as shown in Example 10-22.
Example 10-22 Displaying the NVRAM File System on a Router
Router#
Router# cd nvram:
Router# pwd
nvram:/
Router#
Router# dir
Directory of nvram:/
32769 -rw- 1024 startup-config
32770 ---- 61 private-config
32771 -rw- 1024 underlying-config
1 ---- 4 private-KS1
2 -rw- 2945 cwmp_inventory
5 ---- 447 persistent-data
6 -rw- 1237 ISR4221-2x1GE_0_0_0
8 -rw- 17 ecfm_ieee_mib
9 -rw- 0 ifIndex-table
10 -rw- 1431 NIM-2T_0_1_0
12 -rw- 820 IOS-Self-Sig#1.cer
13 -rw- 820 IOS-Self-Sig#2.cer
33554432 bytes total (33539983 bytes free)
Router#
The present working directory command is pwd. This command verifies that you are viewing the NVRAM directory. Finally, the dir command lists the contents of NVRAM. Although there are several configuration files listed, of specific interest is the startup-configuration file.
Switch File Systems (10.6.2)
With the Cisco 2960 switch flash file system, you can copy configuration files and archive (upload and download) software images.
The command to view the file systems on a Catalyst switch is the same as on a Cisco router: show file systems (see Example 10-23).
Example 10-23 Displaying the File System on a Switch
Switch# show file systems
File Systems:
Size(b) Free(b) Type Flags Prefixes
* 32514048 20887552 flash rw flash:
- - opaque rw vb:
- - opaque ro bs:
- - opaque rw system:
- - opaque rw tmpsys:
65536 48897 nvram rw nvram:
- - opaque ro xmodem:
- - opaque ro ymodem:
- - opaque rw null:
- - opaque ro tar:
- - network rw tftp:
- - network rw rcp:
- - network rw http:
- - network rw ftp:
- - network rw scp:
- - network rw https:
- - opaque ro cns:
Switch#
Use a Text File to Back Up a Configuration (10.6.3)
Configuration files can be saved to a text file by using Tera Term, as shown in Figure 10-24. To use Tera Term to back up a configuration, follow these steps:
Figure 10-24 Example of Using Tera Term to Back Up a Configuration
Step 1. On the File menu, click Log.
Step 2. Choose the folder location and a filename for the file and click on Save. Tera Term opens the Tera Term: Log window and now captures all commands and output generated in the terminal window.
Step 3. To capture the current configuration, enter the show running-config or show startup-config command in privileged EXEC mode. The text displayed in the terminal window is also directed to the chosen file.
Step 4. When the capture is complete, click Close in the Tera Term: Log window.
Step 5. Open the file to verify that the configuration was captured properly and ensure that it is not corrupt.
Use a Text File to Restore a Configuration (10.6.4)
A configuration can be copied from a file and then directly pasted to a device. IOS executes each line of the configuration text as a command. This means that the file needs to be edited to ensure that encrypted passwords are in plaintext and that non-command text such as --More-- and IOS messages are removed. In addition, you may want to add enable and configure terminal to the beginning of the file or enter global configuration mode before pasting the configuration. (This process is discussed in the lab later in this section.)
Instead of copying and pasting, you can restore a configuration from a text file by using Tera Term, as shown in Figure 10-25.
When using Tera Term to restore a configuration, the steps are as follows:
Step 1. On the File menu, click Send file.
Step 2. Locate the file to be copied to the device and click Open. Tera Term pastes the file to the device. The text in the file is applied as commands in the CLI and becomes the running configuration on the device.
Use TFTP to Back Up and Restore a Configuration (10.6.5)
Copies of configuration files should be stored as backup files in the event of a problem. Configuration files can be stored on a Trivial File Transfer Protocol (TFTP) server or a USB drive. A configuration file should also be included in the network documentation.
To save the running configuration or the startup configuration to a TFTP server, use either the copy running-config tftp or copy startup-config tftp command, as shown in Example 10-24.
Figure 10-25 Example of Using Tera Term to Restore a Configuration
Example 10-24 Transferring the Running Configuration to a TFTP Server
R1# copy running-config tftp Remote host []? 192.168.10.254 Name of the configuration file to write[R1-config]? R1-Jan-2019 Write file R1-Jan-2019 to 192.168.10.254? [confirm] Writing R1-Jan-2019 !!!!!! [OK] R1#
Follow these steps to back up the running configuration to a TFTP server:
Step 1. Enter the copy running-config tftp command and press Enter.
Step 2. Enter the IP address of the host where the configuration file will be stored and press Enter.
Step 3. Enter the name to assign to the configuration file and press Enter.
To restore the running configuration or the startup configuration from a TFTP server, use either the copy tftp running-config or copy tftp startup-config command. Use the following steps to restore the running configuration from a TFTP server:
Step 1. Enter the copy tftp running-config command and press Enter.
Step 2. Enter the IP address of the host where the configuration file is stored and press Enter.
Step 3. Enter the name to assign to the configuration file and press Enter.
USB Ports on a Cisco Router (10.6.6)
The Universal Serial Bus (USB) storage feature enables certain models of Cisco routers to support USB flash drives. USB provides an optional secondary storage capability and an additional boot device. Images, configurations, and other files can be copied to or from the Cisco USB flash memory with the same reliability as when storing and retrieving files by using a Compact Flash card. In addition, modular integrated services routers can boot any Cisco IOS software image saved on USB flash memory. Ideally, USB flash can hold multiple copies of Cisco IOS and multiple router configurations. The USB ports of a Cisco 4321 router are shown in Figure 10-26.
Figure 10-26 Backplane of the Cisco 4231
Use the dir command to view the contents of a USB flash drive, as shown in Example 10-25.
Example 10-25 Displaying the Contents of an Attached USB Drive
R1# dir usbflash0: Directory of usbflash0:/ 1 -rw- 30125020 Dec 22 2032 05:31:32 +00:00 c3825-entservicesk9-mz.123-14.T 63158272 bytes total (33033216 bytes free) R1#
Use USB to Back Up and Restore a Configuration (10.6.7)
When backing up to a USB port, it is a good idea to issue the show file systems command to verify that the USB drive is there and confirm the name, as shown in Example 10-26.
Example 10-26 Displaying the File System to Verify That the USB Drive Is Connected
R1# show file systems
File Systems:
Size(b) Free(b) Type Flags Prefixes
- - opaque rw archive:
- - opaque rw system:
- - opaque rw tmpsys:
- - opaque rw null:
- - network rw tftp:
* 256487424 184819712 disk rw flash0: flash:#
- - disk rw flash1:
262136 249270 nvram rw nvram:
- - opaque wo syslog:
- - opaque rw xmodem:
- - opaque rw ymodem:
- - network rw rcp:
- - network rw http:
- - network rw ftp:
- - network rw scp:
- - opaque ro tar:
- - network rw https:
- - opaque ro cns:
4050042880 3774152704 usbflash rw usbflash0:
R1#
Notice that the last line of output in Example 10-26 shows the USB port and name: usbflash0:.
Next, as shown in Example 10-27, use the copy run usbflash0:/ command to copy the configuration file to the USB flash drive. Be sure to use the name of the flash drive, as indicated in the file system. The slash is optional but indicates the root directory of the USB flash drive.
Example 10-27 Copying the Running Configuration to a USB Drive
R1# copy running-config usbflash0:/ Destination filename [running-config]? R1-Config 5024 bytes copied in 0.736 secs (6826 bytes/sec)
IOS prompts for the filename. If the file already exists on the USB flash drive, the router prompts to overwrite, as shown in the examples.
When copying to a USB flash drive with no preexisting file, you get output similar to that shown in Example 10-27.
When copying to a USB flash drive, with the same configuration file already on the drive, you see output similar to that shown in Example 10-28.
Example 10-28 Warning When the Same Filename Already Exists on the USB Drive
R1# copy running-config usbflash0: Destination filename [running-config]? R1-Config %Warning:There is a file already existing with this name Do you want to over write? [confirm] 5024 bytes copied in 1.796 secs (2797 bytes/sec) R1#
Use the dir command to see the file on the USB drive and use the more command to see the contents, as shown in Example 10-29.
Example 10-29 Verifying That the File Is Now on the USB Drive
R1# dir usbflash0:/
Directory of usbflash0:/
1 drw- 0 Oct 15 2010 16:28:30 +00:00 Cisco
16 -rw- 5024 Jan 7 2013 20:26:50 +00:00 R1-Config
4050042880 bytes total (3774144512 bytes free)
R1#
R1# more usbflash0:/R1-Config
!
! Last configuration change at 20:19:54 UTC Mon Jan 7 2013 by
admin version 15.2
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R1
!
boot-start-marker
boot-end-marker
!
logging buffered 51200 warnings
!
no aaa new-model
!
no ipv6 cef
R1#
Restore Configurations with a USB Flash Drive
To copy a file back to a device from a flash drive, you need to edit the USB R1-Config file with a text editor. For example, if the filename is R1-Config, use the copy usbflash0:/R1-Config running-config command to restore a running configuration.
Password Recovery Procedures (10.6.8)
Passwords are used on devices to prevent unauthorized access to those devices. For encrypted passwords, such as the enable secret passwords, the passwords must be replaced after recovery.
Note
Console access to a physical device is required to perform password recovery.
The detailed procedure for password recovery varies depending on the device. However, all the password recovery procedures follow the same basic process:
Step 1. Enter the ROMMON mode.
Step 2. Change the configuration register.
Step 3. Copy the startup configuration to the running configuration.
Step 4. Change the password.
Step 5. Save the running configuration as the new startup configuration.
Step 6. Reload the device.
Console access to the device through a terminal or terminal emulator software on a PC is required for password recovery. The terminal settings to access the device are:
9600 baud rate
No parity
8 data bits
1 stop bit
No flow control
Password Recovery Example (10.6.9)
The following sections describe the steps in password recovery.
Step 1. Enter the ROMMON mode.
With console access, a user can access the ROMMON mode by using a break sequence during the bootup process or by removing the external flash memory when the device is powered off. When successful, the rommon 1 > prompt displays, as shown in Example 10-30.
Note
The break sequence for PuTTY is Ctrl+Break. A list of standard break key sequences for other terminal emulators and operating systems can be found by searching the internet.
Example 10-30 Entering the ROMMON Mode
Readonly ROMMON initialized monitor: command "boot" aborted due to user interrupt rommon 1>
Step 2. Change the configuration register.
The ROMMON software supports some basic commands, such as confreg. For example, the confreg 0x2142 command sets the configuration register to 0x2142. With the configuration register at 0x2142, the device ignores the startup configuration file during startup. (The startup configuration file is where the forgotten passwords are stored.) After setting the configuration register to 0x2142, type reset at the prompt to restart the device. Enter the break sequence while the device is rebooting and decompressing IOS. Example 10-31 shows the terminal output of a 1941 router in the ROMMON mode after using a break sequence during the bootup process.
Example 10-31 Changing the Configuration Register
rommon 1 > confreg 0x2142 rommon 2 > reset System Bootstrap, Version 15.0(1r)M9, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 2010 by cisco Systems, Inc. (output omitted)
Step 3. Copy the startup-config to the running-config.
After a device has finished reloading, copy the startup configuration to the running configuration by using the copy startup-config running-config command, as shown in Example 10-32.
Example 10-32 Copying the Startup Configuration to the Running Configuration
Router# copy startup-config running-config Destination filename [running-config]? 1450 bytes copied in 0.156 secs (9295 bytes/sec) R1#
Notice that the router prompt changes to R1# because the hostname is set to R1 in the startup configuration.
Caution
Do not enter copy running-config startup-config. This command erases the original startup configuration.
Step 4. Change the password.
While in privileged EXEC mode, you can configure all the necessary passwords. Example 10-33 shows how to change a password.
Note
The password cisco is not a strong password and is used here only as an example.
Example 10-33 Changing the Password
R1(config)# enable secret cisco R1(config)#
Step 5. Save the running-config as the new startup-config.
After the new passwords are configured, change the configuration register back to 0x2102 by using the config-register 0x2102 command in global configuration mode. Save the running configuration to the startup configuration, as shown in Example 10-34.
Example 10-34 Saving the Running Configuration as the New Startup Configuration
R1(config)# config-register 0x2102 R1(config)# end R1# R1# copy running-config startup-config Destination filename [startup-config]? Building configuration... [OK] R1#
Step 6. Reload the device.
Reload the device, as shown in Example 10-35.
Example 10-35 Reloading the Device
R1# reload Proceed with reload? [confirm] *Mar 1 13:04:53.009: %SYS-5-RELOAD: Reload requested by console. Reload Reason: Reload Command.
Notice that you are prompted to confirm the reload. To continue, press Enter. (To cancel, press Ctrl+C.) The device reboots and now uses the newly configured passwords for authentication. Be sure to use show commands to verify that all the configurations are still in place. For example, verify that the appropriate interfaces are not shut down after password recovery.
Note
To find detailed instructions for password recovery procedures for a specific device, search the internet.
Packet Tracer—Back Up Configuration Files (10.6.10)
In this activity, you will restore a configuration from a backup and then perform a new backup. Due to an equipment failure, a new router has been put in place. Fortunately, backup configuration files have been saved to a Trivial File Transfer Protocol (TFTP) server. You are required to restore the files from the TFTP server to get the router back online as quickly as possible.
Lab—Use Tera Term to Manage Router Configuration Files (10.6.11)
In this lab, you will complete the following objectives:
Part 1: Configure basic device settings
Part 2: Use terminal emulation software to create a backup configuration file
Part 3: Use a backup configuration file to restore a router
Lab—Use TFTP, Flash, and USB to Manage Configuration Files (10.6.12)
In this lab, you will complete the following objectives:
Part 1: Build the network and configure basic device settings
Part 2: (Optional) Download TFTP server software
Part 3: Use TFTP to back up and restore the switch running configuration
Part 4: Use TFTP to back up and restore the router running configuration
Part 5: Back up and restore running configurations using router flash memory
Part 6: (Optional) Use a USB drive to back up and restore the running configuration
Lab—Research Password Recovery Procedures (10.6.13)
In this lab, you will complete the following objectives:
Part 1: Research the configuration register
Part 2: Document the password recovery procedure for a specific Cisco router
IOS Image Management
In this section, you will learn how to upgrade an IOS system image.
Video—Managing Cisco IOS Images (10.7.1)
Refer to the online course to view this video.
TFTP Servers as a Backup Location (10.7.2)
Earlier in this chapter, you learned how to copy and paste a configuration. This section takes that idea one step further with IOS software images. As a network grows, Cisco IOS software images and configuration files can be stored on a central TFTP server, as shown in Figure 10-27.
Figure 10-27 TFTP Topology
Storing the images and files centrally helps to control the number of IOS images and the revisions to those IOS images, as well as the configuration files that must be maintained.
Production internetworks usually span wide areas and contain multiple routers. For any network, it is good practice to keep a backup copy of the Cisco IOS software image in case the system image on the router becomes corrupted or accidentally erased.
Widely distributed routers need a source or backup location for Cisco IOS software images. Using a network TFTP server allows image and configuration uploads and downloads over the network. The network TFTP server can be another router, a workstation, or a host system.
Backup IOS Image to TFTP Server Example (10.7.3)
To maintain network operations with minimum downtime, it is necessary to have procedures in place for backing up Cisco IOS images. Such procedures enable a network administrator to quickly copy an image back to a router in the event of a corrupted or erased image.
In Figure 10-28, the network administrator wants to create on the TFTP server at 172.16.1.100 a backup of the current image file on the router (isr4200-universalk9_ ias.16.09.04.SPA.bin).
Figure 10-28 TFTP Topology—R1 to TFTP Server
The following sections describe the steps to create a backup of the Cisco IOS image to a TFTP server.
Step 1. Ping the TFTP server.
To ensure that the network TFTP server is accessible, ping the server as shown in Example 10-36.
Example 10-36 Pinging the TFTP Server
R1# ping 172.16.1.100 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.1.100, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 56/56/56 ms R1#
Step 2. Verify image size in flash.
Verify that the TFTP server has sufficient disk space to accommodate the Cisco IOS software image. As shown in Example 10-37, use the show flash0: command on the router to determine the size of the Cisco IOS image file. The file in this example is 517153193 bytes long.
Example 10-37 Verifying Image Size in Flash
R1# show flash0:
-# - --length-- -----date/time------ path
8 517153193 Apr 2 2019 21:29:58 +00:00
isr4200-universalk9_ias.16.09.04.SPA.bin
(output omitted)
R1#
Step 3. Copy the image to the TFTP server.
Copy the image to the TFTP server by using the copy source-url destination-url command. After issuing the command by using the specified source and destination URLs, you are prompted for the source filename, the IP address of the remote host, and the destination filename. Typically, you press Enter to accept the source filename as the destination filename. The transfer then begins, as shown in Example 10-38.
Example 10-38 Copying the Image to the TFTP Server
R1# copy flash: tftp: Source filename []? isr4200-universalk9_ias.16.09.04.SPA.bin Address or name of remote host []? 172.16.1.100 Destination filename [isr4200-universalk9_ias.16.09.04.SPA.bin]? Writing isr4200-universalk9_ias.16.09.04.SPA.bin... !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! (output omitted) 517153193 bytes copied in 863.468 secs (269058 bytes/sec) R1#
Copy an IOS Image to a Device Example (10.7.4)
Cisco consistently releases new Cisco IOS software versions to resolve issues and provide new features. This section shows an example of using IPv6 for the transfer to show that TFTP can also be used across IPv6 networks.
Figure 10-29 illustrates the process of copying a Cisco IOS software image from a TFTP server. A new image file (isr4200-universalk9_ias.16.09.04.SPA.bin) is copied from the TFTP server at 2001:DB8:CAFE:100::99 to the router.
Figure 10-29 TFTP Topology—TFTP Server to R1
Select a Cisco IOS image file that meets the requirements in terms of platform, features, and software. Download the file from cisco.com and transfer it to the TFTP server. The following sections explain the process to upgrade the IOS image on the Cisco router.
Step 1. Ping the TFTP server.
To ensure that the network TFTP server is accessible, ping the server as shown in Example 10-39.
Example 10-39 Pinging the TFTP Server
R1# ping 2001:db8:cafe:100::99 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2001:DB8:CAFE:100::99, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 56/56/56 ms R1#
Step 2. Verify the amount of free flash.
Ensure that there is sufficient flash space on the router that is being upgraded. The amount of free flash can be verified by using the show flash: command. Compare the free flash space with the new image file size. The show flash: command in Example 10-40 is used to verify free flash size. Free flash space in the example is 6294806528 bytes.
Example 10-40 Verifying the Amount of Free Flash
R1# show flash: -# - --length-- -----date/time------ path (output omitted) 6294806528 bytes available (537251840 bytes used) R1#
Step 3. Copy the new IOS image to flash.
Copy the IOS image file from the TFTP server to the router by using the copy command, as shown in Example 10-41. After issuing this command with specified source and destination URLs, you are prompted for the IP address of the remote host, the source filename, and the destination filename. Typically, you press Enter to accept the source filename as the destination filename. The transfer of the file begins.
Example 10-41 Copying the New IOS Image to Flash
R1# copy tftp: flash: Address or name of remote host []? 2001:DB8:CAFE:100::99 Source filename []? isr4200-universalk9_ias.16.09.04.SPA.bin Destination filename [isr4200-universalk9_ias.16.09.04.SPA.bin]? Accessing tftp://2001:DB8:CAFE:100::99/ isr4200- universalk9_ias.16.09.04.SPA.bin... Loading isr4200-universalk9_ias.16.09.04.SPA.bin from 2001:DB8:CAFE:100::99 (via GigabitEthernet0/0/0): !!!!!!!!!!!!!!!!!!!! [OK - 517153193 bytes] 517153193 bytes copied in 868.128 secs (265652 bytes/sec) R1#
The boot system Command (10.7.5)
To upgrade to the copied IOS image after that image is saved on the flash memory of a router, configure the router to load the new image during bootup by using the boot system global configuration command, as shown in Example 10-42. Save the configuration. Reload the router to boot the router with the new image.
Example 10-42 Configuring the Image to Boot
R1(config)# boot system flash0:isr4200-universalk9_ias.16.09.04.SPA.bin R1(config)# exit R1# R1# copy running-config startup-config R1# R1# reload Proceed with reload? [confirm] *Mar 1 12:46:23.808: %SYS-5-RELOAD: Reload requested by console. Reload Reason: Reload Command.
To continue, press Enter. (To cancel, press Ctrl+C.)
During startup, the bootstrap code parses the startup configuration file in NVRAM for the boot system commands that specify the name and location of the Cisco IOS software image to load. Several boot system commands can be entered in sequence to provide a fault-tolerant boot plan.
If there are no boot system commands in the configuration, the router defaults to loading the first valid Cisco IOS image in flash memory and runs it.
After the router has booted, to verify that the new image has loaded, use the show version command, as shown in Example 10-43.
Example 10-43 Verifying That the Router Booted the Specified Image
R1# show version
Cisco IOS XE Software, Version 16.09.04
Cisco IOS Software [Fuji], ISR Software (X86_64_LINUX_IOSD-UNIVERSALK9_IAS-M),
Version 16.9.4, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2019 by Cisco Systems, Inc.
Compiled Thu 22-Aug-19 18:09 by mcpre
Cisco IOS-XE software, Copyright (c) 2005-2019 by cisco Systems, Inc.
All rights reserved. Certain components of Cisco IOS-XE software are
licensed under the GNU General Public License ("GPL") Version 2.0. The
software code licensed under GPL Version 2.0 is free software that comes
with ABSOLUTELY NO WARRANTY. You can redistribute and/or modify such
GPL code under the terms of GPL Version 2.0. For more details, see the
documentation or "License Notice" file accompanying the IOS-XE software,
or the applicable URL provided on the flyer accompanying the IOS-XE
software.
ROM: IOS-XE ROMMON
Router uptime is 2 hours, 19 minutes
Uptime for this control processor is 2 hours, 22 minutes
System returned to ROM by PowerOn
System image file is "flash:isr4200-universalk9_ias.16.09.04.SPA.bin"
(output omitted)
R1#
Packet Tracer—Use a TFTP Server to Upgrade a Cisco IOS Image (10.7.6)
A TFTP server can help manage the storage of IOS images and revisions to IOS images. For any network, it is good practice to keep a backup copy of the Cisco IOS software image in case the system image in the router becomes corrupted or accidentally erased. A TFTP server can also be used to store new upgrades to IOS and then deployed throughout the network where needed. In this activity, you will upgrade the IOS images on Cisco devices by using a TFTP server. You will also back up an IOS image with the use of a TFTP server.
Summary (10.8)
The following is a summary of the sections in this chapter.
Device Discovery with CDP
Cisco Discovery Protocol (CDP) is a Cisco-proprietary Layer 2 protocol that is used to gather information about Cisco devices that share the same data link. The device sends periodic CDP advertisements to connected devices. CDP can be used as a network discovery tool to determine information about the neighboring devices. This information gathered from CDP can help build a logical topology of a network when documentation is missing or lacking detail. CDP can assist in network design decisions, troubleshooting, and making changes to equipment. On Cisco devices, CDP is enabled by default. To verify the status of CDP and display information about CDP, enter the show cdp command. To enable CDP globally for all the supported interfaces on a device, enter cdp run in global configuration mode. To enable CDP on a specific interface, enter the cdp enable global configuration command. To verify the status of CDP and display a list of neighbors, use the show cdp neighbors command in privileged EXEC mode. The show cdp neighbors command provides helpful information about each CDP neighbor device, including device identifiers, the port identifier, the capabilities list, and the platform. Use the show cdp interface command to display the interfaces on a device that are CDP enabled.
Device Discovery with LLDP
Cisco devices support Link Layer Discovery Protocol (LLDP), which is a vendor-neutral neighbor discovery protocol similar to CDP. This protocol advertises its identity and capabilities to other devices and receives information from a physically connected Layer 2 device. To enable LLDP globally on a Cisco network device, enter the lldp run command in global configuration mode. To verify that LLDP has been enabled on the device, enter the show lldp command in privileged EXEC mode. With LLDP enabled, you can discover device neighbors by using the show lldp neighbors command. When you need more details about the neighbors, use the show lldp neighbors detail command to find information such as the neighbor IOS version, IP address, and device capability.
NTP
The software clock on a router or switch starts when the system boots and is the primary source of time for the system. When the time is not synchronized between devices, it is impossible to determine the order of the events and the cause of an event. You can manually configure the date and time, or you can configure NTP, a protocol that allows routers on a network to synchronize their time settings with an NTP server. When NTP is implemented in a network, it can be set up to synchronize to a private master clock or it can synchronize to a publicly available NTP server on the internet. NTP networks use a hierarchical system of time sources, and each level in this system is called a stratum. The synchronized time is distributed across the network by using NTP. Authoritative time sources, also referred to as stratum 0 devices, are high-precision time-keeping devices. Stratum 1 devices are directly connected to the authoritative time sources. Stratum 2 devices, such as NTP clients, synchronize their time by using the NTP packets from stratum 1 servers. You issue the ntp server ip-address command in global configuration mode to configure a device as the NTP server. To verify the time source is set to NTP, use the show clock detail command. Use the show ntp associations and show ntp status commands to verify that a device is synchronized with the NTP server.
SNMP
SNMP allows administrators to manage servers, workstations, routers, switches, and security appliances on an IP network. SNMP is an application layer protocol that provides a message format for communication between managers and agents. The SNMP system consists of three elements: SNMP manager, SNMP agents, and the MIB. To configure SNMP on a networking device, you must define the relationship between the manager and the agent. The SNMP manager is part of an NMS. The SNMP manager can collect information from an SNMP agent by using the get action and can change configurations on an agent by using the set action. SNMP agents can forward information directly to a network manager by using traps. The SNMP agent responds to SNMP manager GetRequest-PDUs (to get an MIB variable) and SetRequest-PDUs (to set an MIB variable). An NMS periodically uses the get request to poll the SNMP agents by querying the device for data. A network management application can collect information to monitor traffic loads and to verify device configurations of managed devices.
SNMPv1, SNMPv2c, and SNMPv3 are all versions of SNMP. SNMPv1 is a legacy solution. Both SNMPv1 and SNMPv2c use a community-based form of security. The community of managers that is able to access the agent's MIB is defined by a community string. SNMPv2c includes a bulk retrieval mechanism and more detailed error message reporting. SNMPv3 provides for both security models and security levels. SNMP community strings are read-only (ro) and read-write (rw). They are used to authenticate access to MIB objects. The MIB organizes variables hierarchically. MIB variables enable the management software to monitor and control the network device. OIDs uniquely identify managed objects in the MIB hierarchy. The snmpget utility provides some insight into the basic mechanics of how SNMP works. The Cisco SNMP Navigator on the http://www.cisco.com website allows a network administrator to research details about a particular OID.
Syslog
The most common method of accessing system messages is to use a protocol called syslog. The syslog protocol uses UDP port 514 to allow networking devices to send their system messages across the network to syslog servers. The syslog logging service provides three primary functions: gather logging information for monitoring and troubleshooting, select the type of logging information that is captured, and specify the destinations of captured syslog messages. Destinations for syslog messages include the logging buffer (RAM inside a router or switch), console line, terminal line, and syslog server. Table 10-8 lists the syslog levels.
Table 10-8 Syslog Severity Levels
Severity Name |
Severity Level |
Explanation |
Emergency |
Level 0 |
System unusable |
Alert |
Level 1 |
Immediate action needed |
Critical |
Level 2 |
Critical condition |
Error |
Level 3 |
Error condition |
Warning |
Level 4 |
Warning condition |
Notification |
Level 5 |
Normal but significant condition |
Informational |
Level 6 |
Informational message |
Debugging |
Level 7 |
Debugging message |
Syslog facilities identify and categorize system state data for error and event message reporting. Common syslog message facilities reported on Cisco IOS routers include IP, OSPF protocol, SYS operating system, IPsec, and IF. The default format of syslog messages on Cisco IOS software is %facility-severity-MNEMONIC: description. Use the service timestamps log datetime global configuration command to force logged events to display the date and time.
Router and Switch File Maintenance
Cisco IFS lets an administrator navigate to different directories, list the files in a directory, and create subdirectories in flash memory or on a disk. Use the show file systems command to display all the available file systems on a Cisco router. Use the directory command dir to display the directory of bootflash. Use the change directory command cd to view the contents of NVRAM. Use the present working directory command pwd to view the current directory. Use the show file systems command to view the file systems on a Catalyst switch or a Cisco router. Configuration files can be saved to a text file by using Tera Term. A configuration can be copied from a file and then directly pasted to a device. Configuration files can be stored on a TFTP server or a USB drive. To save the running configuration or the startup configuration to a TFTP server, use either the copy running-config tftp command or the copy startup-config tftp command. Use the dir command to view the contents of a USB flash drive. Use the copy run usbflash0:/ command to copy the configuration file to the USB flash drive. Use the dir command to see the file on the USB drive. Use the more command to see the contents of the drive. For encrypted passwords, such as the enable secret passwords, the passwords must be replaced after recovery.
IOS Image Management
Cisco IOS software images and configuration files can be stored on a central TFTP server to control the number of IOS images and the revisions to those IOS images, as well as the configuration files that must be maintained. Select a Cisco IOS image file that meets the requirements in terms of platform, features, and software. Download the file from cisco.com and transfer it to the TFTP server. Ping the TFTP server. Verify the amount of free flash by using the show flash: command. If there is enough free flash to hold the new IOS image, copy the new IOS image to flash. To upgrade to the copied IOS image after that image is saved on the router's flash memory, configure the router to load the new image during bootup by using the boot system global configuration command. Save the configuration. Reload the router to boot the router with the new image. After the router has booted, to verify that the new image has loaded, use the show version command.
Packet Tracer—Configure CDP, LLDP, and NTP (10.8.1)
In this Packet Tracer activity, you will complete the following objectives:
Build the network and configure basic device settings
Network discovery with CDP
Network discovery with LLDP
Configure and verify NTP
Lab—Configure CDP, LLDP, and NTP (10.8.2)
In this lab, you will complete the following objectives:
Build the network and configure basic device settings
Network discovery with CDP
Network discovery with LLDP
Configure and verify NTP
Practice
The following activities provide practice with the topics introduced in this chapter. The labs are available in the companion Enterprise Networking, Security, and Automation Labs & Study Guide (CCNAv7) (ISBN 9780136634690). The Packet Tracer activity instructions are also in the Labs & Study Guide. The PKA files are found in the online course.
Labs
Lab 10.4.10: Research Network Monitoring Software
Lab 10.6.11: Use Tera Term to Manage Router Configuration Files
Lab 10.6.12: Use TFTP, Flash, and USB to Manage Configuration Files
Lab 10.6.13: Research Password Recovery Procedures
Lab 10.8.2: Configure CDP, LLDP, and NTP
Packet Tracer Activities
Packet Tracer 10.1.5: Use CDP to Map a Network
Packet Tracer 10.2.6: Use LLDP to Map a Network
Packet Tracer 10.3.4: Configure and Verify NTP
Packet Tracer 10.6.10: Back Up Configuration Files
Packet Tracer 10.7.6: Use a TFTP Server to Upgrade a Cisco IOS Image
Packet Tracer 10.8.1: Configure CDP, LLDP, and NTP
Check Your Understanding Questions
Complete all the review questions listed here to test your understanding of the topics and concepts in this chapter. The appendix “Answers to the ‘Check Your Understanding’ Questions” lists the answers.
1. Which of the following is one difference between CDP and LLDP?
CDP can gather information from routers, switches, and wireless APs, whereas LLDP can only gather information from routers and switches.
CDP can obtain both Layer 2 and Layer 3 information, whereas LLDP can only obtain Layer 2 information.
CDP is a proprietary protocol, whereas LLDP is a vendor-neutral protocol.
CDP is enabled on an interface using two commands, while LLDP requires only one command.
2. A network administrator wants to configure a router so that only a specific interface will send and receive CDP information. Which two configuration steps accomplish this? (Choose two.)
R1(config)# no cdp enable
R1(config)# no cdp run
R1(config-if)# cdp enable
R1(config-if)# cdp receive
R1(config-if)# cdp transmit
3. What information can be gathered about a neighbor device from the show cdp neighbors detail command that cannot be found with the show cdp neighbors command?
The capabilities of the neighbor
The hostname of the neighbor
The IP address of the neighbor
The platform that is used by the neighbor
4. What is the configuration command to globally enable LLDP on a Cisco Catalyst switch?
enable lldp
feature lldp
lldp enable
lldp run
5. Which option correctly enables LLDP on an interface?
R1(config-if)# lldp enable
R1(config-if)# lldp enable
R1(config-if)# lldp receive
R1(config-if)# lldp receive
R1(config-if)# lldp transmit
R1(config-if)# lldp enable
R1(config-if)# lldp receive
R1(config-if)# lldp transmit
6. What are the most common syslog messages?
Error messages about hardware or software malfunctions
Link up and link down messages
Output messages that are generated from debug output
Messages that occur when a packet matches a parameter condition in an access control list
7. Which syslog logging severity level indicates that a device is unusable?
Level 0—Emergency
Level 1—Alert
Level 2—Critical
Level 3—Error
8. Which protocol or service allows network administrators to receive system messages that are provided by network devices?
NTP
NetFlow
SNMP
Syslog
9. Which syslog message type is accessible only to an administrator via the Cisco CLI?
Alerts
Debugging
Emergency
Errors
10. Which default destination do Cisco routers and switches use to send Syslog messages?
Console
Nearest syslog server
NVRAM
RAM
11. What is the result of configuring the logging trap 4 global configuration command?
The syslog client sends to the syslog server any event message that has a severity level of 4 or lower.
The syslog client sends to the syslog server event messages with an identification trap level of only 4.
The syslog client sends to the syslog server any event message that has a severity level of 4 or higher.
After four events, the syslog client sends an event message to the syslog server.
12. The ntp server 10.1.1.1 global configuration command is issued on router R1. What impact does this command have?
Identifies the NTP server that R1 will send system log messages to
Identifies the NTP server that R1 will use to store backup configurations
Identifies R1 as the NTP server using IP address 10.1.1.1
Synchronizes the clock of R1 with the time server at IP address 10.1.1.1
13. Which two statements are true about NTP servers in an enterprise network? (Choose two.)
All NTP servers synchronize directly to a stratum 1 time source.
NTP servers at stratum 1 are directly connected to an authoritative time source.
NTP servers control the mean time between failures (MTBF) for key network devices.
NTP servers ensure an accurate timestamp on logging and debugging information.
There can be only one NTP server on an enterprise network.
14. What can a network administrator do to access a router if the password has been lost?
Access the router remotely through Telnet and use the show running-config command.
Boot the router into ROMMON mode and reinstall IOS from a TFTP server.
From ROMMON mode, configure the router to ignore the startup configuration when the router initializes.
Reboot the router and use the break key sequence to bypass the password during IOS bootup.
15. What is the result of configuring the confreg 0x2142 command at the rommon 1> prompt?
Contents in NVRAM are erased.
Contents in NVRAM are ignored.
Contents in RAM are erased.
Contents in RAM are ignored.
16. A network technician is attempting a password recovery on a router. From ROMMON mode, which command must be entered to bypass the startup configuration file?
rommon> config-register 0x2102
rommon> confreg 0x2102
rommon> config-register 0x2142
rommon> confreg 0x2142
17. What must an administrator have in order to reset a lost password on a router?
A crossover cable
A TFTP server
Access to another router
Physical access to the router
18. A network engineer is upgrading the Cisco IOS image on a 2900 Series ISR. What command could the engineer use to verify the total amount of flash memory as well as how much flash memory is currently available?
show boot memory
show flash0:
show interfaces
show startup-config
show version
19. Which two conditions should a network administrator verify before attempting to upgrade a Cisco IOS image using a TFTP server? (Choose two.)
Verify connectivity between the router and TFTP server by using the ping command.
Verify that the checksum for the image is valid by using the show version command.
Verify that the TFTP server is running by using the tftpdnld command.
Verify the name of the TFTP server by using the show hosts command.
Verify that there is enough flash memory for the new Cisco IOS image by using the show flash command.
20. Which statement describes SNMP operation?
The SNMP agent uses a get request to query the device for data.
The NMS uses a set request to change configuration variables in the agent device.
An NMS periodically polls the SNMP agents that are residing on managed devices by using traps to query the devices for data.
An SNMP agent that resides on a managed device collects information about the device and stores that information remotely in the MIB that is located on the NMS.
21. Which SNMP feature provides a solution to the main disadvantage of SNMP polling?
SNMP community strings
SNMP get messages
SNMP set messages
SNMP trap messages
22. When SNMPv1 or SNMPv2 is being used, which feature provides secure access to MIB objects?
Community strings
Message integrity
Packet encryption
Source validation
23. Which SNMP version uses weak community string-based access control and supports bulk retrieval?
SNMPv1
SNMPv2c
SNMPv3
SNMPv2Classic