Category: fabric

A Technology Market Builder (in his own words) from a major networking vendor decided to publish a thought leadership article (in my sarcastic words) describing how Cisco’s embrace of complexity harmed the whole networking industry.

Let’s see how black this kettle-blaming pot really is ;), and make sure to have fun reading the comments to the original article.

An engineer working for a large system integrator sent me this question:

Since you are running a detailed series on leaf-and-spine fabrics these days, could you please suggest if following design scenarios of Facebook and Linkedin Data centers are also covered?

Short answer: No.

A few months ago I met a number of great engineers from Avaya and they explained to me how they creatively use Shortest Path Bridging (SPB) to create layer-2, layer-3, L2VPN, L3VPN and even IP Multicast fabrics – it was clearly time for another deep dive into SPB.

It took me a while to meet again with Roger Lapuh, but finally we started exploring the intricacies of SPB, and even compared it to MPLS for engineers more familiar with MPLS/VPN. Interested? Listen to Episode 54 of Software Gone Wild.

The featured webinar in March 2016 is the Leaf-and-Spine Designs update to the Leaf-and-Spine Fabrics webinar, and in the featured videos (the ones marked with a star) you'll find in-depth explanation of BGP features available in Cumulus Linux, including a cool trick that allows you to run EBGP sessions across unnumbered interfaces.

My latest spanning tree protocol (STP) posts generated numerous comments, some of them so relevant that I decided to summarize them into another blog post.

Weird Things Happen

The unidirectional link scenario mentioned by Antonio is pretty well known:

A few days ago Inside-IT published an interview Christoph Jaggi did with me. In case you don’t understand German, here’s the English version of it.

There is a lot of talk about data center fabrics. What problem do they try to solve?

The data center fabrics are supposed to solve a simple-to-define problem: building a unified data center infrastructure that seamlessly supports data and storage communications. As always, the devil hides in the details.

Continuing our bridging loops discussion Christoph Jaggi sent me another question:

Theoretically STP should avoid bridging loops, and yet you claim they cause data center meltdowns. What am I missing?

In theory, STP avoids bridging loops. In practice, there are numerous reasons STP got a bad name.

My friend Christoph Jaggi, the author of fantastic Metro Ethernet and Carrier Ethernet Encryptors documents, sent me this question when we were discussing the Data Center Fabrics Overview workshop I’ll run in Zurich in a few weeks:

When you are talking about large-scale VLAN-based fabrics I assume that you are pointing towards highly populated VLANs, such as VLANs containing 1000+ Ethernet addresses. Could you provide a tipping point between reasonably-sized VLANs and large-scale VLANs?

It's not the number of hosts in the VLAN but the span of a bridging domain (VLAN or otherwise).

A while ago someone posted a link to an article that links to LinkedIn’s blog post describing their switch-building efforts to the LinkedIn SDN group (how’s that for a circular reference?), and a consultant from Brocade felt compelled to share his wisdom with the world. Unfortunately he got most of the facts wrong.

While the large data centers increasingly use BGP as the routing protocol within their fabrics, the enterprise engineers tend to shy away from that idea because they think BGP is too complex/scary/hard-to-configure/obsolete/unknown/whatever.

It’s time to fix that.

Online webinars are great, but many engineers still prefer live workshops – they’re an excellent opportunity for unrestricted 2-way communication and exchange of ideas – so I decided to turn a few of my best webinars (or webinar tracks) into workshops, and Gabi Gerber, the wonderful organizer of Data Center days in Switzerland took over the logistics, resulting in the first-ever Data Center Fabrics workshop in Zurich in late March.

In theory, you should shut down a network device with a well-defined procedure:

• Drain the traffic from the device;
• Verify the device is no longer forwarding traffic;
• Turn off the device.

In practice, network devices don’t have a shutdown command, and reload typically just restarts the network OS.

Juniper recently launched their Tomahawk-based switch (QFX5200) and included a lot of information on the switching hardware in one of their public presentations (similar to what Cisco did with Nexus 9300), so I got a non-NDA glimpse into the latest Broadcom chipset.

You’ll get more information on QFX5200 as well as other Tomahawk-based switches in the Data Center Fabrics Update webinar in spring 2016.

Here’s what I understood the presentation said:

Do you want to know more about Cumulus Linux after learning what data center architectures it supports, what base technologies it uses, and how you can use it to simplify network configurations? It’s time to explore Cumulus Linux architecture (part 5 of the presentation Dinesh Dutt had during the Data Center Fabrics webinar).

I was really excited when Juniper announced Junos Fusion. I hoped for QFabric Done Right, but after watching the NFD10 video describing the architecture, I was disappointed: they reinvented Fabric Extenders.

The blog post was slightly updated on November 14th 2015 based on feedback received from Juniper engineers.