Network Technologies | IPNET

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.

How to protect your network and users with not additional costs

One of the biggest problems in today’s network security is users surfing on the Internet. I’m not against offering Internet access at work place or schools, for example, but I believe that some measures should be taken by the network administrators to limit the users from being able to access (intentionally or not) the webpages with threatening content (hijack, malware, spyware and so on…).

If big corporation have the money to invest in security development and devices, than the SOHO business would rather invest those money in something else. Sometime ago, I was having in my home a small network meaning on one PC and a notebook in my apartment and some few devices in other friend flat from the same building. Since the other partners that I was sharing the network with, where not so familiar with the bad things on the Internet, I had to come with a solution to limit the monthly problems with strange software being installed on their PCs after a night of web surfing. You know what I talking about, right? Nice banner pop-up, user click on it then something like spyware getting installed on his/her device.

Instead of investing in some firewalls, or configuring a Linux machine to filter traffic, I let some smart machines to filter my traffic: Domain Name Servers. So, I arrived at opendns.com. Free service that let you use their NS services, provide you with stats and filtering. Exactly what I needed. From that point everything was easy. I announced their NS IP addresses in my home network from our Cisco router through DHCP as default DNS servers, and I was protected. I assume that you also have a Cisco device, but if not, please have a look here where you might find your device and how to configure it.

One note has to be mentioned, before I invite you to see the tutorial below. OpenDns.com stated clear in their Terms of Use, that their services are for home users. So, if you have so kind of small or medium business, please send ask them before you use their service as explained below.

Please click on the image below to see the presentation:

Cisco: TCP and UDP small servers

Do you like Linux with all this services that you can enable on the fly when you want to test something? I know that I really like Linux boxes. But what about Cisco? Well Cisco supports also some services to be enabled for testing purposes. This are called “TCP and UDP small servers”.

Maybe I should start by telling you that there are never ending discussions about this servers, whenever they should be enabled and how to protect the access to them, since this is still an open security issue which can attract and attacker. In my opinion you cannot keep them close and also running some tests (that require certain ports to be open) in the same time, but let open access to them is not a solution either. So, what can you do, is to enable TCP and UDP small servers only when you need them for testing and then disable these services. Another solution that I see, is to let this services all the time enabled, but to use some security tools (e.g. access-lists on external ports) to reduce the amount of hosts that can access them. In this way you let them accessible only for the hosts from where you want to be. And the third solution is not to enabled them at all, but then you cannot test anything. It’s like the story when a computer is safe? When you destroy the hard-drive and look the device into a safe. Good, the computer is secure, but you cannot use it anymore, so what’s the point of doing this?

But back to our discussion, TCP and UDP small servers are servers (strange phrase, I know) that run in the router which are useful for diagnostics.

TCP small servers:
Echo: Echoes back whatever you type through the telnet x.x.x.x echo command.
Chargen: Generates a stream of ASCII data. Use the telnet x.x.x.x chargen command.
Discard: Throws away whatever you type. Use the telnet x.x.x.x discard command.
Daytime: Returns system date and time, if it is correct. It is correct if you run Network Time Protocol (NTP), or have set the date and time manually from the exec level. Use the telnet x.x.x.x daytime command.

UDP small servers:
Echo: Echoes the payload of the datagram you send.
Discard: Silently pitches the datagram you send.
Chargen: Pitches the datagram you send, and responds with a 72-character string of ASCII characters terminated with a CR+LF.

In addition to the one above, the Cisco devices also offers finger service and async line bootp service, which you can independently turn on / off.

For this presentation I will use 2 point-to-point connected routers named RT-TEST-CLIENT (10.0.0.2 /30) and RT-SERVERS-ENABLE (10.0.0.1 /30). I will enable TCP and UDP small servers on one of them and test from the other one. Please click the image below to see the video presentation:

If you cannot see the Flash movie above please consult this text document which explain how to enable TCP / UDP small server and how to test them.

Cisco: How to configure Frame-Relay Hub and Spoke in simple steps

Some days ago, during my preparation for CCIE RS I had to configure Frame-Relay Hub and Spoke environment. Since I already did it, I said that is good to have it here also, maybe somebody will find it useful. Even if it sounds quite complicate as title, FR hub and spoke. This post assume that you are somehow familiar with Frame-Relay concept and you know basic stuff. If you need to refresh your knowledge there is good topic about Frame-Relay on Ciscopress page.

So, what is this FR hub and spoke anyway? A basic example is with 3 device (can be more) in which on of them connect the other ones in a central point. This is the opposite to (full or circular) mesh in which every router is connected with at least another 2 devices. For things to be more clear please have a look to this topology file.

As you can see in the topology provided, R1 is connecting the other 2 routers in a central point. R1 device is the Hub and R2, R3 are the Spokes. Like explained in the topology, the green lines represent PVC circuit and red ones the physical connection. The communication between R2 and R3 will be done only through R1 since there is no PVC that connect this 2 devices. You can be tempted to say that the communication is direct, because red lines have a common point in the FR switch, but the things are not like this. This is not Ethernet, so for L3 to work you need a map from L2 to L3. Since there is no PVC define in FR switch for R2 to R3 communication, everything is passing through R1.

To configure Frame-Relay Hub and Spoke is not very difficult. The most hard part is regarding FR switch, but luckily you don’t have to deal with it, as this is usually a provider equipment, and they will do the L2 to L3 frame-relay routing, providing you with the need DLCI information. From this point you only have to be careful to details (IP, DLCI, interface) when configuring frame-relay map on your devices.

In a future post I will extend this topic and show how you can configure OSPF in a Frame-Relay Hub and Spoke environment. For now please check this topic presented in the tutorial below:

If Flash movie is not available for you, then please check this text file which contains the configuration.

Cisco: Quick IOS check in 4 simple steps

This post is rather for the beginners in Cisco’s world than for advance professionals, but still I encounter situation when IOS image was corrupted even if it was uploaded to the device by a network guru. Why? It’s quite simple! Because you can be the master of the Cisco networking, but still sometime you cannot control the device behavior or the transport of the packets to destination.

The problems is that in case of a corrupted IOS image being uploaded on a Cisco device, and having that device reloaded you can run into situation when it will not boot up anymore. When the device is in front of you, or on your desk, there is not a problem, because you can troubleshoot, find the issue (e.g wrong or corrupted IOS image) and solve it! But, what if your device is at 5000 km distance, it is 3:00 AM and you have no professional help on that location?! That’s one ugly situation and the reason for which I always insist to verify the IOS image after it is uploaded and ready to go into production.

For those of you who are dealing with this stuff everyday, this post may seem like a joke, but I bet that there are out there IT’s which never check this stuff or they are beginners and don’t know how to do it. It’s more simple that you may think it is, make you spend about 4-5 minutes for a full check, but can spare you for bigger problems in the future.

So, what are the 4 steps:
1. Check what Cisco device you have (to know what IOS image you need)
2. Check what IOS image Cisco device has (to know what IOS release to download)
3. Verify the IOS image
4. Check the results of your verification
As simplest as it can get.

Please check the tutorial by clicking the image below:

For those who cannot see a Flash movie, please read this text file, that consist of the command you should perform for IOS checking.