Configuring a large number of similar BGP peers on a router and ensuring that the changes in your routing policy or BGP design are applied to all of them can be a management nightmare. BGP peer groups were the only scalability tool available on Cisco IOS until the IOS release 12.3T and they had significant limitations as they were also used as a performance improvement tool.

IOS releases 12.0S and 12.3T introduced peer templates, a scalable hierarchical way of configuring BGP session parameters and inbound/outbound policies. For example, to configure the session parameters for all your IBGP sessions, use the following session template:

The chances that you would be able to start SSH or Telnet session from an EEM applet were pretty slim, but the comment from melwong triggered my curiosity and I simply had to try it. After all, as the action cli command uses a VTY line (like a regular user session), you might be able to use the pattern option of the action cli command to write something similar to an expect script. This was my best shot at getting it done:

event manager applet SSH
 event none
 action 0.9 cli command "enable"
 action 1.0 cli command "ssh -l ssUser R2" pattern "word:"
 action 1.1 cli command "ssPassword" pattern "#"
 action 2.0 cli command "clear ip route *" pattern "#"
 action 3.0 cli command "exit" pattern "#"

My applet got past the SSH authentication (debugging on R2 confirmed that the SSH session was started) but could not send data through the session itself (it hung on the clear ip route command).

Brian Dennis wrote a long post about the unexpected side effects of the ip default-network command. The Cisco documentation describes the “side effects” but in an even more obscure manner.

What's really happening is this:

• If the parameter of the ip default-network command is a major network, it specifies the default route (how it gets inserted into the routing protocol you're using is a completely different story).
• If the parameter is a subnet of a major network, it specifies the default subnet for the network.

In any case, it's an obscure leftover from the classful days that should probably never be used today outside of a CCIE lab.

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:

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.