Cisco IP SLA IOS-XE

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
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.

X(config-ip-sla)#?
IP SLAs entry configuration commands:
  dhcp         DHCP Operation
  dns          DNS Query Operation
  ethernet     Ethernet Operations
  exit         Exit Operation Configuration
  ftp          FTP Operation
  http         HTTP Operation
  icmp-echo    ICMP Echo Operation
  icmp-jitter  ICMP Jitter Operation
  mpls         MPLS Operation
  path-echo    Path Discovered ICMP Echo Operation
  path-jitter  Path Discovered ICMP Jitter Operation
  tcp-connect  TCP Connect Operation
  udp-echo     UDP Echo Operation
  udp-jitter   UDP Jitter Operation

The next subsections will review some of them.

Jitter operations

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
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
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.

SLA reaction configuration command references an IP SLA operation and has a mandatory parameter specifying what monitored element of SLA we want to monitor. For example, this can be a timeout or threshold-based value. Available monitored elements vary based on the type of IP SLA operation. A compatibility table is available on this page. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipsla/configuration/xe-16-9/sla-xe-16-9-book/sla-threshold-mon.html

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.

X(config)#ip sla reaction-configuration 1 react timeout action-type trapOnly threshold-type immediate
X(config)#snmp-server enable traps ipsla
X(config)#snmp-server host 10.0.0.5 PUBLIC

To test it, I’ve turned off the interface on router Z and enabled debug of SNMP packets to confirm that SNMP traps were generated by the router.

X#debug snmp packets
*Feb  4 09:41:49.232: SNMP: Queuing packet to 10.0.0.5
*Feb  4 09:41:49.232: SNMP: V1 Trap, ent rttMonNotificationsPrefix, addr 10.0.0.1, gentrap 6, spectrap 2 
 rttMonCtrlAdminTag.1 =  
 rttMonHistoryCollectionAddress.1 = 0A 00  03 01    
 rttMonCtrlOperTimeoutOccurred.1 = 2
<output is truncated>

Enhanced Object Tracking

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.

X#show ip sla statistics 1 | incl code
Latest operation return code: Timeout

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.

X(config)#event manager applet TRACK-1-DOWN 
X(config-applet)#event track 1 state down
X(config-applet)#action 1 cli command "enable"
X(config-applet)#action 2 cli command "conf t"
X(config-applet)#action 3 cli command "ip access-list extended INTERNET-IN"
X(config-applet)#action 4 cli command "permit ip host 1.2.3.4 any"         
X(config-applet)#action 5 syslog msg "TEST Message"

X#show run | section ^ip access-list
<none>

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

Cisco Clock Timezone Configuration

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:mm date 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

CityCommand
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 1 Sun Nov 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
Ottawa, Canada
Ontario, Canada
Montreal, Canada
Quebec, Canada
# 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
Havana, Cuba# Cuba Standard Time
clock timezone EST -5

# Cuba Daylight Time
clock summer-time EDT 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

CityCommand
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

CityCommand
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

CityCommand
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
Islamabad, Pakistan
Karachi, Pakistan
Lahore, Pakistan
# Pakistan Standard Time
clock timezone PKT +5
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 OST +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 +7
Hong Kong, Hong Kong# Hong Kong Time
clock timezone HKT +7
Kuala Lumpur, Malaysia# Malaysia Time
clock timezone MYT +8
Manila, Philippines# Philippine Time
clock timezone PHT +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

CityCommand
Bissau, Guinea-Bissau
Monrovia, Liberia
Timbuktu, Mali
Dakar, Senegal
# Greenwich Mean Time
clock timezone GMT
Algiers, Algeria
Constantine, Algeria
Tunis, Tunisia
# Central European Time
clock timezone CET +1
Kinshasa, Congo
Lagos, Nigeria
# West Africa Time
clock timezone WAT +1
Casablanca, Morocco
Marrakech, Morocco
Tangier, Morocco
# Western European Time
clock timezone WET

# Western European Summer Time 2020-21
clock summer-time WEST date 9 Jun 2019 2:00 19 Apr 2020 Apr 3:00
clock summer-time WEST date 24 May 2020 2:00 11 Apr 2021 Apr 3:00
Alexandria, Egypt
Cairo, Egypt
Tobruk, Libya
Tripoli, Libya
# Eastern European Time
clock timezone EET +2
Cape Town, South Africa
Johannesburg, South Africa
Pretoria, South Africa
# South Africa Standard Time
clock timezone SAST +2
Khartoum, Sudan
Port Sudan, Sudan
# Central Africa Time
clock timezone CAT +2
Addis Ababa, Ethiopia
Mombasa, Kenya
Mogadishu, Somalia
Zanzibar City, Tanzania
# Eastern Africa Time
clock timezone EAT +3

Table 5. Africa Cities and Cisco Timezone Configuration Commands

Australia/Pacific

CityCommand
Perth, Australia# Australian Western Standard Time
clock timezone AWST +8
Darwin, Australia# Australian Central Standard Time
clock timezone ACST +9 30

Brisbane, Australia
Cairns, Australia
# Australian Eastern Standard Time
clock timezone AEST +10
Adelaide, Australia# Australian Central Standard Time
clock timezone ACST +9 30

# Australian Central Daylight Time
clock summer-time ACDT recurring 1 Sun Oct 2:00 1 Sun Apr 3:00
Canberra, Australia
Sydney, Australia
Hobart, Australia
Melbourne, Australia
# Australian Eastern Standard Time
clock timezone AEST +10

# Australian Eastern Daylight Time
clock summer-time AEDT recurring 1 Sun Oct 2:00 1 Sun Apr 3:00
Noumea, New Caledonia# New Caledonia Time
clock timezone NCT +11
Port Vila, Vanuatu# Vanuatu Time
clock timezone VUT +11
Auckland, New Zealand
Christchurch, New Zealand
Wellington, New Zealand
# New Zealand Standard Time
clock timezone NZST +12

# New Zealand Daylight Time
clock summer-time NZDT recurring last Sun Sep 2:00 1 Sun Apr 3:00

Table 6. Australia/Pacific Cities and Cisco Timezone Configuration Commands

Reference Information

Alphabetically sorted list of time zone abbreviations:

https://www.timeanddate.com/time/zones/

IANA supports the time zone database (https://www.iana.org/time-zones) and at the time of this blog post writing the latest one is 2019c release. To receive updates on time zone database updates, you can subscribe to the IANA’s mailing list (https://mm.icann.org/mailman/listinfo/tz-announce).

Configure SNMP on Cisco Devices

Configure SNMP on Cisco Devices

SNMP Overview

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 Interface
Figure 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.

Figure 3. SnmpB Agent Profile General Settings
Figure 4. Agent Profile SNMPv1/v2c Settings

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 Configuration
Figure 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.

Figure 11. SnmpB: Enable SNMPv3
Figure 12. SnmpB: Enable SNMPv3 – 2

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

snmp-server user SNMP-Admin network-operator auth sha
#password# priv aes-128 #password# localizedkey

Let’s test that we can poll N9K using SNMPv3.

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

groupname: ILMI security model:v2c
contextname: storage-type: permanent
readview : *ilmi writeview: *ilmi
notifyview:
row status: active

groupname: SNMP-Group security model:v3 priv
contextname: storage-type: nonvolatile
readview : v1default writeview:
notifyview:
row status: active

groupname: FastRerouteRO security model:v1
contextname: storage-type: permanent
readview : v1default writeview:
notifyview:
row status: active

groupname: FastRerouteRO security model:v2c
contextname: storage-type: permanent
readview : v1default writeview:
notifyview:
row status: active

groupname: FastRerouteRW security model:v1
contextname: storage-type: permanent
readview : v1default writeview: v1default
notifyview:
row status: active

groupname: FastRerouteRW security model:v2c
contextname: storage-type: permanent
readview : v1default writeview: v1default
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.

N9K-1# debug snmp pkt-dump  
N9K-1#
2018 Dec 27 11:45:07.929429 snmpd: 1063.000000:iso.3.6.1.2.1.1.3.0 = NULL SNMPPKTEND
2018 Dec 27 11:45:07.929489 snmpd: SNMPPKTSTRT: 3.000000 160 1063.000000 393237.000000 0.000000 0.000000 0 4 3 3 0 0 remote ip,v4: snmp_54789_172.16.17.75 \200 11 0 \200 11 SNMP-Admin 10 0 0 0x11e950d4 90
2018 Dec 27 11:45:07.929560 snmpd: 1063.000000:iso.3.6.1.2.1.1.3.0 = Timeticks: (339820) 0:56:38.20 SNMPPKTEND
2018 Dec 27 11:45:07.929577 snmpd: SNMPPKTSTRT: 3.000000 162 1063.000000 393237.000000 0.000000 0.000000 0 4 3 3 0 0 remote ip,v4: snmp_54789_172.16.17.75 \200 11 0 \200 11 SNMP-Admin 10 0 0 0x11e950d4 90

Cisco TCL multiple commands at once

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.

ROUTER#tclsh
ROUTER(tcl)#puts [open “flash:script.tcl” w+] {interface GigabitEthernet2
description WAN}


Note that there is no Enter after the first curly brace.