Ivan Pepelnjak

Author Archives: Ivan Pepelnjak

Explaining the Pervasive Kludgeitis

I found a great explanation for hodgepodge of kludges found in "organically grown" solutions (legacy precursors to SD-WAN come to mind):

In a long-lived project, components are being replaced. Nice reusable components are easy to replace and so they are. Ugly non-reusable components are pain to replace and each replacement means both a considerable risk and considerable cost. Thus, more often then not, they are not replaced. As the years go by, reusable components pass away and only the hairy ones remain. In the end the project turns into a monolithic cluster of ugly components melted one into another.

Note: You really should read the whole blog post.

Can You Avoid Networking Software Bugs?

One of my readers sent me an interesting reliability design question. It all started with a catastrophic WAN failure:

Once a particular volume of encrypted traffic was reached the data center WAN edge router crashed, and then the backup router took over, which also crashed. The traffic then failed over to the second DC, and you can guess what happened then...

Obviously they’re now trying to redesign the network to avoid such failures.

Read more ...

Why Should I Care About Networking?

A month ago I was asked to deliver a short presentation on “something interesting about networking” at my local university. The temptation to talk about network automation and SDN was huge, but I quickly figured out that would make no sense (the audience were students in their freshman year) and decided to talk about a fundamental question: why should a programmer care about networking.

Unfortunately the presentation wasn’t recorded, but you can browse the slide deck on the ipSpace.net public content web site.

Some Ridiculous SD-WAN Claims

SDx Central is usually a pretty good web site that I love to read, but even they occasionally manage to publish a gem like this one:

The problem with MPLS and similar technologies is that they weren’t designed with today’s business challenges in mind. Today, a company may need to launch an overseas R&D office overnight, or it may acquire a startup and want to immediately network with offices in distant regions and countries. Older technologies just don’t have the flexibility to do this on the fly.

Not surprisingly, the above paragraph triggered a severe case of Deja-Moo.

Read more ...

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.

Read more ...

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…

Read more ...

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.

Read more ...

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.

Read more ...

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.

Read more ...