Category: WAN

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

One of my readers sent me this question:

What is best practice to get a copy of the VM image from DC1 to DC2 for DR when you have subrate (155 Mbps in my case) Metro Ethernet services between DC1 and DC2?

The slow link between the data centers effectively rules out any ideas of live VM migration; to figure out what you should be doing, you have to focus on business needs.

Achieving 40 Gbps of forwarding performance on an Intel server is no longer a big deal - Juniper got to 160 Gbps with finely tuned architecture - but can you do real-time optimization of a million concurrent TCP sessions on that same box at 20 Gbps?

Juho Snellman from Teclo Networks explained how they got there in Episode 25 of Software Gone Wild… and you’ll learn a ton of things about radio networks on the way.

In mid-February a blog post on Cisco’s web site announced stretched ACI fabric (bonus points for not using marketing grammar but talking about a shipping product). Will it work better than other PowerPoint-based fabrics? You bet!

What’s the Big Deal?

Cisco’s ACI fabric uses distributed (per-switch) control plane with APIC controllers providing fabric configuration and management functionality. In that respect, the ACI fabric is no different from any other routed network, and we know that those work well in distributed environments.

One of my readers got an interesting idea: he’s trying to make the most of his WAN links by doing per-packet load balancing between a 30 Mbps and a 50 Mbps link. Not exactly surprisingly, the results are not what he expected.

A few months ago I described how bandwidth limitations shatter the dreams of spread-out application stacks with elements residing (or being dynamically migrated) between data centers. Today let’s focus on bandwidth’s ugly cousin: latency.

TL&DR Summary: Spreading the server components of an application across multiple locations (multiple data centers or hybrid cloud deployments) can easily result in dismal performance even when there’s plenty of bandwidth available.

One of my readers sent me an interesting challenge:

We have two MPLS providers sending us default routes and it seems like whenever we have problem with SP1 our failover is not happening properly and actually we have to go in manually and influence our traffic to forward via another path.

Welcome to the wondrous world of byzantine routing failures ;)

Like many of us Khalid Raza wasted countless hours sitting in meetings discussing hybrid WAN connectivity designs using a random combination of DMVPN, IPsec, PfR, and one or more routing protocols… and decided to try to create a better solution to the problem.

More than a year ago I wrote a response to a comment Pascal wrote on my Predicting the IPv6 BGP table size blog post. I recently rediscovered it and figured out that it’s (unfortunately) as relevant as it was almost 18 months ago.

Other people have realized we have this problem in the meantime, and are still being told to stop yammering because the problem is not real. Let’s see what happens in a few years.

People talking about long-distance workload mobility and cloudbursting often forget the physical reality documented in the fallacies of distributed computing. Today we’ll focus on bandwidth, in a follow-up blog post we’ll deal with its ugly cousin latency.

TL&DR summary: If you plan to spread application components across the network without understanding their network requirements, you’ll get the results you deserve.