Scripting
Expect Script – Daylight Saving Time
5I recently received a message from someone looking for someway to automated the re-configuration of over 100 switches with the correct Daylight Saving Time configuration. I explained to the person that the best long term solution would probably be to use the SNMP MIB but a quick and dirty solution might be to use Expect and call it from a Bash script looping over all the switches that needed to be re-configured. In short Expect is a scripting language that mimics user input at a TTY. The Except script is written to issue a set of commands, as if a human were typing them, and expects various responses.
The script I wrote below only support a limited number of switches. If you have a particular switch you’re welcome to modify the script to support that particular switch. The script will attempt to determine if the switch is running the software that has the features we’re looking to implement. I didn’t have a whole lot of time to test so buyer beware!
Here’s the expect script that I authored;
#!/usr/bin/expect -f
#
##############################################################################
#
# Filename: /usr/local/etc/set-nortel-timezone.exp
#
# Purpose: Expect script designed to telnet into Nortel Ethernet Switches
# and execute the CLI commands to confgure the appropriate timezone
# information, including Day Light Saving time.
#
# Switches: Ethernet Switch 460 v3.7.x
# Ethernet Switch 470 v3.7.x
# Ethernet Switch 4500 v5.2.x
# Ethernet Switch 5500 v5.1.x
#
# Author: Michael McNamara
#
# Date: June 1, 2008
#
# Version: 1.1
#
# Changes:
#
# June 8, 2008 (M.McNamara)
# - added documentation and ARGV command line checks
# June 14, 2008 (M.McNamara)
# - added check for switch version and exit if v3.6 switch software
# - added check for Username introduced in v3.7 switch software
#
#
##############################################################################
#
# This Expect script was generated by autoexpect on Wed Jul 27 17:25:28 2005
# Expect and autoexpect were both written by Don Libes, NIST.
#
set force_conservative 1 ;# set to 1 to force conservative mode even if
;# script wasn't run conservatively originally
if {$force_conservative} {
set send_slow {1 .1}
proc send {ignore arg} {
sleep .1
exp_send -s -- $arg
}
}
if {[llength $argv] != 2} {
puts "usage: set-nortel-timezone.exp < SWITCH > < PASSWORD >>"
exit 1
}
#
set PATH "/usr/local/etc/"
set TELNET "/usr/bin/telnet"
set SWITCH [lindex $argv 0]
set PASSWORD [lindex $argv 1]
set TODAY [timestamp -format %y%m%d ]
set WEEKDAY [timestamp -format %a ]
set DATE [timestamp -format %c ]
set send_human {.1 .3 1 .05 2}
#log_file $PATH/$SWITCH.expect.log
log_file /usr/local/etc/password.expect.log
log_user 0 # Disable logging to STDOUT
#log_user 1 # Enable logging to STDOUT
set timeout 10
spawn $TELNET $SWITCH
match_max 100000
expect "Trying"
expect {
"Connected" {
expect "SW:v3.6" {
send_log "\n\nThis version of software doesn't support the CLI commands!\n"
send_user "\n\nThis version of software doesn't support the CLI commands!\n"
exit 1
}
sleep 1
send -- ""
}
Timeout {
send_log "We're unable to connect to the switch $SWITCH"
send_user "We're unable to connect to the switch $SWITCH"
exit 1;
}
}
expect {
"Username" {
send -- "RW\r"
}
}
expect "Enter Password"
send -- "$PASSWORD\r"
expect {
"Main Menu" {
}
"Incorrect Password" {
send_log "$SWITCH : Incorrect Password"
exit 1
}
"Incorrect Credentials" {
send_log "$SWITCH: Incorrect Credentials"
exit 1
}
}
sleep 1
# Let's get into the CLI interface from the menu prompts
send -- "C"
# Depending on the version of software we sometimes need a CR/LF
send -- "\r"
sleep 1
# Let's wait for the CLI prompt which includes the #
expect "#"
send -- "config term\r"
send -- "clock time-zone EST -5\r"
send -- "clock summer-time EDT date 9 Mar 2008 2:00 2 Nov 2008 2:00 +60\r"
send -- "exit\r"
send -- "logout\r"
expect eofYou can download the entire Expect script from this URL; set-nortel-timezone.exp.
The command line arguments are fairly straight forward;
usage: set-nortel-timezone.exp <SWITCH> <PASSWORD>
Where the SWITCH is the fully qualified domain name (FQDN) or the IP address of the switch in question and the PASSWORD is the Read-Write password for the switch.
If you had hundreds of switches to reconfigure you could wrap this Except script in a Bash shell script similar to the following;
#!/bin/bash # ##################################################################### # # Language: Bash Shell Script # # Filename: /usr/local/etc/set-nortel-timezone.sh # # Purpose: This script will kickoff the Expect script that will # configure the Daylight Saving Time features for each switch # # Author: Michael McNamara # # Date: June 1, 2008 # # Version: 1.0 # # Changes: # # June 10, 2006 (M.McNamara) # - added remote sites into shell script processing # ##################################################################### # # Variables PATH_TO=/usr/local/etc UPGRADE=set-nortel-timezone.exp MAIL_LIST='' PAGER_LIST='' ERROR_FLAG=0 MAILEXE='/usr/bin/mutt' LOCKFILE=/tmp/trace.lck # Check paramaters if [ "$#" != 2 ] then echo "Usage: `basename $0` <password>" exit 1 fi PASSWORD=$1 ##################################################################### ##################################################################### # YOU SHOULD EDIT THE "SWITCHES" VARIABLE BELOW TO INCLUDE ALL THE # SWITCHES THAT YOU WISH TO HAVE THE EXPECT SCRIPT RUN AGAINST ##################################################################### ##################################################################### SWITCHES='sw1-5520.acme.org sw2-5520.acme.org sw3-5520.acme.org' for SWITCH in $SWITCHES do $PATH_TO/$UPGRADE $SWITCH $PASSWORD done exit
You can download the Bash shell script from this URL; set-nortel-timezone.sh.
I’ve only tested this on CentOS v5.2 but it should work on any Linux host with Expect installed although you may need to modify the path locations.
Cheers!
WiFi Hotspot Portal
1I needed to provide a public WiFi hotspot across our existing corporate wireless infrastructure at our five major sites. It obviously needed to be secure from our internal network, it needed to be 100% automated (there were no resources available to support this offering) and it needed to work (there’s a surprise requirement). We also needed to keep internal (corporate) laptops and wireless devices from connecting to the unencrypted network and circumventing current Internet access policies.
Because of security concerns I decided to only allow HTTP (TCP 80) and HTTPS (TCP 443) traffic from the public wireless network. I also tabled any ideas of content/URL filtering from the original design. Instead we would reliable on Blue Coat ProxySG/ProxyAV appliances and Websense to perform content filtering and AV scanning of the traffic in a later upgrade.
How did we do it?
We carved out an ESSID (“public”) from our Motorola Wireless LAN infrastructure at each facility. We setup the wireless network without any encryption or security so as to minimize any end-user difficulties in connecting to the wireless network. We took CentOS and built a WiFi portal server/gateway/firewall/router using an HP Proliant DL360. We essentially turned our Linux server into a cheap and very efficient firewall/gateway for the WiFi Hotspot. We connected one NIC of the Linux server to the wireless WLAN and the other to our internal network. This allowed use to use the Linux server to provide IP addresses to the wireless devices through DHCP. It also allowed use to have the Linux server provide DNS for name resolution. And most importantly it allowed use to use IPtables to provide firewalling between the wireless network and our internal network. This solution also allowed us to implement bandwidth shaping/throttling to prevent the public WiFi Hotspot wireless users from utilizing too much of our Internet link (DS-3 ~ 45Mbps).
Once a device associates with the wireless network the Linux portal server will issue the device a DHCP address from the 192.168.16.0/20 network. When the user opens their web browser they will be redirected to the Linux portal web server and the registration page as it appears below;
Once the user clicks on the “I AGREE” button the Linux server will kick off the “register.pl” script to check the IP/MAC address and decide if they should be granted access. If they are granted access they will be redirected to our Internet homepage after which they’ll be free to surf to any URL. If the user is denied access they will be directed to an error page.
It is also possible that the user may attempt to register multiple times due to their web browser caching the portal page contents as the contents of a legitimate Internet website. Example: A user opens their web browser to www.cnn.com and is greeted with the portal page. User registers that is then re-directed to www.acme.org. The user then types www.cnn.com back into the browser address bar, but instead of getting the legit content for the CNN website the user is greeted again by the portal page. The user not knowing any better clicks the “I AGREE” button for the second time in as many minutes. Previously this problem would have gone on and on over and over, now the system will detect that the user is already registered and will through an error alerting the user to “refresh” their web browser. In order to refresh the browser the user should just type in the URL of the website they are attempting to visit and click “Go” (or hit “enter”). If they are greeted with the portal page they should click the “refresh” button from the browser button bar. That will instruct the web browser to ignore any cached content and attempt to retrieve all the data direct from the source website.
Every night at midnight the firewall rules will be reset to the defaults. Requiring any that wishes to access the WiFi Hotspot to agree to the AUP again. This is done to prevent folks from continually sitting/camping on the WiFi Hotspot.
Initially I thought we might be able to use a VPN or GRE tunnel to connect the five public WLANs to a single Linux server. Unfortunately I was a little ahead of the times and VPN/GRE tunnels were just starting to be supported in the various wireless switches (Motorola in this case). So I decided to take an easier approach and installed five HP Prolaint DL360 servers, one for each site.
I’m very happy to report that the solution works very well and virtually supports itself.
The only issue that we’ve seen is the need to continually update the blacklist file to keep corporate wireless devices from connecting to the public network. Thankfully I’ve written a small Bash Shell script to help with that process.
I hope to write a more detailed account of how to set this up on my website sometime in the future. If your interested in hearing more or have questions please drop me a line.
Cheers!
Perl Scripting
11
I really like using Perl because of the Net-SNMP Perl libraries that make it really easy to write code to interact with devices that support SNMP.
Hopefully everyone out there is backing up their network switch configurations in the unlikely event that if their hardware dies they only need to worry about replacing the hardware and not about re-configuring the entire switch.
Quite a few years back I wrote a Perl script that would send the proper SNMP commands to instruct a network switch to copy it’s configuration to a TFTP server. This script essentially became known as “switchtftpbackup.pl” It’s nothing fancy or pretty but it gets the job done.
I’ve posted this Perl script on my webiste under the Perl section.
I run this script from Cron one of our CentOS Linux servers at work every week. The same server also acts as a central TFTP server for the entire organization. I also run other scripts that then archive the weekly backups, in the event that I need to go to a backup that’s more than a week old.
I believe both Nortel’s Optivity NMS and Cisco’s Cisco Works both have options to backup switch configurations these days.
What are you using?
Cheers!


