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.

Several SDN solutions that coexist with the traditional control- and data planes instead of ripping them out and replacing them with the new awesomesauce use BGP to modify the network’s forwarding behavior.

Border6 decided to turn that concept into a commercial product that we dissected in Episode 12 of Software Gone Wild podcast.

Enjoy the show (this time in video format).

I was listening to the Packet Pushers show #203 – an interesting high-level discussion of policies (if you happen to be interested in those things) – and unavoidably someone had to mention how the networking is all broken because different devices implement the same functionality in different ways and use different CLI/API syntax.

If you want to get a free copy of my SDN and OpenFlow – The Hype and the Harsh Reality book, download it now. The offer will expire by October 20th.

My “Was it bufferbloat?” blog post generated an unexpected amount of responses, most of them focusing on a side note saying “it looks like there really are service providers out there that are clueless enough to reorder packets within a TCP session”. Let’s walk through them.

Michael Church wrote an interesting answer on Quora, describing a logarithmic scale of programming skills and (even more importantly) hints to follow to get from n00b into the top N% (for some small value of N):

• Budget 7–14 years;
• Study voraciously;
• Build things when you don’t know that you’ll succeed;
• Network to get new ideas;
• Job hop when you stop learning.

Replace “programmer” with “networking engineer” and read the whole answer ;)

Randall Greer left a comment on my Revisited: Layer-2 DCI over VXLAN post saying:

Could you please elaborate on how VXLAN is a better option than OTV? As far as I can see, OTV doesn't suffer from the traffic tromboning you get from VXLAN. Sure you have to stretch your VLANs, but you're protected from bridging failures going over your DCI. OTV is also able to have multiple edge devices per site, so there's no single failure domain. It's even integrated with LISP to mitigate any sub-optimal traffic flows.

Before going through the individual points, let’s focus on the big picture: the failure domains.

In July I wrote about an Amazon Kindle version of my Data Center Design Case Studies book and complained about their royalties model. Someone quickly pointed out how to adapt to their system: split the book into multiple volumes and charge $9.99 for each.

It took me months to get there, but the first two volumes are finally on Amazon:

I was listening to the I2RS Packet Pushers podcast a while ago and was more than glad that when Greg Ferro yet again mentioned the complexity of OSPF, someone simply pointed out that controllers would not reduce the complexity; if anything they would increase it.

Bryan sent me an interesting question:

When you have the opportunity to use LAG or ECMP, what are some things you should consider?

He already gathered some ideas (thank you!), and I expanded his list and added a few comments.

Purpose: resiliency or more bandwidth? For resiliency you want fast failure detection and the ability to connect to multiple uplink devices, for more bandwidth, you want better hashing.

Last week’s Interop New York was hard work (three workshops in two days), but also lots of nerdy fun. I love doing workshops with smart participants who bring their real-life problems to the room and challenge my assumptions and conclusions, and I had plenty of these interactions during the week. Thank you all (you know who you are)!

The stars have finally aligned, and after months of scheduling Jason and myself found time to chat about network automation tools and all the other exciting things Jason is doing (and blogging about).

We started with easy topics:

Every now and then I get an email from a subscriber having video download problems. Most of the time the problem auto-magically disappears (and there’s no indication of packet loss or ridiculous latency in traceroute printout), but a few days ago Henry Moats managed to consistently reproduce the problem and sent me exactly what I needed: a pcap file.

TL&DR summary: you have to know a lot about application-level protocols, application servers and operating systems to troubleshoot networking problems.

After covering the basics of MPLS, my discussion with Seamus Gilchrist turned to the basics of MPLS Traffic Engineering.

The video of that discussion is available in the MPLS Essentials webinar.

During one of my ExpertExpress engagements I got an interesting question: “could we replace a pair of central firewalls with iptables on the Linux server?”

Short answer: Maybe (depending on your security policy), but I’d still love to see some baseline scrubbing before the traffic hits the server – after all, if someone pwns your server, he’ll quickly turn off iptables.