Is Linux TCP/IP Stack Really That Slow?

Most people casually involved with virtual appliances and network function virtualization (NFV) believe that replacing Linux TCP/IP stack with user-mode packet forwarding (example: Intel’s DPDK) boosts performance from meager 1 Gbps to tens of gigabits (and thus makes hardware forwarding obsolete).

Having data points is always better than having opinions; today let’s look at Receiving 1 Mpps with Linux TCP/IP Stack blog post.

2015-07-18: The blog post was updated based on feedback by Kristian Larsson.

Routing Protocols and SD-WAN: Apples and Furbies

Ethan Banks recently wrote a nice blog post detailing the benefits and drawbacks of traditional routing protocols and comparing them with their SD-WAN counterparts.

While I agree with everything he wrote, the comparison between the two isn’t exactly fair – it’s a bit like trying to cut the cheese with a chainsaw and complaining about the resulting waste.

Video: ISP IPv6 Transition Strategies

The responses of Internet Service Providers (ISPs) to lack of IPv4 address space range from outright denial (sometimes coupled with reassuringly-expensive large-scale carrier-grade NAT) to all-in IPv6-only designs using 464XLAT for residual IPv4 connectivity.

To understand the implications of these extremes and a few data points between them, watch the ISP IPv6 Transition Strategies video from Enterprise IPv6 – the First Steps webinar.

Business Case for SD-WAN

An anonymous commenter wrote this comment to my initial SD-WAN post:

I can still hardly imagine the business case behind SD-WAN. Any thoughts?

This question is really easy to answer. There’s a huge business case that SD-WAN products are aiming to solve: replacing traditional MPLS/VPN networks with encrypted transport over public Internet. However…

Save the Date: Designing Infrastructure for Private Clouds Workshop in Switzerland

Gabi Gerber (the wonderful mastermind behind the Data Center Day event) is helping me bring my Designing Infrastructure for Private Clouds workshop (one of the best Interop 2015 workshops) to Switzerland.

This is the only cloud design workshop I’m running in Europe in 2015. If you’d like to attend it, this is your only chance – register NOW.

Project Calico: Is It Any Good?

At least a dozen engineers sent me emails or tweets mentioning Project Calico in the last few weeks – obviously the project is getting some real traction, so it was high time to look at what it’s all about.

TL&DR: Project Calico is yet another virtual networking implementation that’s a perfect fit for a particular use case, but falters when encountering the morass of edge cases.

LDP Label Allocation Revisited

One of my readers was having an LDP argument with his colleague:

Yesterday I was arguing with someone who works for a large MPLS provider about LDP label allocation. He kept saying that LDP assigns a label to each next-hop, not to each prefix. Reading your blog, I believe this is the default behavior on Juniper but on Cisco LDP assigns a unique label for each IGP (non-BGP) prefix.

He’s absolutely right; Cisco and Juniper use different rules when allocating MPLS labels.

Software-Defined Hardware Forwarding Pipeline on HP Switches

Writing OpenFlow controllers that interact with physical hardware is harder than most people think. Apart from developing a distributed system (which is hard in itself), you have to deal with limitations of hardware forwarding pipelines, differences in forwarding hardware, imprecise abstractions (most vendors still support single OpenFlow table per switch), and resulting bloated flow tables.

More on Centralized Control and SDN

After I wrote a comment on a LinkedIn discussion in the Carrier Ethernet group (more details here), Vishal Sharma wrote an interesting response, going into more details of distinction between centralized control and centralized control plane.

Webinars in 1H2015, and a Look Forward

The first half of 2015 was extremely productive – seven brand new webinars (or 22 hours of new content) were added to the ipSpace.net webinar library.

Most of the development focus was on SDN and network automation: OpenFlow, NETCONF and YANG, Ansible, Jinja and YAML, and Monitoring SDN networks. There was also the traditional Data Center Fabrics Update session in May, IPv6 Microsegmentation webinar in March, and (finally!) vSphere 6 Networking Deep Dive in April.

Do I have to mention that you get all of them (and dozens of other webinars) with the ipSpace.net subscription?

Software-Defined WAN:Well-Orchestrated Duct Tape?

One of the Software Defined Evangelists has declared 2015 as the Year of SD-WAN, and my podcast feeds are full of startups explaining how wonderful their product is compared to the mess made by legacy routers, so one has to wonder: is SD-WAN really something fundamentally new, or is it just another old idea in new clothes?

IPv6 Is Here, Get Used to It

Geoff Huston published an interesting number-crunching exercise in his latest IPv6-focused blog post: 8% of the value of the global Internet (GDP-adjusted number of eyeballs) is already on IPv6, and a third of the top-30 providers (which control 43% of the Internet value) have deployed large-scale IPv6.

The message is clear: The big players have moved on. Who cares about the long tail?

Just Out: Metro- and Carrier Ethernet Encryptors Market Overview

Christoph Jaggi has just published the third part of his Metro- and Carrier Ethernet Encryptor trilogy: the 2015 market overview. Public versions of all three documents are available for download on his web site:

• Introduction to Metro- and Carrier Ethernet Encryption
• Evaluation Guide for Metro- and Carrier Ethernet Encryptors
• Metro- and Carrier Ethernet Encryptors: 2015 Market Overview

Open-Source Network Engineer Toolbox

Elisa Jasinska, Bob McCouch and I were scheduled to record a NetOps podcast with a major vendor, but unfortunately their technical director cancelled at the last minute. Like good network engineers, we immediately found plan B and focused on Elisa’s specialty: open-source tools.

Another Spectacular Layer-2 Failure

Matjaž Straus started the SINOG 2 meeting I attended last week with a great story: during the RIPE70 meeting (just as I was flying home), Amsterdam Internet Exchange (AMS-IX) crashed.

Here’s how the AMS-IX failure impacted ATLAS probes (world-wide monitoring system run by RIPE) – no wonder, as RIPE uses AMS-IX for their connectivity.

SDN/OpenFlow/NFV Workshop: Frequent Questions

One of the potential attendees of my SDN workshop sent me a long list of questions. Almost every networking engineer, team leader or CIO asks the first one:

What will happen, if we don´t follow the SDN hype (in the short term, in the medium term and in the long term)?

Answering this question is the whole idea of the workshop.

The up-to-date list of scheduled SDN workshops is available on my web site.

Centralized Control Is Not Centralized Control Plane

Every other week I stumble upon a high-level SDN article that repeats the misleading SDN is centralized control plane mantra (often copied verbatim from the Wikipedia article on SDN, sometimes forgetting to quote the source).

Yesterday, I had enough and decided to respond.

Industry Thoughts in 30 seconds

A while ago someone working for an IT-focused media site approached me with a short list of high-level questions. Not sure when they’ll publish the answers, so here they are in case you might find them interesting:

What can enterprises do to ensure that their infrastructure is ready for next-gen networking technology implementations emerging in the next decade?

Next-generation networks will probably rely on existing architectures and forwarding mechanisms, while being significantly more uniform and heavily automated.

This Blog Post Wasn’t Properly Scheduled

A few days ago I stumbled upon an interesting blog post by my friend J Metz in my RSS feeds. As with all blog posts published on Cisco’s web site, all I got in the feed was a teaser (I know, I shouldn’t complain, I’m doing the same ;), but when I wanted to read more, I was greeted with a cryptic 404 (not even a fancy page full of images saying “we can’t find what you’re looking for).

NAPALM: Integrating Ansible with Network Devices on Software Gone Wild

What happens when network engineers with strong programming background and focus on open source tools have to implement network automation in a multi-vendor network? Instead of complaining or ranting about the stupidities of traditional networking vendors and CLI they write an abstraction layer that allows them to treat all their devices in the same way and immediately open-source it.