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

Re-enable debugging without EEM

In his comment to my post about re-enabling debugging after router reload, Mike pointed out an interesting IOS feature: you can execute the do command from a configuration file, not just from the user interface. To make his tip even more useful, you can store the do command(s) in an external file on a TFTP server, not in the startup configuration (which would have to be edited manually). With the boot host URL configuration command you'd then ensure that these commands are executed after the router reload.

Notes:
  • The router expects a newline character at the end of the configuration file. The best way to ensure it's always there is to add a comment line at the end of the file
  • The configuration file load usually fails immediately after the reboot, as the interfaces and IP routing processes are not yet fully operational. You might thus miss the first few seconds of the router's operations (unless you store the extra configuration file Flash or NVRAM).
add comment

Sample configuration: periodic upload of router configuration

Pete Vickers sent me a very interesting configuration sample:

To get an IOS device to upload it’s configuration periodically to an external FTP server:

ip ftp source-interface loopback 0
ip ftp username ftp_username
ip ftp password ftp_password
file prompt quiet
!
kron policy-list backup
 cli copy running-config ftp://10.20.30.40
!
kron occurrence daily-backup at 0:30 recurring
 policy-list backup

The beauty of this example is that you can use it on platforms that don't support Embedded Event Manager (which has a very similar cron functionality) as the kron commands were introduced in 12.2T and 12.3 IOS releases.

Note: You have to use the file prompt quiet configuration command as the commands executed by kron cannot supply any user input

see 7 comments

Update: The “show ip interface” command I've always wanted to have

After I've published the Tcl script that displays the interface IP parameters in a formatted table, cos quickly pointed out a bug: I've expected the IP addresses in the address mask format. In the meantime, I've figured out the root cause of the problem (our remote labs are set to display IP masks in decimal format for compatibility reasons) and fixed the Tcl script. It temporarily sets the terminal ip netmask-format to bit-count before executing the show command. The new script recognizes three parameters:

  • active: display only interfaces that are up/up;

  • configured: display only interfaces with configured IP addresses (unnumbered interfaces using IP address of an interface without one count as configured since IOS reports their IP address as 0.0.0.0).

  • address: displays IP address of the unnumbered interface, not the interface that it's borrowing the address from.
You can view the Tcl source or download it from my web site.
see 6 comments

Changing the Format of IP Routes

The comment to one of my previous posts reminded me of a cool feature that's been available in Cisco IOS for a number of years - you can change how the IP addresses and routes are displayed in various show printouts (but not in the router configuration) with the terminal ip netmask-format bit-count|decimal exec-level command. You can even make the change permanent by configuring ip netmask-format format on console and VTY lines.

And the funniest part of the whole story is that I was utterly impressed with the feature when it was introduced ... and now almost started to reinvent the wheel and implement the same functionality in Tcl

see 1 comments

Update: Preparing for the MPLS CCIP exam

Following my post about the relationship between the MPLS and VPN architectures books and CCIP MPLS exam, Peter Dob had an excellent idea: combine the MPLS and VPN architectures (Volume I, CCIP edition would be even better) with the MPLS fundamentals from Luc de Ghein. By reading Luc's book, you'll also get exposure to other MPLS-related topics (for example, AToM) on top of MPLS TE overview that you need for the exam.

This article is part of You've asked for it series.

add comment

Inspection of router-generated traffic does not recognize DHCP client traffic

After I've published a post on how you can use the new router-traffic keyword to minimize the Internet-facing access list you use with CBAC, Euphrates Greene pointed out to me that this feature does not work for client DHCP traffic (if the router is acting as a DHCP client, for example, when connected to a MAN Ethernet environment).

Once you start thinking about what's really going on, it all becomes obvious: as the router has no IP address when it sends the DHCP request, and it sends the DHCP request to a broadcast address (as it doesn't know the IP address of the upstream DHCP server), there is no session that could be entered into the CBAC session table. So you still have to allow all DHCP traffic to your router with an access-list similar to this one:
ip access-list extended Internet
 permit udp any eq bootps any eq bootpc
 deny ip any any

Note: Replace the highlighted any keyword with the actual DHCP server's IP adress if you have it available and you want to have an even more secure IP access-list.

add comment

DHCP and BOOTP coexistence

If you have an existing BOOTP environment (for example, a set of old Unix workstations and X-terminals) and want to deploy DHCP on the same LAN segment, you could run into interesting compatibility issues, as the DHCP servers by default responds to BOOTP requests.

However, IOS has an interesting feature when you use a router as a DHCP server: you can tell it to ignore the BOOTP requests with the ip dhcp bootp ignore global configuration command (introduced in 12.2T and 12.3). Even more, the router can respond to DHCP requests and forward BOOTP requests to a non-local BOOTP server configured with the ip helper-address interface configuration command.
see 1 comments
Sidebar