“Daddy, why is Internet not working even though I have good signal?”
“You really want to know?”
“Sure”
“OK, let me draw a diagram or two ;)”

… and now my 8-year old knows how DHCP and DNS works (root cause was a broken DNS proxy running on upstream $0.99 WAN router).

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.

Engineers developing open-source wireless mesh network protocols and solutions get together every now and then to test the performance of competing mesh network ideas.

The next conference is organized in August 2015 in Maribor, Slovenia, so if you ever needed a good excuse to drop by Slovenia, now you have one ;)

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.

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.

While some people lament the lack of IPv6 business case, others are busy rolling it out – you (RFC 2119) SHOULD check out the Status of Swisscom’s IPv6 Activities presentation from recent Swiss IPv6 summit.

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.

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…

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.

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.

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.

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.

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.

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?

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?