CLN Video

Router Time Sources

Most Cisco routers have a hardware and software clock, which can be managed separately. The following two sections discuss these two clocks.

Hardware Clock

The hardware clock, often called a system calendar clock, is a battery-powered clock that keeps track of the date and time even when the router is powered off. Most routers have a hardware clock. If no other time source is available, the router uses its hardware clock to provide the date and time. Because the clock is powered by a battery, if the battery dies, the clock defaults to a hard-configured date and time, as shown here:

00:00:00.000 UTC Mon Mar 1 1993

Software Clock

The router’s software clock is the primary source for the date and time. It begins when the router starts up and ends when the router shuts down. Initially, the software clock gets the date and time from the hardware clock, when the router is booting up; however, the software clock can get its date and time from a number of sources, including these:

• NTP
• Simple Network Time Protocol (SNTP)
• CLI commands

Because the software clock can be updated dynamically from a more reliable source, like NTP, it typically has a more accurate date and time than the hardware clock.

The router uses the software clock to provide the date and time to the following services:

• The hardware clock
• NTP, if the router is an NTP server
• Log messages
• Debug messages
• Various show commands
• Time ranges in ACLs

The default time zone of the software clock is Coordinated Universal Time (UTC), which also is referred to as Greenwich Mean Time (GMT). However, you can override this with a manual configuration, in which you can specify the router’s time zone as well as daylight savings time, sometimes referred to as summer time.

Manual Time and Date Configuration

If the hardware clock’s battery is dead and you have no other time source to synchronize your router with, you can manually configure the current date and time after the router boots up. However, you should use this only as a last resort because you would have to change the time setting manually every time the router reboots. The following sections discuss how to configure your router’s time settings manually.

Time Zone

As I mentioned at the beginning of this section, the default time zone is UTC. To change the time zone, use the clock timezone command, shown here:

Router(config)# clock timezone zone_name hours_offset

  [minutes_offset]

The zone_name parameter is the name of time zone. This is the standard acronym, such as EST for Eastern Standard Time. The hours_offset parameter is the number of hours, plus or minus, different from UTC. For example, New York City would be ?5. Typically, the minutes_offset parameter is not used; however, certain time zones, such as Atlantic Canada Standard Time (AST) is 3.5 hours different from UTC. This is represented as ?3 30. Here is a simple example for setting the time zone for a router in Orlando, Florida:

Router(config)# clock timezone EST -5

Daylight Saving Time

If your time zone follows daylight saving time (DST), commonly referred to as summer time, you can configure this setting on your router with the clock summer-time command. If your time zone uses the standard times and dates for the beginning and end of the summer time clock change, you can use this command to set up DST:

Router(config)# clock summer-time zone_name recurring

  [1-4 | first | last] [day month hh:mm day month hh:mm [offset_value]]

After you specify the name of the time zone, specify which week the time change occurs: 1 through 4 is the number of the week, first is the first week of the month, and last is the last week. If you do not specify the week, day, month, and time, it defaults to the standard for the time change. Likewise, if you omit the offset value, it defaults to 60 minutes, which is added to the current time when the first time is reached in the spring, and then is subtracted from the current time when the second time is reached in the fall. Here is a simple example, using the default settings, for Orlando, Florida:

Router(config)# clock summer-time EDT recurring

If your router uses nonstandard days for changing your clock’s time, use either of the following two commands:

Router(config)# clock summer-time zone_name date

  month day year hh:mm month day year hh:mm [offset]

or:

Router(config)# clock summer-time zone_name date

  day month year hh:mm day month year hh:mm [offset]

With these two commands, you must specify the exact date and time when summer time begins and ends.

Software Clock Settings

If your router’s software clock is synchronized to an external time source, such as an NTP server, it is not necessary to configure the software clock’s time settings manually. However, if your router is not synchronized to an external time source, you can manually change the time on the router to set it correctly. This is accomplished with either of the following privileged EXEC commands:

Router# clock set hh:mm:ss date month year

or:

Router# clock set hh:mm:ss month date year

Here is a simple example:

Router# clock set 12:34:00 November 19 2003

If you want to resynchronize the software clock with the hardware clock, use this command:

Router# clock read-calendar

To view the time and date of the software clock, use the show clock command, as in Example 18-10.

Example 18-10. Viewing the Date and Time of the Software Clock

Router# show clock

12:34:58.015 EST Wed Nov 19 2003

The show clock detail command displays the current time as well as your clock settings, as shown in Example 18-11.

Example 18-11. Using the show clock detail Command

Router# show clock detail

12:35:51.431 EST Wed Nov 19 2003

Time source is user configuration

Summer time starts 02:00:00 EST Sun Apr 4 2004

Summer time ends 02:00:00 EDT Sun Oct 31 2004

Hardware Clock Settings

Normally, the only time that the hardware clock is used is initially to give the software clock the correct date and time when the router boots up. After this, the software clock is responsible for ensuring that the hardware clock is updated with the correct time. This way, if you are using NTP and the clock battery in your router is dead, NTP will update the software clock, which, in turn, updates the hardware clock with the correct date and time. The software clock does this at regular intervals.

To change the time of the hardware clock manually, use either of the two following commands:

Router# calendar set hh:mm:ss day month year

or:

Router# calendar set hh:mm:ss month day year

Note that the calendar set command is not supported on all router models. Use the show calendar command to view the time of the hardware clock.

To set the hardware clock from the software clock, use the following command:

Router# clock update-calendar

Network Time Protocol Overview

NTP, which runs on top of UDP, is an IP protocol used to synchronize time across devices in a network. NTP supports three versions; the newest version, version 3, is defined in RFC 1305. NTP uses a client/server function.

Time Distribution

The server is an authoritative source of time and, as such, should have the most correct time among all devices. This can be supplied by a radio or atomic clock, or even a GPS device. NTP uses the term stratum to describe how many hops away the source of time is. For example, a stratum 1 time source is the NTP master server with a reliable clocking mechanism that the server uses to derive time. Each part of your network might have an additional NTP server. These servers are stratum 2 time sources because they derive their time from the NTP master server. The servers are responsible for giving the time to other lower-stratum servers as well as clients.

Distribution of time can be accomplished by the server periodically broadcasting the time or the client requesting the time periodically from the server. When the broadcast method is used in a Layer 2 network, it ensures that, because only one packet is sent, all devices typically have the same time, within a millisecond or so of each other. However, broadcasting has two problems:

• It is easy to spoof, so your timing information could be corrupted.
• It does not work well in a Layer 3 network.

Because of these problems, most NTP implementations have the clients periodically request the time from the server. NTPv3 does support authentication, which greatly reduces the likelihood that a spoofing attack will occur on your timing infrastructure; however, this feature is supported only in client polling, not broadcasting.

Simple Network Time Protocol

A simplified form of NTP, called the Simple Network Time Protocol (SNTP), can be used on clients to derive time, but not to pass time to other devices. For example, when using SNTP, the old (and discontinued) Cisco 1000 series routers, can only accept time from an NTP server; they cannot, in turn, pass the timing information to devices behind them. Unlike the NTP distribution method, SNTP typically provides accuracy of time within 100 milliseconds, and it does not support authentication (NTPv3). Because of these limitations, SNTP should be used only if your router does not support NTPv3.

The remaining part of this section deals with how to configure NTP on your router. I focus on three areas: how to configure your router as a client, how to configure your router as a server, and how to verify your NTP configuration.

Router Client Configuration for NTP

By default, NTP is disabled on all your router’s interfaces. Your router, acting as a client, can use two methods to gain the most up-to-date time from an NTP server: periodically polling an NTP server or listening for periodic broadcasts from NTP servers. The following two sections discuss the configuration of both of these services.

Poll-Based Configuration

Clients can use two different polling modes to acquire their timing information from NTP servers:

• Client mode
• Symmetric active mode

In client mode, the client polls all NTP servers in its configuration for the time and then picks one server to use. This mode is a client/server mode, with the router acting as a client. This mode typically is used if the router will not be sending time to other devices. The ntp server command is used to specify the information to access the NTP servers.

In symmetric active mode, the router polls the configured time servers for the current time and also sends time to time servers. This mode typically is used to synchronize the group of NTP servers themselves at the same stratum level. The ntp peer command is used to specify the other NTP server peers of the router.

Here is the router command to define other NTP servers:

Router(config)# ntp {server | peer} IP_address [version number]

  [key keyid] [source interface] [prefer]

If the router is functioning as only a client, use the server parameter; otherwise, if the router is acting as a server and is peering to other servers, use the peer parameter. Following this is the IP address of the remote NTP server. If you do not specify the version number for NTP, it defaults to 3 (NTPv3). The optional keyid parameter references authentication information to be used to verify the server or peer’s timing communications. I discuss this later. The source parameter specifies what IP address on the router to use as the source address in the IP packet header when sending communications to the remote NTP server. If you omit this parameter, it defaults to the address of the outgoing interface. When you are entering multiple NTP servers, you can use the prefer parameter, which specifies that this NTP server is preferred over other servers for synchronization purposes.

Broadcast-Based Configuration

Broadcast-based synchronization is preferred in larger Layer 2 networks, especially in networks where bandwidth, memory, and CPU resources are limited. Only one mode exists for broadcast-based configuration: broadcastclient mode. Unlike poll-based synchronization, in broadcastclient mode, the client passively listens for NTP broadcasts from an NTP server. Obviously, for this to work, the client and server must be in the same subnet. Enabling broadcastclient mode is done under a router’s interface:

Router(config)# interface type [slot_#/]port_#

Router(config-if)# ntp broadcast client

Router(config-if)# ntp broadcastdelay microseconds

Enable this command only on the interface(s) on which you have NTP servers, to reduce the likelihood of an NTP server spoofing attack. The ntp broadcast client command enables the NTP client function on the specified interface to accept time broadcasts from NTP servers. The ntp broadcastdelay command is optional. By default, the router compensates for the time delay between the NTP server and the router by adding 3000 microseconds to the NTP servers’ advertised time, to adjust for travel delay. You can change this to more accurately affect the delay. This value ranges from 1 to 999,999 microseconds.

SNTP Configuration

SNTP should be used only on routers that do not provide support for NTP. Some Cisco routers that do not provide support for NTP are the 1000, 1600, and 1700 series, depending on the software version running on them.

If your router will be polling the NTP server periodically, use this command:

Router(config)# sntp server {IP_address | hostname} [version number]

You need to specify only the IP address or hostname of the NTP server. The version number defaults to 1 if you omit it.

If your router will be using time synchronization broadcasts from an NTP server, use this command:

Router(config)# sntp broadcast client

Router Server Configuration for NTP

Besides performing client functions, a router can be an NTP server. This is very useful in remote office environments, in which the perimeter router at these locations can function as both a client and a server, acquiring timing information from the corporate NTP servers and then, acting as a server, passing this information to the remote office devices behind it.

Distributing Timing Information

I already discussed how to set up peer relationships between routers acting as NTP servers at the same stratum level (ntp peer command), as well as how a router can access timing information directly from a server at a higher level (ntp server command).

If your router, acting as an NTP server, will be using broadcasts to disseminate timing information, you need to configure the following command on each interface where you want your router to advertise its time synchronization information:

Router(config)# interface type [slot_#/]port_#

Router(config-if)# ntp broadcast [version number]

If you omit the version, it defaults to 3 (NTPv3).

Configuring an External Clock

As I mentioned at the beginning of the “Time Distribution” section, you can have your router act as an NTP server and obtain clocking information from an externally attached device. You would choose this option if you want your router to be the master NTP server in your network.

Cisco does not support stratum level 1 clocking services, such as atomic or radio clocks; however, it does support certain GPS-based devices (stratum level 2) that you can attach to your router. Your router then can use these devices to obtain timing information, which, in turn, can be redistributed through NTP. When attaching a GPS to a Cisco router, you need a free line. Typically, most administrators do not use the auxiliary port on the router for WAN or CLI communications, so you can attach the GPS device to this.

Not all routers support the attachment of an external clock to them. Cisco supports two types of GPS clocks:

• Trimble Palisade NTP synchronization kit (works only with the 7200 series routers)
• Symmetricom (Telecom-Solutions) GPS clock kit (works only with certain router models)

If you have the Trimble GPS clock and are attaching it to the auxiliary port of a 7200 router, you need to configure the following on your router:

Router(config)# line aux 0

Router(config-line)# ntp refclock trimble pps none stratum 1

The ntp refclock command tells the 7200 that it has a Trimble GPS clock attached. The pps parameter indicates the type of pulse-per-second reference support: In the case of Trimble, this is set to none. Because this is probably the root time source for your network, you define the time source as a stratum service level of 1.

If you are connecting a Symmetricom GPS product to your router’s auxiliary port or TTY line, you use the following configuration:

Router(config)# ntp refclock telecom-solutions pps {cts | ri | none}

   [inverted] [pps-offset number]

   [stratum number] [timestamp-offset number]

Depending on the Symmetricom GPS product, you need to choose the pulse-per-second (PPS) option as either CTS, RI, or none. The inverted option indicates that the PPS pulse is inverted; the pps-offset option indicates the PPS pulse offset, in milliseconds. The stratum option refers to the NTP stratum level of service that this router will provide as a clock source. This can range from 0 to 15. If this router is the master clock, choose 1. You also can apply an offset to any time stamp that the router generates with the timestamp-offset option, which is specified in milliseconds.

Setting Up the NTP Server

If your router will be an authoritative NTP server, as typically would be the case if you attached a GPS unit to it, you must configure the following on your router:

Router(config)# ntp master [stratum_level]

NTP Security

You can take two security measures to create a more secure NTP environment for your router:

• Use access groups to restrict who can access the router’s NTP resources.
• Use authentication with the MD5 hashing function to restrict NTP communications between trusted devices.

The following two sections discuss these solutions.

Access Groups

Access groups enable you to define a standard ACL that is used to filter types of NTP messages that the router receives. This feature is useful if your router is an NTP server and you want to restrict NTP access to it. The syntax of the command is as follows:

Router(config)# ntp access-group {query-only | serve-only |

  serve | peer} standard_ACL_#

Table 18-4 explains the different control options. When matched with a permit or deny statement in the specified standard ACL, only those communication processes are allowed or prohibited. If you have more than one ntp access-group statement defined, the first statement that matches in the first ntp access-group statement is used.

Table 18-4. NTP Access Group Control Options

Authentication

NTP supports authentication, which is used to validate NTP messages received from another NTP device. This authentication is similar to that used by routing protocols, such as OSPF and EIGRP, and PPP’s CHAP. MD5 is used to create a cryptographic checksum, which is attached to the NTP message. A key, known to both sides, is used to create the authentication checksum. When enabled, if the checksum cannot be verified, the NTP message is ignored. One advantage that authentication has over access group control is that access group control is susceptible to IP spoofing attacks. Authentication does not rely on the IP address for authentication?instead, a shared secret key is used.

You need to configure three commands to set up authentication:

Router(config)# ntp authenticate

Router(config)# ntp authentication-key key_# md5 key_value

Router(config)# ntp trusted-key key_#

The ntp authenticate command enables NTP authentication. The ntp authentication-key command defines a reference number for the key (key_#) as well as the authentication key (the same key_value must be configured on the remote NTP device). Finally, the ntp trusted-key command specifies which NTP devices should be trusted with authentication, which prevents an accidental synchronization to a system that is not trusted. Notice that a reference number is used. This reference number must match the one used in the ntp authentication-key command. By using a key number, you can create multiple keys; this means that you can update keys more easily and can have different keys for different peers.

After you have defined authentication, you need to reference the key number in the ntp {server | peer} command, which tells the router which key to use when sending messages to specific peers.

Other NTP Commands

This last section on NTP configuration covers three miscellaneous commands. Earlier, I discussed how to specify the source IP address to be used in communications with other NTP devices (using the ntp {server | peer} command). However, you globally can specify the source IP address to use with the following NTP command:

Router(config)# ntp source interface

If you configure the interface in the ntp {server | peer} command, this configuration overrides the global configuration.

For routers that have a hardware clock, you can have the router update the hardware clock from the software clock; however, this is advisable only if the software clock is updated from a reliable NTP source. This is sometimes necessary because the hardware clock can drift slightly over time. To update the hardware clock from the software clock when using NTP, use the following command:

Router(config)# ntp update-calendar

Chapter 4, “Disabling Unnecessary Services,” discussed disabling unnecessary services. With NTP, you can enable or disable it on an interface-by-interface basis. To prevent NTP attacks, disable NTP on interfaces that you will not be using to obtain time. For example, if you have a three-interface router?inside, outside, and DMZ?and your NTP server is off the inside interface, I highly recommend that you disable NTP on the other two interfaces. To disable NTP on an interface, use the following configuration:

Router(config)# interface type [slot_#/]port_#

Router(config-if)# ntp disable

NTP Verification

After you have configured NTP on your router, you can use various show commands to examine your configuration and troubleshoot problems. To see the current time on the router’s software clock, use the show clock command; to see the time of the hardware clock, use show calendar.

NTP Commands

You use two basic commands to examine NTP information:

• show ntp associations
• show ntp status

The first command displays associations with other NTP devices. Example 18-12 displays sample output from the show ntp associations command.

Example 18-12. Using the show ntp associations Command

Router> show ntp associations

  address     ref clock   st when  poll reach delay offset  disp

*~192.1.2.11  192.1.2.11   2   31  1024  377    4.1  -8.38   1.5

* master (synced), # master (unsynced), + selected, - candidate,

    ~ configured

In Example 18-12, the first set of leading characters displays synchronization information:

The address column lists the addresses of the NTP peer devices. The ref clock column lists the addresses for where peers in the address column are getting their time. The st column indicates the stratum level of the peer. The when column indicates the time since the last NTP message was received from this peer. The poll column indicates the polling interval, in seconds, that this router is using to contact the specified peer. The reach column indicates the peer’s reachability, in octal. The delay column displays the roundtrip delay, in milliseconds, to the peer. The offset column displays the relative time of the peer’s clock to the local router’s clock, in milliseconds.

The show ntp status command displays the status of NTP on the router. Example 18-13 shows sample output of the show ntp status command.

Example 18-13. Using the show ntp status Command

Router# show ntp status

Clock is synchronized, stratum 2, reference is 192.1.2.11

nominal freq is 250.0000 Hz, actual freq is 249.9990 Hz, precision is 2**19

reference time is AFE2525E.70597C87 (00:10:39.511 EDT Thu Jan 1 2004)

clock offset is 6.21 msec, root delay is 83.98 msec

root dispersion is 81.96 msec, peer dispersion is 2.02 msec

In Example 18-13, the router is synchronized with the NTP server at 192.1.2.11, which provides a stratum level 2 service.

SNTP Command

Only one command is used to verify the configuration and operation of SNTP: show sntp. Example 18-14 shows sample output.

Example 18-14. Verifying SNTP

Router# show sntp

SNTP server     Stratum   Version    Last Receive

192.1.2.11        2         3        00:00:34     Synced  Bcast

Broadcast client mode is enabled.

In Example 18-14, one NTPv3 server, 192.1.2.11, provides a stratum level 2 service to this router. This router is learning about the time from this server through local broadcasts.

NTP Configuration Example

Now that you have a basic understanding of NTP and its configuration, take a look at a simple example in which a perimeter router at a corporate network needs to synchronize its time to an internal NTP server. Figure 18-1 is used to illustrate this example. Example 18-15 shows the router’s configuration.

Example 18-15. Configuring NTP on Your Router, Acting as a Client

Router(config)# ntp server 192.1.2.11 key 99 source ethernet0

Router(config)# ntp authenticate

Router(config)# ntp authentication-key 99 md5 55ab8971F

Router(config)# ntp trusted-key 99

Router(config)# ntp update-calendar

Router(config)# access-list 1 permit 192.1.2.11 0.0.0.0

Router(config)# ntp access-group peer 1

Router(config)# interface ethernet1

Router(config-if)# ntp disable

Router(config)# interface ethernet2

Router(config-if)# ntp disable

In this example, the NTP server is 192.1.2.11, which is specified in the first command. The next three commands set up authentication and refer back to the first command with the key reference number of 99. Notice that the hash key is 55ab891F, which also must be configured on the NTP server. This router has a hardware clock, so the ntp update-calendar command updates the hardware clock from the software clock. The access-list and ntp access-group commands restrict NTP interaction with only 192.1.2.11. Finally, NTP is disabled on the outside and DMZ interfaces. As you can see, setting up NTP is straightforward.

The Embedded Syslog Manager (ESM), new in Cisco IOS 12.3(2)T, enables you to filter, change the severity level of, route, and customize logging messages on your router. ESM allows logging messages to be logged independently as standard messages, messages formatted using XML, and ESM filtered messages. These messages then can be forwarded to the standard logging destinations: console, internal buffer, and syslog server. By using a separate logging process, ESM ensures that if there is a problem with the ESM filtering modules, the standard logging process will be unaffected.

ESM Overview

As I mentioned in the introduction, ESM is an enhancement, not a replacement, to the existing logging mechanism, including syslog. Both simultaneously can be running on your router. ESM, however, provides enhanced services above and beyond the normal syslog functions of a router.

ESM gives you complete control over the logging process on the router. Before this feature was introduced, if you wanted to perform extra processing on logging events, such as filtering, or have the router take an action for a specific event, you had to write your own scripts and run them against syslog files on a syslog server. With ESM, you can do these tasks on the router itself. Here are some benefits that ESM provides you:

• You can limit the number of syslog messages to prevent a flood of messages in a time of duress or attack.
• You can customize processing of logging messages, such as forwarding specific messages to specific syslog servers.
• You can send e-mail notifications based on a specific log message or message type being generated.
• You can change the security levels for logging messages instead of using the ones that Cisco assigns to the messages.

To perform these functions, ESM uses filter modules, which are scripts written in the Tcl language. Cisco has some predefined scripts that you can use, but you easily can modify these or create your own (assuming that you know Tcl). These scripts can be stored locally on the router, such as in Flash, or on a remote server. The scripts can be stored in plain text or can be precompiled; the latter increases your security because they cannot be edited directly (you can use the tool TclPro to precompile scripts, but other tools are available).

ESM requires Tcl 8.3.4 support, which is available only in Cisco IOS 12.3(2)T and later. Because only Tcl is supported for scripting, you must be proficient in using the Tcl coding language to create your own custom scripts. One limitation with ESM is that it cannot be applied to SNMP logging, such as log messages related to the snmp-server enable traps syslog and logging history commands.

Before you can use ESM, you must either create or obtain filtering modules. When you enable ESM, all logging messages first are processed through the referenced ESM filter modules. You can have the router use multiple filter modules, where the modules are processed by the position tag associated with the logging filter command. This enables you to enter your logging filter commands in any order, but it has the Cisco IOS process them based on the position tag values. When multiple modules are referenced, the output of the first filter module is passed as the input to the second module. If you had a third module, the output of the second module would be passed to the third one.

One component always passed from filter module to filter module is the original logging message. When all filter modules have been processed, the original logging message can be directed to one of three locations: standard, XML, or ESM. With the router’s standard logging process, the logging message is directed to the normal destinations: console, buffered, or syslog.

Input Process

Normally, a logging message contains the following variables: facility, severity level, mnemonic, message text, and, optionally, a sequence number and time stamp. However, ESM, preappends a syslog count number to each message. The logging message itself is passed as a Tcl global namespace variable to the filter module. Each component in a logging message is a Tcl global variable, and each of these is prefixed with a double colon (::) when referencing them in the script module. Table 18-5 lists the valid variables that you have access to within a filter module.

Table 18-5. ESM Filter Module Variables

Filtering Process

After you have set up ESM, each time the router generates a logging message, the filter modules are processed in the order in which they are referenced, (that is, configured). As each module is processed, it passes its output as input to the next module. Because the Tcl variables in Table 18-5 are global namespace variables, each of these can be changed within your filters and can be used by other filters.
return Statement

Two Tcl global variables automatically are updated by ESM based on the execution of filtering modules: ::orig_msg and ::cli_args (the latter is the arguments passed into the filter module). The ::origin_msg value is set automatically to the return value of the filter module. This is done with the return command. For example, if you had a one-line filter module and wanted to pass a value of “This is my new value” to the next filter module, your return statement in your first filter module would look like this:

return “This is my new value”

With this example, the filter module ignores any parameters passed to it and passes the previous text string to the next filter module in the chain.

Here are some other return statement examples. With this return statement, all syslog messages are blocked to the ESM stream process:

return “”

This example sends the value in ::orig_msg to the next module:

return $::orig_msg

Cisco IOS Commands

You can add Cisco IOS commands to your filter modules by using the Tcl config and exec commands. For example, assume that you want to add the inbound ACL applied to an interface to your logging message. Assume that the ACL is the one applied to ethernet1, which is also the source address for logging statements to a syslog server. This could be done with the following:

set acl_info [exec show ip interface e1 | inc Outbound access list]

puts $acl_info

"  Outgoing access list is not set"

In this example, the last line is the output passed to the syslog message.

Example Filter Modules

Cisco provides some sample Tcl scripts on its website for ESM filter modules; however, Cisco does not support all of these scripts. The phrase “buyer beware” applies. Some of the example scripts include the following:

• Escalating the severity level of a message
• Counting messages
• Creating XML tags
• Associating logging messages to a stream ID
• Sending an e-mail alert

As I mentioned at the beginning of this section on ESM, this chapter does not provide an in-depth study of the configuration of Tcl scripts. To give you a flavor of scripting, however, I look at two scripts included on the Cisco website: email.txt and email_guts.txt.

The email.txt script creates an e-mail message with the logging message. Here are the guts of this script:

# Usage:  Provide email address as CLI argument.  Set email server IP in

#         email_guts.tcl

# Namespace: email

if {





 == 0 } {

   source flash:/email_guts.tcl

}

# Check for null message

if { [string length $::orig_msg] == 0} {

      return ""

   }

if {





 } {

    if { [string compare -nocase CONFIG_I $::mnemonic ] == 0 } {

                email::sendmessage $::cli_args $::mnemonic \

                [string trim $::orig_msg]

    }

}

return $::orig_msg

One argument that you must pass to this script is the e-mail address where you want e-mail messages sent.

The email_guts.txt script specifies the e-mail server’s IP address, as well as the from and friendly strings:

# Usage: Set email host IP, from, and friendly strings below.

#

namespace eval email {

    set sendmail(smtphost) 192.1.1.2

    set sendmail(from) $::hostname

    set sendmail(friendly) $::hostname

    proc sendmessage {toList subject body} {

        variable sendmail

        set smtphost $sendmail(smtphost)

        set from $sendmail(from)

        set friendly $sendmail(friendly)

        set sockid [socket $smtphost 25]

## DEBUG

set status [catch {

        puts $sockid "HELO $smtphost"

        flush $sockid

        set result [gets $sockid]

        puts $sockid "MAIL From:<$from>"

        flush $sockid

        set result [gets $sockid]

        foreach to $toList {

            puts $sockid "RCPT To:<$to>"

            flush $sockid

        }

        set result [gets $sockid]

        puts  $sockid "DATA "

        flush $sockid

        set result [gets  $sockid]

        puts  $sockid "From: $friendly <$from>"

        foreach to $toList {

            puts $sockid "To:<$to>"

        }

        puts  $sockid "Subject: $subject"

        puts  $sockid "\n"

        foreach line [split $body "\n"] {

            puts  $sockid " $line"

        }

        puts  $sockid "."

        puts  $sockid "QUIT"

        flush $sockid

        set result [gets  $sockid]

} result]

        catch {close $sockid }

    if {$status} then {

        return -code error $result

    }

}

} ;# end namespace email

set email::init 1

Introduction to ESM Setup and Configuration

After you have created your filter modules for ESM, put them in a place where the router can locate them through a URL-style syntax. I recommend that you put the Tcl scripts (filter modules) in the router’s Flash. When this is done, you need to perform the following steps:

Step 1. Reference each filter module with a separate logging filter command.

Step 2. Use the logging {console | buffered | monitor | host} filtered command to use your ESM filter modules. Optionally, configure other logging commands, such as logging source-interface and logging origin-id.

Step 3. Verify your configuration with the show logging command.

The following sections cover the configuration in more depth.

Specifying Filter Modules

The first thing that you must do is reference your filter modules. This is done using the logging filter command:

Router(config)# logging filter filter_url [position_#]

  [args filter_arguments]

The filter_url parameter specifies the location of the filter module. If the module is stored locally in the router’s Flash, use flash: or slot0: as the source. If it is stored remotely, use either ftp:, rcp:, or tftp:. For a remote location, the filter URL should also contain the IP address of the module, as well as the directory in which the module is located. For locally and remotely stored modules, you need to specify the name of the module. The extension of these scripts is either .txt for a plain, noncompiled Tcl script or .tcl for a precompiled Tcl script.

Following the URL specification is the position number of the filter module during the filtering process. If you omit the position number, the router processes filter modules in the order in which you configure them. For each filter module that you have, you need a separate logging filter command. Finally, the optional args parameter specifies any arguments that you want to pass to the filter (in the filter, you need to reference these arguments if you want to use them). For example, you could pass an e-mail address to a script by using this syntax: args richard@quizware.com. If you have multiple arguments, separate the arguments by a space. Note that if the script is set up to accept an argument already, you do not need to preface the argument with the args parameter.

Here is a simple example of referencing a compiled script stored in the router’s Flash:

Router(config)# logging filter flash:/email.tcl richard@quizware.com

Using Filter Modules

Next, you must tell your router to use the filter modules that you specified with the logging filter command. This is done using the following commands:

Router(config)# logging [console | buffered | monitor] filtered

  [severity_level]

Router(config)# logging host {IP_address | hostname} filtered

  [stream stream_ID]

In the first logging command, the optional severity_level parameter specifies that logging messages at that severity level or higher (lower number) will be processed by the filter modules. Note that the severity level specified in the logging console, logging buffered, and logging monitored commands takes precedence over the severity level specified in this command.

In the second command, the optional stream parameter can be used to direct logging messages to a specific syslog host. As an example, you could specify that all severity level 5 messages should have a stream ID of 7 associated with them; then, with the stream parameter, you could have the appropriate logging host command process these logging messages.

Example 18-16 shows a simple example that e-mails a message for any messages logged to the console with a severity level of 0 to 3.

Example 18-16. Sending an E-mail Message Based on Logging Severity Levels

Router(config)# logging filter slot0:/email.tcl richard@quizware.com

Router(config)# logging filter slot0:/email_guts.tcl

Router(config)# logging console filtered 3

Verifying Your ESM Configuration

After you have configured your ESM filters, you can use the show logging command to verify your configuration. Example 18-17 shows a sample output of this command based on Example 18-16.

Example 18-17. Using the show logging Command to Verify Your ESM Configuration

Router# show logging

Syslog logging: enabled(0 messages dropped, 12 messages rate-limited,

  0 flushes, 0 overruns, xml disabled, filtering enabled)

  Console logging: level debugging, 32 messages logged, xml disabled,

    filtering enabled

  Monitor logging: level warnings , 0 messages logged, xml disabled,

    filtering disabled

  Buffer logging: level debugging, 839 messages logged, xml disabled,

    filtering disabled

  Logging Exception size (8192 bytes)

  Count and timestamp logging messages: disabled

Filter modules:

     slot0:/email.tcl richard@quizware.com

     slot0:/email_guts.tcl

Log  Buffer (8192 bytes):

*Jan 5 12:49:02.513: %SYS-5-CONFIG_I: Configured from console

  by console

<--output omitted-->

Cisco Router and Security Device Manager (SDM) is installed on this device and
it provides the default username “cisco” for  one-time use. If you have already
used the username “cisco” to login to the router and your IOS image supports the
“one-time” user option, then this username has already expired. You will not be
able to login to the router with this username after you exit this session.

It is strongly suggested that you create a new username with a privilege level
of 15 using the following command.

username <myuser> privilege 15 secret 0 <mypassword>

Replace <myuser> and <mypassword> with the username and password you want to
use.

———————————————————————–
^
banner login ^
———————————————————————–
Cisco Router and Security Device Manager (SDM) is installed on this device.
This feature requires the one-time use of the username “cisco”
with the password “cisco”. The default username and password have a privilege level of 15.

Please change these publicly known initial credentials using SDM or the IOS CLI.
Here are the Cisco IOS commands.

username <myuser>  privilege 15 secret 0 <mypassword>
no username cisco

Replace <myuser> and <mypassword> with the username and password you want to use.

For more information about SDM please follow the instructions in the QUICK START
GUIDE for your router or go to http://www.cisco.com/go/sdm
———————————————————————–
^
!
line con 0
login local
line vty 0 4
access-class 23 in
privilege level 15
login local
transport input telnet
transport input telnet ssh
line vty 5 15
access-class 23 in
privilege level 15
login local
transport input telnet
transport input telnet ssh
!
!  End of SDM default config file
end

on/off interface
Router(config-if)#no cdp enable

Router#show cdp
Global CDP information:
Sending CDP packets every 60 seconds
Sending a holdtime value of 180 seconds
Sending CDPv2 advertisements is  enabled

The show cdp neighbors command displays this information:

type of device that is discovered

name of the device

number and type of the local interface (port)

number of seconds the CDP advertisement is valid for the port

device type

device product number

port ID

Router#show cdp neighbors
Capability Codes: R – Router, T – Trans Bridge, B – Source Route Bridge
S – Switch, H – Host, I – IGMP, r – Repeater

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
R2-AGS           Ser 1              129          R        2500      Ser 0
R6-2500          Eth 0              144          R        4000      Eth 0
Router#

show cdp neighbors detail

show cdp entry

cdp timer

cdp holdtime

clear cdp counters -Resets the traffic counters to zero.

clear cdp table – Deletes the CDP table of information about neighbors.

show cdp

Displays the interval between transmissions of CDP advertisements, the number of seconds the CDP advertisement is valid for a given port, and the version of the advertisement.

show cdp entry entry-name [protocol | version]

Displays information about a specific neighbor. Display can be limited to protocol or version information.

show cdp interface [type number]

Displays information about interfaces on which CDP is enabled.

show cdp neighbors [type number] [detail]

Displays the type of device that has been discovered, the name of the device, the number and type of the local interface (port), the number of seconds the CDP advertisement is valid for the port, the device type, the device product number, and the port ID. Issuing the detail keyword displays information on the native VLAN ID, the duplex mode, and the VTP domain name associated with neighbor devices.

show cdp traffic

Displays CDP counters, including the number of packets sent and received and checksum errors.

show debugging

Displays information about the types of debugging that are enabled for your router. See the Cisco IOS Debug Command Reference for more information about CDP debug commands.

Use SHOW IP PROTOCOLS to see RIP info

To see the routes being advertised in RIP updates and the metrics of these routes, run debug ip rip.

Dynamic, distance vector routing protocol based around the Berkely BSD application routed and was developed for smaller IP based networks.

UDP port 520 for route updates.

Metric: Hop Count (limit 15 as 16 is seen as unreachable)

Classful Routing Only

RIP ROUTING UPDATES

Default behavior is to send version 1 updates only, but to accept both versions 1 and 2.
Broadcast the full list of all the routes they know every 30 seconds.
When a router running RIP hears a broadcast it runs the distance vector algorithm to create a list of best routes.

RIP TIMERS

TIMER               DEFAULT     CONTROLS
Update               30 sec.            Interval between route update advertisements
Hold-Down       90 sec.           Period a route is withdrawn from the table to prevent a routing loop.
Timeout            180 sec.          Interval a route should stay ‘live’ in the routing table. This counter is reset every time the router hears an update for this route.
Flush                 120 sec.          How long to wait to delete a route after it has timed out.

The routing-update timer controls the time between routing updates. Default is usually 30 seconds, plus a small random delay to prevent all RIP routers from sending updates simultaneously.

The route-timeout timer controls when a route is no longer available. The default is usually 180 seconds. If a router has not seen the route in an update during this specified interval, it is dropped from the router’s announcements. The route is maintained long enough for the router to advertise the route as down (hop count of 16).

The route-flush timer controls how long before a route is completely flushed from the routing table. The default setting is usually 120 seconds.

RIP sends updates as broadcasts by default.  If you are running RIP over Frame Relay you can’t just shout out the updates as a boradcast.  Instead to must tell a specific neighbor.  A unicast.  Use the neighbor command

Router(config-router)#neighbor 192.168.1.1

RIP v2

RIP v2 default behavior is to autosummarize routes advertised across classful boundaries. To disable this behavior, run the no auto-summary command under the RIP process.
To hardcode RIP to send and receive only version 1 or version 2, run the appropriate version command under the RIP process.

R1#conf t
R1(config)#router rip
R1(config-router)#version 2
R1(config-router)#no auto-summary

RIP version 2 supports variable-length subnet masking (VLSM), but you still enter the classful network number under the RIP process.

R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router rip
R1(config-router)#version 2
R1(config-router)#no auto-summary
R1(config-router)#network 172.10.0.0

You can paste the following into your router to get a kickstart

en
clo