Blog Posts in September 2007
Update: mturoute
- Any C program compiled with the free Visual C++ compiler from Microsoft requires runtime library that has to be installed separately. Update: not completely true, if you use change the runtime library to the non-DLL version (Project properties/C++/Code generation tab), the exe size increases, but the external dependencies are removed.
- The Visual C++ 2008 that I've used has no publicly available runtime library that you could install.
- The new build can be downloaded from the same location.
- It includes a README file that documents the changes made to the source.
- To run it, you have to install the VC++ 2005 runtime library from Microsoft
There are also a few caveats when using this program on a Windows platform enabled for Path MTU discovery (default for the last few years):
- Whenever the Windows TCP stack receives an ICMP specifying the maximum MTU, it caches the reported MTU size (makes sense).
- The cached MTU sizes eventually expire (but I was not able to find any documentation on the expiration time).
- I was also not able to find any documented way of purging the path MTU cache. The command that works for me is the route -f which flushes the IP routing table.
- Obviously, after executing route -f, the DHCP-installed default route is gone, so you have to execute ipconfig /renew.
Note: Any hints on the internal workings of path MTU cache on Windows platforms are highly appreciated
mturoute: A utility that measures hop-by-hop path MTU
Stop Inter-VRF static route leaking
The MPLS VPN implementation on Cisco IOS has always allowed you to create VRF static routes that pointed to interfaces belonging to other VRFs. The feature can be used to implement interesting overlapping VPN (or common services VPN) designs, some of which are explained in the MPLS and VPN Architectures books.
However, quite often the ability to create inter-VRF static routes is considered a major security problem, as an operator configuration error could establish undesired inter-VPN connectivity. In these cases, use the no ip route static inter-vrf configuration command to prevent such routes from being installed in the VRF routing table.
You might also want to read a good explanation of MPLS VPN route leaking from Cisco systems
Router as a TFTP server
Fortunately, as of IOS 11.0, the function is more generic; you can serve any file residing on the router (you still cannot upload files), but you have to declare each file to be served with the tftp-server path global configuration command. You could even specify an alias to have the file available under a different name and attach an access list to each configured file to restrict its availability.
Note: This article is part of You've asked for it series.
Material worth reading
EEM syslog messages look like debugging messages
Five routers on your laptop
In case you haven't heard about Dynamips/Dynagen yet: Dynamips emulates a variety of IOS platforms (from 2600 to 7200) on Intel platform and Dynagen provides friendlier user interface (more than friendly enough for me, probably too cryptic for GUI addicts). I've seen Dynamips a year or two ago, checked what it can do and decided to stay with the real routers in a remote lab environment. In the meantime, the software has improved drastically, allowing you to test all sorts of IOS features and topologies, as long as you don't expect QoS to work or real-time features to act in real-time (simulation is, after all, a bit slower than the real life).
To start using this tool, download it from dynagen.org, read the tutorial and you're in business. I will also start providing more interesting scenarios in the dynagen configuration file format.
Let me conclude with a few tips:
- If you don't need 7200-specific features, select 37xx or 26xx platform, it consumes less virtual memory per router.
- Setting idlepc is mandatory if you want to have decent response. Read the tutorial, the idlepc section is great.
- Unzip the IOS files. With uncompressed files, the routers are ready to be configured in under a minute on my laptop; if the IOS image is compressed, it takes several minutes.
- If you have larger topologies, use GhostIOS and Sparsemem features.
- Reduce the size of NVRAM and Flash to minimum that would work. These are stored as persistent files on your disk; you can have 256MB Flash if you want, but then you'll have 256MB less of your hard drive (per router).
With all the above-mentioned features enabled, I was easily running eight 3700-series routers on my laptop (IBM T60).
Frame Relay congestion management
In the “good old days” we've been teaching our students that although a router can act as a Frame Relay switch, it supports only the rudimentary functionality of switching the packets, but not the policing/marking features available in Frame Relay switches. That hasn't been true for a while - in IOS release 12.1T, Cisco has introduced the congestion management features. You can specify the congestion management per-interface (with the frame-relay congestion-management interface configuration command) and set the DE drop/ECN mark percentages for all PVCs on the interface or you can set the parameters within a map-class.
I don't know how useful this feature is to you; I was fond of finding it because it solves some interesting problems I had a (long) while ago. If you need more in-depth description or actual configurations, post a comment or send me a message.
Assigning Server IP addresses with DHCP
Using DHCP to assign server IP addresses is usually not a wise decision. To start with, you have to define static DHCP mappings, which rely on client-id attribute in the DHCP request (usually the MAC address of the client). For me, the easiest way to find the correct client ID is as follows:
- Use DHCP to assign the IP address to the server
- Note the newly assigned IP address
- Use the show ip dhcp bindings | include ip-address command to display the client-id to IP address binding.
- Create a static DHCP mapping (for example, by configuring a host DHCP pool on the router) and release/renew IP address on the server
CEF accounting
The "How could we figure out if any traffic uses the default route" challenge was obviously too easy; a number of readers quickly realized that the CEF accounting can do what we need (and I have to admit I've completely missed it).
However, when I started to explore the various CEF accounting features, it turned out the whole thing is not as simple as it looks. To start with, the ip cef accounting global configuration command configures three completely unrelated accounting features: per-prefix accounting (that we need), traffic matrix accounting (configured with the non-recursive keyword) and prefix-length accounting.
The per-prefix accounting is the easiest one to understand: every time a packet is forwarded through a CEF lookup, the counters attached to the CEF prefix entry are increased. To clear the CEF counters, you can use the clear ip cef address prefix-statistics command. The per-prefix counters are also lost when the IP prefix is removed from the CEF table (for example, because it temporarily disappears from the IP routing table during network convergence process). The CEF per-prefix accounting is thus less reliable than other accounting mechanisms (for example, IP accounting).
Note: The CEF per-prefix counters are always present; if the CEF per-prefix accounting is not configured, they simply remain zero.
Last but not least, you don't need the detail keyword if you want to display the CEF accounting data for a particular prefix. The show ip cef address mask command is enough. And, finally, if you're running IOS release 12.2SB or 12.2XN, you can inspect the CEF counters with SNMP.
Increased Number of OSPF processes in MPLS VPN Environments
When we were writing the MPLS and VPN architectures books, there was a limit on the number of OSPF processes you could configure per PE-router. The limit was based on the fact that IOS supports up to 32 routing information sources. Two of them are static and connected; you also need an IGP and BGP in the MPLS VPN backbone, resulting in 28 OSPF processes that could be configured on a single PE router. This “feature” severely limited OSPF-based MPLS VPN deployments until IOS release 12.3(4)T when the limitation was removed, resulting in the availability of up to 30 routing processes per VRF.
RIP, BGP, and EIGRP never experienced the same limitations as you configure VRF-specific routing instances within address families of a single routing protocol
Logging to flash disk
- The directory argument specifies where you want the files to be stored (for example, flash:/logging).
- The filesystem-size specifies the maximum disk space the logging files can consume (once you exceed the limit, the oldest file is deleted)
- The logging-file-size parameter specifies the maximum size of each file (once the file grows too large, a new file is created).
Note: You can store the log files on the router's flash memory if it appears as a disk file system (check with the show file systems command). Wouldn't it be great if this feature would also work on USB drives ...
DNS resolver package for IOS Tcl
- Extract all the files from the ZIP archive and copy the Tcl files into a subdirectory on your router's flash (I would recommend you use flash:tcllib/dns).
- Configure the package initialization script with the scripting tcl init flash:tcllib/dns/pkgIndex.tcl global configuration command
router#tclsh
router(tcl)#package require dns
1.3.1
router(tcl)#
Static routing with Catalyst 3750: and the winner is …
The Static routing with Catalyst 3750 post has generated a lot of good, creative ideas. Some of the proposed solutions were better than the others and some were simply not implementable (but nonetheless, had great creative potential :). Here is my list of the favorites:
A routing protocol: as a few of you have rightly pointed out, this is the best choice.
Aggressive Unidirectional Link Detection (UDLD): this is my second favorite, as it's a reliable link-level mechanism that will detect a break in the fiber cable … exactly the right tool for the job.
Workaround: track the actual IP routing status of an interface
- Create a static IP route pointing to the interface you want to test. Make sure this route is not redistributed into any routing protocols.
- Track the reachability of the static route
Get Creative: Static Routing with Catalyst 3750
Here's an interesting scenario:
We have two sites, each using a Catalyst 3750 switch, and routing between them using static routes. There's a primary fiber link between them and we're using twisted-pair-to-fiber converters due to port limitations on Cat3750. These converters do not report fiber link down status correctly (the carrier is still present on twisted pair even if fiber is down), so the primary Ethernet interfaces do not go down if the fiber link breaks and the primary static route is not removed, requiring manual action to switch over to the backup link.
The setup is summarized in this diagram:
Persistent DHCP bindings stored in NVRAM
If you'd like to implement persistent DHCP bindings on Cisco IOS, but cannot store them on an external server, you could always use the on-board NVRAM. Simply configure ip dhcp database nvram:dhcp.txt. Later on, you can examine the contents of the dhcp.txt file with more nvram:dhcp.txt command.
This post was written in 2007, when a lot of low-end Cisco routers still shipped with flash formatted in the “old” Cisco format and the flash was not really usable to store ever-changing files. For more details on storing DHCP bindings in onboard flash, read the Flash-based DHCP Database blog post.
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:
- Install a Tcl interpreter on your workstation (use ActiveState's ActiveTcl in Windows environment).
- Collect all the source files needed for your set of packages into one directory on your workstation.
- Execute Tcl pkg_mkIndex command in that directory.
$ 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.
Don't miss the obvious
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.