Early November seems to be the right time for data center product harvest: after last week’s Juniper launch, Arista launched its new switches on Monday. The launch was all we came to expect from Arista: better, faster, more efficient switches … and a dash of PureMarketing™ – the Splines.

You did read my blog post on ThousandEyes, didn’t you? What I forgot to mention was that they have this cool API that allows you to extract measurement data (including BGP topology) from their system. Can we do something cool with that?

The recent Juniper product launch included numerous components, among them: a new series of data center switches (including a badly-needed spine switch), MetaFabric reference architecture (too meta for me at the moment – waiting to see the technical documentation beyond the whitepaper level), and (finally) a leaf-and-spine virtual chassis – Virtual Chassis Fabric.

A while ago I had a discussion with someone who wanted to be able to move whole application stacks between different private cloud solutions (VMware, Hyper-V, OpenStack, Cloud Stack) and a variety of public clouds.

Not surprisingly, there are plenty of startups working on the problem – if you’re interested in what they’re doing, I’d strongly recommend you add CloudCast.net to your list of favorite podcasts – but the only correct way to solve the problem is to design the applications in a cloud-friendly way.

PLNOG organizers published the video of my Overlay Virtual Networking Explained presentation. They did a fantastic job, nicely merging live video with slides and splendid background.

If you need more details or an in-depth evaluation of products from numerous vendors, check out the Overlay Virtual Networking webinar (the final videos have just been published).

Last week I described how Cisco Modeling Lab (CML, the product formerly known as VIRL) works behind its fantastic UI, and promised more information about the UI once I get access to a preview version of CML, which I got a few days ago. Here are the results of the first brief stroll down the virtual lane.

A group of researches presented an “interesting” result @ IETF 87: migrating from IBGP full mesh to IBGP reflectors can introduce temporary forwarding loops. OMG, really?

Don’t panic, the world is not about to become a Vogon hyperspace bypass. Let’s put their results in perspective.

Michael Haines (probably inspired by my data center design and recent tweet) sent me the best traceroute hint I've ever seen. Do traceroute obiwan.scrye.net and you'll see something like this:

Every good data center presentation starts with redefining The Problem and my VMware NSX Architecture webinar was no exception – the first section describes Infrastructure-as-a-Service Networking Requirements.

I sprinted through this section during the live session, the video with longer (and more detailed) explanation comes from the Overlay Virtual Networking webinar.

The first hints of VIRL started appearing around Cisco Live US 2013 where the product development team demonstrated Cisco’s take on 21st century network modeling tool. A few days ago, Omar Sultan, Joel Obstfeld and Ed Kern gave us a brief peek behind the scenes of this totally awesome tool (note to Cisco haters: I haven’t been drinking the teal Kool-Aid for a long time – this is my honest impression).

Ashton Bothman from Juniper invited me to an interesting contest: build a Lego Data Center. I just happen to have in-house Lego Design Experts (read: kids), so I gladly delegated the task to that team. Here are the results (using the Force instead of unicorns).

An odd idea stroke me when watching the Avalanche NEXT presentation during Networking Tech Field Day – they have a fuzzing module that you can use to test whether your servers and applications survive all sorts of crazy illegal requests. Could that be used to detect SQL injection vulnerabilities in your web apps?

The number of OpenFlow flows you can use in hardware switches is one of the major roadblocks in a large-scale OpenFlow deployment. Vendors often use hardware TCAM tables to match OpenFlow entries, and as those tables are expensive to implement in silicon, they tend to be small. Typical TCAM tables have a few thousand entries.

Is that good enough? As always, the answer depends on the use case, the network size, and implementation details. This blog post will focus on the last part.

TL&DR summary: Use switches that support OpenFlow 1.3.

Ronald Bartels created an interesting network troubleshooting checklist that covers numerous aspects of the troubleshooting process, from information gathered during problem reporting phase to timelines, investigation activities, device and port checks ... Feedback highly welcome!