Using Tcl packages on Cisco IOS

Although it's not exactly trivial, you can use standard Tcl packages with Tcl
shell on Cisco IOS by following this procedure:

$ tclsh
% pkg_mkIndex . *.tcl
% ^Z
$
  • Edit the pkgIndex.tcl file created with the pkg_mkIndex command and set the $dir variable to the IOS directory before the first package command (for example, set dir "flash:tcl/").
  • Alternatively, add the Tcl command set dir [file dirname [info script]] in front of the first package command. This command sets the $dir variable to the path of the pkgIndex.tcl file.
  • Transfer all the source files into a directory on the router's flash (or any other local storage device).
  • Configure the execution of the pkgIndex.tcl file at tclsh startup with the scripting tcl init configuration command (for example, scripting tcl init flash:tcl/pkgIndex.tcl).

When you have completed these steps, the pkgIndex.tcl file will be executed every time the Tcl shell is started in Cisco IOS, defining all the packages you've prepared. Now you can use the package require name Tcl command to load the packages you need in your Tcl script.

see 2 comments

Don't miss the obvious

I've recently replaced my old home router (well, actually a combination of two low-end models, one could handle ISDN and the other one 3DES) with a 1812. After I've struggled past the “interesting” interface names (it has 8 switched ports, named FastEthernet2 to FastEthernet9) and brushed up my BVI/VLAN skills, configuring it was a breeze … only the DHCP server was causing me problems; every time my laptop would wake from the standby mode, it would take almost half a minute before it got the LAN IP address. The obvious suspect (as I've installed the 12.4(15)T on it) was the software, the next one DHCP ping timers.

After replacing the software (didn't help) and tweaking DHCP timers (no change), it finally dawned on me: the ethernet ports are switched, so the spanning tree was playing tricks with me. Disabling spanning tree with the spanning-tree portfast interface configuration command solved the problem.
see 13 comments

Track interface IP routing detects incorrect interface state

The track number interface name ip routing command is supposed to track an interface readiness to forward IP packets. In reality, it only tracks the interface line protocol status plus the IPCP status in case of PPP interfaces (as well as the actual presence of an IP address on the interface). If you configure IP Event Dampening (with the dampening) command, the interface might be suppressed (unavailable for IP routing), but the track object will report it as available (tested on IOS release 12.4(6)T). This could result in suboptimal HSRP/GLBP decisions if you use track objects to influence HSRP/GLBP priority or actual loss of data if you use such a track object to control policy-based routing.
read more see 2 comments

MPLS LDP Autoconfiguration

Most MPLS books (mine included) and courses tell you that you have to manually enable MPLS on each interface where you want to run it with the mpls ip interface configuration command. However, this task was significantly simplified in IOS release 12.3(14)T with the introduction of MPLS LDP autoconfiguration. If you use OSPF as the routing protocol in your network, you can use the mpls autoconfig ldp [area number] router configuration command to enable LDP on all interfaces running OSPF (optionally limited to an OSPF area).

As the careful readers of my MPLS books know, it’s dangerous to run LDP with your customers; the moment you run LDP with them (Carrier’s carrier model is an exception), they can insert any labeled packet into your network, bypassing inbound access lists and sending traffic where it’s not supposed to go (even into another VPN). It’s vital that you consider security implications before deploying MPLS LDP autoconfiguration.

Using this feature on P routers is absolutely safe, as they have no customer links. You have to be more careful on the PE routers, more so if you run routing protocols with your customers. The safest configuration method would be to configure LDP autoconfiguration inside a single OSPF area, but even then, a configuration error (placing a PE-CE interface in a wrong area) could open your network to MPLS-based attacks.

see 1 comments

Warm reload does not change the config register

Contrary to what the regular reload does, the warm reload does not change the configuration register value (obviously that's done by ROMMON, which is not involved in the warm reload process). If you just did a password recovery and changed the configuration register back to a normal value, you'd thus be unpleasantly surprised when the NVRAM would be ignored (yet again) after a warm reload (I stumbled across this as I was trying a new IOS release with the reload warm file URL command).
add comment

DHCP-based static routes

If you have configured your router as a DHCP client, you can use the default router option received in a DHCP reply as the next-hop for a static route. For example:
ip route 10.0.0.0 255.0.0.0 dhcp
You could use this functionality in scenarios where your core network uses DHCP (for example, in metropolitan networks using layer-2 Ethernet transport from an ISP), but your router needs a different default route.

You can also use this feature to change the administrative distance of the DHCP-based default route (or you could use the ip dhcp-client default-router distance value configuration command that one of the readers described in a comment to a previous DHCP-related post).

Any other good ideas where this might come handy? Post them as comments ...
see 4 comments

Reload a Router from Tcl Script

In his comment, Michal has asked about the ability to execute IOS commands with prompts from Tcl shell. I haven't found a generic solution yet, but you can reload a router from a Tcl script. First you have to define an EEM applet that reloads the router and can be triggered from command-line interface:
event manager applet forceReload
event none
action 1.0 reload
Now you can use the exec "event manager run forceReload" Tcl command in your Tcl script to run the applet (and reload the router).

Notes:

see 2 comments

Import DHCP options from an upstream DHCP server

If your router gets its IP address from an upstream DHCP server, it can automatically import the other DHCP options (DNS server, WINS server, domain prefix etc.) into its DHCP pools. For example, if you use a router to connect to a cable or MAN Ethernet ISP (see the following figure), you can use the DHCP option import to minimize your router configuration (and make it fail safe from any changes in the ISP network).

To configure the DHCP option import, use the import all DHCP pool configuration command. You cannot select which options you want to import, but you can override them with other DHCP pool configuration commands.

read more see 4 comments

OSPF Graceful Shutdown

Reloading a core router in a high-availability network is always a tricky proposition. Even if you tweak the routing protocol hello timers (or use fast L2 mechanisms to detect next-hop loss), it still takes a few seconds for the routing protocols to converge. For example, when using OSPF, the adjacent routers have to detect the neighbor loss, change their router LSAs, flood them (LSA flooding is rate-limited), the changed LSAs have to be propagated across the whole area and all routers in the area have to run SPF (which is also rate-limited).

It would be much better if you could gracefully take a router offline by increasing the OSPF cost on all its interfaces, thus forcing an OSPF SPF run while the router is still capable of forwarding the traffic (resulting in no packet loss).

read more see 14 comments

Default DHCP client-id

If you configure a Cisco router as a DHCP client, you'll notice that it uses weird client-id in its DHCP requests (assuming you care about client IDs on the DHCP server). Instead of using the interface MAC address as the client ID (as most workstations do), the client ID is the string 'cisco-dotted.mac.ascii-ifname' where the dotted.mac.ascii is the interface MAC address in ascii and the ifname is the short interface name.

Obviously, if your ISP checks your MAC address (and at least most cable operators do), you might have a problem. To make the router behave like a workstation, use the ip address dhcp client-id interface-name configuration command. The new client ID will be the MAC address of the specified interface (which can be different from the interface you're configuring).
read more see 3 comments

Example: Tcl script with command-line parameters

In a comment to the “Execute multiple commands at once” post, Michal has asked for a complete Tcl-shell-with-parameter example. Here's a short script that shuts down the interface and displays its status:

  • Variable ifname is set to the value of the first command-line parameter (in many other programming languages, this would be written as argv[0]);
  • If the ifname is empty, the script aborts and prints the usage guidelines (again, in a more human-oriented programming language, this would be if (ifname == “”) ...);
  • The show ip interface ifname command is executed. If it fails, the interface name is not correct and the script aborts.
  • IOS configuration commands interface ifname and shutdown are executed.
  • The show ip interface brief configuration command is executed and filtered with the interface name.
#
# ifname is set to first CLI parameter (interface name)
#
set ifname [lindex $argv 0]
if {[string equal $ifname ""]} { puts "Usage: shutdown ifname"; return; }
if { [ catch { exec "show ip interface $ifname" } errmsg ] } {
puts "Invalid interface $ifname, show ip interface failed"; return}

ios_config "interface $ifname" "shutdown"
puts [ exec "show ip interface brief ¦ include $ifname" ]

If you store this Tcl script into your flash as shutdown.tcl and configure alias exec shutdown tclsh flash:shutdown.tcl, you can execute the command shutdown Serial0 to shut down the serial interface.

Notes:

  • The last show command will display the interface status only if the specified interface name exactly matches the actual IOS interface name (whereas the rest of the script accepts shortcut names). The more generic matching algorithm is left as an exercise for the reader
  • For more in-depth information on Tclsh implementation on Cisco IOS, read the IOS Tclsh resources.
  • This article is part of You've asked for it series.
see 10 comments
Sidebar