Many people may be confused as to why I would dedicate an entire post to network monitoring tools and their configuration.  The reason is because these topics are tested relatively heavily on the actual CCNP SWITCH Exam.  Whether you agree or disagree about the weight given to these topics given the number of others is irrelevant.  It’s covered on the exam – so take the time to understand the topics (especially IP SLA).

Here we go…

Syslog

Syslog is a network management protocol that is not unique to Cisco devices, but integrates well within IOS.  Syslog allows a network-attached device to report and log error and notification messages either locally or to a remote Syslog server.

Syslog messages are plain text sent using UDP port 514.

Every syslog message contains two parts, a severity level and a facility.  The severity level goes from 0 to 7 with 0 being the most severe to 7 being simply informational.

Syslog Priority (highest to lowest):
0.  Emergency (highest)
1.  Alert
2.  Critical
3.  Error
4.  Warning
5.  Notice
6.  Informational
7.  Debug (lowest)

Facilities are service identifiers that categorize events and messages for easier reporting.

The most common facilities on IOS devices include:

• IP
• OSPF
• SYS (operating system)
• IP Security (IP Sec)
• Route Switch Processor (RSP)
• Interface (IF)

Messages are presented in the following format:
%FACILITY-SUBFACILITY-SEVERITY-MNEMONIC:Message-text

Configuring Syslog

To configure Syslog to export events to an external Syslog server, use the following commands:

Switch(config)# logging <ip address of server>
Switch(config)# logging trap <severity level>

To configure the local switch to store syslog messages, use the logging buffered command.

Switch(config)# loggingbuffered ?
<0-7>             Logging severity level

Use the show logging command to show the contents of the local log files.

SNMP network management application periodically uses UDP to poll the agent residing on a managed device for useful, predetermined information.  The problem is it polls the device on a set schedule, so there will be a lag between when an event occurs and when the application learns of it.

SNMP traps, are not so passive. When certain criteria are met, the agent sends the application a notification instantly, so it no longer has to wait around to find out.  This can introduce bandwidth savings.  Think of it like push notification in the cellular world.

The data that the agent collects is stored in its MIB.  Community strings are used to provide a level of authorization for the MIB contents (read or write) - kind of like a weak SNMP passwords.  They are transmitted in clear text across the network, so be careful.

SNMP Versions

• SNMP v1 – insecure
• SNMP v2 – introduced the read/write community strings, added 64 bit counter support, more intelligent requesting, insecure
• SNMP v3 – provides encryption and authentication (most secure – recommended whenever possible)

SNMP Configuration

1. Configure SNMP access lists (optional, but recommended)
2. Configure community strings
3. Configure SNMP trap destination
4. Configure SNMP v3 user (optional, but recommended)

Example Configuration
Switch(config)# access-list 100 permit ip 10.1.1.0 0.0.0.255 any
Switch(config)# snmp-server community aaron RO 100
Switch(config)# snmp-server community thisismoresecure RW 100
Switch(config)# snmp-server trap 192.168.1.52

IP Service Level Agreement

Service level agreements or SLAs are contractual agreements usually between a customer and service provider that spell out the minimum acceptable levels of service.  SLAs are often attached to WAN and MPLS links because any downtime can significantly affect business performance/profits.

In terms of the exam, Cisco’s SLA attempts to measure latency, jitter, and packet loss for a given link.  Cisco does this by enabling IOS to send synthetic traffic  to a specific host computer or router that is configured to respond.  The router can then use determine one way jitter, delay, an packet loss.

Router <——–> Router
OR
Router <———> PC

Common IP SLA Functions

• Active edge-to-edge network availability monitoring
• Network performance monitoring
• VoIP, video, and VPN monitoring
• IP heath assessment
• MPLS monitoring
• Troubleshooting

IP SLA can measure the following statistics:

• Network latency (delay) and response time
• Packet loss
• Jitter and voice quality scoring
• end-to-end network connectivity

IP SLA Operations

Multiple IP SLA operations (measurements) can run in a network at the same time.  The reporting tools use SNMP to fetch the data so they can report on it.

The source router needs to be configured with a target device, protocol, and UDP/TCP port number for each IP SLA operation.  The source router uses the IP SLA control protocol to confirm communication with the responding host before the source sends the test messages.

To increase security, the responder can use an MDF hash to authenticate the message from the source, securing the exchange.

When the operation is complete, the results are stored in the IP SLA MIB on the source and can be retrieved via SNMP (or by traps which can be conditionally set to send alerts if thresholds are exceeded).

Almost all of the configuration occurs on the source router.  The source sends the probe packets that test whatever protocols the administrator chooses. 

Note:  Although any IP device can be a responder, another IP SLA router running IOS is preferred because the measurement accuracy will be improved and it is required if you want to measure jitter.

IP SLA Operation Breakdown

1. Source sends a IP SLA control message with the configured operation to the responder using UDP port 1967.  The control message carries the protocol, port, and duration defined when the operation was configured on the source router.
   *  If MD5 is enabled, the checksum is sent with the control message.
   *  I authentication is enabled, the responder verifies it.  If authentication fails, the responder returns an authentication failure message.
   * If a response is not received from the responder, it will attempt to retransmit until it eventually times out.
2. The responder sends a confirmation message back to the source router and listens on the specified port.
3. If the response from the control message is OK, it begins sending probe packets.
4. The responder responds to the incoming probe packets for the predetermined time.

 The diagram above outlines the timestamp process IP SLA uses to calculate round trip time (RTT) accurately.

1. The source sends a packet at time T1
2. The responder record both the receipt time (T2) and the transmitted time (T3).  Because there can delay between when the router receives t packet and when a confirmation is sent back out the interface, it tracks the difference in time(in sub-milliseconds).  The source later subtracts this difference from the total RTT because it was not time in transit, but rather router software processing time.

An additional benefit of so many timestamps is the ability to track one-way delay, jitter, and packet loss.  Remember that traffic behavior can be asynchronous.  Also, make sure that both devices are using the same source for clock information.  The same NTP server is a requirement for many of these functions.

Configuring IP SLA

1. Configure the source router
2. Activate the IP SLA on the source
3. Configure that tracking object on the source
4. Configure responder

Example Source Configuration
Switch(config)# ip sla 10 (number indicates the IP SLA test identifier)
Switch(config-sla)# type echo prot ipIcmpEcho 192.168.1.10 source-int fa0/1
Switch(config-sla)# frequency 20 (number of times the operation repeats)
Switch(config)# exit
Switch(config)# ip sla schedule 10 life forever start-time now
Switch(config)# track 1 ip sla 10 reachability

Responder Configuration:
Switch2(config)# ip sla monitor responder

Verifying IP SLA

Switch# show ip sla statistics

Switch# show ip sla configuration {operationID}

Switch# show ip sla application
Verifies which operation types are supported in software.