Yap Chin Hoong has been looking at the OSI protocol stack I’ve published and asked an interesting question: “where is CLNS in that protocol stack?”

The OSI protocol stack has a major advantage over the TCP/IP stack: it defines both the protocols and the APIs between the layers. CLNS (Connection-less network Service) is the API (the function calls that allow transport layers to exchange datagrams across the network) while CLNP (Connection-less network Protocol) is the layer-3 protocol that implements CLNS. In my diagram, CLNS would be a thin line above CLNP between L3 and L4 boxes.

Two weeks ago I listed six IPv6 myths, asking you to add your own favorites. Obviously the MythBusters are not reading my blog and everyone else decided to focus on a single provocative sentence (got you!) and expressed strong feelings about NAT being (or not being) a security feature.

I've described the myths (including the mobility myth to get their number up to the nearest magic number) in more details in the Seven IPv6 networking myths that don't match reality article published by SearchTelecom.

The snmp-server host command in Cisco IOS has an interesting option: you can specify an URL as the destination host, for example: snmp-server host http://1.2.3.4/xxx traps snmpv2c public. However, I was not able to make it work; the router would accept the configuration command, but the outbound HTTP session never starts. Has anyone managed to get this to work? Any ideas what else is required?

I love reading Scott Berkun’s blog. For years I’ve been doing (and preaching) most of the things he writes about, but sometimes he manages to describe them so eloquently that the reading of familiar thoughts becomes pure pleasure. You simply must read the Cult of Busy post; I’ve seen too many people working 12+ hours a day and achieving nothing or pointy-haired bosses who judged the productivity of their team solely by the time they left the office (and consequently managed to end with a heap of useless individuals).

One of the decades-long grudges most people have with BGP is that it’s so easy to insert bogus routing information into the Internet if your upstream ISP happens to be a careless idiot (as Google discovered when Pakistan decided to use blackhole routing for Youtube and leaked the routes). There are two potential solutions that use X.509 certificates to authenticate BGP information: Secure BGP (which uses optional transitive attributes) authenticates the originator as well as the whole AS-path (using AS-by-AS certificates), while the significantly simpler Secure Origin BGP (which uses new BGP messages) authenticates only the originator of the routing information.

When I received the first invitations to Cisco’s product announcement that will “forever change the Internet”, I knew it would be another case of overpromising and underdelivering. But even being prepared for the let down, I was totally disappointed when the “magic” product was another high-end router. No doubt it’s an important product, no doubt it will give the Tier-1 service providers a tenfold improvement of the total network throughput, no doubt it’s a wonderful piece of engineering (quoting the Cisco’s press release: it unifies the combined power of six chips to work as one ... you see how banal and degrading the engineering efforts look when described by marketing?), but it will “forever change the Internet” in the same way that AGS+, Cisco 7000, Cisco 7500, Cisco 12000 and CRS-1 did ... by providing ever-higher core network throughput.

Bad designer, one of my favorite devil’s advocates asked an interesting question about post-course survey results:

Once in a course or similar and you get to know someone it becomes v difficult to give bad results, in particular, if it is life effecting in some way such as bonuses or future work etc. In fact one can argue that you should get high results just for high effort with integrity.

The bias toward higher scores is definitely present and is in fact so strong that 4.0 usually represents a barely acceptable result; sometimes the minimum acceptable average score for an instructor is set to 4.3 – 4.5. It’s also very important to understand how the questions are phrased and what the results actually mean.

The local Cisco office sent me such a nice invitation to the Cisco Expo Slovenia event that I simply had to register. So, if you’ll be in Portorož during the event and would like to join me for a cup of coffee or a beer (hopefully on a terrace overlooking the sea), get in touch ... or look for the guy asking nasty questions from the back row ;)

A post in the My CCIE Training Guide pointed me to the GoogleTechTalk given by Yakov Rekhter (one of the fathers of BGP) in 2007. You should watch the whole video (it helps you understand numerous BGP implementation choices), but its most important message is undoubtedly the Design by Pragmatism approach:

• They had a simple, manageable problem (get from a spanning-tree Internet topology to a mesh topology).
• They did not want to solve all potential future problems; they left that marvelous task to IDRP (which still got nowhere the last time I've looked).
• They started with simple specifications (three napkins), had two interoperable implementations in a few months, and wrote the RFC after BGP was already in production use.
• They rolled it out, learnt from its shortcomings and fixed it.
• They gradually made it easily extensible: TLV encoding, optional attributes, capabilities negotiations. This approach made it possible to carry additional address families in BGP and use it for applications like MPLS VPN and VPLS.

One could only hope that the IPv6 architects had used the same approach ... but as Yakov said in his talk, that’s “water under the bridge”.

The Market trends in Service Provider networks webinar was well received by the attendees... the “only” problem was that there were so few of them. The conversion ratios were murderous:

• From over a hundred thousand visitors who have seen the webinar announcement, approximately 1% clicked on the registration link. This is normal and expected; most people are banner-blind and many visitors are not interested in the particular topic or don’t want to attend a webinar.
• Over a thousand visitors decided that the registration page is worth looking at, but only around 1% actually registered for the webinar. This ratio needs some serious fixing; increasing it by a few percentage points would make the whole idea viable.

If you were among those that were interested enough in the webinar to look at the registration page but did not proceed, please tell me what stopped you from registering. And, obviously, if you’ve spotted a glaring stupidity I made, please share it with me.

When the friendly sales guy from your favorite vendor honors you with an “independent test lab” report on the newest wonderful gadget he’s trying to sell you, there’s one thing you can be sure of: the box behaves as described in the report. The “independent” labs are earning too much money verifying the test results to participate in outright lies. Whether the results correlate with your needs is a different story, but we’ll skip this discussion.

However, when you’re faced with a competitive report from an independent test lab “sponsored” (read: paid) by one of the vendors, rest assured it’s as twisted as it can be (you should also suspect the sponsoring vendor has some significant issues he’s trying to cover). The report will dutifully list the test configurations and the test results ... without mentioning that the configurations and the tests were cherry-picked by the sponsoring vendor. You don’t believe me? Put on your most cynical glasses and read the About us statement from the premier independent test lab.

You still want me to prove my point: look at the latest HP-versus-Cisco blade server test results (paid by HP). They took an oversubscribed UCS chassis (it had 4 10GB uplinks and up to 8 servers) and compared it to an HP chassis with 8 servers and 8 10GB uplinks. Furthermore, Kevin Tolly himself admitted in the comments that they’ve really tested the bandwidth between the servers within the chassis (absolute kudos for being so frank), which you might suspect could be somewhat irrelevant in a typical deployment scenario.

TL&DR: QPPB works in MPLS VPNs… with a few limitations (at least in Cisco IOS implementation).

And now for the long story: A while ago I’ve noticed that my LinkedIn friend Joe Cozzupoli changed his status to something like “trying to get QPPB to work in MPLS VPN environment”. I immediately got in touch with him and he was kind enough to send me working configurations; not just for the basic setup, but also for Inter-AS Option A, B and C labs.

Knowing that QPPB relies on CEF, I doubted it would work as well on VRF interfaces as it does in pure IP environments, so I decided to do a few tests of my own. Here are the limitations I found:

I had my yearly “paperwork day” today. As part of that ordeal I was sorting the Cisco Press book sales reports and stumbled across e-book data for my MPLS VPN books. I can’t tell you how well the Safari access is doing (electronic subscriptions are bundled with numerous totally unrelated items into the “Others” category), but the reports have separate line items for PDF and Mobile (I assume that’s Kindle) edition. The sales of these editions are negligible compared to the “regular” sales.

Obviously even the highly technical audience is not interested in electronic books (or someone bought a single PDF copy that’s now enjoyed by the whole Internet) ... or you feel (like I do) that the reference books belong on the bookshelf.

Once you’ve spent a few hours trying to understand the implications of IPv6, you quickly realize that the only significant change is the increase in the address length. All the other goals that some people had been talking about were either forgotten or failed due to huge mismatch between idealistic view of the Internet IPv6 developers had 15 years ago and today’s reality. However, you still find mythical properties of IPv6 propagated across the Internet. Here are a few I’ve found; add your favorites in the comments.

IPv6 provides service/location separation. Total nonsense. The only mechanism used to find services is still DNS and it’s still used from the wrong position in the protocol stack.

If you ever have to stand up and speak in front of an audience, the Confessions of a Public Speaker is a must-read. I've read the book a few weeks ago (and found it a fantastic resource), but never got time to write a review. Now I don't have to … Liz Danzico from A List Apart did a wonderful job.