Blog Posts in January 2009
Readers of my blog have probably noticed that I’m occasionally documenting the shortcomings of DNS and DHCP servers built into Cisco IOS (I will not even mention the HTTP server, this one gets constantly degraded). On the other hand, although you could centralize all these services, the centralization makes the branch offices completely dependent on the availability of WAN uplinks; without a working uplink, a branch office stops completely.
Another undocumented (and thus very probably unsupported) Tcl-on-IOS detail: numerous Tcl packages are bundled with IOS and available in the tmpsys:lib/tcl directory (the tmpsys: is a virtual file system mapped to a part of the IOS image).
I’ve just opened the January Technical Services News from Cisco. Nothing in there that would really interest me. Almost no routing protocols (one OSPF article), no BGP, no MPLS VPN. Based solely on this newsletter, one could get the feeling that I’m producing more documents covering core IP routing in a month than Cisco (I am positive that’s not the case).
But maybe Cisco’s engineers are refocusing on the new Support Wiki. Not really. After I’ve filtered out sequential changes to a single document, there were only 11 significantly changed documents in the Support Wiki in the last 30 days.
So I’m left wondering … what’s going on? Has everything already been written about the core IP routing features and the productive minds have shifted to voice and wireless? Are the engineers focused on IP routing becoming the dinosaurs? What’s your perspective?
But one thing is clear: I need to slow down.
One of my readers sent me an interesting question a while ago:
I reviewed one of your blog posts "Per-Destination or Per Packet CEF Load Sharing?" and wondered if you had investigated previously on how MQC QoS worked together with the CEF load-sharing algorithm (or does it interact at all)? For example, let's say I have two equal cost paths between two routers and the routing table (as well as CEF) sees both links as equal paths to the networks behind each router. On each link I have the same outbound service policy applied with a simple LLQ, BW, and a class-default queues. Does CEF check each IP flow and make sure both link's LLQ and BW queues are evenly used?
Unfortunately, packet forwarding and QoS are completely uncoupled in Cisco IOS. CEF performs its load balancing algorithm purely on source/destination information and does not take in account the actual utilization of outbound interfaces. If you have bad luck, most of the traffic ends on one of the links and the packets that would easily fit on the other link will be dropped by the QoS mechanisms.
You could use multilink PPP to solve the problem in low-speed environments. With MLPPP, CEF sends the traffic to a single output interface (the Multilink interface) and the queuing mechanisms evenly distribute packet fragments across the links in the bundle.
In high-speed environments, you can only hope that the number of traffic flows traversing the links will be so high that you’ll get a good statistical distribution (which is usually the case).
Pete sent me an interesting question a while ago:
It might be interesting to write an article about ip dhcp database flash:dhcp-db command, documenting the pros of surviving a reboot versus cons of wear on the flash device.
I’ve already written about a few problems that can be solved with the DHCP database (but obviously a longer text is warranted … already stored in my to-do list) and it took me a while to find the time to dig out the relevant information on the flash device wear.
When I was discussing the details of the BGP troubleshooting video with one of my readers, he pointed out that I should mention the need for CEF switching in EBGP multipath scenario. My initial response was “Why would you need CEF? EBGP multipath is older than CEF” and his answer told me I should turn on my gray cells before responding to emails: “Your video as well as Cisco’s web site recommends CEF for EBGP multipath design… but interestingly, it does work without CEF”.
The real reason we need CEF in EBGP load sharing designs is the efficacy of load distribution. Without CEF, the router will send all traffic toward a single BGP prefix over one of the links (fast switching performs per-destination-prefix load sharing). With CEF, the load is distributed based on the source-destination IP address pair combinations. Even if multiple clients send the traffic toward the same server, the load is spread across available links.
A few days ago, a reader sent me an e-mail titled “Telnet Automation from a Cisco Router” and complained that IOS Tcl does not support the expect commands (spawn, send and expect). Since Expect is a Tcl extension, not part of the core Tcl, it’s not included in Cisco IOS, which was the only answer I could give.
Brain dumps are the biggest threat to the certification industry these days, significantly devaluing certifications that rely primarily on multiple-choice answers. Similarly to the threat-prevention measures adopted by airport security (read the insightful analysis of their behavior from Bruce Schneier, a renowned security guru), IT vendors are responding with high-tech measures.
The idea to write an article describing how you can use MPLS VPN-enabled NAT to implement flexible extranets that allow participants to retain their existing (and sometimes overlapping) IP address space has been sitting in my to-do list for over a year.
After I’ve finally written it (without even hinting what I’ve been working on), I got several e-mails from my readers asking the questions this article answers, so it looks like the topic has suddenly become very hot. Do you have any ideas why that would be the case?
You’ll find the original article somewhere in this list.
Numerous companies use certifications to screen job candidates. Even if all the caveats associated with this process are given, you might encounter candidates who have multiple high-level certifications but cannot differentiate a router from a box of cheese. How can you identify (and reject) such people?