If you're too young to remember the days of IBM mainframes, punched cards and 132-column printouts, you could get a feeling for what we had to cope with by looking at the original RFC texts. Even the latest RFCs are published in text-only fixed-font format with no extra formatting, making it a nightmare to quote a section of the RFC in a post or an article (not to mention the very real danger of falling asleep just by looking at an RFC).

A variety of third-party web sites have tried to fill the gap by providing RFCs in hyperlinked or PDF format. I've tried a few of them and usually got turned away by inconsistent or broken links.

Finally, IETF recognized that we live in the third millenium and started offering IETF documents (including RFCs) with HTML markup. To get hyperlinked versions of the RFCs, go to IETF tools web site and enter RFC number or use Google to search the IETF repository.

Olivier Guillemain has asked an interesting question: “how could I originate a default route into OSPF based on IP SLA (for example, based on pinging a remote IP address)?”

This is very easy to do when the router originating the default route into OSPF needs an SLA-based default route itself:

1. Configure IP SLA and a corresponding track object;
2. Configure a default route using reliable static routing
3. Advertise the default route into OSPF with the default-information originate router configuration command

The solution is a bit more complex when the router originating the default route into OSPF should not have a default route. In this case, you could use a routing trick:

1. Configure IP SLA and a corresponding track object as before;
2. Use reliable static routing to configure a static host route for a bogus IP address (for example, 10.0.0.1/32) pointing to null0 (for example, ip route 10.0.0.1 255.255.255.255 null 0 track 100). Obviously, this host route should not be redistributed into any routing protocol.
3. Conditionally advertise default route into OSPF based on presence of the static host route.

The routing information you source into the public Internet with BGP should be as accurate and stable as possible. The best way to achieve this goal is to statically configure the IP prefixes you’ve been allocated on your core routers and advertise them into BGP:

• BGP will only advertise an IP prefix if a matching entry is found in the IP routing table. To ensure the IP prefix you want to advertise is always present, configure an IP static route to null interface, unless you're advertising a connected interface (example: Internet edge router on a DMZ segment).
• Most public IP prefixes advertised today do not fall on the classful network boundary. To advertise a classless prefix, you have to configure the prefix and the mask in the BGP routing process.

Internal BGP (IBGP) sessions (BGP sessions within your autonomous system) are identified by the neighbor’s AS number being identical to your AS number. While the external BGP (EBGP) sessions are usually established between directly connected routers, IBGP sessions are expected to be configured across the network.

The current best practice is to configure IBGP sessions between the loopback interfaces of the BGP neighbors, ensuring that the TCP session between them (and the BGP adjacency using the TCP session) will not be disrupted after a physical link failure as long as there is an alternate path toward the adjacent router.

Terry Slattery took time (after 15 years) and wrote a short history of Cisco CLI. I've been involved with Cisco's software (it was remarketed as IOS in mid-nineties) for a few years and for me the CLI as we know it today was one of the best features introduced in IOS release 9.21 (I was ecstatic when I've got my hands on the first code during the beta tests). So now that I know who's responsible, I can only say “Thanks, Terry!”

I've stumbled across an interesting problem recently:

• I've added a Linux box to my home network;
• It used my Cisco router to get a dynamic DHCP address;
• I've inspected the DHCP bindings on the Cisco router to find the new MAC address and configured a host DHCP pool as I'm using the Linux box as a server;
• Even after multiple configuration changes, the IOS would fail to use the host DHCP pool.

The only solution I've found was to restart the IOS DHCP server with the no service dhcp followed by service dhcp configuration commands. Obviously, you lose all DHCP bindings when you restart the DHCP server (which could be a problem if you use conflict logging) unless you've configured the router to store them in an external file.

If you do a lot of telnetting in your lab, you could set up an internal DNS server to be able to use router names instead of IP addresses.

Were you ever in a situation where a file that would have to be on the router was sitting on your laptop, but you couldn't store it into the router's flash across the Telnet session or through the console port?

If the file in question is a text file, and the router supports Tcl shell, _danshtr_ documented an interesting trick: you create the file in Tclsh interpreter, cut-and-paste the text through the telnet session into a Tcl string and write the string to the file. If you want to have a more cryptic solution here it is:

• Start tclsh;
• Enter puts [open "flash:filename" w+] {. Do not hit the ENTER key at the end of the line
• Copy-paste the file contents. The contents should not include unmatched curly right brackets (every curly right bracket has to be preceded by a matching curly left bracket).
• After the file contents have been pasted, enter } and press ENTER.
• End the tclsh session with tclquit.

In one of his posts, Joe Harris describes a great Linux-based WAN emulation toolkit that you can use to introduce latency, bandwidth constraints or packet loss in your lab environment.

In the last few months I ran across a number of IP fragmentation issues. Unfortunately I also encountered a lot of misconceptions about IP fragmentation, its impact on GRE and IPSec, as well as the fragmentation-related mechanisms like MTU Path Discovery. I documented most of what I found in the The Never-Ending Story of IP Fragmentation.

In a response to my post Redundant DHCP Server I've speculated that a Cisco router should coexist with a Windows-based DHCP server if you configure them with non-overlapping address ranges. I was wrong, Edgar Cahuana discovered that Microsoft's DHCP server wants to have complete control over the LAN it's serving and shuts down if it detects another DHCP server on the same LAN.

To make the two DHCP servers coexist, you have to disable rogue DHCP server detection in Windows DHCP server.

Sometimes you end up having wrong BGP AS number throughout your network. It could be a result of an unexpected merger or split or you could have started using a private BGP AS number and realized you have to connect to the Internet using a real AS number. The proper solution would be a total reconfiguration of the whole network, but of course not many engineers have the time and courage to do it ;), so it's time to introduce another kludge: the neighbor local-as configuration command.

If you do a lot of tests in a router lab, you're probably getting upset when you have to retype the login and enable password whenever you log into a router. What I do in my labs is to disable VTY login, set the default privilege level to 15 and disable exec timeout (to stop the router from terminating my session).

line con 0
 exec-timeout 0 0
 privilege level 15
line vty 0 4
 exec-timeout 0 0
 privilege level 15
 no login

Obviously, this would not bring you additional points on the CCIE lab exam :)

You've probably already heard the phrase "When the only tool you have is a hammer, everything looks like a nail" (and seen people acting according to it). Likewise, if you have an IOS release with EEM support, a lot of things that would require smart design could be solved in a brute-force way with a few EEM applets. For example, the problem of the BGP default route could be solved “easily” with a few applets that track syslog messages reporting when the BGP neighbors go up/down.

Cisco IOS allows you to define aliases for the commands you commonly use with the alias global configuration command. The alias command accepts the CLI mode (exec, configuration ...) for the new command and the string that replaces the command name. If you specify additional parameters in the new command, they are appended to the alias string.

For example, if want to have the ipconfig command that displays interface IP configuration, you can configure alias exec ipconfig show ip interface. When you execute ipconfig ifname the alias is expanded into show ip interface ifname and displays the IP configuration of a single interface.