Blog Posts in April 2010
Every now and then an incident reminds us how vulnerable BGP is. Very few of these incidents are intentional (the Pakistan vs. YouTube is a rare exception) and few of them are propagated far enough to matter on a global scale (bugs in BGP implementations are scarier). Most of these incidents could be prevented with either Secure BGP or Secure Origin BGP but it looks like they will not be implemented any time soon.
Ever since I’ve figured out how to explain complex topics to bright engineers, I wanted to develop content (books, courses, documents) that explained (in this order):
- The Big Picture and WIIFM (What will the student gain by understanding and deploying something based on what I’m describing).
- How the technology we’re using actually works (remember: knowledge, not recipes) and finally
- How to configure, monitor and troubleshoot the actual boxes used to build the solution.
I’m positive you agree this approach makes perfect sense, and every now and then I’ve managed to get it right (for example, in the MPLS VPN books). Unfortunately, you’re often facing an uphill battle, as people want to focus on hands-on topics and hate to learn why things work the way they do instead of memorizing recipes like “Thou shalt not have more than 3 OSPF areas per router”.
I never believed I would see this: OSPF is becoming a multi-protocol routing protocol. RFC 5838 specifies how you can redefine the instance ID field in OSPFv3 to support four address families (IPv6 and IPv4 unicast+multicast).
It looks like this feature currently runs in PowerPoint and in a very-limited-availability image (if you’ve seen it working on an actual box, let me know).
Every so often I stumble across a blog post (or receive an e-mail) complaining how hard it is to learn the material needed to pass a certification exam. That’s definitely true if you try the memorization approach to networking: trying to cram as many facts as possible into your grey matter. However, it’s impossible to make any reasonable progress that way; to move forward, you have to handle networking like you would math or physics: having a firm basic foundation, you slowly expand it, all the time trying to fit the new concepts into a coherent model (let’s call it “the big picture”).
Recently-published RFC 5837 describes additions to ICMP messages that would allow you to gather more information (including interface ifIndex, IP address and name). Two obvious applications are enhanced traceroute and path MTU discovery where the new ICMP extensions could indicate which interface is the MTU bottleneck.
The RFC authors come from BT, Juniper and Cisco, so there’s a non-zero chance it will actually get implemented where it’s most needed.
Jerry sent me an interesting question:
I was wondering if there's a way to modify an as-path access-list much like we do with regular access lists, simply by adding/ removing lines according to their sequence numbers.
I'm not aware of any such mechanism in Cisco IOS (but then maybe I’m missing something), but his question made me wonder: if you’re maintaining large AS-path access lists, do you edit them on the router (I guess not) or off-line (on a NMS platform) and download them when they need to be changed?
If you’re on the buying side of the IT industry, you’ll love the “42 is the answer” post by Storagebod. The really fun part describes vendors trying to properly position themselves ... and failing in the process:
When all you have is a hammer, every problem looks a nail but even if your hammer is the best hammer in all the world and sure you could bang in a screw, at the end of the day, there will be dissatisfaction with results.
BTW, his question that gives the answer 42 is way too narrow (although personally relevant; just read his post); Douglas Adams took a much wider perspective.
Scott Berkun has (yet another) fantastic article on his blog: a teacher was complaining that the students use Facebook or check their e-mail in class. Scott’s response? Maybe it’s the teaching skills and the fascination with one-way lecturing, not the Internet, that’s at fault. Read the whole response; if you’ve been faced with too many narrow-minded teachers in your life, you’ll enjoy it as much as I did.
The Wednesday's Building IPv6 Service Provider Core was a huge success (compared to the previous one); I had three times as many attendees from all over the world (map below) even though the topic was highly technical and pretty limited in scope. I can’t tell you how delighted I am that it went so well and I would like to thank (again) everyone who chimed in with improvement ideas.
RFC 4364 (also known as RFC 2547bis from its draft days) specifies two methods of transporting VPN packets between PE-routers: well-known MPLS transport and GRE transport. The GRE transport idea is extremely simple: you take the labeled VPNv4 packet, put it into a GRE envelope, set the GRE Ethertype field to MPLS Unicast (0x8847) and send the GRE packet to the IP address of the egress PE-router.
This is not the same mechanism as running MPLS over point-to-point LDP-enabled GRE tunnels or running MPLS over DMVPN tunnels; this one does not require multiple tunnels or LDP/NHRP to work.
SearchTelecom has just published my new article: Traffic grooming in optical networks: Making real-world choices. If you’re new to the optical networking (or if you’ve been bedazzled by vendors’ marketing departments), you’ll probably find it a useful introductory text.
As the production-grade all-optical traffic grooming solutions don’t exist yet, the only short answer anyone (apart from people trying to sell you specific gear) can give you on this topic is “it depends”. You have to evaluate your needs, do several alternative designs, and find the design that best fits your needs, your budget and your long-term cost expectations.
As Network World writes, the latest product announcements from Cisco were met with the “so what” attitude. As one of my recent pet projects dealt with improving presentation skills, I found it interesting to try to understand the marketing techniques used in these announcements. The Presentation secrets of Steve Jobs book was a great help. Among other advices given by its author, you’ll find these:
Create Twitter-like Headlines ... but there’s a difference between already far-fetched “Apple reinvents the phone” (Steve Jobs @ iPhone launch) and CRS-3 will forever change the Internet.
Did you know that you could do server-to-server file transfers with FTP? I didn’t; this little gem (usually known as FXP – File eXchange Protocol) was described by davro and g in comments to the FTP Butterfly Effect post.
If you’re using FXP, please write a comment; although I am well aware why it was extremely useful 25 years ago, I’m wondering how many people are actually using it today.
Do you like the solutions to the L2TP default routing problem? If you do, the ASR 1000 definitely doesn’t share your opinion; so far it’s impossible to configure a working combination of L2TP, IPSec (described in the original post) and PBR or VRFs:
PBR on virtual templates: doesn’t work.
Virtual template interface in a VRF: IPSec termination in a VRF doesn’t work.
L2TP interface in a VRF: This one was closest to working. In some software releases IPSec started, but the L2TP code was not (fully?) VRF-aware, so the LNS-to-LAC packets used global routing table. In other software releases IPSec would not start.
There are three tools that can (according to a CCIE friend of mine) solve any networking-related problems: GRE tunnels, PBR and VRFs. The solutions to the L2TP default routing challenge nicely prove this hypothesis; most of them use at least one of those tools.
Policy-based routing on virtual template interface. Use the default route toward the Internet and configure PBR with set default next-hop on the virtual template interface. The PBR is inherited by all virtual access interfaces, ensuring that the traffic from remote sites always passes the network core (and the firewall, if needed).
Imagine you have a large retail network: your remote offices use ISDN to dial into the central site and upload/download whatever periodic reports they have. Having a core router connected to an ISDN PRI interface is the perfect solution:
A few years later, ISDN is becoming too slow for your increased traffic needs and you want to replace it with DSL or VPN-over-Internet solution. Your Service Provider offers you PPPoE forwarding with L2TP. This is a perfect solution as it allows you to minimize the changes:
In a comment to my “Did you notice 15.1T is released?” post kcuorbax shared exciting news about the new CCIE track launched yesterday:
CCIE Numbering experts will have the outstanding ability to find if a bug fixed in release A is fixed in release B. They will understand why new features are inadvertently introduced in mainline trains and why developers forget to commit fixes in the branches where the bugs were discovered. They will master the double numbering of IOS-XE and the sudden change from 12.2XN to 15.0S.
Anyone brave enough to try to take this exam?
This looks like another April 1st RFC (but it's apparently not):
Several applications extending the Hypertext Transfer Protocol (HTTP) require a feature to do partial resource modification. The existing HTTP PUT method only allows a complete replacement of a document. This proposal adds a new HTTP method, PATCH, to modify an existing HTTP resource.
Unveiling of the Cisco IOS release 15.1(1)T was the extreme opposite of the CRS-3 and Catalyst 3750-X splashes; the next release of one of the foundations of Cisco’s core business deserved a modest two-paragraph mention in the What's New in Cisco Product Documentation page.
If you’re a voice guru, you’ll probably enjoy the list of 20+ voice-related new features, including the all-important Enhanced Music on Hold. For the rest of us, here’s what I found particularly interesting:
One of the exciting new features of the recently launched CRS-3 router enables Service Providers to implement first-ever all-optical end-to-end traffic grooming. One of the new linecards (unfortunately not compatible with CRS-1 due to increased hardware complexity) supports the SFSS protocol (defined in RFC 4824).
Using a high-quality video link and all-optical spatial separators you can easily transport more than one SFSS instance on the same wavelength, allowing you to implement a true sub-lambda traffic grooming in the optical domain. There’s just one gotcha: due to the encoding requirements of SFSS, you cannot carry it in the dense channel spacing of DWDM; you have to use CWDM or even wider optical bands depending on the receiver’s capabilities.