Packet capture provides a way of getting a copy of the packets traversing a router. This can be useful for troubleshooting purposes when you want to see if the packets are being received or sent by the router via the expected interface.
There are 2 ways to perform the packet capture – one is using the vManage user interface, and another one is using CLI directly on the router. In this article, we will explain how to use both of them.
Using vManage
Packet capture is reachable via the Device Troubleshooting page – Monitor > Network > Device name > Troubleshooting. By default, there is no Packet Capture option under the Traffic section, as shown in Figure 1.
Figure 1. Packet Capture in vManage before Data Streaming is enabled
The pop-up alert displays: “Data Stream is disabled. Go to the Settings page to enable Data Stream to use Packet Capture, Speed Test, and Debug Logs”. To run packet captures via vManage we must enable Data Stream.
Navigate to Administration > Settings. Then expand the Data Stream option, as shown in the screenshot below. Click on the “Enabled” radio box, type in the hostname, which is the name or IP address of vManage and VPN that the edge router should use to reach the controller.
Figure 2. Enable Data Stream Configuration in vManage
Note that for virtualized platforms, like the one we use for the lab, VPN 512 (out-of-band) cannot be used. To make this work, we are using the public IP of vManage, which is reachable via transport VPN 0. Our lab topology is shown in the figure below.
Figure 3. Data Streaming Topology
After enabling Data Streaming, the Packet Capture option is now visible in the Troubleshooting section. After clicking on this option, we can define packet capture parameters.
Figure 4. Packet Capture in vManage after Data Streaming is enabled
Packet capture screen requires VPN and Interface filter selection. You can optionally provide other filters, such as source and destination IPs and protocol information. Traffic is captured in both ingress and egress directions. Let’s change the filter to protocol 1 (ICMP) and start capture by pressing the Start button.
Figure 5. Packet Capture Parameters
By default, the capture will run for 5 minutes. You can stop the timer at any time to download packets captured so far. The file in pcap format will be available for download shortly.
Figure 6. Packet Capture Progress
The content of the file can be viewed in Wireshark, as shown below.
Figure 7. Display Captured Packets in Wireshark
CSR01#show monitor capture
Status Information for Capture 71f87e76_847e_4770_8289_56b5242ac115
Target Type:
Interface: GigabitEthernet3, Direction: BOTH
Status : Active
Filter Details:
IPv4
Source IP: any
Destination IP: any
Protocol: 1
Buffer Details:
Buffer Type: LINEAR (default)
Buffer Size (in MB): 5
Limit Details:
Number of Packets to capture: 0 (no limit)
Packet Capture duration: 300
Packet Size to capture: 0 (no limit)
Maximum number of packets to capture per second: 1000
Packet sampling rate: 0 (no sampling)
Using CLI on the router
If for some reason you can’t use vManage, you can use IOS-XE Embedded Packet Capture directly on the device (the previous process uses this feature on the backend). Use SSH to connect to the device either via client installed on your computer or via the tools menu in vManage.
The next configuration commands provide an example of running packet capture.
Embedded packet capture commands begin with monitor capture commands. They are available in exec mode, other operational commands, like “show” and “debug”.
CSR01#monitor capture ?
WORD Name of the Capture
clear Clear all Buffers
start Enable all capture points
stop Disable all capture points
Specify a name for the packet capture instance, in our example it is TEST_CAPTURE. The available command options are shown below.
CSR01#monitor capture TEST_CAPTURE ?
WORD Name of the Capture
access-list access-list to be attached
buffer Buffer options
class-map class name to attached
clear Clear Buffer
control-plane Control Plane
export Export Buffer
interface Interface
limit Limit Packets Captured
match Describe filters inline
start Enable Capture
stop Disable Capture
stop_export Disable Capture and Export Buffer
The next commands configure the same options we used in vManage:
GigabithEthernet3 as interface
ICMP packets only (IP protocol 1)
CSR01#monitor capture TEST_CAPTURE interface GigabitEthernet3 both
CSR01#monitor capture TEST_CAPTURE match ipv4 protocol 1 any any
Below are the available options for inline filters.
CSR01#monitor capture TEST_CAPTURE match ?
any all packets
ipv4 IPv4 packets only
ipv6 IPv6 packets only
mac MAC filter configuration
pktlen-range Packet length range to capture
CSR01#monitor capture TEST_CAPTURE match ipv4 ?
A.B.C.D/nn IPv4 source Prefix <network>/<length>, e.g., 192.168.0.0/16
any Any source prefix
host A single source host
protocol Protocols
CSR01#monitor capture TEST_CAPTURE match ipv4 protocol ?
<0-255> An IP protocol number
tcp Filter by TCP protocol
udp Filter by UDP protocol
CSR01#monitor capture TEST_CAPTURE match ipv4 protocol 1 ?
A.B.C.D/nn IPv4 source Prefix <network>/<length>, e.g., 192.168.0.0/16
any Any source prefix
host A single source host
CSR01#monitor capture TEST_CAPTURE match ipv4 protocol 1 any ?
A.B.C.D/nn IPv4 destination Prefix <network>/<length>, e.g., 192.168.0.0/16
any Any destination prefix
host A single destination host
To validate capture parameters run the command: show monitor capture TEST_CAPTURE. As shown in the listing below, by default, the capture will run till its buffer will reach 10MB.
CSR01#show monitor capture TEST_CAPTURE
Status Information for Capture TEST_CAPTURE
Target Type:
Interface: GigabitEthernet3, Direction: BOTH
Status : Inactive
Filter Details:
IPv4
Source IP: any
Destination IP: any
Protocol: 1
Buffer Details:
Buffer Type: LINEAR (default)
Buffer Size (in MB): 10
Limit Details:
Number of Packets to capture: 0 (no limit)
Packet Capture duration: 0 (no limit)
Packet Size to capture: 0 (no limit)
Maximum number of packets to capture per second: 1000
Packet sampling rate: 0 (no sampling)
Now we can activate the defined capture.
CSR01#monitor capture TEST_CAPTURE start
After running some pings from a test PC connected to the service side via GigabitEthernet3, we can validate that packets are being captured. The brief format is shown below. Detailed and dump options display truncated and full packet content.
Let’s stop packet capture with the following command.
CSR01#monitor capture TEST_CAPTURE stop
To analyze packet capture buffer offline, use export it using the command shown below:
CSR01#monitor capture TEST_CAPTURE export ?
bootflash: Location of the file
flash: Location of the file
ftp: Location of the file
http: Location of the file
https: Location of the file
pram: Location of the file
rcp: Location of the file
scp: Location of the file
sftp: Location of the file
tftp: Location of the file
CSR01#monitor capture TEST_CAPTURE export bootflash:test_capture.pcap
Exported Successfully
Cisco SD-WAN devices can be either in vManage or CLI mode.
In vManage mode, the configuration is performed on vManage and then pushed to the device. Local configuration changes are not allowed. In CLI mode, changes are performed locally on the device. vManage mode is the preferred and recommended option for most SD-WAN implementations. However, you can occasionally switch devices into CLI mode to perform specific tasks.
Administrators can connect to the device using SSH or serial console to use various show and debug commands in both modes.
We will focus on edge devices in this article. However, controllers can also be in one of these modes. Cisco-hosted controllers are initially provisioned in CLI mode and then converted to vManage mode by a network administrator. Some features require controllers to be switched to vManage mode.
vManage mode
Consider a sample network shown in Figure 1. Our task is to prepare an edge router for a remote office. We’ve applied the required feature and device templates with dynamic IP assignment on the Internet-facing interface. After the router is shipped to the remote location and plugged in, it cannot establish connectivity to vManage. We discover that the ISP doesn’t have DHCP enabled, and a static IP configuration is required.
Figure 1. SD-WAN Edge Sample Scenario
Let’s assume that we can access the router via console cable attached to a laptop on-site.
Run the “show sdwan system status” command on the edge device to validate the device mode. In the sample output below, the CSR01 router is in vManage mode (vManaged: true).
CSR01#show sdwan system status
Viptela (tm) vEdge Operating System Software
Copyright (c) 2013-2021 by Viptela, Inc.
Controller Compatibility: 20.3
Version: 17.03.03.0.4762
<output omitted>
Personality: vEdge
Model name: CSR1000V
Services: None
vManaged: true
Commit pending: false
Configuration template: CSR01
<output omitted>
Firstly, we try to set a static IP address on the transport interface using CLI. We use the “config-t” command to enter the configuration mode. The “commit” command activates the configuration.
CSR01#config-t
CSR01(config)# interface GigabitEthernet 2
CSR01(config-if)# ip address 21.1.1.2 255.255.255.252
CSR01(config-if)# commit
The following warnings were generated:
'system is-vmanaged': This device is being managed by the vManage. Any configuration changes to this device will be overwritten by the vManage after the control connection to the vManage comes back up.
Proceed? [yes,no] yes
Commit complete.
CSR01#show run interface GigabitEthernet 2
Building configuration...
<output omitted>
interface GigabitEthernet2
description Transport Interface
ip address 21.1.1.2 255.255.255.252
In our example, we didn’t have connectivity to vManage, so the changes were committed. However, as the warning message above advises vManage will overwrite modifications done on the device (see the example in the following listing) once the control connection is up.
CSR01#show run interface GigabitEthernet 2
Building configuration...
<output omitted>
interface GigabitEthernet2
description Transport Interface
ip address dhcp
Rollback to the original configuration (i.e. setting dynamic IP on the transport interface) causes connectivity to vManage fail, which introduces the connectivity problem we tried to solve in the first place. When we have connectivity to vManage, the CLI commands are just rejected, as shown in the listing below. vManage mode doesn’t permit changes on the edge device.
CSR01#config-t
CSR01(config)# interface GigabitEthernet2
CSR01(config-if)# ip address 21.1.1.2 255.255.255.252
CSR01(config-if)# commit
Aborted: 'system is-vmanaged': This device is being managed by the vManage. Configuration through the CLI is not allowed.
CLI Mode
There are several solutions to the problem described above. The first is to switch the device into CLI mode beforehand before sending it to the remote location. We can then adjust the configuration and set static IP address, and move the device back to vManage mode.
The second solution is using hidden support commands, which is not a supported way of configuring the device unless directed by Cisco TAC. However, it works and can be helpful in lab environments or as a quick fix to get the branch running (with full router reset later).
Let’s see how both options work with the examples below.
Switching device to CLI mode via vManage
An administrator can switch the device to CLI mode (and back) via vManage. Navigate to Configuration > Devices. Click on the Change Mode drop-down menu and select CLI mode.
Figure 2. Switching device to CLI mode via vManage
In the dialog window, select and move to the right panel the router you want to switch into CLI mode and click on Upgrade to CLI Mode.
After the conversion, we can use “show sdwan system status” command to validate that the vManaged property is false.
CSR01#show sdwan system status
Viptela (tm) vEdge Operating System Software
Copyright (c) 2013-2021 by Viptela, Inc.
Controller Compatibility: 20.3
Version: 17.03.03.0.4762
Build: Not applicable
<output omitted>
Personality: vEdge
Model name: CSR1000V
Services: None
vManaged: false
Commit pending: false
Configuration template: None
<output omitted>
After the device comes back online, we can update templates to include static IP address configuration and switch it back to the vManage mode. To do this, we need to attach the device template to the vEdge router. If the device had a template attached before, the variable values would be populated automatically.
Figure 3. Switching device to vManage mode
Switching device to CLI mode using hidden commands
This procedure in this section uses hidden commands and should be used only as a last resort. Cisco TAC may not support it; use it at your own risk.
When the router hasn’t been switched to CLI mode beforehand and cannot establish a control connection to vManage, refer to the following example to switch to CLI mode.
After entering the configuration mode, let’s see available options under the system command:
CSR01#config-t
CSR01(config)# system ?
Possible completions:
admin-tech-on-failure Collect admin-tech before reboot due to daemon failure
allow-same-site-tunnels Allow tunnels to be formed between vEdges in the same site
console-baud-rate Console baud-rate
control-session-pps Control session policer rate, in packets per second
controller-group-list Controller group list
debug
description System description
device-groups List of vManage groups to which the device belongs
disable
domain-id Domain ID
environment
fnf
gps-location GPS latitude and longitude of the device
host-policer-pps Rate at which to police packets bound to the control plane (in pps) per QOS level
icmp-error-pps Rate at which to police ICMP error messages either generated or received (in pps).
idle-timeout Idle CLI timeout, in minutes
ignore
location Location description of the device
max-controllers (DEPRECATED) Set the maximum number of controllers to which the device can connect - Deprecated in 15.4
max-omp-sessions Set the maximum number of OMP sessions the device can have
mode-button
mtu
on-demand Set various configuration for On-demand tunnels
organization-name Organization name
overlay-id Overlay ID
port-hop Enable port hopping for all tlocs
port-offset Port offset (unique value; use only if multiple Viptela devices are behind the same NAT)
site-id Site ID
sp-organization-name Service Provider Organization name
system-ip System IP address
system-tunnel-mtu Control tunnel MTU
tcp-optimization-enabled Carve out a dedicated core to use for TCP optimization - applies after reboot
timer Set various timer timeouts
tls ssl-opt cert management config
track-default-gateway Enable/Disable default gateway tracking
track-interface-tag OMP Tag attached to routes based on interface tracking
track-transport Enable transport tracking
upgrade-confirm Configure software upgrade confirmation timeout
vbond Configure remote vBond or local IPv4 vbond address
<cr>
“unhide viptela_internal” command enables the display of “system” command hidden options. The example below shows these subcommands.
CSR01(config)# unhide viptela_internal
CSR01(config)# system ?
Possible completions:
admin-tech-on-failure Collect admin-tech before reboot due to daemon failure
allow-same-site-tunnels Allow tunnels to be formed between vEdges in the same site
allow-sw-vedge (HIDDEN) Allow non-release software vedges to operate without certificates
console-baud-rate Console baud-rate
control-session-pps Control session policer rate, in packets per second
controller-group-list Controller group list
daemon-reboot (HIDDEN) Reboot device if a non-restartable daemon fails
daemon-restart (HIDDEN) Restart restartable daemons if they fail
debug
description System description
device-groups List of vManage groups to which the device belongs
disable
dnsd-ttl config DNS reply TTL in secs
domain-id Domain ID
dpi-cache-expiry (HIDDEN) Cache expiry time in minutes
dpi-cache-size (HIDDEN) Cache size
dpi-disable-track-tx (HIDDEN) Enable/Disable DPI TRACK TX
dpi-enable (HIDDEN) Enable/Disable DPI
dpi-gc-time (HIDDEN) Garbage collect time in secs
dpi-multicore (HIDDEN) Enable multi-core for dpi
dpi-stat-time (HIDDEN) Stats collection time for dpi
environment
fnf
fp-buffer-check (HIDDEN) Enable fastpath buffer validity check
fp-qos-interval config fp qos interval
fp-qos-weight-percent-factor config fp qos weight percent factor
gps-location GPS latitude and longitude of the device
host-policer-pps Rate at which to police packets bound to the control plane (in pps) per QOS level
icmp-error-pps Rate at which to police ICMP error messages either generated or received (in pps).
idle-timeout Idle CLI timeout, in minutes
ignore
increase-bp-count (HIDDEN) Increase port backpressure threshold for all ports
is-vmanaged Device is managed by the vmanage
last-vmanage-transaction-id Used by vManage to maintain integrity of transactions initiated by it towards device
location Location description of the device
max-controllers (DEPRECATED) Set the maximum number of controllers to which the device can connect - Deprecated in 15.4
max-omp-sessions Set the maximum number of OMP sessions the device can have
mode-button
mtu
on-demand Set various configuration for On-demand tunnels
organization-name Organization name
overlay-id Overlay ID
patch-confirm (HIDDEN) Configure software patch confirmation timeout
port-bp-threshold configure port backpressure threshold
port-hop Enable port hopping for all tlocs
port-offset Port offset (unique value; use only if multiple Viptela devices are behind the same NAT)
pseudo-confirm-commit Only valid for vmanage ..
reboot-on-failure (HIDDEN) Reboot device if any daemon fails
simulated-color Simulated device's color
simulated-devices Additional number of simulated devices
simulated-wan-ip Starting IP address for the simulated interface
site-id Site ID
sp-organization-name Service Provider Organization name
system-ip System IP address
system-tunnel-mtu Control tunnel MTU
tcp-optimization-enabled Carve out a dedicated core to use for TCP optimization - applies after reboot
timer Set various timer timeouts
tls ssl-opt cert management config
track-default-gateway Enable/Disable default gateway tracking
track-interface-tag OMP Tag attached to routes based on interface tracking
track-transport Enable transport tracking
unpin-flows-with-reboot (HIDDEN) Enable with reboot OR Disable flow pinning to FP cores
upgrade-confirm Configure software upgrade confirmation timeout
vbond Configure remote vBond or local IPv4 vbond address
ztp-status ZTP status
<cr>
To switch the device to CLI mode, use is-vmanaged option.
CSR01(config)# interface GigabitEthernet 2
CSR01(config-if)# ip address 21.1.1.2 255.255.255.0
CSR01(config-if)# commit
Aborted: 'system is-vmanaged': This device is being managed by the vManage. Configuration through the CLI is not allowed.
CSR01(config-if)# exit
CSR01(config)# system is-vmanaged false
CSR01(config-system)# commit
Commit complete.
CSR01#show run int GigabitEthernet 2
Building configuration...
interface GigabitEthernet2
description Transport Interface
ip dhcp client default-router distance 1
ip address 21.1.1.2 255.255.255.0
The device will connect to vManage. However, the controller will not overwrite the configuration. At this stage, vManage’s view of the router configuration will not reflect the actual state. We need to remediate this as soon as possible, either by switching the device to CLI mode or applying a configuration template that brings consistency. Let’s update the device template to use static interface configuration to get to the consistent state. In the screenshot below, we see the template adjustments. The bottom part of the figure contains the snippet of the command difference. As we saw in the previous command listing, the device already had a static IP address configured, but vManage is not aware of that change, so from its perspective, the device still has DHCP settings configured.
Figure 4. Apply Device Template to WAN Edge
Changing WAN Edge System IP
In the final section of this blog post, let’s see another example when switching to CLI mode can be helpful. When done via template change, the change of System IP can cause the configuration push to be stuck and not apply correctly.
As a workaround, you can switch the device into CLI mode, change System IP, and move it to template configuration back. Follow the steps below.
Step 1. To switch the device to CLI mode, refer to the procedure described in the first section and Figure 2.
Step 2. Using CLI apply the configuration change. In the example below, we change System IP from 1.1.1.101 to 1.1.1.11.
Step 3. Move device to vManaged mode by applying template and ensuring that the System IP variable matches the new value.
Cisco IP Service Level Agreements (SLAs) is a proprietary feature available on Cisco routers and switches, which actively generates monitoring traffic, processes replies, and measures network performance.
This feature can be used to perform continuous end-to-end connectivity testing with automated re-routing over failover links. It can also simulate different application behavior, such as voice and video to check if the network provides the expected level of service.
The examples and features described in this article are based on Cisco IOS-XE version 16.9.
Configuration Components
IP SLA configuration starts with defining an SLA operation and then scheduling it to run immediately or at a specific time.
SLA Operation Definition
To create or edit an SLA operation use the “ip sla <operation-id>” global configuration mode command. It places CLI into the IP SLA configuration sub-mode, where you can select one of the IP SLA types and provide corresponding configuration parameters.
One of the simplest types of IP SLA operations is icmp-echo. The router pings a specified IP address and records round-trip times if the remote side is reachable. In the example below, we will set the type of SLA entry as ICMP echo with the destination’s IP address of 10.0.3.1. The sample topology is shown in Figure 1.
Figure 1. IP SLA Test Topology
The configuration mode changes to IP SLA echo where you can adjust different optional parameters, such as request sending frequency and timeout for replies.
X(config)#ip sla 1
X(config-ip-sla)# icmp-echo 10.0.3.1 source-ip 10.0.0.1
X(config-ip-sla-echo)#?
IP SLAs Icmp Echo Configuration Commands:
data-pattern Data Pattern
default Set a command to its defaults
exit Exit operation configuration
frequency Frequency of an operation
history History and Distribution Data
no Negate a command or set its defaults
owner Owner of Entry
request-data-size Request data size
tag User defined tag
threshold Operation threshold in milliseconds
timeout Timeout of an operation
tos Type Of Service
verify-data Verify data
vrf Configure IP SLAs for a VRF
Scheduling IP SLA
Once SLA is defined and optional parameters are specified, start it by running the “ip sla schedule <id>” command. IP SLA can be configured to start at a specific time or as soon as the command is entered, which is shown in the example below.
X(config)#ip sla schedule 1 start-time now life forever
To check SLA operation’s details use the “show ip sla statistics <id> details” command.
X#show ip sla statistics 1 details
IPSLAs Latest Operation Statistics
IPSLA operation id: 1
Latest RTT: 1 milliseconds
Latest operation start time: 10:08:18 UTC Sat Jan 30 2021
Latest operation return code: OK
Over thresholds occurred: FALSE
Number of successes: 2
Number of failures: 0
Operation time to live: Forever
Operational state of entry: Active
Last time this entry was reset: Never
To see configuration details, including default values for various parameters, use the “show ip sla configuration” command.
X#show ip sla configuration
IP SLAs Infrastructure Engine-III
Entry number: 1
Owner:
Tag:
Operation timeout (milliseconds): 5000
Type of operation to perform: icmp-echo
Target address/Source address: 10.0.3.1/10.0.0.1
Type Of Service parameter: 0x0
Request size (ARR data portion): 28
Data pattern: 0xABCDABCD
Verify data: No
Vrf Name:
Schedule:
Operation frequency (seconds): 60 (not considered if randomly scheduled)
Next Scheduled Start Time: Start Time already passed
Group Scheduled : FALSE
Randomly Scheduled : FALSE
Life (seconds): Forever
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000
Distribution Statistics:
Number of statistic hours kept: 2
Number of statistic distribution buckets kept: 1
Statistic distribution interval (milliseconds): 20
Enhanced History:
History Statistics:
Number of history Lives kept: 0
Number of history Buckets kept: 15
History Filter Type: None
Once SLA operation is scheduled, it cannot be modified. Instead, the old operation can be deleted, and then a new one created again using the same ID.
Different IP SLA Types
To view available types of SLA operations, use context-sensitive help as shown in the next example.
Jitter is a variation in the delay between packets. The smaller the jitter the better performance of time-sensitive applications such as voice. It also means that the network delivers packets with a predictable delay and doesn’t experience congestions causing intermittent delays along the paths.
There are 2 types of SLA operations performing Jitter measurements – ICMP and UDP-based.
ICMP Jitter
ICMP Jitter SLA operation is based on ICMP message types (Timestamp Request and Timestamp Reply). The destination can be any device that supports these ICMP messages. Not all devices support it, or it can be blocked by the firewalls. The previously shown ICMP Echo operation is based on more commonly used Echo and Reply message types.
The configuration in the example below demonstrates how to configure ICMP jitter operation and, that once launched, it reports the round-trip-time (RTT) and jitter statistics from the source to the destination, and vice versa.
X(config)# ip sla 2
X(config-ip-sla)# icmp-jitter 10.0.3.1 source-ip 10.0.0.1
X(config)# ip sla schedule 2 start-time now life forever
X#show ip sla statistics 2
IPSLAs Latest Operation Statistics
IPSLA operation id: 2
Type of operation: icmp-jitter
Latest RTT: 1 milliseconds
Latest operation start time: 00:20:39 UTC Sun Jan 31 2021
Latest operation return code: OK
RTT Values:
Number Of RTT: 10 RTT Min/Avg/Max: 1/1/1 milliseconds
Latency one-way time:
Number of Latency one-way Samples: 0
Source to Destination Latency one way Min/Avg/Max: 0/0/0 milliseconds
Destination to Source Latency one way Min/Avg/Max: 0/0/0 milliseconds
Jitter Time:
Number of SD Jitter Samples: 9
Number of DS Jitter Samples: 9
Source to Destination Jitter Min/Avg/Max: 0/1/1 milliseconds
Destination to Source Jitter Min/Avg/Max: 0/1/1 milliseconds
Over Threshold:
Number Of RTT Over Threshold: 0 (0%)
Packet Late Arrival: 0
Out Of Sequence: 0
Source to Destination: 0 Destination to Source 0
In both Directions: 0
Packet Skipped: 0 Packet Unprocessed: 0
Packet Loss: 0
Loss Periods Number: 0
Loss Period Length Min/Max: 0/0
Inter Loss Period Length Min/Max: 0/0
Number of successes: 4
Number of failures: 0
Operation time to live: Forever
To measure jitter, a source router sends a number of packets (10, by default) periodically. The time between these packets is called interval (20ms). The operation is repeated at a specified frequency (60 seconds by default).
The example below shows default configuration values – every 60 seconds the router will send 10 packets with 20 milliseconds interval between each packet.
X#show ip sla configuration 2
IP SLAs Infrastructure Engine-III
Entry number: 2
Owner:
Tag:
Operation timeout (milliseconds): 5000
Type of operation to perform: icmp-jitter
Target address/Source address: 10.0.3.1/10.0.0.1
Packet Interval (milliseconds)/Number of packets: 20/10
Type Of Service parameter: 0x0
Vrf Name:
Schedule:
Operation frequency (seconds): 60 (not considered if randomly scheduled)
<output is truncated>
UDP Jitter and IP SLA responder
UDP is used in voice and video communications. Using UDP traffic for measurements suits better to simulate such applications. In an IP SLA operation configuration codec type can be specified, and this will define packet size and enable various voice-specific metric calculations, such as Mean Opinion Score (MOS).
Figure 2. IP SLA Responder Configuration
To use the UDP Jitter destination device must also be a Cisco device with an IP SLA responder feature enabled on it. The responder’s basic configuration is completed with the single command on router Z:
Z(config)#ip sla responder
Back on the router X, IP SLA configuration is done per the example below.
X(config)#ip sla 3
X(config-ip-sla)#udp-jitter 10.0.3.1 2345 source-ip 10.0.0.1
X(config)#ip sla schedule 3 start-time now life forever
X#show ip sla statistics
IPSLAs Latest Operation Statistics
IPSLA operation id: 3
Type of operation: udp-jitter
Latest RTT: 1 milliseconds
Latest operation start time: 05:53:56 UTC Sun Jan 31 2021
Latest operation return code: OK
RTT Values:
Number Of RTT: 10 RTT Min/Avg/Max: 1/1/1 milliseconds
Latency one-way time:
Number of Latency one-way Samples: 0
Source to Destination Latency one way Min/Avg/Max: 0/0/0 milliseconds
Destination to Source Latency one way Min/Avg/Max: 0/0/0 milliseconds
Jitter Time:
Number of SD Jitter Samples: 9
Number of DS Jitter Samples: 9
Source to Destination Jitter Min/Avg/Max: 0/1/1 milliseconds
Destination to Source Jitter Min/Avg/Max: 0/1/1 milliseconds
Over Threshold:
Number Of RTT Over Threshold: 0 (0%)
Packet Loss Values:
Loss Source to Destination: 0
Source to Destination Loss Periods Number: 0
Source to Destination Loss Period Length Min/Max: 0/0
Source to Destination Inter Loss Period Length Min/Max: 0/0
Loss Destination to Source: 0
Destination to Source Loss Periods Number: 0
Destination to Source Loss Period Length Min/Max: 0/0
Destination to Source Inter Loss Period Length Min/Max: 0/0
Out Of Sequence: 0 Tail Drop: 0
Packet Late Arrival: 0 Packet Skipped: 0
Voice Score Values:
Calculated Planning Impairment Factor (ICPIF): 0
Mean Opinion Score (MOS): 0
Number of successes: 1
Number of failures: 0
Operation time to live: Forever
Path operations
When measuring latency between two hosts it is useful to know how much delay is contributed by each hop along the path. Path-type SLAs work by running traceroute first and then performing echo or jitter operation against each discovered hop.
X(config)#ip sla 4
X(config-ip-sla)#path-echo 10.0.3.1 source-ip 10.0.0.1
X(config)#ip sla schedule 4 start-time now life forever
The configuration is based on the same network topology with 2 paths available to the destination.
Figure 3. IP SLA Path Operations
The “show ip sla statistics aggregated 4 details” command will display round-trip time statistics for each hop. For example, the command output below shows statistics for the first hop in the path going via router B. The remaining hops statistics are omitted in the example below.
X#show ip sla statistics aggregated 4 details
IPSLAs aggregated statistics
Distribution Statistics:
Bucket Range: 0 to < 20 ms
Avg. Latency: 1 ms
Percent of Total Completions for this Range: 100 %
Number of Completions/Sum of Latency: 1/1
Sum of RTT squared low 32 Bits/Sum of RTT squared high 32 Bits: 1/0
Operations completed over threshold: 0
Start Time Index: *09:54:47.234 UTC Tue Feb 2 2021
Path Index: 3
Hop in Path Index: 1
Type of operation: path-echo
Number of successes: 18
Number of failures: 0
Number of over thresholds: 0
Failed Operations due to Disconnect/TimeOut/Busy/No Connection: 0/0/0/0
Failed Operations due to Internal/Sequence/Verify Error: 0/0/0
Failed Operations due to Control enable/Stats retrieve Error: 0/0
Target Address 172.16.100.6
<output is truncated>
Other operations
IP SLA can perform application-specific monitoring, for example, it can run HTTP or FTP operations against a remote server. For generic TCP applications, TCP operation can be used, which validates if the TCP connection can be established and how long it takes to connect to the server.
The other available operation types are DHCP (checks how long it takes to obtain an IP address) and DNS queries.
Reactions and Proactive Monitoring
In the previous sections, we’ve reviewed different types of SLA operations and how to check their operations using CLI. By using SNMP-based monitoring software, administrators can poll SLA data from routers periodically, which is a more scalable approach to monitoring. Cisco provides SNMP MIB called RTTMON that provides access to IP SLAs from monitoring software.
It is also possible for a router to send an SNMP trap or Syslog message if a certain event happens. IP SLA includes a feature called proactive threshold monitoring. To enable it IP SLA reaction must be configured.
The example below uses a previously configured IP SLA operation of icmp-echo type.
ip sla 1
icmp-echo 10.0.3.1 source-ip 10.0.0.1
ip sla schedule 1 life forever start-time now
The reaction configuration below references SLA operation 1 and selects timeout as a monitored element. Then we enable simple SNMP configuration to send a trap when operations times out.
The final section of this document addresses how a router can change its data plane operation in response to IP SLA operational status.
The feature responsible for translating the status of IP SLA operations to the data plane protocols is called Enhanced Object Tracking. First-Hop Redundancy Protocols, such as HSRP and VRRP use the tracking objects to take over or release data forwarding roles. Static and policy-based routing can also use the tracking objects to re-route around degraded paths.
EEM (Embedded Event Manager) scripts can monitor tracking object’s status changes. This makes it possible to run powerful EEM scripting in response to track status change.
A Track object can have 2 states – Up and Down. IP SLA operations can have several return codes. For the purpose of object tracking, we are interested in the 3 return codes discussed below. All other codes that are not covered in this article translate into the Down state of the Track object.
Let’s re-use the IP SLA ICMP Echo operation from the previous example and check the code of the operation. The second command in the listing shows how to check the default threshold (5000ms):
X#show ip sla statistics 1 | incl code
Latest operation return code: OK
X#show ip sla configuration 1 | include Threshold
Threshold (milliseconds): 5000
The operation’s return code is OK, which means that the ping operation is successful and its round-trip time is within the threshold (in our network it is 1ms). OK status always translates to the UP state of the corresponding track object.
If we will turn off the remote interface on router Z, the return code will change to Timeout, as per the listing below. This is the second SLA operation code, which always translates into the Down state of the Track object.
The third code that is relevant for the purpose of track operation is OverThreshold. To demonstrate it, we increased the request data size to 5000 bytes, so the operation takes longer than 1ms. We also decreased the threshold to 1ms, so the operation goes over the threshold.
The OverThreshold code translates differently to the track object state, which we will discuss in the next section.
X(config)#ip sla 2
X(config-ip-sla)#icmp-echo 10.0.3.1 source-ip 10.0.0.1
X(config-ip-sla-echo)# request-data-size 5000
X(config-ip-sla-echo)# threshold 1
X(config)#ip sla schedule 2 start-time now life forever
X#show ip sla statistics 2
IPSLAs Latest Operation Statistics
IPSLA operation id: 2
Latest RTT: 2 milliseconds
Latest operation start time: 09:44:48 UTC Sat Feb 6 2021
Latest operation return code: Over threshold
Number of successes: 2
Number of failures: 0
Operation time to live: Forever
IP SLA Track State vs. Reachability
“track <id> ip sla <sla-id>” command creates a track object that references SLA operation. There are 2 types of track objects for SLA – reachability, and state. Let’s configure both types against the previously configured SLA 2 to see the difference.
X(config)#track 1 ip sla 2 reachability
X(config)#track 2 ip sla 2 state
X#show track
Track 1
IP SLA 2 reachability
Reachability is Up
1 change, last change 00:00:29
Latest operation return code: Over threshold
Latest RTT (millisecs) 2
Track 2
IP SLA 2 state
State is Down
1 change, last change 00:00:17
Latest operation return code: Over threshold
Latest RTT (millisecs) 2
Track 1 is based on reachability and it is UP, even when the underlying IP SLA object is over the threshold. As the name suggests, we only interested in the fact that we can reach the remote side of the connection. Track 2 is state-based and it returns DOWN for the same IP SLA object. Track of the state type checks both reachability and that the IP SLA object is under the specified threshold.
Static Routes
The next listing demonstrates how to use the track objects with static routes:
X(config)#ip route 0.0.0.0 0.0.0.0 172.16.100.2 track 1 200
X(config)#ip route 0.0.0.0 0.0.0.0 172.16.100.6 track 2
X#sh ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
Known via "static", distance 200, metric 0, candidate default path
Routing Descriptor Blocks:
* 172.16.100.2
Route metric is 0, traffic share count is 1
The route via 172.16.100.6 is the preferred, as it has the default administrative distance of 1. The route via 172.16.100.2 is a backup route with an administrative distance of 200. However, the route table shows that the router prefers the route via 172.16.100.2.
For a route to be installed into the routing table the corresponding track must be UP. Because track object #2 is Down, the static route via 172.16.100.6 is withdrawn and the backup route is chosen and installed into the routing table.
EEM Scripts with IP SLA
The final example of this article is an EEM (Embedded Event Manager) script that adjusts the router configuration, generates a Syslog message in response to the Track state change.
The script is triggered when Track object #1 goes down, with the “event track <object-id> state down” command.
The access-list is being adjusted by the script in this example only for demonstration purposes. It can be adjusted to suit real-life requirements. For example, the script can reconfigure VPN tunnel endpoints or enable a backup interface. EEM can perform many other non-CLI actions as well.
To test the script, I’ve turned off the remote interface on router Z causing IP SLA and track to go down. The router generates a test Syslog message and creates an access-list, as shown in the listing below. “terminal monitor” command displays console messages into VTY lines, such as SSH or Telnet.
X#terminal monitor
*Feb 6 10:13:50.285: %TRACK-6-STATE: 1 ip sla 2 reachability Up -> Down
*Feb 6 10:13:50.530: %HA_EM-6-LOG: TRACK-1-DOWN: TEST Message
X#sh run | section ^ip access-list
ip access-list extended INTERNET-IN
permit ip host 1.2.3.4 any
This article provides sample Cisco configuration
commands for popular cities using “clock timezone” and “clock summer-time”
commands. It also aggregates information about different time zones and their
daylight saving dates.
Many services are dependent on the clock
and time zone configuration on Cisco devices. Services such as certificate
validity checks, logging are the obvious ones. The other examples include time-based
ACLs or scheduled tasks that can cause outages during the daylight saving
changes. The daylight savings rules are also changing time after time.
Time Zones and Daylight Settings
The time zone represents an area or region that observes the same time. Coordinated Universal Time (UTC) is the reference time. Time zones are expressed as an offset from it. Offset can be either negative or positive represented in a number of hours and in some cases in minutes.
Some regions observe daylight savings time when clocks are adjusted twice a year so there is an extra hour of daylight in the evening during summer. There are more daylight hours in summer than during winter. The difference is more noticeable when moving away from the equator. The adjustment is done in spring by moving clocks forward (spring forward) and then reversed in autumn by moving clocks back (fall back). Note that summer starts in December in some of the countries in the Southern hemisphere.
Time Configuration on Cisco devices
We recommend using NTP to ensure that time is accurately synchronized. NTP server sends time information in UTC, so it is important to set the correct time zone.
If manual clock settings are in use, the router assumes that the time is specified in the router’s local time zone, which is UTC by default. Therefore, the time zone settings should be configured before setting the clock manually, as otherwise, it will need to be re-adjusted after the router applies time zone configuration.
The following paragraphs show how to configure the correct time zone and daylight savings settings on the device.
To specify time zone and daylight settings two commands are used:
R1(config)#clock ?
summer-time Configure summer (daylight savings) time
timezone Configure time zone
Time zone configuration requires only 2 parameters:
clock timezone zone hours-offset [minutes-offset]
Summer-time configuration can be either recurring or date-specific:
clock summer-time zone recurring [week day month hh:mm week day month hh:mm [offset]]
clock summer-time zone date date month year hh:mmdate month year hh:mm [offset]
Time Configuration on Cisco devices
The easiest way to lookup information is by navigating to the timeanddate.com website and browsing to the world clock page.
Then find the city name and click on it. Select the Time Zone button and it will display abbreviation and up-to-date information on when DST starts.
Below are the configuration samples for some of the popular cities with updated daylight information as of March 2020.
North America
City
Command
Honolulu, US
# Hawaii Standard Time
clock timezone HST -10
Vancouver, Canada
# Pacific Standard Time
clock timezone PST -8
# Pacific Daylight Time
clock summer-time PDT recurring 2 Sun Mar 2:00 1 Sun Nov 2:00
Los Angeles, US
San Francisco, US
Las Vegas, US
Seattle, US
# Pacific Standard Time
clock timezone PST -8
# Pacific Daylight Time
clock summer-time PDT recurring 2 Sun Mar 2:00 1 Sun Nov 2:00
Mexico City, Mexico
# Central Standard Time
clock timezone CST -6
# Central Daylight Time
clock summer-time CDT recurring 1 Sun Apr 2:00 last Sun Oct 2:00
Denver, US
# Mountain Standard Time
clock timezone MST -7
# Mountain Daylight Time
clock summer-time MDT recurring 2 Sun Mar 2:00 1 Sun Nov 2:00
Cancun, Mexico
# Eastern Standard Time
clock timezone EST -5
Panama, Panama
# Eastern Standard Time
clock timezone EST -5
New Orleans, US
Kansas City, US
Austin, US
Dallas, US
Milwaukee, US
# Central Standard Time
clock timezone CST -6
# Central Daylight Time
clock summer-time CDT recurring 2 Sun Mar 2:00 1 Sun Nov 2:00
# Eastern Daylight Time
clock summer-time EDT recurring 2 Sun Mar 2:00 1 Sun Nov 2:00
Havana, Cuba
# Cuba Standard Time
clock timezone CST -5
# Cuba Daylight Time
clock summer-time CDT recurring 2 Sun Mar 2:00 1 Sun Nov 1:00
Washington DC, US
Florida, US
Tampa, US
Atlanta, US
Indianapolis, US
Louisville, US
Baltimore, US
Boston, US
Michigan, US
New York, US
Philadelphia, US
Pittsburgh, US
Portsmouth, US
# Eastern Standard Time
clock timezone EST -5
# Eastern Daylight Time
clock summer-time EDT recurring 2 Sun Mar 2:00 1 Sun Nov 2:00
Halifax, Canada
# Atlantic Standard Time
clock timezone AST -4
# Atlantic Daylight Time
clock summer-time ADT recurring 2 Sun Mar 2:00 1 Sun Nov 2:00
Table 1. North America Cities and Cisco Timezone Configuration Commands
South America
City
Command
Bogota, Colombia
# Colombia Time
clock timezone COT -5
Lima, Peru
# Peru Time
clock timezone PET -5
Santa Cruz, Bolivia
# Bolivia Time
clock timezone BOT -4
Caracas, Venezuela
# Venezuelan Standard Time
clock timezone VET -4
Buenos Aires, Argentina
Santa Fe, Argentina
# Argentina Time
clock timezone ART -3
Brasilia, Brazil
Rio de Janeiro, Brazil
Sao Paulo, Brazil
# Brasilia Time
clock timezone BRT -3
Asuncion, Paraguay
# Paraguay Time
clock timezone PYT -4
# Paraguay Summer Time
clock summer-time PYST recurring 1 Sun Oct 0:00 last Sun Oct 0:00
Montevideo, Uruguay
# Uruguay Time
clock timezone UYT -3
Table 2. South America Cities and Cisco Timezone Configuration Commands
Europe
City
Command
Reykjavik, Iceland
# Greenwich Mean Time
clock timezone GMT
Dublin, Ireland
# Greenwich Mean Time
clock timezone GMT
# Irish Standard Time (Daylight saving)
clock summer-time IST recurring last Sun Mar 1:00 last Sun Oct 2:00
Lisbon, Portugal
Porto, Portugal
# Western European Time
clock timezone WET
# Western European Summer Time
clock summer-time WEST recurring last Sun Mar 1:00 last Sun Oct 2:00
Birmingham, UK
Bristol, UK
Leeds, UK
Liverpool, UK
London, UK
Manchester, UK
Belfast, UK
Edinburgh, UK
Glasgow, UK
# Greenwich Mean Time
clock timezone GMT
# British Summer Time
clock summer-time BST recurring last Sun Mar 1:00 last Sun Oct 2:00
Tirana, Albania
Salzburg, Austria
Vienna, Austria
Brussels, Belgium
Sarajevo, Bosnia-Herzegovina
Zagreb, Croatia
Prague, Czechia
Copenhagen, Denmark
Strasbourg, France
Paris, France
Versailles, France
Toulouse, France
Marseille, France
Stuttgart, Germany
Munich, Germany
Berlin, Germany
Hamburg, Germany
Frankfurt, Germany
Hannover, Germany
Dortmund, Germany
Leipzig, Germany
Gibraltar, Gibraltar
Budapest, Hungary
Naples, Italy
Turin, Italy
Venice, Italy
Amsterdam, Netherlands
The Hague, Netherlands
Oslo, Norway
Krakow, Poland
Warsaw, Poland
Belgrade, Serbia
Ljubljana, Slovenia
Barcelona, Spain
Ibiza, Spain
Madrid, Spain
Stockholm, Sweden
Bern, Switzerland
Geneva, Switzerland
Lugano, Switzerland
Vatican City, Vatican City State
# Central European Time
clock timezone CET +1
# Central European Summer Time
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
Plovdiv, Bulgaria
Sofia, Bulgaria
Tallinn, Estonia
Helsinki, Finland
Athens, Greece
Riga, Latvia
Vilnius, Lithuania
Bucharest, Romania
Kyiv, Ukraine
Odesa, Ukraine
# Eastern European Time
clock timezone EET +2
# Eastern European Summer Time
clock summer-time EEST recurring last Sun Mar 3:00 last Sun Oct 4:00
Kaliningrad, Russia
# Eastern European Time
clock timezone EET +2
Minsk, Belarus
Bryansk, Russia
Sochi, Russia
Moscow, Russia
Saint-Petersburg, Russia
# Moscow Standard Time
clock timezone MSK +3
Table 3. Europe Cities and Cisco Timezone Configuration Commands
Asia
City
Command
Jerusalem, Israel
Tel Aviv, Israel
# Israel Standard Time
clock timezone IST +2
# Israel Daylight Time
clock summer-time IDT recurring last Sun Mar 2:00 last Sun Oct 2:00
Beirut, Lebanon
# Eastern European Time
clock timezone EET +2
# Eastern European Summer Time
clock summer-time EEST recurring last Sun Mar 0:00 last Sun Oct 0:00
Baghdad, Iraq
Kuwait City, Kuwait
Doha, Qatar
Riyadh, Saudi Arabia
# Arabia Standard Time
clock timezone AST +3
Istanbul, Turkey
# Turkey Time
clock timezone TRT +3
Tbilisi, Georgia
# Georgia Standard Time
clock timezone GET +4
Yerevan, Armenia
# Armenia Time
clock timezone AMT +4
Baku, Azerbaijan
# Azerbaijan Time
clock timezone AZT +4
Dubai, United Arab Emirates
# Gulf Standard Time
clock timezone GST +4
Kabul, Afghanistan
# Afghanistan Time
clock timezone AFT +4 30
Tehran, Iran
# Iran Standard Time
clock timezone IRST +3 30
# Iran Daylight Time 2020
clock summer-time IRDT date 21 Mar 2020 0:00 21 Sep 2020 0:00
# Iran Daylight Time 2021-2023
clock summer-time IRDT date 22 Mar 2021 0:00 22 Sep 2021 0:00
clock summer-time IRDT date 22 Mar 2022 0:00 22 Sep 2022 0:00
clock summer-time IRDT date 22 Mar 2023 0:00 22 Sep 2023 0:00
Ufa, Russia
Chelyabinsk, Russia
Yekaterinburg, Russia
# Yekaterinburg Time
clock timezone YEKT +5
Dushanbe, Tajikistan
# Tajikistan Time
clock timezone TJT +5
Ashgabat, Turkmenistan
# Turkmenistan Time
clock timezone TMT +5
Tashkent, Uzbekistan
# Uzbekistan Time
clock timezone UZT +5
Delhi, India
New Delhi, India
Bangalore, India
Mumbai, India
Kolkata, India
Colombo, Sri Lanka
# India Standard Time
clock timezone IST +5 30
Kathmandu, Nepal
# Nepal Time
clock timezone NPT +5 45
Dhaka, Bangladesh
# Bangladesh Standard Time
clock timezone BST +6
Almaty, Kazakhstan
Nursultan, Kazakhstan
# Alma-Ata Time
clock timezone ALMT +6
Bishkek, Kyrgyzstan
# Kyrgyzstan Time
clock timezone KGT +6
Omsk, Russia
# Omsk Standard Time
clock timezone OMST +6
Phnom Penh, Cambodia
Hanoi, Vietnam
Ho Chi Minh, Vietnam
# Indochina Time
clock timezone ICT +7
Jakarta, Indonesia
# Western Indonesian Time
clock timezone WIB +7
Novosibirsk, Russia
# Novosibirsk Time
clock timezone NOVT +7
Beijing, China
Guangzhou, China
Shenzhen, China
Harbin, China
Nanjing, China
Shanghai, China
Chengdu, China
Lhasa, China
Hangzhou, China
Taipei, Taiwan
# China Standard Time
clock timezone CST +8
Hong Kong, Hong Kong
# Hong Kong Time
clock timezone HKT +8
Kuala Lumpur, Malaysia
# Malaysia Time
clock timezone MYT +8
Manila, Philippines
# Philippine Time
clock timezone PHST +8
Irkutsk, Russia
# Irkutsk Time
clock timezone IRKT +8
Singapore, Singapore
# Singapore Time
clock timezone SGT +8
Kyoto, Japan
Osaka, Japan
Sapporo, Japan
Tokyo, Japan
Yokohama, Japan
# Japan Standard Time
clock timezone JST +9
Chita, Russia
Yakutsk, Russia
# Yakutsk Time
clock timezone YAKT +9
Busan, South Korea
Daegu, South Korea
Incheon, South Korea
Seoul, South Korea
# Korea Standard Time
clock timezone KST +9
Vladivostok, Russia
# Vladivostok Time
clock timezone VLAT +10
Table 4. Asia Cities and Cisco Timezone Configuration Commands
Africa
City
Command
Bissau, Guinea-Bissau
Monrovia, Liberia
Timbuktu, Mali
Dakar, Senegal
SNMP (Simple Network Management Protocol) defines communication and message format between network management stations and agents.
Every managed network element, such as a router, switch, or host is running a management agent. Its function is to retrieve and modify operational variables’ values as requested by network management stations.
This article contains information on how to enable SNMP agents on different Cisco devices, including IOS, IOS-XE, and NX-OS-based.
SNMPv1/SNMPv2c Configuration
SNMPv1 and SNMPv2c use the same security mechanisms based on communities transmitted in clear-text format. It is still used in some networks, however, SNMPv3 should be used in new deployments.
I will start with SNMPv1 and SNMPv2 configuration first. SNMPv3 configuration will be shown in the later sections.
I’m using 3 different types of devices in this demonstration: Classic IOS, IOS-XE, and NX-OS. The community string is the only required configuration and it is the same for SNMPv1/v2c on our platforms with slightly different keyword options on NX-OS.
Classic IOS (Cisco 1940)
You can specify if the community string is for read-only and read-write access, as well as access-list to control which management stations are allowed to query the device. All options except for community string are optional, with read-only access being the default if none is specified. You can enter more than one community string, as the command doesn’t overwrite previous community value.
C1940(config)#snmp-server community FastRerouteRO ? <1-99> Std IP accesslist allowing access with this community string <1300-1999> Expanded IP accesslist allowing access with this community string WORD Access-list name ipv6 Specify IPv6 Named Access-List ro Read-only access with this community string rw Read-write access with this community string view Restrict this community to a named MIB view
C1940(config)#snmp-server community FastRerouteRO ro C1940(config)#snmp-server community FastRerouteRW rw
IOS-XE (CSR1000V)
IOS-XE has the same options and keywords as classic IOS:
CSR1000V(config)#snmp-server community FastRerouteRO ? <1-99> Std IP accesslist allowing access with this community string <1300-1999> Expanded IP accesslist allowing access with this community string WORD Access-list name ipv6 Specify IPv6 Named Access-List ro Read-only access with this community string rw Read-write access with this community string view Restrict this community to a named MIB view
CSR1000V(config)#snmp-server community FastRerouteRO ro CSR1000V(config)#snmp-server community FastRerouteRW rw
NX-OS (Nexus 9000V)
N9K-1(config)# snmp-server community FastRerouteRO ?
group Group to which the community belongs ro Read-only access with this community string rw Read-write access with this community string use-ipv4acl Specify IPv4 ACL, the ACL name specified after must be IPv4 ACL. use-ipv6acl Specify IPv6 ACL, the ACL name specified after must be IPv6 ACL.
N9K-1(config)#snmp-server community FastRerouteRO ro N9K-1(config)#snmp-server community FastRerouteRW rw
NMS Configuration
To test the configuration I will be using a great free application called SnmpB (link). For each device, you will require an Agent Profile. Press the Tools button as shown in Figure 1.
Figure 1. SnmpB User InterfaceFigure 2. SnmpB Agent Profile Configuration
I’ve created a
profile for each of the 3 devices. The settings are shown in Figure 3.
My Cisco 1940 router’s IP address is 172.16.17.1 with the SNMP community of FastRerouteRO as shown in Figure 4.
Once profiles are configured, let’s test simple get request for the device uptime. We need to request (using SNMP GET) value of an object that represents device uptime. Any object in SNMP has a unique identifier (OID) and its format and description will be defined in a MIB.
What is MIB and OID?
As per RFC1155 (link) – “Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB… Each type of object (termed an object type) has a name, a syntax, and an encoding. The name is represented uniquely as an OBJECT IDENTIFIER. An OBJECT IDENTIFIER is an administratively assigned name.”
MIB describes a set of objects, including their identifiers, expected reply format, and if values are read-only or can be changed.
For example, MIB-II has the following definition for interface description:
Figure 5. SNMP Interface Description Object
A network device usually supports a standard-based MIB, such as MIB-II (link), as well as vendor-proprietary MIBs. Most NMS have pre-loaded modules for standard MIBs. Import is required to support vendor-specific extensions.
Object Identifier (OID) is written in dotted notation starting with the top-level node. For example, the Internet subtree of Object Identifiers is 1.3.6.1. The object hierarchy has an unlabelled root. Under root, there are 3 allocated child nodes: ccitt (0), iso (1), and joint-iso-ccitt (2).
ISO has a subtree for other organizations org (3), with the child node of (6) assigned to the US Department of Defense (DOD). DoD in turn allocated a node (1) to Internet Activities Board (IAB).
SNMPv2 Testing
To test – expand the MIB tree and navigate to sysUpTime object (1.3.6.1.2.1.1.3). Note that the Node Info window displays detailed information about the selected object. Right-click on sysUpTime and then select Get.
Figure 6. Get Request for sysUpTime
The Figure 7 shows uptime of the Cisco 1940 router.
Figure 7. Reply for sysUpTime (Cisco 1940)
Figure 8 and Figure 9 shows uptime of the Nexus 9000V and CSR. To poll different devices select the corresponding entry in the drop-down box called Remote SNMP Agent.
Figure 8. Reply for sysUpTime (Nexus 9000V) Figure 9. Reply for sysUpTime (CSR1000)
SNMPv3 Configuration
SNMPv3 defines the User-based Security Model (USM) with the ability to authenticate and encrypt communication between agents and monitoring stations. There are 3 security levels listed below with the weakest first: • noAuthNoPriv (no authentication or encryption) • authNoPriv (authentication only) • authPriv (authentication and encryption)
Minimal configuration of SNMPv3 requires 2 components: Group and User.
Note: There are some interoperability issues between Cisco IOS and IOS-XE devices and SnmpB when AES192 and AES256 used, so AES128 is configured instead in all examples. SNMP debug (debug snmp detail and debug snmp packets) produce the following error with AES192 and AES256:
*Dec 26 02:47:55.691: SNMP: Packet received via UDP from 172.16.17.75 on GigabitEthernet1no such type in ParseType (152) (0x98) ParseSequence, Unexpected type: FFFFFFFFFFFFFFFF SrParseV3SnmpMessage: ParseSequence: SrParseV3SnmpMessage: Failed. SrDoSnmp: ASN Parse Error *Dec 26 02:47:58.693: SNMP: Packet received via UDP from 172.16.17.75 on GigabitEthernet1no such type in ParseType (152) (0x98) ParseSequence, Unexpected type: FFFFFFFFFFFFFFFF SrParseV3SnmpMessage: ParseSequence: SrParseV3SnmpMessage: Failed. SrDoSnmp: ASN Parse Error
Classic IOS (Cisco 1940)
C1940(config)#snmp-server group SNMP-Group v3 ? auth group using the authNoPriv Security Level noauth group using the noAuthNoPriv Security Level priv group using SNMPv3 authPriv security level
C1940(config)#snmp-server group SNMP-Group v3 priv C1940(config)#snmp-server user SNMP-Admin SNMP-Group v3 auth sha FastReroute priv aes 128 FastReroute
Note: SNMP users are not stored as part of running or startup configuration, so the second line will not be visible via “show running-config“.
SnmpB requires the configuration of SNMPv3 User. To access the configuration setting click on Options > Manage SNMPv3 USM Profile. Once the USM profile window opens, right-click on a blank space in the list of profiles and select “New USM profile”. I’ve configured username, security parameters to match the ones we configured on the router earlier. See Figures 9 and 10 for details.
Figure 9. SnmpB: SNMP User ConfigurationFigure 10. SnmpB: SNMP User Configuration – 2
Go back to our device profiles, as shown in the Figure 1. Select SNMPv3 as supported version and choose corresponding Security Name and Levels as shown in Figure 11 and 12.
Let’s try to poll the Cisco 1940 to confirm that we still can access uptime information as shown in Figure 13.
Figure 13. SnmpB: Poll Uptime with SNMPv3 Enabled (Cisco 1940)
IOS-XE (CSR1000V)
IOS-XE is configured identically as Classic IOS.
CSR1000V(config)#snmp-server group SNMP-Group v3 priv CSR1000V(config)#snmp-server user SNMP-Admin SNMP-Group v3 auth sha FastReroute priv aes 128 FastReroute
Figure 14. SnmpB: Poll Uptime with SNMPv3 Enabled (CSR1000)
NX-OS (Nexus 9000V)
Nexus 9000V minimal configuration is based on a single string, as SNMP groups in NX-OS are replaced by roles for Role-Based Access Control, and by default new users will be assigned network-operator permissions. As a side effect, by default SNMP users will be able to log-in via CLI to the switch with access to all show commands.
Note that there is no group option under SNMP. Use the “role” set of commands, which then can be used as groups in SNMP.
N9K-1(config)# snmp-server ? aaa-user Set duration for which aaa-cached snmp user exists community Set community string and access privs contact Modify sysContact context SNMP context to be mapped counter Configure port counter configuration drop Silently drop unknown v3 user packets enable Enable SNMP Traps engineID Configure a local SNMPv3 engineID globalEnforcePriv Globally enforce privacy for all the users host Specify hosts to receive SNMP notifications location Modify sysLocation mib Mib access parameters packetsize Largest SNMP packet size protocol Snmp protocol operations source-interface Source interface to be used for sending out SNMP notifications system-shutdown Configure snmp-server for reload(2) tcp-session Enable one time authentication for snmp over tcp session. user Define a user who can access the SNMP engine
You can assign users to a group for SNMP-Admin by typing it in straight after the username.
N9K-1(config)# snmp-server user SNMP-Admin ?
WORD Group name (ignored for notif target user) (Max Size 28) auth Authentication parameters for the user enforcePriv Enforce privacy for the user use-ipv4acl Specify IPv4 ACL, the ACL name specified after must be IPv4 ACL. use-ipv6acl Specify IPv6 ACL, the ACL name specified after must be IPv6 ACL.
N9K-1(config)# snmp-server user SNMP-Admin auth sha FastReroute priv aes-128 FastReroute
NX-OS also creates a normal user in addition to the SNMP user. Both users are stored in the running configuration.
N9K-1(config)# show run | incl SNMP
username SNMP-Admin password 5 #password# role network-operator
Figure 15. SnmpB: Poll Uptime with SNMPv3 Enabled (Nexus 9000V)
SNMP show commands
Classic IOS (Cisco 1940) and IOS-XE (CSR1000V)
Devices keep track of which objects were polled and associated timestamps, as shown in the listings below.
CSR1000V#show snmp stats oid
time-stamp #of times requested OID 03:27:46 UTC Dec 21 2018 6 sysUpTime 09:54:49 UTC Dec 18 2018 3 system.6 09:54:46 UTC Dec 18 2018 3 system.4 09:53:49 UTC Dec 18 2018 2 system.5 09:53:49 UTC Dec 18 2018 2 system.1 11:27:41 UTC Dec 17 2018 1 sysOREntry.3
To get the list of SNMP groups use the “show snmp group” command. Note that SNMPv1 and SNMPv2c have groups and as there is no concept of users, they are named as the community name. Also not covered in this article, SNMP views allow restricting access only to specific OIDs or subtrees.
CSR1000V#show snmp group groupname: ILMI security model:v1 contextname: storage-type: permanent readview : *ilmi writeview: *ilmi notifyview: row status: active
To get the list of SNMP users use the “show snmp user” command. As users are not displayed in the configuration, this command is the only way to check the SNMP users.
CSR1000V#show snmp user User name: SNMP-Admin Engine ID: 800000090300000C29B86282 storage-type: nonvolatile active Authentication Protocol: SHA Privacy Protocol: AES128 Group-name: SNMP-Group
NX-OS (Nexus 9000V)
N9K-1# show snmp oid-statistics
SNMP OID Stats - Object ID Min Max Avg Max Access TS Last-polled NMS Poll Count (ms) (ms) (ms)
iso.3.6.1.2.1.1.3 <1 <1 <1 02:33:25:515 Dec 21 2018 172.16.17.75 1
NX-OS in addition to OID statistics also provides show command to display statistics related to a management station.
N9K-1# show snmp nms-statistics
- SNMP NMS OID Stats -
NMS IP Address GET GET GET SET First Poll Last Poll NEXT BULK -------------------------------------------------------------------------------- ---------------------------------------- 172.16.17.75 1 0 0 0 02:33:25:515 Dec 21 2018 02:33:25:515 Dec 21 2018
To get the list of SNMP groups use the “show snmp group” command. Its output is the same as the “show role” command would produce.
N9K-1(config)# show snmp group
Role: aaa-db-admin Description: Predefined AAA DB admin, has no cli permissions. Allows RESTful A PI
Rule Perm Type Scope Entity
1 permit read-write
#some output omitted
Role: network-admin Description: Predefined network admin role has access to all commands on the switch
Rule Perm Type Scope Entity
1 permit read-write Role: network-operator Description: Predefined network operator role has access to all read commands on the switch
Rule Perm Type Scope Entity
1 permit read
#some output omitted
To get the list of SNMP users use the “show snmp user” command. Admin users are automatically enabled as SNMP users, as NX-OS implements a single user and role storage.
N9K-1(config)# show snmp user SNMP USERS
User Auth Priv(enforce) Groups acl_filter _ ___ ___ admin md5 des(no) network-admin SNMP-Admin sha aes-128(no) network-operator
NOTIFICATION TARGET USERS (configured for sending V3 Inform)
User Auth Priv _ ___
SNMP debug commands
Classic IOS (Cisco 1940) and IOS-XE (CSR1000V)
Two commands displaying if there is communication with NMS are “debug snmp detail” and “debug snmp packets“. Below is the output generated when a simple SNMP Get request is performed.
CSR1000V#debug snmp detail SNMP Detail Debugs debugging is on CSR1000V#debug snmp packets SNMP packet debugging is on CSR1000V#terminal monitor *Dec 26 23:41:59.539: SNMP: Packet received via UDP from 172.16.17.75 on GigabitEthernet1SrParseV3SnmpMessage: Failed..
*Dec 26 23:41:59.539: SNMP: Get request, reqid 1062, errstat 0, erridx 0 sysUpTime.0 = NULL TYPE/VALUESrDoSnmp: received get pdu CheckClassMIBView: all included CheckMIBView: OID is in MIB view.
*Dec 26 23:41:59.539: SNMP: Response, reqid 1062, errstat 0, erridx 0 sysUpTime.0 = 305892 *Dec 26 23:41:59.540: SNMP: Packet sent via UDP to 172.16.17.75
NX-OS (Nexus 9000V)
In NX-OS use “debug snmp pkt-dump” which is similar to commands shown above for IOS/IOS-XE. Below is the output generated when a simple SNMP Get request is performed.
Built-in into IOS, TCL interpreter can be useful in several scenarios.
You may need to apply several commands on a Cisco device when some of the earlier commands can prevent later commands to be delivered. For example, one may need to move an external interface of a remote router to a different VRF. The moment the command that changes VRF delivered, the router removes IP address on the interface and the interactive terminal will not be able to send the remaining commands.
To avoid a lockout, prior to applying the configuration, save the configuration and enter the “reload in 10″ exec command, which will restart the router in 10 minutes unless canceled. Don’t forget to do “reload cancel” once you are happy with the outcome.
The following example shows how to enter interface configuration mode and change its description.
ROUTER#tclsh
ROUTER(tcl)#ios_config “interface GigabitEthernet2” “description WAN Interface”
Instead of using an interactive interpreter, one can create a script file and save it on the flash to be later invoked.
flash:/script.tcl file content:
ios_config “interface GigabitEthernet1” “description LAN Interface”
To execute this file, pass it as an argument to tclsh command:
ROUTER#tclsh
ROUTER(tcl)#tclsh flash:/script.tcl
To upload script files to the router’s flash memory use one of the protocols that router supports, such as TFTP. If such access is not available, one can use puts function of TCL that writes the list of strings into a text file.
