Jan
11

UPDATE: I have received numerous submissions and currently in the process of reviewing them. I'm going to extend the deadline until Wednesday (2012-01-18). At that time all people who submitted working solutions will be awarded 100 tokens!

Recently I have been working with a large enterprise customer that is looking to implement a new change control policy. The main goal of the policy is to be able to track who is making changes to devices in the network, and specifically what those changes are. As opposed to using a full blown network management suite to do this for them, I suggested a simple solution of using TACACS for exec and command accounting (all devices are Cisco), and EEM scripting along with a TFTP server for tracking the actual configuration changes in case they need to roll back to a well-known good working config. The final result worked out very well, and I thought it would make a good CCIE level challenge as well.

So here is the challenge - write an EEM script to manage change control in the network as follows. The first person to submit a working script will win 100 rack rental tokens valid for any rack rental or mock lab session.

Every time a user makes a change to the configuration, the router should automatically TFTP its running configuration to the TFTP server 10.0.0.1 using the following naming convention:

HOSTNAME.YYYY-MM-DD.HHhMMmSSs.ADMIN_NAME.working.cfg

This ensures that if a change is made to the network but not actually saved to NVRAM, and there is a device crash, you can recover the last working running config of the device. Also this naming format tells you when exactly the change was made and by who. Remember that the router always generates a %SYS-5-CONFIG log message when a change is made. So for example suppose the following change was made:

EDGE-ROUTER-1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
EDGE-ROUTER-1(config)#int lo1234
EDGE-ROUTER-1(config-if)#shutdown
EDGE-ROUTER-1(config-if)#
*Jan 11 19:05:49.694: %LINK-5-CHANGED: Interface Loopback1234, changed state to administratively down
*Jan 11 19:05:50.694: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback1234, changed state to down
EDGE-ROUTER-1(config-if)#end
EDGE-ROUTER-1#
*Jan 11 19:05:59.054: %SYS-5-CONFIG_I: Configured from console by bmcgahan on console

The router would then TFTP its running config to 10.0.0.1 using the filename EDGE-ROUTER-1.2011-01-11.19h05m59s.bmcgahan.working.cfg

Secondly, the script should also make backups of configs that are actually saved to NVRAM. Similar to the previous requirement, files should be backed up to TFTP using the naming convention HOSTNAME.YYYY-MM-DD.HHhMMmSSs.ADMIN_NAME.startup.cfg. However in this case you need to account for the fact that different admins use different syntax when saving configs. Some of them use "write memory" or shorter variations like "wr m" or just "wr", while others use the "copy run start" variations. However regardless which variation is used, the router spits out the same output afterwards as follows:

EDGE-ROUTER-1#wr
Building configuration...

[OK]
EDGE-ROUTER-1#copy run start
Destination filename [startup-config]?
Building configuration...

[OK]

Lastly make sure that the script doesn't mistake a "show run" output for the same as a "write memory", as the outputs are similar:

EDGE-ROUTER-1#sh run
Building configuration...

Current configuration : 3438 bytes
!
! Last configuration change at 19:05:59 UTC Wed Jan 11 2012 by bmcgahan
version 15.1

Submit your script as a comment and the first one with fully functional requirements wins 100 tokens!

Mar
25

In the earlier article titled EEM demystified, we took an introductory look at the basic format for EEM applets, and some basic samples for general operation, including some basic CLI command usage, getting input, and displaying output.

In this article, we are going to take a look at some of the additional actions available, specifically looking at variables, a few operators, and some general conditional structures.

Note: For any commands that are shown that start with the word "action", these are commands configured from within applet configuration mode.

Variables.
There are a number of built in variables, but you can also define some variables on your own. Cisco environmental variables begin with an underscore "_". Because of this it is strongly recommended that you do not use variables that start with "_", to avoid potential conflict.

In some cases, you will see a variable referenced with a dollar sign in front "$". This is to identify that the following item is a variable.

For example, comparing the following two lines:

action 1000 puts I
action 1001 puts $I

Action 1000 will print the character "I", whereas action 1001 will print the value of the variable "I".

Variables can be set within the applet

Action 100 set I 5000

This will set the variable "I" to 5000.

Variables can also be set from global configuration

event manager environment I 5000

This will set the variable "I" to 5000.

Variables can also be set by CLI input using the "gets" action.

Action 1002 gets MYVAR

This action will take input from the console, and save the entered value as the variable MYVAR.

Add / Subtract / Multiply / Divide

Depending on what assumptions you make, you may not be correct in how these actions work. Basic math operations take place, but the

confusion generally centers around what happens with the resulting value.

Let's start with a basic example:

action 1000 set i 50
action 1001 set j 60
action 1002 add $i $j

Although we configured the operation of addition, the values for i and j are not changed by action 1002. The action just takes the two numbers and adds them together. Internally, the result is stored in the environmental variable "_result". If we wanted to see the answer to the addition, we could output the value using "puts".

action 1003 puts "The total is $_result."

Subtraction will subtract the second operand from the first, so "action 1004 subtract $i $j" would store the value "-10" in the variable "_result".

Division is slightly different. Division will populate two variables, _result and _remainder.

action 1006 divide $j $i

If we divide 60 by 50, the value for _result would be 1, and the value for _remainder would be 10.

Increment / Decrement
These will actually increase (or decrease) the variables. The default value to increment / decrement is 1, but other values can be specified.

event manager applet I
event none
action 1000 set a 1
action 1001 puts $a
action 1002 increment a
action 1003 puts $a
action 1004 increment a 10
action 1005 puts $a

The output received when the applet runs would be:
1
2
12

Note: For the set, increment, and decrement commands, the $ is not needed, since the syntax knows that it is expecting a variable. For the puts command, the $ is needed, so that the applet knows that you are not trying to just print the letter a.

Let's take a look at some conditional loops. Say we wanted to create 100 loopbacks, with a /24 mask, and the first two octets of 192.168, a fourth octet value of 1, and a third octet value from 0 to 99.

Here, we are going to use multiple variables. We are going to nest a while loop inside another while loop, while also adding in some

examples of addition and multiplication as shown earlier. We will take the values a and b and increment them from 0 to 9. The variables a and b will both start out at 0. Variable a will stay at 0 while variable b increments from 0 to 9. For each value, we are going to create a loopback interface. Once b reaches 9, we will reset variable b to 0, and increment a.

event manager applet NEWLOOP
event none
action 1000 set a 0
action 1001 set b 0
action 1002 cli command enable
action 1003 cli command "conf t"
action 1004 while $a le 9
action 1005 while $b le 9
action 1006 multiply $a 10
action 1007 set c _result
action 1008 add $c $b
action 1009 cli command "interface loopback $_result"
action 1010 cli command "ip address 192.168.$_result.1 255.255.255.0"
action 1011 increment b
action 1012 end
action 1013 set b 0
action 1012 increment a
action 1013 end

OK, so additional variables used here include c and _result. Using the multiplication function, c will be 10 times a . After the multiplication, _result is overwritten with the value of c+b, and is used for the loopback creation. For each of the loopbacks created, the loopback number will effectively be (10*a)+b. When the conditional cycles complete, we will have 100 loopbacks, numbered from 0 to 99.

Note: We could have just used a single variable, and incremented from 0 to 99, but this example shows the usage of multiplication and addition for additional complexity.

Additional Examples
Let's take a look at some additional miscellaneous examples. According to some people, you can never be too evil when creating a practice lab.

Every 30 seconds, shut down the Fa0/0 interface, wait 10 seconds, and bring it back.

event manager applet FLAP
event timer watchdog time 30
action 1 cli command "enable"
action 100 cli command "config t"
action 101 cli command "interface Fa0/0"
action 102 cli command "shut"
action 103 wait 10
action 104 cli command "no shut"

Intercept attempts to use the "write" commands, spoof some output, and then reload the device.

event manager applet NOSAVE
event cli pattern "write" sync yes
action 111 puts "Building configuration..."
action 112 wait 5
action 113 puts "[OK]"
action 114 set _exit_status "0"
action 115 reload

Use CLI matching to prevent specific commands from running:

event manager applet NOSHSTART
event cli pattern "show start" sync no skip yes
event manager applet NOWRT
event cli pattern "write term" sync no skip yes
event manager applet NOWRE
event cli pattern "write erase" sync no skip yes

Note: The CLI detector will match patterns based on the full command, not just on what was typed. For example, "wr t" entered at the console will still be matched by the pattern "write term".

Hide applets from the running config by intercepting the "show run" command, and replacing with filtered output.

event manager applet TheseAreNotTheAppletsYou'reLookingFor
event cli pattern "show run" sync yes
action 111 cli command "enable"
action 112 cli command "show run | excl applet|event|action"
action 113 puts "$_cli_result"
action 114 set _exit_status "0"

Using EEM to create an IOS menu without using the "menu" command.

username MYUSER secret cisco
username MYUSER priv 15
username MYUSER autocommand MN
alias exec MN event manager run MYNOC
event manager applet MYNOC
event none
action 0 puts ""
action 1 puts "1 Shutdown Frame Interface"
action 2 puts "2 Bring up Frame Interface"
action 3 gets opt
action 4 if $opt eq 1 goto 800
action 5 if $opt eq 2 goto 900
action 6 if $opt ne 2 goto 1
action 800 puts "Shutting Down Frame"
action 801 cli command "enable"
action 802 cli command "config term"
action 803 cli command "interface Ser0/0/0"
action 804 cli command "shut"
action 805 cli command "end"
action 806 cli command "wr mem"
action 850 exit
action 900 puts "Bringing up Frame"
action 901 cli command "enable"
action 902 cli command "config term"
action 903 cli command "interface Ser0/0/0"
action 904 cli command "no shut"
action 905 cli command "end"
action 906 cli command "Wr mem"
action 950 exit
Jan
18

A discussion / introduction to EEM, and basic configurations.

Why EEM?
Embedded Event Manager (EEM) allows you to have event tracking and management functionality directly on the Cisco IOS device, rather than on an external device. By having the configuration locally, actions can still be taken, even if the connection to an external monitoring station is unavailable. Plus, it is a great topic that can be used to challenge (or torment) CCIE candidates.

 
EEM Components:
Let's start by taking a look at the components of EEM: EEM server, event publishers, and event subscribers.

EEM server - an internal process that handles the interaction between the publishers and subscribers.

EEM publisher (detector) - software that screens events, publishes if there is a policy match. Some of the different detectors are CLI, NetFlow, SNMP, syslog, timers and counters. Newer releases have more options available.

EEM subscriber (policy) - defines an event and actions to be taken. There are two policy types, applets and scripts. Applets are defined within CLI, scripts are written using TCL.

For this section, we are just going to look at some of the basic applet configurations, which are defined using the CLI.

Policy Creation:
Basic steps for creating a policy:

1. Select event

2. Define detector options for the event

3. Define variables (if needed)

4. Define actions (optional)

Variables will be covered more in part two. This section is focusing on events and actions.

Start off by creating the applet with the CLI command event manager applet YYY, where YYY is the applet name that you want to use.

For a basic applet configuration, we will have an event and one or more actions.

Defining the event:
For the command syntax, we have the option of just specifying an event, or specifying an event with a tag value. Newer versions allow multiple events to be specified, and the tag values are used to correlate to attribute tags. We will come back to attribute tags in a later example, for now, just be aware that if you only have a single event, the tag is optional. Here are some sample event config lines. As mentioned earlier, without tags and additional configuration, you would only have one of these lines within your applet.

event syslog pattern ".*UPDOWN.*FastEthernet1/0.*"

event none

event track 99 state any

event timer cron cron-entry "15 13 * * 1-5"

There are a variety of different event detectors. For some of these we will go into greater detail, but here is a quick list of what some of the various options watch:

cli - screening CLI input for regex

counter - watch a named counter

interface - generic interface counters / thresholds (absolute or incremental)

ioswdsysmon - watchdog - CPU / memory values/ thresholds

ipsla - watch for SLA events

nf - watch for NetFlow events

none - allows an event to be run manually

oir - hardware - online insertion removal events

resource - event from embedded resource manager

rf - dual RP - redundancy framework

routing - changes to RIB

rpc - invoke from off-box using SSH/SOAP encoding to exchange XML messages

snmp - monitor a MIB object for values / thresholds

snmp-notification - match info in trap/inform messages

syslog - screen for regex match

timer - absolute time of day, countdown, watchdog, CRON

track - Tracking object event

Note: If you do not configure an event, your applet will not show as registered, and you will receive an error message when exiting applet configuration mode.

Detectors:
Let's take a look at some of the detectors in more detail.

None
This detector will let you manually trigger, using the event manager applet YYY run command, where YYY is the name of your applet.

CLI Detector
This detector allows for regex matching of CLI input.

Some of the various options that we have within the CLI detector:

Synchronous vs. Asynchronous
With Synchronous ( sync yes), the CLI command in question is not executed until the policy exits. Whether or not the command runs depends on the value for the variable _exit_status. If _exit_status is 1, the command runs, if it is 0, the command is skipped. (More on configuring variables later in part two.)

With Asynchronous (sync no), the event is published, and is the command can be suppressed (skip yes) or executed (skip no)

Timer Detector
Some of the various options include:

absolute

countdown - counts down to 0

watchdog - counts down to 0 and then resets to initial value

CRON - uses CRON specification

For those of you not familiar with CRON, here is a basic field listing and examples:

minute - range 0 to 59
hour - range 0 to 23
day of month 1 to 31
month of year 1 to 12
day of week - 0 to 6 (Sunday is 0)

For individual fields, an asterisk represents all valid values, a comma can specify a list of values, and a hyphen can specify a range.

"1 1 1 1 *" 1:01 AM, 1 January

"1 9 * * 1-5" 9:01 AM, Monday-Friday

"5 8,16 * * 0,6" 8:05 AM or 4:05 PM, Saturday or Sunday

SNMP trap detector
watch for a trap with a specified OID.

Track detector
Watch for change in a defined track object. Can watch for going down to up (up), up to down (down), or either of those two changes (any)

Actions:
Compared to the event types, the IOS descriptions for actions are a lot more straightforward.

With multiple actions, the tags will be sorted in ascending alphanumeric (lexicographical) order, using the label. Most examples use labels like 1.0, 2.0, 3.0, but using numbers and decimal values is not required.

Here is a sample list of action commands with various tag values, as sorted by the device. Notice that numbers come before letters, and that upper case letters come before lower case. Also, notice that 11 comes before 2 in the sort order, since it is sorted by the order of the individual characters.

action ... puts "where"
action 1.0 puts "Reno"
action 11.0 puts "Today"
action 2.0 puts "EEM"
action RRR puts "ABC"
action abc puts "12345"
action nnn puts nonewline "test123"
action rrr puts "hellothere"

Action prerequisites
This may be self-explanatory, but there are times when you need to have additional configuration outside of the applet. Here are some examples, as well as items that may not already be configured.

Action:   Requirement:
Track      -  Define objects

SNMP     - Trap Basic snmp config, enable traps event-manager

Syslog     - Logging enabled

Individual Actions
OK, so let's look at some of the actions, grouped by functions:

cli - execute a CLI command

gets/puts - used to send to or pull from tty.

mail/syslog/snmp-trap/cns-event - used to send messages

increment/decrement/append - changing variables

if/else/elseif/while/end/break/continue/foreach - conditional operators

wait - pause for a period of time

track - read or set a tracking object

regexp - match

reload/force-switchover - system actions

add/subtract/multiply/divide - hopefully self-explanatory, if you have no idea what these might be used for, then perhaps you have much bigger issues than EEM to worry about.

Applet Examples:
OK, now lets take a look at some examples. Since we are focusing on the available actions, we will use the event value of none, so that we can manually run these, and don't have to wait for an event to be triggered.

Basic example to "no shut" for an interface, and save the config afterwards.

event manager applet NOSHUT

event none

action 1.0 cli command "enable"

action 2.0 cli command "config term"

action 3.0 cli command "interface Ser0/0/0"

action 4.0 cli command "no shut"

action 5.0 cli command "end"

action 6.0 cli command "write mem"

Basic track and put example. Define the Track object first, configure the applet to read the object state. Object state will be stored by default with the variable _track_state. The puts command can output the value of the variable.

track 1 stub-object
default-state down

event manager applet EOT
event none
action 110 track read 1
action 111 puts "Object 1 is $_track_state."

! Run the applet

Router#event manager run EOT

down

!

Next example, still using track and puts. Here, we want to set the value for the object as well. Even though the applet sets the state of the object, that state is not entered into the variable _track_state unless you read the value. Additional discussion on variables will be covered in part two of this blog entry.

event manager applet EOT2

event none

action 110 track set 1 state up

action 110a track read 1

action 111 puts "$_track_state"

action 112 track set 1 state down

action 112a track read 1

action 113 puts "$_track_state"

Router#event manager run EOT2

up

down

If you look at the output of show track, it will show that EEM made the state changes.

Router#show track 1

Track 1

Stub-object

State is Down

3 changes, last change 00:00:10, by EEM

Router#

Basic example using gets, puts, and wait:

event manager applet G

event none maxrun 300

action 1 gets LINE1

action 2 puts "$LINE1"

action 3 puts "start"

action 4 wait 50

action 5 puts "end wait"

action 6 gets LINE2

action 7 puts "$LINE2"

Note:  If you don't configure the "maxrun" parameter when configuring "wait", you may think the applet is broken, and you may not see the items after the wait. The default for "maxrun" is 20 seconds.

Once you have an applet defined, you may want to use it in other locations.  Here, we have the applet titled RUNTEST2 configured to call the applet TEST2 after sending a message to the tty line.

event manager applet TEST2

event none

action 1.0 cli command "enable"

action 2.0 cli command "config term"

action 3.0 cli command "interface Ser0/0/0"

action 4.0 cli command "no shut"

action 5.0 cli command "end"

action 6.0 cli command "write mem"

event manager applet RUNTEST2

event none

action 1 puts "Enabling Ser0/0/0 Interface"

action 2 policy TEST2

Router#event manager run RUNTEST2

Enabling Ser0/0/0 Interface
Router#

Jan 18 12:15:57.063: %SYS-5-CONFIG_I: Configured from console by on vty0 (EEM:TEST2)

Router#

Jan 18 12:15:59.071: %LINK-3-UPDOWN: Interface Serial0/0/0, changed state to up

Router#

Jan 18 12:16:00.131: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0, changed state to up

Router#

As mentioned earlier, the variable "_exit_status" can be used with synchronous CLI events. Here, we are setting the exit status to 0, so that the command isn't run. In addition, a syslog message with priority 0 is configured.

event manager applet NOSAVE
event cli pattern "write mem.*" sync yes
action 1.0 syslog priority emergencies msg "Not Allowed"
action 2.0 set _exit_status "0"

For asynchronous events, you can determing whether the command runs (skip no), or doesn't run (skip yes) keyword options within the event command. Here, we have an applet that is setting a syslog message, and is not allowing the command to execute.

event manager applet NOSAVE2
event cli pattern "write mem.*" sync no skip yes
action 1.0 syslog priority emergencies msg "NO!"

As mentioned earlier, it is possible to have an event without an action. You may receive a warning message that you do not have an action configured, but the event will still trigger. In the case below, the CLI interception will prevent someone from using the write mem command.

event manager applet NOSAVE2
event cli pattern "write me.*" sync no skip yes

More examples, in addition to some more complex configurations, will be covered in part two.

Oct
20

Even more updates have been posted to the IP Services section of the CCIE Routing & Switching Lab Workbook Volume 1 Version 5.0. Yes, that’s right, two in two days ;) The following topics are now available in System Management:

12.1 Exec Aliases
12.2 System Message Logging
12.3 Syslog Logging
12.4 Logging Counting and Timestamps
12.5 Logging to Flash Memory
12.6 Configuration Change Notification and Logging
12.7 Configuration Archive & Rollback
12.8 Logging with Access-Lists
12.9 TCP Keepalives
12.10 Generating Exception Core Dumps
12.11 Conditional Debugging
12.12 Telnet Service Options
12.13 Tuning Packet Buffers
12.14 Terminal Line Settings
12.15 SNMPv2c Server
12.16 SNMPv2c Access Control
12.17 SNMP Traps and Informs
12.18 CPU and Memory Thresholds
12.19 SNMPv3
12.20 SNMP MAC Address Notifications
12.21 SNMP Notifications of Syslog Messages
12.22 CDP
12.23 RMON Alarms
12.24 RMON Statistics Collection
12.25 HTTP Server and Client
12.26 FTP Server and Client
12.27 TFTP Server and Client
12.28 Remote Shell
12.29 NTP
12.30 NTP Authentication
12.31 NTP Access Control
12.32 Auto-Install over LAN Interfaces using DHCP
12.33 Auto-Install over Frame-Relay
12.34 Auto-Install over LAN Interfaces using RARP
12.35 IOS Menus
12.36 IOS Banners
12.37 KRON Command Schedule

Some minor changes were made today to the IP Services labs that were posted yesterday. So if you have the version from yesterday you should re-download the current version again.

The following topics are now 100% available:

1. Bridging & Switching
2. Frame Relay
3. IP Routing
4. RIP
5. EIGRP
12. System Management
13. IP Services

QoS will start getting posted this week as well incrementally. As always product access is available through the http://members.internetworkexpert.com site, and technical discussion should be held on www.IEOC.com.

Please keep your feedback coming in and let me know if there are any bugs with the material. Also if anyone has problems with the initial config files let me know, there were some corrupt files apparently when they were changed from DOS to UNIX formatting.

Happy Labbing!

Jul
29

NTP security goal is to prevent unauthorized time sources to affect time synchronization within a set of network devices. Cisco IOS offers two methods of securing NTP infrastructure:

1) NTP Access Control. Limit types of NTP access and NTP sources associating with out router.
2) NTP Authentication. Validate the identity of NTP sources.

Let’s see how access control works. It is convenient to classify NTP messages in two types:

1) Control messages. Documented in RFC 1305 Appendix B, serve the purpose, usually fulfilled by SNMP. Without digging into any details, let’s just say the control messages are for reading and writing internal NTP variables and obtaining NTP status information. Not to deal with time synchronization itself.
2) NTP request/update messages. Those are used for actual time synchronization. Request packet obviouly asks for synchronization information, and update packet contains synchronization information, and may change local clock.

IOS router defines the following four types of access for NTP:

1) Peer – permits router to respond to NTP requests and accept NTP updates. NTP control queries are also accepted. This is the only class which allows a router to be synchronized by other devices.
2) Serve – permits router to reply to NTP requests, but rejects NTP updates (e.g. replies from a server or update packets from a peer). Control queries are also permitted.
3) Serve-only – permits router to respond to NTP requests only. Rejects attempt to synchronize local system time, and does not access control queries.
4) Query-only – only accepts NTP control queries. No response to NTP requests are sent, and no local system time synchronization with remote system is permitted.

IOS router may associate an access-list with any of the above access-types, classifying NTP message sources by their types. Two rules are observed by IOS when an incoming NTP packet is matched against configured types of access:

1) All access-groups associated with access types are scanned in the ordrer presented above (from 1 to 4) – that is, following from most permissive to most restrictive. The first match is used to determine the message source access type.
2) If any of the access types has been defined with an ACL, all other access types are implicitly denied. Just by restricting some sources, you may effectively block all others as well

Now here is a catch. If your router is configured as NTP master, and you set up any access-control group, you must allow “peer” access type to a source with IP address “127.127.7.1”. This is because “127.127.7.1” is the internal server created by ntp master command, which the local router synchronizes to. If you forget to enable it peer access, your server will always be out of sync. Here are some examples. First one: configure R1 as NTP master and allow the server to be polled for NTP updates just by one client. Client should receive updates just from one source:

R1:
access-list 1 permit 127.127.7.1
access-list 2 permit 150.1.2.2
ntp master
ntp access-group peer 1
ntp access-group serve-only 2

R2:
access-list 1 permit 150.1.1.1
ntp source Loopback0
ntp access-group peer 1
ntp server 150.1.1.1

A more complicated example. R1 and R3 are both NTP masters, peering via NTP. R2 is a client to both of them. Configure so that R1 and R3 only allow R2 to poll themselves for time updates, and allow synchronizing each other. Correspondingly, R2 should only accept NTP updates from R1 or R3.

R1:
access-list 2 permit 150.1.2.2
access-list 3 permit 150.1.3.3
access-list 3 permit 127.127.7.1
ntp master
ntp access-group serve-only 2
ntp access-group peer 3
!
! The following is needed to poll our peer from
! a consistent source IP address
!
ntp source Loopback0
ntp peer 150.1.3.3

R3:
access-list 2 permit 150.1.2.2
access-list 1 permit 150.1.1.1
access-list 1 permit 127.127.7.1
ntp master
ntp access-group serve-only 2
ntp access-group peer 1
ntp source Loopback0
ntp peer 150.1.1.1

R2:
access-list 13 permit 150.1.1.1
access-list 13 permit 150.1.3.3
ntp source Loopback0
ntp access-group peer 13
ntp server 150.1.1.1
ntp server 150.1.3.3

Some show commands output for the last example:

Rack1R1#show ntp associations detail
150.1.3.3 configured, selected, sane, valid, stratum 8
ref ID 127.127.7.1, time D2AA2222.362546B9 (00:06:58.211 UTC Sun Jan 1 2012)
our mode active, peer mode active, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.05, reach 377, sync dist 12.466
delay 24.70 msec, offset 0.0294 msec, dispersion 0.05
precision 2**18, version 3
org time D2AA2222.363128BC (00:06:58.211 UTC Sun Jan 1 2012)
rcv time D2AA2222.395A8A9D (00:06:58.224 UTC Sun Jan 1 2012)
xmt time D2AA221C.BA22B989 (00:06:52.727 UTC Sun Jan 1 2012)
filtdelay = 24.77 24.70 24.69 24.69 24.81 24.78 25.16 24.60
filtoffset = 0.01 0.03 0.01 0.01 0.07 0.02 0.30 0.04
filterror = 0.02 0.03 0.05 0.06 0.08 0.09 0.11 0.12

127.127.7.1 configured, our_master, sane, valid, stratum 7
ref ID 127.127.7.1, time D2AA224F.BA0A656E (00:07:43.726 UTC Sun Jan 1 2012)
our mode active, peer mode passive, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.00, reach 17, sync dist 0.015
delay 0.00 msec, offset 0.0000 msec, dispersion 0.02
precision 2**18, version 3
org time D2AA224F.BA0A656E (00:07:43.726 UTC Sun Jan 1 2012)
rcv time D2AA224F.BA0A656E (00:07:43.726 UTC Sun Jan 1 2012)
xmt time D2AA224F.BA09890A (00:07:43.726 UTC Sun Jan 1 2012)
filtdelay = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
filtoffset = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
filterror = 0.02 0.99 1.97 2.94 15995.3 15995.3 15995.3 15995.3
Reference clock status: Running normally
Timecode:

Rack1R3#show ntp associations detail
150.1.1.1 configured, selected, sane, valid, stratum 8
ref ID 127.127.7.1, time D2AA224F.BA0A656E (00:07:43.726 UTC Sun Jan 1 2012)
our mode active, peer mode active, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.03, reach 376, sync dist 13.474
delay 24.70 msec, offset 0.0428 msec, dispersion 0.84
precision 2**16, version 3
org time D2AA2252.BA44EC9D (00:07:46.727 UTC Sun Jan 1 2012)
rcv time D2AA2252.BD81F301 (00:07:46.740 UTC Sun Jan 1 2012)
xmt time D2AA2262.362614E6 (00:08:02.211 UTC Sun Jan 1 2012)
filtdelay = 24.99 24.70 24.69 25.02 24.70 24.67 24.67 24.66
filtoffset = -0.15 0.04 -0.06 0.16 -0.04 -0.04 0.03 -0.02
filterror = 0.75 0.76 0.78 0.79 0.81 0.82 0.84 0.85

127.127.7.1 configured, our_master, sane, valid, stratum 7
ref ID 127.127.7.1, time D2AA2263.362511B6 (00:08:03.211 UTC Sun Jan 1 2012)
our mode active, peer mode passive, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.00, reach 377, sync dist 0.015
delay 0.00 msec, offset 0.0000 msec, dispersion 0.02
precision 2**18, version 3
org time D2AA2263.362511B6 (00:08:03.211 UTC Sun Jan 1 2012)
rcv time D2AA2263.362511B6 (00:08:03.211 UTC Sun Jan 1 2012)
xmt time D2AA2263.36244305 (00:08:03.211 UTC Sun Jan 1 2012)
filtdelay = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
filtoffset = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
filterror = 0.02 0.99 1.01 1.02 1.04 1.05 1.07 1.08
Reference clock status: Running normally
Timecode:

Rack1R2#show ntp associations detail
150.1.1.1 configured, our_master, sane, valid, stratum 8
ref ID 127.127.7.1, time D2AA224F.BA0A656E (00:07:43.726 UTC Sun Jan 1 2012)
our mode client, peer mode server, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.03, reach 17, sync dist 2924.316
delay 92.15 msec, offset -814906.4035 msec, dispersion 2877.85
precision 2**16, version 3
org time D2AA225B.921F769B (00:07:55.570 UTC Sun Jan 1 2012)
rcv time D2AA258A.85F5230D (00:21:30.523 UTC Sun Jan 1 2012)
xmt time D2AA258A.6E599935 (00:21:30.431 UTC Sun Jan 1 2012)
filtdelay = 92.15 90.97 90.84 136.81 0.00 0.00 0.00 91.34
filtoffset = -814906 -814908 -814909 -814886 0.00 0.00 0.00 2.22
filterror = 0.02 0.99 1.97 2.94 16000.0 16000.0 16000.0 7.83

150.1.3.3 configured, selected, sane, valid, stratum 8
ref ID 127.127.7.1, time D2AA2263.362511B6 (00:08:03.211 UTC Sun Jan 1 2012)
our mode client, peer mode server, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.05, reach 377, sync dist 13.916
delay 24.57 msec, offset -814905.7885 msec, dispersion 1.59
precision 2**18, version 3
org time D2AA2273.89780E2F (00:08:19.536 UTC Sun Jan 1 2012)
rcv time D2AA25A2.747F40E8 (00:21:54.455 UTC Sun Jan 1 2012)
xmt time D2AA25A2.6E3030A3 (00:21:54.430 UTC Sun Jan 1 2012)
filtdelay = 24.57 24.73 24.70 24.84 24.64 24.75 24.55 24.67
filtoffset = -814905 -814907 -814907 -814907 -814907 -814907 -814907 -814907
filterror = 0.02 0.99 1.01 1.02 1.04 1.05 1.07 1.08

Jul
19

The tutorial presented below is a small excerpt from the "System Management" section of beta IEWB-RS Vol I version 5.

SNMPv3 protocol a security model, defining new concepts to replace the old community-based pseudo-authentication and provide communication privacy by means of encryption. The new concepts are: user, group and security level. A group defines the access policy for a set of users. An access policy defines which SNMP objects can be accessed for reading and writing or which SNMP objects can generate notifications to the members of a group. Policy is defined by associating the respective read, write or notify view with a group. By using a notify view, a group determines the list of notifications its users can receive. A group also defines the security model and security level for its users.

Essentially, all groups form a table, which maps users to their read/write/notify views and security models. Note that if a group is defined without a read view than all objects are available to read. Contrary to that, if no write or notify view is defined, no write access is granted and no objects can send notifications to members of the group. The notify view is usually not configured manually. Rather, it’s added by the snmp-server host command automatically, when a users in a group is bound to a notification target host. Note that SNMP will use the username configured with snmp-server host along with the security model specified to authenticate and possibly encrypt the notifications. If the security model is set to «noauth» then a plain username is sent in a manner resembling the old community string.

The following security models exist: SNMPv1, SNMPv2, SNMPv3. The following security levels exits: “noAuthNoPriv” (no authentiation and no encryption – noauth keyword in CLI), “AuthNoPriv” (messages are authenticated but not encrypted – auth keyword in CLI), “AuthPriv” (messages are authenticated and encrypted – priv keyword in CLI). SNMPv1 and SNMPv2 models only support the “noAuthNoPriv” model since they use plain community string to match the incoming packets. The SNMPv3 implementations could be configured to use either of the models on per-group basis (in case if “noAuthNoPriv” is configured, username serves as a replacement for community string). All users sharing a group utilize the same security model, however, the specific model settings (password, encryption key) are sep per-user. Note that SNMPv3 does not send passwords in clear-text and uses hash-based authentication with either MD5 or SHA1 functions (HMAC authentication – the packet conted is hashed along with authentication key to produce the authentication string). For encryption, statically configured keys are used along with DES56 symmetric cipher (that mean the same key should be configured on NMS for the particular user).

Consider the example below. Three groups are created. Groups «NORMAL» and «RESTRICTED» are used to control remote users access and group «TRAP» is used to send notifications. Note that only read-view is specified for group "RESTRICTED" and it's limited to IfEntry fields for a fixed interface index. The group «RESTRICTED» has an access-list applied to control the NMS stations the users can access from. Note that the groups have different security levels. Next, three users are created, one for each group respectively, with their authentication and encryption keys. Finally, SNMP link up and down notifications are enabled and SNMP trap destination host is configured. This operation automatically creates and assigns the «notify» view for the respective group (will appear in show commands output below).

!
! Access-List to control users in the RESTRICTED group.
!
access-list 99 permit 155.1.146.0 0.0.0.255

!
! Set ifIndexes persistent, for view definition is based on IfIndexes
!
snmp-server ifindex persist

!
! The first view covers the “ISO” sub-branch and the second one covers
! all “lifEntry” fields for interface with IfIndex 3 (Serial 0/0).
!
snmp-server view NORMAL iso included
snmp-server view RESTRICTED ifEntry.*.3 included

!
! Define three groups. The first one allows to read and write
! into a large portion of the MIB tree. The second one allows reading
! just information specific to Serial 0/0 interface, and limits user
! access based on access-list
!
! The third group is for sending traps. A user belonging to this group
! will be utilized to send trap messages. Its name and password
! will be used to create authentication credentials in a trap message
! and the users privacy password will be used to encrypt the packet.
! Note that this group has NO notify view defined, which is done on
! on purpose. The notify view will be automatically populated when
! notification hosts are configured and bound to users
!

snmp-server group NORMAL v3 priv read NORMAL write NORMAL
snmp-server group RESTRICTED v3 auth read RESTRICTED access 99
snmp-server group TRAP v3 priv

!
! Users, their passwords and encryption keys are defined now
!
snmp-server user NORMAL NORMAL v3 auth sha CISCO priv des56 CISCO
snmp-server user RESTRICTED RESTRICTED v3 auth sha CISCO
snmp-server user TRAP TRAP v3 auth sha CISCO priv des56 CISCO

!
! Allow sending traps and configure a destination host. Note that when
! a host is configured and bound to SNMPv3 username, the corresponding
! group notify view is populated based on traps allowed for this
! particular destination. This is why it’s not required to configure
! the notify view for a group.
!
snmp-server enable traps snmp linkup linkdown
snmp-server host 155.1.146.100 traps version 3 priv TRAP

Perform some basic verifications next using the show commands. Note that SNMPv3 users do not appear in the running configuration for security reason (different management channel) but you can see some information using show snmp users command. Also, pay attention to the automatic view assigned to the “TRAP” group.

Rack1R6#show snmp user 

User name: TRAP
Engine ID: 80000009030000119221DA80
storage-type: nonvolatile active
Authentication Protocol: SHA
Privacy Protocol: DES
Group-name: TRAP

User name: NORMAL
Engine ID: 80000009030000119221DA80
storage-type: nonvolatile active
Authentication Protocol: SHA
Privacy Protocol: DES
Group-name: NORMAL

User name: RESTRICTED
Engine ID: 80000009030000119221DA80
storage-type: nonvolatile active
Authentication Protocol: SHA
Privacy Protocol: None
Group-name: RESTRICTED

Rack1R6#show snmp group
groupname: ILMI security model:v1
readview : *ilmi writeview: *ilmi
notifyview:
row status: active

groupname: ILMI security model:v2c
readview : *ilmi writeview: *ilmi
notifyview:
row status: active

groupname: TRAP security model:v3 noauth
readview : writeview:
notifyview: *tv.FFFFFFFF.FFFFFFFF.FFFFFFFF0F
row status: active

groupname: TRAP security model:v3 priv
readview : v1default writeview:
notifyview:
row status: active

groupname: NORMAL security model:v3 priv
readview : NORMAL writeview: NORMAL
notifyview:
row status: active

groupname: RESTRICTED security model:v3 auth
readview : RESTRICTED writeview:
notifyview:
row status: active access-list: 99

Rack1R6#show snmp view
*ilmi system - included permanent active
*ilmi atmForumUni - included permanent active
NORMAL iso - included nonvolatile active
v1default iso - included permanent active
v1default internet.6.3.15 - excluded permanent active
v1default internet.6.3.16 - excluded permanent active
v1default internet.6.3.18 - excluded permanent active
v1default ciscoMgmt.394 - excluded permanent active
v1default ciscoMgmt.395 - excluded permanent active
v1default ciscoMgmt.399 - excluded permanent active
v1default ciscoMgmt.400 - excluded permanent active
RESTRICTED ifEntry.0.3 FF:EF included nonvolatile active
*tv.FFFFFFFF.FFFFFFFF.FFFFFFFF0F iso.2.840.10036 - included volatile active
*tv.FFFFFFFF.FFFFFFFF.FFFFFFFF0F internet - included volatile active

Feb
03

When you work with a remote rack by using an access-server (e.g. 25xx) with the async lines connected to the console ports of the pod's routers, you effectively have only one terminal window opened. Using ctrl-Shift-6-x you can quickly switch between terminal lines; however, if you need to monitor "debug" command output on one terminal line, while performing some activity on the other you may face some difficulties.

For example, when you enable debug crypto isakmp on one router, and then switch to the other router, to generate packets with ping command, you may lose some of the debugging output, while switching back to the original router. Two obvious ways to resolve this issue exist: first one - open multiple terminal windows; next one - use logging buffered command to collect the debug logs into logging buffer. The third, not so well-known way to cope with the issue, is to use service telnet-zeroidle command on the access server.

What this command does, is announces TCP receive window with the value of zero for "idle" (currently non-active) connections. How does this work? When a TCP "server" is told that the other side's TCP receive window is zero, the server starts buffering data to be send, until the other side "un-shrinks" the window again. Now, since all sessions from an access-server are effectively reverse-telnet connections to the access-server itself, by advertising TCP window value of zero, we make access-server buffer router's console output (e.g. from debug commands), until the respective session becomes active again. In effect, with service telnet-zeroidle enabled, you may start, say, debug crypto isakmp on one router, switch to other, type ping x.x.x.x, then get back to the original router just to grab all the debug output at once - without any loss! Just make sure, your large debugging output runs fit into TCP xmit buffer, and don’t be scared by flood of output when you get back to an idle connection!

Dec
29

Hi Brian,

How do I switch between devices when using a Cisco access server?

There are two ways to connect to devices attached to an access server, you can terminate your exec session on the access server itself (one terminal window for all sessions), or you can terminate your exec session on the device connected to the access server (one terminal window for each session). In the CCIE Lab Exam you will have the option to do either, so pick whichever method works best for you and stick with it during your preparation.

When you terminate your exec session on the access server you then "reverse telnet" to the individual devices connected to the access server. Normally to do this you first login to the access server and then issue the "show hosts" command to see the host mappings. Next, reverse telnet to them by typing the hostname and pressing enter. To get back to the access server issue the escape sequence CTRL-SHIFT-6-X. To do so hold ctrl and shift, hit 6, release all keys, then hit X. From the access server you can then open new connections or resume connections that you already have open.

When you terminate your exec session on the device connected to the access server, i.e. by telnetting to the access server at port 2001, you cannot issue the escape sequence to reconnect to the access server. In this situation you would open multiple terminal windows if you wanted to connect to multiple devices.

For more information watch this class-on-demand video on using an access server.

Dec
28

Hi Brian,I configured NTP on 2 Routers back-to-back with authentication (md5). So far everything works fine. I removed authentication on one of the Routers (no ntp authenticate) and they continue to sync. I even rebooted the router on which I had removed the authentication and they still sync. Any ideas why?

A common misconception about NTP authentication is the direction in which authentication occurs, however it makes perfect sense if you ask yourself this question: what is the purpose of using NTP authentication?

One clear answer is that authentication is used to prevent tampering with the timestamps on the logs generated by devices. To implement an attack on NTP, a hacker would make their rogue host appear to be a valid NTP server. NTP authentication is therefore used to authenticate the time source, not the client.

Take the following scenario:

R1--12.0.0.0/8--R2

R1 and R2 share the segment 12.0.0.0/8. R1 is the NTP master, and R2 is the client. To get a better understanding of how NTP authentication works, try the following possible configurations and see which of them work and which of them do not.

Case 1: No authentication

R1#sh run | in ntp
ntp master 1

R2#sh run | in ntp server
ntp server 12.0.0.1

R2#sh ntp status | in synch
Clock is synchronized, stratum 2, reference is 12.0.0.1

R2#show ntp associations detail
12.0.0.1 configured, our_master, sane, valid, stratum 1

Case 2: Authentication on server, no authentication on client

R1#sh run | in ntp
ntp authentication-key 1 md5 121A0C041104 7
ntp authenticate
ntp master 1

R2#sh run | in ntp
ntp clock-period 17179863
ntp server 12.0.0.1

R2#sh ntp status | in sync
Clock is synchronized, stratum 2, reference is 12.0.0.1

R2#sh ntp assoc detail
12.0.0.1 configured, our_master, sane, valid, stratum 1

Case 3: No authentication on server, authentication on client

R1#sh run | in ntp
ntp master 1

R2#sh run | in ntp
ntp authentication-key 1 md5 08701E1F28492647465A5D547E 7
ntp authenticate
ntp trusted-key 1
ntp clock-period 17179863
ntp server 12.0.0.1 key 1

R2#sh ntp status | in sync
Clock is unsynchronized, stratum 16, no reference clock

R2#sh ntp assoc detail
12.0.0.1 configured, insane, invalid, unsynced, stratum 16

Case 4: Authentication on server and client

R1#sh run | in ntp
ntp authentication-key 1 md5 0822455D0A16 7
ntp authenticate
ntp master 1

R2#sh run | in ntp
ntp authentication-key 1 md5 060506324F41 7
ntp authenticate
ntp trusted-key 1
ntp clock-period 17179865
ntp server 12.0.0.1 key 1

R2#sh ntp status | in sync
Clock is synchronized, stratum 2, reference is 12.0.0.1

R2#sh ntp assoc detail
12.0.0.1 configured, authenticated, our_master, sane, valid, stratum 1

As shown by the above configuration, NTP authentication is used to authenticate the NTP source, not any associated clients.

Subscribe to INE Blog Updates

New Blog Posts!