Blog Posts in April 2008
PE-A#show ipv6 interface brief | section up
The definition of the associated follow-up lines depends on the printout. Usually the indented lines are assumed to belong to a section, but you might be surprised.
As my readers have mentioned in a comments to my previous post on this topic, you should use kernel-based floods for high-performance or you could use Iperf to do the UDP floods or TCP bandwidth measurements. However, as I do the QoS tests in a remote lab with virtual PCs that have no Internet connectivity for obvious security reasons, it's easiest to make changes to a PERL script over the console window.
ISO makes a fine semantic distinction between the service offered to higher layers (CLNS) and the protocol used to implement it (CLNP). There is no such distinction in the IP world.CLNS (and CLNP) uses long variable-length addresses, making it a viable successor to IPv4. At the time when the IETF community started to design the next-generation IP (before IPv6 appeared on the drawing board), the proposals to use CLNS were taken pretty seriously even though they used interesting acronyms like TUBA (TCP and UDP over Big Addresses) and FOOBAR (FTP Operation Over Big Address Records).
Follow the links in the previous paragraph, they point to actual RFCs.In the end, IETF decided to invent yet another protocol (IPv6), effectively quadrupling the IPv4 address size while retaining most of the benefits and drawbacks of IPv4. If I remember correctly, the technical explanation for this decision was the variable-length of the CLNS addresses (which make the hardware implementation of layer 3 forwarding pretty complex), while one of the real reasons was probably also the "not-invented-here" syndrome (and the lack of total control over a new protocol inherited from another organization).
CLNS was widely used in early large IP networks primarily due to the multi-protocol implementation of IS-IS (the CLNS routing protocol that is roughly equivalent to OSPF), which came from DECnet phase V(anyone remember DEC, the maker of great minicomputers and probably the best operating system ever written?). Several very large networks used IS-IS at that time, forcing Cisco to optimize IS-IS code before they managed to fix the OSPF code. This led to an interesting phenomenon: the best-performing IP routing protocol was a protocol endorsed by ISO that was never designed (initially) to carry IP prefixes.
When network engineers claim that they use CLNS in their networks, they usually want to say that the use IS-IS, which uses CLNS addresses to identify routers (similar to IPv4 addresses used by OSPF as the Router ID). The actual forwarding of CLNP datagrams (what I would consider the real usage of CLNS) is very rare today; the last time I've seen it, CLNP was used in the management networks to manage Sonet/SDH devices. According to one of the comments to my initial post, most of these devices support IP as the transport protocol today, making CLNP mostly obsolete.
Anyhow, I've recently discovered that Cisco supports CLNS routing over BGP and wanted to write about it … obviously, based on the poll results, that would be a purely academic exercise.
This e-lesson describes how you can optimize BGP convergence in your network without overloading the routers running BGP. The hands-on remote exercise will enable you to configure fast BGP convergence under various conditions and test the convergence times in a controlled lab environment instead of trying these techniques in a production network.
Recently I had to implement Internet access using ADSL as the primary link and ISDN as the backup link. Obviously the most versatile solution would use the techniques described in my IP Corner article Small Site Multi-homing, but the peculiarities of Cisco IOS implementation of the ADSL technology resulted in a much simpler solution.
A few days ago, Arden Packeer covered the same topic in one of his blog posts, so it looks like the underlying problem (and the solution) is not as widely known as I had assumed. Time to write a tutorial on Queuing Principles in Cisco IOS.
Quite often, you'd like to include results of various show printouts as the body of the e-mail sent by an EEM applet. It's easy to include a single printout: execute the show command with the action cli command and include the $_cli_result variable in the e-mail body (more details can be found in the Send email from EEM applet article).
It's trickier to include outputs from several show commands in the same e-mail: you have to collect the outputs into a file in the router's flash, list the contents of the file and send the result.
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:
E-lessons are subscription-based; you can repeat each module in the lesson (including the lab) as many times as needed.
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 :))
Cisco partners can test the non-transit AS implementation in the Using Multihomed BGP Networks and Employing AS - Path Filters remote lab exercises. If you're don't have access to Partner Education Connection, you can buy our Configuring BGP on Cisco Routers e-learning solution or the BGP Remote Lab Bundle.
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. But 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, at least the IOS release 12.4T accepts either the wildcard bits or the subnet mask and figures out which one you've used.
More detailed observations are also most welcome: just add a comment to this post.
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:
- NTP is supposed to solve a pretty hard problem of synchronizing multiple independent time sources over communication paths with unpredictable delay and jitter. Considering the limitations it's faced with, it does an amazingly good job.
- NTP configuration on IOS is no more complex than the openntpd configuration if the only thing you want is to do is to configure an upstream NTP server. The only commands you need are ntp server and ntp master.
However, the most important point, in my opinion, is the difference between "aiming for a short recipe" and "understanding the technology". If the only task you ever need to perform is to configure upstream NTP servers, don't even bother to read the IOS documentation or my article, you don't need more than a single configuration command … but then, when things really break, you'll be in trouble.
Likewise, the only thing some people want to know about OSPF are the following two commands:
router ospf 1
0.0.0.02522.214.171.124 area 0
There are others, however, that might need a slightly more in-depth understanding of OSPF design, configuration and troubleshooting (that's why we developed an OSPF course and corresponding set of remote lab exercises and Tom Thomas wrote a whole book about it).
During the Partner summit, the Cisco Partner Space hosts the virtual version of the event, including the exhibitor booths. You can visit us by choosing the Reseller Exhibition Hall (what a nice name, isn't it … all of a sudden, their Gold Partners are caller Resellers) from the menu on the first page (after you log in), selecting Booths 26-36 and NIL from the Booth List. If you let me know when you'll go there, I might even be there to chat with you (I can't promise it, though).
Sometimes I find the information on the Internet that is so far from the facts that it might actually hurt someone. For example, the configuration in this post supposedly prevents you from becoming a transit AS (which is a really bad idea if you're a multi-homed end-user). Actually, it achieves the goal as it drops all incoming routes due to a malformed AS-path access-list that denies everything :) … but then, why do you need BGP in the first place?
I've always considered building (almost identical) initial router configurations a waste of time, more so when I had to enter them manually, enabling interfaces, configuring IP addresses and Frame Relay subinterfaces on the fly … as well as entering dozens of commands that I feel should be present in every router configuration.
When I finally had enough, I've stopped my non-critical lab tests for a few weeks (that's why there's still no answer on the very good question whether the NBAR started by NAT is of any use) and wrote configMaker: a PERL script that parses dynagen lab topology and produces initial router configurations based on a template file that you can adjust to your own needs. Read more about it in the CT3 wiki.
A while ago I've been involved in an interesting discussion focusing on NTP authentication and whether you can actually implement it reliably on Cisco IOS. What I got out of it (apart from a working example :) was the feeling that NTP and it's implementation in Cisco IOS was under-understood and under-documented, so I planned to write an article about it.
However, as I did my research, I figured out there's so much I didn't know about NTP (do you know what's the essential difference between a peer and a server?)that I decided to start with an introductory article explaining the basics of NTP, SNTP and their IOS implementation. It's been published under the name “It’s Good to be on Time” in the IP corner section of our company's web site.
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.
If you want to stress-test the router's forwarding functionality, you could use the host route to the null0 interface; all packets sent to that IP address will be CEF-switched, so the only impact of the UDP flood to the unreachable IP address will be the increased interrupt CPU load. I was able to increase the interrupt CPU load to close to 50% on a 2800 router using a virtual PC with a Fast Ethernet interface.
And just in case you need it, here is the configuration from my test router. All packets sent to 10.0.0.22 are CEF-switched and dropped (the CPU load from the IP input process is negligible).
interface FastEthernet 0/0
ip address 10.0.0.1 255.255.255.0
ip route 10.0.0.22 255.255.255.255 null 0
My recent post about a CCNP bootcamp program we've launched 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 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).