All Entries in the "Cisco-services" Category
Cisco: How to use kron to automate tasks
Now and then everybody in IT network industry has to stay awake over the night to accomplish some tasks that cannot be performed during the work hours because will disturb regular activity. Some of this task usually need your presence in field (virtually or in place), to assure that everything is working fine and you don’t have any unwanted surprise the next day.Skipping this tasks, there are other ones with less impact in case of a failure, which I believe you rather prefer to do it automatically and to check the results when you can. I’m talking here usually about configuration save or archive, IP addresses being renew by DHCP or data backup
All this stuff can be achieved by using the Cisco “kron” present in the IOS. I think that everybody who’s ready this post heard about cron jobs, so I will issue just a small explanation. Cron jobs are tasks definite to run at one certain moment or to be recursive over a period of time. In human terms, cron jobs can help us sleep well why they are doing the job over the night.
Speaking now about Cisco “kron” command, you should know that it appear starting with IOS version 12.3(1), so don’t try to find it if you have a previous version installed. Also, The EXEC CLI specified in a Command Scheduler policy list must not generate a prompt or have the ability to be terminated using keystrokes. Command Scheduler is designed as a fully automated facility and no manual intervention is permitted. Command Scheduler allows you to schedule fully-qualified EXEC mode CLI commands to run once, at specified intervals, or at specified calendar dates and times.
Command Scheduler has two basic processes. A policy list is configured containing lines of fully-qualified EXEC CLI to be run at the same time or interval. One or more policy lists are then scheduled to run after a specified interval of time or at a specified calendar date and time. Each scheduled occurrence can be set to run once only or on a recurring basis. Policy lists can be configured after the policy list has been scheduled, but each policy list must be configured before it is scheduled to run. Policy lists consist of one or more lines of fully-qualified EXEC CLI commands. All commands in a policy list are executed when the policy list is run by Command Scheduler using the kron occurrence command. Use separate policy lists for CLI commands to be run at different times.
One mandatory tasks is that before you try to run “kron”, your Cisco device has to know the time. Either manully set or through NTP server. If the device does not know the time, than a warning message will appear when you’ll try to configure kron tasks.
Please see below some brief examples about how you can configure kron tasks.
Popularity: 5% [?]
Cisco: How-to get notifications for IP SLA monitor using EEM
In some previous post, I explained how to configure a basic IP SLA monitor for checking the round-trip time between two Cisco routers. Because in the comments of that post I have been asked how you can get e-mail notification for IP SLA monitor, I have decided to write another post to extend a little bit this topic.
To accomplish e-mail notification for IP SLA monitors we will use Embedded Event Manager (EEM) and some SNMP knowledge.Cisco IOS EEM is a powerful device and system management technology integrated into specific Cisco switches and routers. EEM gives us the ability to customize Cisco IOS behavior based on network events as they happen.
EEM will use a SNMP event to report anomalies in regarding the RTT threshold value. For SNMP to work we need to know and Object name and the OID associated with it. In my example I will use the SNMP Object name: rttMonCtrlOperOverThresholdOccurred (OID: 1.3.6.1.4.1.9.9.42.1.2.9.1.7). On Cisco website you can find more about this SNMP Object and I advice you to read it before going on with this tutorial.
Below you have a basic example about how to get e-mail notification when the threshold of the RTT IP SLA monitor is reached. More examples you can find on Ivan Pepelnjak’s blog: blog.ioshints.info . It’s a good idea to check them also.
The topology remains the same like in the previous post about IP SLA. You can check it here. Please click below to check the tutorial:
If you cannot check the tutorial above, please read this text file, as it contains all the information from the video presentation.
Popularity: 9% [?]
Cisco: How to configure simple IP SLA monitor
Before we begin let’s see what is this SLA term, for those of us who are not very familiar with the Service Provider terms. IP Service Level Agreements (SLAs) enable customers to assure new business-critical IP applications, as well as IP services that utilize data, voice, and video, in an IP network. With Cisco IOS IP SLAs, users can verify service guarantees, increase network reliability by validating network performance, pro actively identify network issues assure an easy way to deploy new IP services. Cisco IOS IP SLAs use active monitoring, enabling the measurement of network performance and health.
For the following how-to please have a quick look into the topology. As you can see I have a basic routing topology, imported from another tutorial from FirstDigest, and let’s assume that we want to monitor the line between R1 and TEST-RT. For this we will configure a very simple IP SLA monitor, based on icmp echo packets, which will measure our RTT (Round Trip Time) or latency and provide us with valuable informations. For example in case of VoIP problems we can check the latency and in case of a value bigger than 200 ms (220 ms maximum accepted for the voice service to function properly) we will know from where are the problems generated. Of course IP SLA can have more complex configuration under Cisco IOS (e.g. http or ftp transfer to check if the service provider assure us the bandwidth specified in the contract).
One personal advice from my experience. Even if all the data and information provided by IOS IP SLA monitor can be checked with “show…” commands, I would advice you to get a third party software that can interpret this data for you and draw nice graphs or store them in an archive for you. This kind of software are MRTG, Weathermap, Nagios, RRDtool and others (I put here only the free ones).
Please check the how-to by clicking the image below:
Popularity: 34% [?]
Cisco: Very simple NTP configuration
NTP (Network Time Protocol) is usually very simple to configure on Cisco devices. Of course you can reach complex configuration, but since I work in this field I didn’t saw somebody to push the things to extreme in NTP configuration.
NTP is based on server – client relation. It is recommended that in a Cisco network environment, you should use online the client part of the NTP, and to choose some external NTP sever to synchronize with. This is because using a NTP server (master) on your networ violates NTP’s hierarchical trust model. You should use a NTP master only is there is no possibility to reach an external one or if some corporate policies dictate this.
NTP can operate in 4 different modes. See a short explanation below:
-> Client: A NTP client is configured to let its clock be set and synchronized by an external NTP timeserver. NTP clients can be configured to use multiple servers to set their local time and are able to give preference to the most accurate time sources. They will not, however, provide synchronization services to any other devices.
-> Server: A NTP server is configured to synchronize NTP clients. Servers can be configured to synchronize any client or only specific clients. NTP servers, however, will accept no synchronization information from their clients and therefore will not let clients update or affect the server’s time settings.
-> Peer: With NTP peers, one NTP-enabled device does not have authority over the other. With the peering model, each device shares its time information with the other, and each device can also provide time synchronization to the other.
-> Broadcast / Multicast: Broadcast/multicast mode is a special server mode with which the NTP server broadcasts its synchronization information to all clients. Broadcast mode requires that clients be on the same subnet as the server, and multicast mode requires that clients and servers have multicast access available and configured.
For our simple NTP configuration we will use the server and client mode. For this tutorial we will use the same topology like in the post “Cisco: BGP path selection for outgoing traffic” where we have already a working BGP environment. If you do not have the topology, you can download it here. Please see the tutorial below:
Popularity: 5% [?]
