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.
DHCP conflict logging: the true story
The on-line configuration help for the ip dhcp conflict logging configuration command (logging: Record address conflicts in a log file) is one of the more misleading texts I've found in Cisco IOS (and the CCO documentation is not much better). Here's how it actually works ...
Track interface IP routing detects incorrect interface state
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.
Insert Responses to Command Prompts in Tclsh
I have been aware of the typeahead Tcl command for months, but somehow I never got it to work.
It works perfectly in IOS release 12.4(15)T; this is what you have to do to clear interface counters:
Skip the “show ip route” legend
Install a Static Route When an IP Address Is NOT Reachable
One of my readers recently asked an interesting question: “How do you install a static route when an IP address is not reachable?”
Without going into the design reasons that prompted the question, you can actually track when IP SLA measurement fails with an obscure configuration syntax of the track objects that tracks when another track object fails.