MacDevCenter    
 Published on MacDevCenter (http://www.macdevcenter.com/)
 See this if you're having trouble printing code examples


 

Cisco Router Management Using Tcl on Mac OS X

by Michael J. Norton
11/27/2001

Editor's Note: In his previous article, Network Test Automation with Mac OS X and Tcl, Michael Norton explained how to use Tcl and a utility that complements it, Expect, to help test and maintain networks. In this article, he builds upon that information by focusing more closely on Cisco Router Management.

In large-scale system test network environments, multiple tests could be executing in a test bed simultaneously. Cisco routers use a console to access each individual router. If one test network operator has the console to the router, then your access is postponed until the operator relinquishes the console. Another way to access the router, without the need for a router console, is through its HTTP server.

Were going to look at a library, written in Tcl, which will allow you to access your router's HTTP server and retrieve the same information as if you had a console. Although this article is geared for the Mac OS X user, Tcl is completely portable. In fact, I have run this library on a Win2K laptop, a Linux box, and a Sun Ultra 5 running Solaris 2.8.

IOS HTTP server

Related Reading

Managing IP Networks with Cisco Routers
Managing IP Networks with Cisco Routers
By Scott M. Ballew
Table of Contents
Index
Sample Chapter
Full Description

Cisco Systems IOS operating system provides an HTTP server to access and manage your Cisco router(s). The router can be configured and modified using the HTTP server just as easily as if you were to sit at the router console and perform these operations. The only operation that can't be performed is a router reload (IOS jargon for performing a reboot).

Considerations need to be made here. First, as any network security guru will tell you, if they have access to a console, then they can easily compromise the network. Don't unwillingly provide a backdoor to hackers when activating the HTTP server. The HTTP server can be used internally if your network is secure behind a firewall. The IOS HTTP server's privileged access is maintainable under TACACS+. Second, if you're learning about the operation of the IOS HTTP server, set up a lab router to play around with. Never, ever, experiment on your live network. This is a good plan of approach for network security and your job security!

Graphic Representation of how Network Topology using TACACS+ works
Figure 1. Network Topology using TACACS+

HTTP server configuration

Comment on this articleAs Michael Norton said in the article, the possibilities are limitless when using Tcl in network testing and management. Do you have another example or situation that would be of interest?
Post your opinion

Before we proceed with the Tcl coding example, we'll need to establish an HTTP connection to our lab router using your browser. You will need console access to your lab router to make these configuration modifications. We will add the IOS IP HTTP server command to your router's configuration. Modifications to the routers configuration can only be added with exec mode access. The exec mode is typically password protected for obvious network security reasons.


lab_router> enable 
Password: 
lab_router# 

From the IOS exec mode, you can proceed to make modifications on your lab router. Type the IOS command, configure terminal or, shorthand, conf t.


lab_router #conf t 

Enter configuration commands, one per line. End with CNTL/Z.


lab_router (config)#ip http server 
lab_router (config)#end 
lab_router# 

HTTP server authentication

Even though this is your lab router, I would like to re-enforce the issue of network security. In this example we'll configure basic HTTP authentication on our lab router. Again, from the IOS exec mode, we'll type:


lab_router #conf t 
Enter configuration commands, one per line.End with CNTL/Z. 
lab_router (config)#username spongebob password ixnay123 
lab_router (config)#end 
lab_router# 

A more exhaustive description of configuring the IOS HTTP server can be found in the Cisco Systems documentation, Cisco IOS Web Browser Commands.

Testing the HTTP server configuration

Once you have entered the HTTP server configuration, you can use your browser to test your setup. In your browser, enter the IP address or the DNS alias of your lab router. If connection is established with your router via your browser, you should see a basic authentication window; see Figure 2. In this window, enter the username and password you configured on the router for HTTP server authentication. The example has username spongebob and password ixnay123.

Screenshot of Auth Window
Figure 2. A basic authentication window on Microsoft Internet Explorer.

Once your login is successful you will see contents in your browser similar to Figure 3. This is the standard home page for a Cisco router Web server. This page is also a useful starting point for examining URLs of various IOS router commands.

Screenshot of a typical Cisco IOS router Web server home page.
Figure 3. A typical Cisco IOS router Web server home page.

With your Web browser connection into your router working and verified, we're now ready to start some Tcl coding.

Connecting to the router's HTTP server using Tcl

Related Articles

Network Test Automation with Mac OS X and Tcl


Multicast Architectures


Accessing a Cisco Router

Our first Tcl coding project will demonstrate how to connect to the Cisco router's IOS HTTP server. The Tcl routines we need have been placed into a library file, IOSHttp.tcl. This file needs to be sourced in our Tcl script. The library IOSHttp.tcl initializes the Tcl HTTP library. The library also contains routines for basic HTTP authentication; see Website Password Authentication with Tcl by Tony Darugar. Darugar's libraries, base64.tcl and http_pwd_encode.tcl, are loaded for base 64 authentication. The first line of the coding example looks like:


source IOSHttp.tcl 

This loads our library of canned HTTP routines into the Tcl interpreter. Next, we set up the router IP address and authentication ID.


# set router http server address 
set router "121.1.1.1" 
set url $router 
# set the HTTP Basic Authentication 
set username "spongebob" 
set password "ixnay123" 
set basicAuth [GetBase64String $username $password] 

The Tcl procedure GetBase64String, in IOSHttp.tcl, is the wrapper for Tony Darugar's base 64 library calls. The encoded base 64 result is stored in the Tcl variable basicAuth. This variable initialization is critical for basic HTTP authentication. Once basicAuth is set, we can connect to the Cisco router's IOS HTTP server, using the following code snippet.


# connect to the router via http server 
set statusToken [GetHttpServerURL $basicAuth $url] 

Once again, the IOSHttp.tcl library primarily contains wrapper functions. GetHttpServerURL is the wrapper for the Tcl HTTP package. The parameters passed in are the basicAuth string and a url string. The function returns a token that contains the name of the global status array. The status array holds information about the state of the URL transaction. To retrieve the actual contents of the HTML sent by the router, we must pass the statusToken to the IOSHttp procedure, GetHttpServerHTML.


# retrieve the HTML response from the globl state array 
set rawHtml [GetHttpServerHTML $statusToken] 
puts $rawHtml 

That's it! Everything you need to connect to your router in about nine lines of Tcl code. The complete listing for this example is provided in source code file, example1.tcl. Next, let's take a look at how to access the router's Cisco IOS exec mode. This is the level you'll need to access for router automation and control. To test the script, execute the following from the workstation command line:


spongebob# tclsh example1.tcl 

IOS exec level operation

All critical router operations and modifications are performed at the IOS exec level. This includes show commands and entering the router's configuration mode. I'll demonstrate in this example how to execute the IOS exec command show interfaces.


lab_router#sh interfaces 
Ethernet0 is up, line protocol is up 
Hardware is Lance, address is 0050.5433.813c (bia0050.5433.813c) 
Internet address is 121.1.1.1/24 
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, 
reliability 255/255, txload 1/255, rxload 1/255 
Encapsulation ARPA, loopback not set 
Keepalive set (10 sec) 
ARP type: ARPA, ARP Timeout 04:00:00 
Last input 00:00:00, output 00:00:00, output hang never 
Last clearing of "show interface" counters never 
Queueing strategy: fifo 
Output queue 0/40, 0 drops; input queue 0/75, 0 drops 
5 minute input rate 1000 bits/sec, 2 packets/sec 
5 minute output rate 1000 bits/sec, 2 packets/sec 
237207 packets input, 17505813 bytes, 0 no buffer 
Received 147438 broadcasts, 0 runts, 0 giants, 0 throttles 
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 
0 input packets with dribble condition detected 
209269 packets output, 14241109 bytes, 0 underruns(3/1/0) 
2 output errors, 4 collisions, 11 interface resets 
0 babbles, 0 late collision, 20 deferred 
2 lost carrier, 0 no carrier 
0 output buffer failures, 0 output buffers swapped out 
--More-- 

You can accomplish this functionality using our IOSHttp.tcl library. First, you must understand how the IOS parser operates and which mode commands operate in. All the show commands in IOS belong to the exec mode. The URL for show interfaces is simply /exec/show/interfaces/CR. Our code looks like this:


set router 121.1.1.1 
set iosurl /exec/show/interfaces/CR 
set url $router$iosurl 

In case you were wondering, yes, the CR is required at the end of a command. The CR instructs the parser to terminate and no other command options are present. The code for show interfaces is presented in example2.tcl. The example script can be executed from your workstation:


spongebob# tclsh example1.tcl 

The tip of the iceberg

Okay, so you can execute a "show interfaces" command via HTTP. Big deal, right? Well, this simple snippet of code is just to get you started. You now have your foot in the door -- of your router, that is. All operations can be performed on your router using the HTTP server, just as if you were sitting at a console. The exception to the rule is in the fact you can't perform a reload (reboot the router). You can do everything else though, and this is where the HTTP server becomes invaluable. Another consideration is to incorporate TACACS+ with the HTTP server, if you're using these network security authentication servers. Once you master regular expressions in Tcl, you'll be banging out traffic statistic charts, or monitoring what routers are running what images. The possibilities are limitless.

Michael J. Norton is a software engineer at Cisco Systems.


Return to the Mac DevCenter.

Copyright © 2009 O'Reilly Media, Inc.