Cisco recently announced a Linux-based add-on board for the ISR router models. It might not be the best thing ever invented, it's probably overpriced and we still have to see what we really get; the materials available on the Cisco's web site are another good example of a great marketing machinery (when I see a title "Our Strategy is Integration and Convergence"on the slide #11 of a Technical Overview presentation, I start wondering whether it's worth my time to continue looking at the presentation). But at least this time they talk about supporting Perl and Python, not Tcl :))

However, what really prompted me to start writing this post was the "wisdom" spread by industry journalists. Network world was still moderate; the gentleman at LinuxWorld had some strong opinions. It would be OK if they would stop at bashing the new module (and questioning the value-for-price is always fair), but of course it's more fun being all over the place, evangelizing the beauties of PC-based open-source routers and the demise of traditional router vendors. While there's (yet again) nothing wrong with open-source, let's bring a bit of the history into the picture:

• 15 years ago, someone had a great idea to install WAN cards and routing software into PC servers. The journalists greeted that idea as the downfall of dedicated routers. Guess what ... it flopped and the router market continued to grow.
• Cheap Layer-3 switches have been greeted as the next router killer. We still have routers and switches in our networks.
• People have been using Linux as their home firewalls for years ... and it hasn't really impacted the low-end router market; SOHO users are still preferring to buy Linksys (or whatever other cheap low-end brand) over configuring firewall on Linux.
• Public-domain BGP implementations have been around for as long as I can remember and they are not bad. Some people with very low budget use them for route servers ... but Cisco and Juniper are still selling high-end boxes.

In the real world of networks that have more than a few routers, if you have enough budget to buy yourself a good night's sleep, you usually install dedicated routing hardware ... but I guess this is not the sort of story that would sell the industry journals.

A few interesting posts found on the Internet:

• Grep for Cisco commands from Cisco Tips & Tricks
• Challenges integrating VMware into Cisco networks from Colin McNamara
• Tutorial: IPv6 Tunnels Part 1 - Manual GRE & IPv6IP Tunnels from Arden Packeer
• Tutorial: How to use Cisco MQC & NBAR to filter websites like Youtube from Arden Packeer

One of the obscure facts about IPv6 OSPF (OSPFv3) is that it uses a 32-bit router ID like OSPFv2. It’s a reasonable choice; I have yet to see an OSPF network with over a billion routers. However, could you guess how this requirement is implemented in Cisco IOS? OSPFv3 searches for an IPv4 address (effectively the same algorithm used by OSPFv2) to get the router ID for the IPv6 routing process. Neat, isn’t it?

You might wonder what happens if you want to configure an IPv6-only router. OSPF won’t start unless you configure the router ID manually. And, no, you cannot enter a number (which would be the expected format, as the router ID is just a number in the IPv6 world); you have to enter an IPv4 address. Long live IPv4 :))

In a comment to my recent NTP-related post mentioning OSPF configuration, Wan Tajuddin correctly stated that the OSPF network statement should contain the wildcard bits, not the subnet mask. However, I was positive I had running networks with the network 0.0.0.0 0.0.0.0 area 0 OSPF configuration, so it was time for one more lab test. As it turns out, Cisco IOS started accepting either the wildcard bits or the subnet mask in the network OSPF configuration command.

In his comment to the one of my NTP articles, Joe said:

This is part of the problem with NTP. It's way more complicated then it needs to be. You shouldn't have to understand so much of it to use it on your routers. Take a look at openntpd. It's free and runs on bsd or linux.

I have to disagree with him on several counts:

One of the first things you have to do when configuring BGP with your ISP is to ensure you won’t become a transit AS. Decent ISPs filter out things that don’t belong to you from your updates, but not everyone cares (including some really big names), and so small organizations manage to bring down large parts of the Internet just with a few fat fingers.

Here’s the BGP configuration you should use on Cisco IOS: apply AS-path access-list to outbound updates with neighbor filter-list command:

If you want to test the ERM policies in a controlled environment, it's almost mandatory to have tools that allow you to overload the router. One way to overload a router is to flood it with UDP packets. Flooding a router's IP address, you're guaranteed to raise the CPU to 100%, with majority of the process CPU being used by the IP Input process (the interrupt CPU load will also be significant).

This phenomenon illustrates very clearly why it's so important to have inbound access lists protecting the router's own IP addresses on all edge interfaces.

My recent post about a CCNP bootcamp program I was involved with generated interesting comments, most of them focusing on the question: “Does it make sense to attend a bootcamp?”

The answer depends on how you got to the stage where you want to (or need to) attain the CCxP certification. Before going into discussions on “experience” versus “knowledge retention” (potentially “aided” by brain dumps), please read The Top 10 Problems with IT Certification in 2008 article published by InformIT. My potential disagreements with this article are so minor that I will not even try to document them.

OK, now that we're on the same page, let's analyze why someone would want to pursue CCxP certification:

• To increase the salary or have better job options (as HR departments ask for people with specific set of certifications). From what I hear, this reason is more viable in US than the rest of the world (in most of Europe we can still test the technical skills of the candidates in any way we want without running the risk of being sued). Bootcamps might not be the best option for these candidates, as they tend to be priced similarly to the regular classes. Reading books or e-learning material (not to mention certain not-so-very-legitimate activities) will get you through the exams as long as they don't have the hands-on part ... and of course you'll end up having certification with zero experience;
• To learn something new and valuable resulting in a formal recognition of the effort. Don't even think about attending the bootcamps. If you're learning completely new concepts, go through the regular courses (or use e-learning combined with hands-on lab exercises). Highly intensive format of the bootcamps (after all, we're trying to squeeze almost two weeks worth of material into a single week) will fly way over your head.
• To formalize your experience ... either because you want to or because your employer needs certified head count (very common with Cisco partners trying to get better discount based on their partner status). In this case, a condensed bootcamp is usually the best option. For example, we had very successful bootcamp program a few years ago running back-to-back with the exams ... and, mind you, we used no cheating or brain dumps, the fact that the students took the exam right after the course obviously helped.

Last but definitely not least, it's worth mentioning that not all five-day courses have five days worth of content. In these cases, condensing them into bootcamps makes even more sense.

The information on the IOS XE software used by the recently launched ASR 1000 router is pretty scarce (there is still no link to the documentation available on CCO), but obviously some backdoor links already exist, as I was able to find some IOS XE-related documents with Google. One of the most amazing features I've found is the support for the security-oriented RFC 3514 which allows you to mark the security level of an IP packet.

The RFC 3514 requires the end host to participate in the process, but as most operating system vendors still don't have a trusted computing platform, a transparent proxy has to be implemented on the network edges to properly tag the ingress packets. ASR 1000 has the first high-speed implementation of the RFC 3514 proxy thanks to its non-deterministic parallel QuantumFlow processors.

The configuration of the RFC 3514 proxy is extremely simple: all you need to do is to configure auto-secure mark on the ingress interfaces of the ASR 1000. Once the security bit has been set, you can use the match ip security-bit 0|1 command in a class-map or a route-map on any router running IOS release 12.4(11)T or later (the command is still hidden).

Andy Davis from the Information Risk Management has written an interesting "application note": how to create a backdoor to Cisco IOS using Tclsh (I've tested it and it works quite nicely). His backdoor implementation relies on a bug in Cisco IOS that allows a "hung" (or never-ending) Tclsh script to continue executing even after the user session has been disconnected (the only means of stopping such a script is with the clear line command). That bug has been fixed in recent IOS versions (I've tested that as well, the Tclsh script is killed as soon as the Telnet session is disconnected in IOS 12.4(15)T), but you can still use the same technique (although it might be a bit less convenient) if you convert the Tclsh script into an EEM policy and trigger it periodically with a timer event.

Cisco has published a series of documents describing how you can connect a SOHO site to two ISPs.

Their configuration also includes a nice trick: the ip dhcp client route track number command is a convenient replacement for a static default route with the track option if one of the upstream interfaces uses DHCP and the router generates the default route based on DHCP replies.

A few days ago I had an “interesting” experience on a router that was running low on memory: when I enabled NAT, it immediately ran out of memory although it had over 4 MB free memory before that (and since I was doing the tests in a lab, I wasn't worried about that … in a production network, 4 MB of free memory is something to worry about).

It took me a while to figure out what was going on: the moment you enable NAT in IOS release 12.4, it activates Network Based Application Recognition (NBAR) even when CEF is disabled (and supposedly NBAR requires CEF to run).

Sometimes the CPU utilization on a router would raise unexpectedly due to incoming packets being process switched. A very common scenario is a GRE tail-end router that has to reassemble IP fragments (usually generated due to incorrect MTU size on the GRE head-end or due to IPSec+GRE combination) or a router under Denial-of-Service attack. To detect these conditions, you can define Embedded Resource Manager (ERM) policy that raises an alert when the CPU utilization of the IP Input process exceeds predefined limits.

resource policy
  policy HighProcCPU type iosprocess
   system
    cpu process
     critical rising 40 falling 25
     major rising 20 falling 10
    !
   !
  !

  user group IPInput type iosprocess
   instance "IP Input"
   policy HighProcCPU

And here are some more ERM usage guidelines:

• This time, we're monitoring a group of processes, so the policy definition is no longer global but has a type (iosprocess is the only type defined at the moment).
• As in the previous ERM example, we're monitoring CPU utilization of the main CPU (system), but this time we're interested in the process utilization.
• The policy is applied to a user group of resources of the type iosprocess (translated into English: a group of IOS processes).
• The only process in this group is the IP Input process (and the "magic keyword" is an instance of the group).

The quotes in the instance configuration command are required, as the command accepts only a single word as the process name.

If you want to have your own Tcl functions available when you start tclsh, you could use the scripting tcl init file configuration command that I've briefly mentioned in one of the previous posts. This command specifies a source file that is executed every time you start Tcl shell. The source file can contain function definitions, package declarations or any other Tcl code.

If you need to, you can specify multiple initialization files.

For example, if you'd like to implement a comfortable Tcl-based pinger (similar to the one Ethan Banks found in the Sadikhov forums, store the following Tcl code into the file flash:pinger.tcl …

proc pinger { iplist } {
  foreach ip $iplist {
    if { [regexp "(!!!)" [exec "ping $ip timeout 1" ]] } {
      puts "$ip"
    } else { puts "$ip **** failed ***" }
  }
}

… and configure scripting tcl init flash:pinger.tcl. Now you can ping a number of hosts in a single operation:

R1#tclsh
R1(tcl)#pinger { 10.0.0.1 10.0.0.2 10.0.0.3 10.0.0.4 }
10.0.0.1
10.0.0.2
10.0.0.3 **** failed ***
10.0.0.4 **** failed ***

In a previous post I've described how you can use neighbor local-as feature to fix AS-number mismatch between adjacent autonomous systems. However, without additional options, the local-as is inserted in the AS-path of incoming BGP updates before any inbound filters. Your inbound filters thus have to match the local-as as well.