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.

I while ago I wrote two articles for SearchTelecom that deal with traffic management in Service Provider networks and Deep Packet Inspection (DPI). The first article analyses whether you need dedicated boxes doing the traffic management in your network; the second one whether you really need DPI to manage the traffic.

Just in case you haven't noticed it yet: Petr Lapukhov wrote a great (and very long) article describing MSTP. It covers everything, from the basics to multi-region design and interoperability issues. Highly recommended reading.

Shivlu left an interesting comment to my IPv6 is not ready for residential deployment post. He wrote: “Still no customer is ready for IPv6. How do I convince them?” The unfortunate answer to this problem is: you can't, but they'll only hurt themselves. If they persist long enough, they’ll become obsolete.

The migration issues are just one of the topics covered in the Enterprise IPv6 Deployment workshop. You can attend an online version of the workshop or we can organize a dedicated event for your team.

The web content providers have long realized that their customers have too many choices. Zvezdan Martič, one of the participants in the last year’s Slovenian IPv6 summit roundtable succinctly explained this phenomenon: “nobody cares whether my web site can be viewed in Internet Explorer or Firefox; if I don’t support the major browsers, the customers will find one of my competitors that does.”

Daniel Miessler described an interesting application of the Workstation-as-a-Service (now you know what WAAS stands for ;) cloud service (formerly known as virtual desktop): enterprise network will have to protect their workstations against browser-based attacks and the best approach is to virtualize the browsers and isolate them in a sandbox behind a firewall.

Virtualization, virtual desktops and other security-related cloud services are described in my Next-generation IP Services workshop.

Today I really wanted to write a deeply technical post (for example, Joe Cozzupoli sent me working configs for QPPB in Inter-AS MPLS VPN environment), but a gem from the SearchNetworking site caught my undistracted attention: they claim the licensing changes introduced in IOS release 15.0 target illicit use of Cisco IOS by Dynamips. The story quotes two of my blogger friends: Stretch and Greg (congratulations to both !!!). Each of them makes very valid points (I am wholeheartedly supporting Stretch’s plea for educational licenses), but somehow the story’s author managed to mix ingredients from their stories to come to a sensational (and totally wrong) conclusion (with a great headline).

When I’ve first heard about Passive Optical Networks, this blast from the past almost made my head explode. Imagine this: you’re replacing obsolete copper cabling with fiber and decide to create shared media access network similar to the widely hated cable networks.

The only benefit of PON networks that I can see is that it only needs passive equipment at the concentration point. My list of drawbacks is huge, ranging from security concerns to service evolution. What’s your opinion? Would you like to correct my bearing?

Jared Valentine found an interesting bug in the EEM’s SNMP event detector: if you’re triggering your EEM applet when the increment of an SNMP variable exceeds the threshold, you cannot re-arm the applet; the exit-type increment does not work. He fixed the problem with a somewhat more convoluted approach:

• The first EEM applet reads the SNMP variable, waits a second, does a second read and stores the difference in a counter.
• The second EEM applet is triggered based on the counter values.

I’m collecting tips like this one in the Embedded Event Manager (EEM) workshop. You can attend an online version of the workshop; we can also organize a dedicated event for your networking team.

Here’s the source code for the first applet (he had to execute CLI show commands to work around the CB-QoS MIB limitations).

More than a year ago, I wrote about the very slow update rate of the variables in the CB-QoS MIB. In August WB found a workaround (do a show policy-map interface before reading the counters) and now Jared has tested it and confirmed that it works. He’s configured a simple EEM applet that executes the show command once per second:

event manager applet UpdateMibTables 
event timer watchdog time 1 
action 1.0 cli command "enable" 
action 2.0 cli command "show policy-map int dialer0" 

With this fix, he can use the SNMP variables in other EEM applets to detect VoIP calls within 1-2 seconds.

Don’t forget: numerous EEM topics are described in the Embedded Event Manager (EEM) workshop. You can attend an online version of the workshop; we can also organize a dedicated event for your networking team.