---
title: Device Management Configuration
tags: Cisco IOS, networking, manual, reference, router, switch, technical, security
---
<header>
<h6>Device Management Configuration</h6>
> [toc]
</header>
---
# Network Security Using Syslog
When certain events occur on a network, networking devices have trusted mechanisms to notify the administrator with detailed system messages. Syslog is the most common method of accessing system messages sent across the network. Syslog uses **UDP port 514** to send event notification messages across IP networks to event message collectors.
The **syslog logging** service on Cisco IOS provides three primary functions, as follows:
* 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
Cisco network devices send 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 is based on device configurations. The network administrator may specify that only certain types of system messages be sent to various destinations. Popular destinations for syslog messages include the in-memory **Logging Buffer**, the **Console line**, the **Terminal line**, or an external **syslog server**. 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 through the **console port**.
## Syslog Message Format
Cisco devices produce syslog messages containing a severity level and a facility.
Smaller numerical levels represent more critical syslog alarms. The severity level of the messages can be set to control where each type of message should be displayed.
The available syslog levels include:
| Severity | Level | Description |
| ------------- |:-----:| ------------------------------- |
| Emergency | 0 | System Unusable |
| Alert | 1 | Immediate Action Needed |
| Critical | 2 | Critical Condition |
| Error | 3 | Error Condition |
| Warning | 4 | Warning Condition |
| Notification | 5 | Normal But Signficant Condition |
| Informational | 6 | Informational Message |
| Debugging | 7 | Debugging Message |
* **Emergency (Level 0) - Warning (Level 4)**: Error messages about software or hardware malfunctions. The severity of the issue determines the exact syslog level applied.
* **Notification (Level 5)**: Used for normal, but important events. Interface Up or Down transitions, and System Restart messages are displayed at the notifications level.
* **Informational (Level 6)**: Useful messages that do not indicate changes to device functionality.
* **Debugging (Level 7)**: This level is used for output generated by debug commands.
Syslog facilities are service identifiers that identify and categorize system state data for error and event message reporting. By default, the format of syslog messages on the Cisco IOS Software is:
```
%facility-severity-MNEMONIC: message
```
Some common syslog message facility codes reported on Cisco IOS routers include:
* **IF** — generated by an interface.
* **IP** — generated by IP.
* **OSPF** — generated by the OSPF routing protocol.
* **SYS** — generated by the device operating system.
* **IPSEC** — generated by the IP Security encryption protocol.
## Syslog Timestamps
By default, log messages are not timestamped. Use the command **`service timestamps log datetime`** to force logged events to display the date and time.
:::success
When using the datetime keyword, the clock on the networking device must be set, either manually or through NTP, as previously discussed.
:::
## Syslog Implemenation
Syslog implementations must contain two types of systems:
* **Syslog Servers** — Also known as log hosts, these systems accept and process log messages from syslog clients.
* **Syslog Clients** — Routers or other types of equipment that generate and forward log messages to syslog servers.
Configure Syslog reporting on a device using the following procedure:
<ol class='step-list'>
<li>Set the destination logging host using the <code><b>logging</b> [<i>hostname</i> | <i>ip-address</i>]</code> command.</li>
<li>(Optional) Set the log severity (trap) level using the <code><b>logging trap</b> <i>level</i></code> command.</li>
<li>(Optional) Set the source interface using the <code><b>logging source-interface</b> <i>interface</i></code> command.</li>
<li>(Optional) Enable logging to all enabled destinations with the <code><b>logging on</b></code> command.</li>
<li>Verify implemenation using the <code><b>show logging</b></code> command.</li>
</ol>
```pug
R1(config)# logging 10.2.2.6
R1(config)#
! *Sep 25 12:57:14.120: %SYS-6-LOGGINGHOST_STARTSTOP: Logging to host 10.2.2.6 port 514 started - CLI initiated
R1(config)#
R1(config)# logging trap informational
R1(config)# logging source-interface lo0
R1(config)# logging on
R1(config)# end
R1#
! *Sep 25 12:58:29.591: %SYS-5-CONFIG_I: Configured from console by console
R1#
R1# show logging
! Syslog logging: enabled (0 messages dropped, 2 messages rate-limited, 0 flushes, 0 overruns, xml disabled, filtering ! disabled)
!
! <...output truncated...>
!
R1#
```
# NTP Configuration
Network Time Protocol (NTP) enables network devices to synchronize their time settings with an NTP authoritative time source such as an NTP server. 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 source. The maximum stratum hop count is 15 (i.e., 0 – 15). NTP servers in the same stratum level can be configured as peers to provide redundant time sources for clients or to synchronize each other.
:::info
NTP stratum 0 devices are non-network high-precision timekeeping devices assumed to be accurate and with little or no delay associated with them.
An NTP client that is not synchronized with a server is assigned a stratum 16 level.
:::
A local network device could be selected as the NTP authoritative time source using the <code><b>ntp master</b> [<i>stratum</i>]</code> global configuration command.
**NTP Configuration with Authentication:**
<ol class='step-list'>
<li>Enable NTP authentication.</li>
<li>Define an authentication key.</li>
<li>Identify the trusted key to use for NTP authentication.</li>
<li>Configure the NTP server to bind to.</li>
</ol>
```pug
R1(config)# ntp authenticate
R1(config)# ntp authentication-key ntpKey md5 cisco123
R1(config)# ntp trusted-key ntpKey
R1(config)# ntp server 192.168.1.5
R1(config)# ntp update-calendar
R1(config)# end
R1#
R1# show clock detail
! 21:41:56.657 UTC Fri Mar 6 2015
! Time source is NTP
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
! <...output truncated...>
!
R1# show ntp associations detail
! 10.1.1.2 configured, ipv4, our_master, sane, valid, stratum 3
! ref ID 104.232.3.3 , time D8A49DA4.A83132C7 (21:41:56.657 UTC Fri Mar 6 2015)
! <...output truncated...>
!
R1#
```
:::warning
It may take several minutes for a configured NTP client to become synced with the NTP server.
:::
Additional devices may be configured to use an available NTP client as an intermediary NTP server via the **`ntp server`** command. This will place the additional device at a lower stratum than the intermediary.
:::info
NTP source and clients open **UDP port 123** to send and receive timestamps.
:::
# Simple Network Management Protocol
Simple Network Management Protocol (SNMP) defines how management information is exchanged between network management applications and management agents. It is an application layer protocol that provides a message format for communication between managers and agents.
:::info
**SNMPv3** provides secure access to devices by utilizing message integrity checks, authentication, and encryption.
:::
The SNMP system consists of three elements:
* SNMP manager
* SNMP agents (managed node)
* Management Information Base (MIB)
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.
The **SNMP agent** and **MIB** reside on SNMP client devices. The MIB stores data and operational statistics about the device.
:::info
The SNMP manager polls the agents and queries the MIB for SNMP agents on **UDP port 161**.
SNMP agents send any SNMP traps to the SNMP manager on **UDP port 162**.
:::
The Management Information Base (MIB) enables the management software to monitor and control the network device. The MIB organizes variables hierarchically into a tree-like data structure. The records within the data tree uniquely identify managed objects (as OID strings) used to monitor and control the network device.
## SNMP Operation
SNMP agents that reside on managed devices collect and store information about the device and its operation. This information is stored by the agent locally in the MIB. The SNMP manager then uses the SNMP agent to access information within the MIB.
The SNMP manager uses the get and set actions to perform the operations described in the table.
| Operation | Description |
| -------------------- | ----------- |
| <div class='mono'>**get-request**</div> | Retrieves a value from a specific variable. |
| <div class='mono'>**get-next-request**</div> | 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. |
| <div class='mono'>**get-bulk-request**</div> | 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.) |
| <div class='mono'>**get-response**</div> | Replies to a get-request, get-next-request, and set-request sent by an NMS. |
| <div class='mono'>**set-request**</div> | Stores a value in a specific variable. |
## SNMP Security
:::warning
In SNMPv1 and SNMPv2c, get/set-requests and response-notifications are not authenticated or encrypted, and are thus more vulnerable to hijacking.
:::
The latest version of SNMP is SNMPv3. Both of the earlier SNMPv1 and SNMPv2c standards 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 "secret" community string.
By contrast, the SNMPv3 standard defines three levels of access restriction:
| Level | Auth Method | Encryption |
| ------------ | -------------- | ---------- |
| noAuthNoPriv | Username Only | None |
| authNoPriv | MD5 or SHA Key | None |
| authPriv | MD5 or SHA Key | DES or AES |
:::info
Because an agent can communicate with multiple SNMP managers, it is possible to configure the software to support communications using multiple SNMP standards.
:::
## SNMP Configuration
A network administrator must configure the SNMP agent to use the SNMP version supported by the management station.
SNMPv3 can be secured with only a few steps:
<ol class="step-list">
<li>Configure an ACL that will permit access to authorized SNMP managers, using the <code><b>ip access-list</b> <i>acl-name</i></code> global configuration command, followed by the <code><b>permit</b> <i>address mask</i></code> command.</li>
<li>Configure an SNMP view with the <code><b>snmp-server view</b> <i>view-name oid-tree</i></code> command to identify the MIB OIDs that the SNMP manager will be able to read. Configuring a view is required to limit SNMP messages to read-only access.</li>
<li>Configure an SNMP group with the <code><b>snmp-server group</b></code> command.</li>
<ul>
<li>Configure a name for the group.</li>
<li>Set the SNMP version to 3 with the <b>v3</b> keyword.</li>
<li>Require authentication and encryption with the <b>priv</b> keyword.</li>
<li>Associate a view to the group and give it read only access with the <b>read</b> command.</li>
<li>Specify the ACL configured in <b>Step 1</b>.</li>
</ul>
<li>Configure group users with the <code><b>snmp-server user</b></code> command.</li>
<ul>
<li>Configure a username and associate the user with the group name configured in <b>Step 3</b>.</li>
<li>Set the SNMP version to 3 with the <b>v3</b> keyword.</li>
<li>Set the authentication type to either <b>MD5</b> or <b>SHA</b> and configure an authentication password. SHA is preferred and should be supported by the SNMP management software.</li>
<li>Require encryption with the <b>priv</b> keyword and configure an encryption password.</li>
</ul>
</ol>
```pug
R1(config)# ip access-list standard PERMIT-ADMIN
R1(config-std-nacl)# permit 192.168.1.0 0.0.0.255
R1(config-std-nacl)# exit
R1(config)# snmp-server view SNMP-RO iso included
R1(config)# snmp-server group ADMIN v3 priv read SNMP-RO access PERMIT-ADMIN
R1(config)# snmp-server user BOB ADMIN v3 auth sha cisco12345 priv aes 128 cisco54321
R1(config)# end
R1#
```
Verify configuration via
```pug
R1# show run | include snmp
! snmp-server group ADMIN v3 priv read SNMP-RO access PERMIT-ADMIN
! snmp-server view SNMP-RO iso included
R1#
R1# show snmp user
! User name: BOB
! Engine ID: 80000009030030F70DA30DA0
! storage-type: nonvolatile active
! Authentication Protocol: SHA
! Privacy Protocol: AES128
! Group-name: ADMIN
!
R1#
```
---
*[NMS]: Network Management System
*[NVRAM]: Nonvolatile Random-Access Memory
---
{%hackmd 7PGmjAHeTXak2VUM3iw5Wg %}