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.

MPLS Traffic Engineer is sometimes promoted as a QoS solution (it seems bandwidth calendaring is a permanent obsession of some networking engineers, and OpenFlow is no more a solution than MPLS-TE was ;), but in reality it’s pretty hard to make the two work together seamlessly (just ask anyone who had to implement auto-bandwidth MPLS-TE in a large network).

One of the main complaints I was continuously getting about my free content is that there’s simply too much of it, and that it’s impossible to find what one is looking for.

New Year holidays gave me enough time to implement a project that has been on my to-do list for almost a year: total redesign of the free content web site. Feedback highly appreciated!

Whenever there’s a weird request to do something totally illogical with BGP, there’s a knob in Cisco IOS to get it done (and increase the heartburn of CCIE candidates). Conditional Route Injection (the ability to insert more specific prefixes into BGP without having them in the IP routing table) is one of them.

Keep in mind: being a MacGyver is not a long-term strategy. Just because you can doesn’t mean that you should.

After discussing the basics of MPLS, MPLS-TE and LDP, and the relationship between FECs, LDP and BGP, Seamus and myself focused on another interesting topic: how MPLS protocol stack uses RSVP to implement traffic engineering.

One of the networking engineers using my ExpertExpress to validate their network design had an interesting problem: he was building a multi-tenant VLAN-based private cloud architecture with each tenant having multiple subnets, and wanted to route within the tenant network as close to the VMs as possible (in the ToR switch).

He was using Nexus 5600 as the ToR switch, and although there’s conflicting information on the number of VRFs supported by that switch (verified topology: 25 VRFs, verified maximum: 1000 VRFs, configuration guide: 64 VRFs), he thought 25 VRFs (tenant routing domains) might be enough.

The edited videos for Scaling Overlay Virtual Networking webinar are available on ipSpace.net Content site. Nuage Networks sponsored the webinar; the videos are thus publicly available (without registration).

Highly customizable high-speed virtual switch written in Lua sounds great, but is it really that easy to use? Simon Leinen was kind enough to get me in touch with Alex Gall, his colleague at Switch, who's working on an interesting project: implementing L2VPN over IPv6 with Snabb Switch.

Facebook published their next-generation data center architecture a few weeks ago, resulting in the expected “revolutionary approach to data center fabrics” echoes from the industry press and blogosphere.

In reality, they did a great engineering job using an interesting twist on pretty traditional multi-stage leaf-and-spine (or folded Clos) architecture.

Simonp made a perfectly valid point in a comment to my latest OVS blog post:

Obviously the page you're referring to is a quick-and-dirty benchmark. If you wanted the optimal numbers, you would have to tune quite a few parameters just like for hardware benchmarks (sysctl kernel parameters, Jumbo frames, ...).

While he’s absolutely right, this is not the performance data a typical user should be looking for.