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:
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.
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 |
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:
Some common syslog message facility codes reported on Cisco IOS routers include:
By default, log messages are not timestamped. Use the command service timestamps log datetime
to force logged events to display the date and time.
When using the datetime keyword, the clock on the networking device must be set, either manually or through NTP, as previously discussed.
Syslog implementations must contain two types of systems:
Configure Syslog reporting on a device using the following procedure:
logging [hostname | ip-address]
command.logging trap level
command.logging source-interface interface
command.logging on
command.show logging
command.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.
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 ntp master [stratum]
global configuration command.
NTP Configuration with Authentication:
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.
NTP source and clients open UDP port 123 to send and receive timestamps.
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.
SNMPv3 provides secure access to devices by utilizing message integrity checks, authentication, and encryption.
The SNMP system consists of three elements:
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.
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 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 |
---|---|
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. |
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 |
Because an agent can communicate with multiple SNMP managers, it is possible to configure the software to support communications using multiple SNMP standards.
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:
ip access-list acl-name
global configuration command, followed by the permit address mask
command.snmp-server view view-name oid-tree
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.snmp-server group
command.snmp-server user
command.Verify configuration via