Build the Next-Generation Data Center
6 week online course starting in spring 2017

Online presentations: technical details

Danny sent me an interesting question about my “Market trends in Service Provider networks” presentation: “I have never attended or seen this sort of webinar event, is this purely web based with video or will it seem like a WebEx type meeting presentation?

Obviously “webinar” was a wrong name. I hate “e-learning” (tells you about as much as “cloud computing”), “Internet-based lecture” sounds awful, and I obviously chose yet another meaningless buzzword.

Here’s what’s going to happen: it will be a live presentation delivered over the Internet using WebEx with one-way voice delivered through VoIP. You’ll see the slides and additional markup that I’ll put on them, but not my talking head … not (only) because I look ugly but (primarily) because the talking head just eats the bandwidth.

ITU and Internet billing: It’s a déjà-vu all over again

My friend Stretch alerted me to an article published by BBC news which reports that “an EU cyber security expert” told “a House of Lords committee” (wow, that’s the perfect body to deal with Internet issues) that the proposal submitted by Chinese to an ITU-T study group required “modifications to BGP” which would “threaten the stability of the entire Internet”.

Regardless of whatever the original proposal has been, the information has been distorted, twisted, adapted, abstracted and misunderstood so many times before being published that it’s impossible to figure out what exactly has been going on. The account of an eyewitness (sitting in the Kampala talks in September) doesn’t tell much more.

Send a SNMP trap from an EEM applet

The engineer who wanted to detect specific DoS attack (WAN link overload) with EEM applet asked for something more in his original question: he wanted to receive a SNMP trap on the NMS when the DoS attack is detected. Implementing this requirement with an EEM applet is simple; you just need to add the trap keyword to the event manager applet configuration command.


EEM-SNMP integration is 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.

Next-generation IP services

A while ago I’ve created a short presentation describing modern IP- and web-based services. It describes the application-layer topics I’ve been focusing on in the last few years, from cloud computing to web-based applications. I've tried to keep it simple enough that someone without the prior knowledge of the field would not get lost after two slides, but still far away from high-level marketing nonsense (you can get plenty of that anywhere else). Today I finally found some time to spend on the paperwork and wrote the description of the Next-generation IP Services tutorial.

IPv6 is not ready for residential deployment

The main driver for IPv6 deployment is the IPv4 address space exhaustion, caused primarily by fast growth of residential users.

Each residential user needs an IP address, a small company doesn’t need anything more and even a reasonably-sized company can survive with a few IP addresses.

One would expect the vendor readiness to follow this pattern, but the situation is just the opposite: while the enterprise networking devices have pretty good IPv6 support (Data Center components from some vendors are a notable exception), the vendors serving the residential market don’t care.


The Service Provider-related IPv6 challenges are covered in my Market trends in Service Provider networks workshop. You can attend a web-based tutorial version or we can organize a dedicated workshop event for your team.

HQF: truly hierarchical queuing

After doing the initial tests of the HQF framework, I wanted to check how “hierarchical” it is. I’ve created a policy-map (as before) allocating various bandwidth percentages to individual TCP/UDP ports. One of the classes had a child service policy that allocated 70% of the bandwidth to TCP and 30% of the bandwidth to UDP (going to the same port#), with fair queuing being used in the TCP subclass.

Short summary: HQF worked brilliantly.

Help appreciated: Best time for web-based sessions

I’m planning to deliver my workshops/tutorials as web-based sessions in the next year. One of the very important aspects (apart from having good content at a reasonable price) is the timing: I’m trying to adapt to the preferences of as many potential visitors as possible.

Could you help me figure out what the best time would be? Let me know what works for you by participating in this poll (but please do so only if you plan to attend one of the sessions).

Book review: Cisco Routers for the Desperate

If you happen to be one of those “universal engineers” tasked with configuring a Cisco router just because you deployed a web site yesterday, you’re probably already searching for a book in the Dummies series. Once your desperation exceeds a certain threshold, you might consider the “Cisco Routers for the Desperate”.

The idea is great: give someone who hasn’t seen Cisco IOS CLI before enough knowledge to perform the basic tasks. The writing style is surprisingly good and the book is filled with well-explained printouts you might get from the router. Looks like a perfect book for the task … if only it wouldn’t be hopelessly outdated.

The sorry state of our industry

One of the few benefits of having a Facebook page is the ability to view the fan statistics (Facebook calls that Insights). I’ve just looked at the gender demographics of my fans and I was astounded; nothing has changed in the last 20 years. What are we doing wrong?



Load sharing 101 (with references)

It looks like my load sharing posts (as well as related IP corner and wiki articles) did not paint the whole picture; I’m always assuming the readers have a basic level of IP routing knowledge (somewhere around BSCI/CCNP) and jump into juicy details. Let’s try to fix this error and start from the beginning.

A router receives its routing information (reachability of IP prefixes) from various sources: connected IP prefixes, static routes and dynamic routing protocols. For every IP prefix, the best source (= one with the lowest administrative distance) is selected and only the route(s) from that source are included in the IP routing table.

If the best source offers multiple equal-cost routes, more than one (up to the value of maximum-paths router configuration command) can be installed in the IP routing table and used for load sharing.

Things can get tricky when you use BGP, read the Load balancing in BGP networks IP corner article for details.

Ten steps of small LAN design

Every so often someone tries to apply the “let all be friends and love each other” mentality to LAN networks and designs a pure layer-2 switched LAN (because it’s simpler). Jay contributed a ten-step “what happens next” description in his comment to my “Lies, damned lies and product marketing” post. The steps are so hilarious I simply had to repost them:

  1. Build everything at layer 2 because "it's simpler".
  2. Scale a little.
  3. Things start breaking mysteriously. Run around in circles. Learn about packet sniffers and STP.
  4. Learn about layer 3 features in switches you already own. Start routing.
  5. Scale more.
  6. Things start breaking mysteriously. Learn about TCAMs. Start wishing for NetFlow.
  7. Redesign. Buy stuff.
  8. Scale more.
  9. VMWare jockeys start asking about bridging across the WAN.
  10. Enroll in hair loss program.

Lies, damned lies and product marketing

Greg Ferro’s “Layer-3 routing” post successfully kicked my huge sore spot: the numerous ways technical terminology is abused by product marketing gurus.

Twenty years ago, before networking became a multi-billion dollar industry, things were clear, simple and consistent: layer-2 (data-link layer) frame forwarding was bridging and layer-3 (network layer) packet forwarding was routing. Everything was crystal clear until some overly smart people tried to turn bridges into something they were not: WAN extension devices. A few large WAN networks were built with bridges … and failed spectacularly. Router vendors quickly used the opportunity to push the “routing is good, bridging is bad” mantra.

Certifications and the hiring process

My good friend Stretch wrote an interesting article about the usability of certifications in the hiring process. I can’t agree more with everything he wrote about certifications, it nicely summarizes the various topics Greg Ferro and myself wrote about during the last year (please note: I’m not claiming Stretch was in any way influenced by our thoughts, anyone seriously considering the current certification processes has to come to the same conclusions).

Regrettably, I have to disagree with most of his alternative approach (although some of the ideas are great). It would work in an ideal world, but faces too many real-life obstacles in this one.

iSCSI and SAN: two decades of rigid mindsets

Greg Ferro asked a very valid question in his blog: “Why does iSCSI use TCP as the underlying transport protocol”? It’s possible to design storage-focused protocol that uses connectionless lower layers (NFS comes to mind), but the storage industry has been too focused on their past to see past the artificial obstacles they’ve set up themselves.


Just in case you’re wondering where the slide is coming from: iSCSI and SAN are covered in the Data Center 3.0 for Networking Engineers webinar (register here).

It all started in 1981 with SCSI: a standard way of connecting storage to hosts with ribbon cables. They’ve made the first mistake when they’ve decided to replace ribbon cables with fiber: instead of developing a network-oriented protocol, they replaced physical layer (cable) with another physical layer and retained whatever was running on top of the ribbon cable (SCSI command protocol). If they wanted this approach to work, the new transport infrastructure had to have similar characteristics to the old one: almost no errors, no lost frames and guaranteed bandwidth. And thus Fiber Channel was born.

IPv6 in the campus but not in the Data Center?

Cisco has recently published two excellent design guides: Deploying IPv6 in Campus Networks and Deploying IPv6 in Branch Networks. As expected from the engineers writing Cisco’s design documents, these guides contain tons of useful information and good recommendations; they’re a highly recommended reading if you’ve started considering IPv6 deployment in your enterprise network. These design guides are part of Design Zone for Branch and Design Zone for Campus.

IPv6 deployment 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.

Let me help you with your budget

I don’t know how your financial year works out; in Central Europe most companies’ financial year coincides with the calendar year. November and December are thus crazy planning/budgeting months, with pointy-haired bosses (myself included) trying to reduce expenses. Training is frequently one of the most exposed items and getting training funds outside of the budget is usually close to Mission: Impossible. Lesson: plan well what you want to spend in the next year.

Have I mentioned that I’m creating a number of WebEx-delivered workshops (we can also arrange on-site events)? Most of them are designed as high-level overview presentations (for whatever reason people think I can create a presentation that’s not too technical but still stays far away from High-Level-Bulls**t) and I would love to do a few really in-depth ones (assuming I can get enough participants). If you want to attend them in the next year, use the following NTE budgetary pricing:

  • €30 ($45)/hour/participant (two attendees @ 2-hour presentation = € 120);
  • €200 ($300)/hour for a private on-line workshop (up to 10 participants).