Category: Switching

It’s always great to see students enrolled in Building Network Automation Solutions online course using ideas from my sample playbooks to implement a wonderful solution that solves a real-life problem.

James McCutcheon did exactly that: he took my LLDP-to-Graph playbook and used it to graph VLANs stretching across multiple switches (and provided a good description of his solution).

One of my readers was wondering about the stability and scalability of large layer-2 domains implemented with VXLAN. He wrote:

If common BUM traffic (e.g. ARP) is being handled/localized by the network (e.g. NSX or ACI), and if we are managing what traffic hosts can send with micro-segmentation style filtering blocking broadcast/multicast, are large layer-2 domains still a recipe for disaster?

There are three major (fundamental) problems with large L2 domains:

I got several questions along the lines of “why is Cisco pushing LISP instead of using EVPN in VXLAN-based Enterprise campus solutions?”

Honestly, I’m wondering that myself (and maybe I’ll get the answer in a few days @ NFD16). However, let’s start at the very beginning…

Eyvonne Sharp wrote an interesting blog post describing the challenges Cisco might have integrating Viptela acquisition, particularly the fact that Viptela has a software solution running on low-cost hardware.

Guess what… Cisco IOS also runs on low-cost hardware, it’s just that Cisco routers are sold as a software+hardware bundle masquerading as expensive hardware.

Got this feedback from a network architect attending the Open Networking for Large-Scale Networks webinar:

I used the webinar when preparing for a meeting/discussion with a NOS SW-vendor. In the meeting, my knowledge was completely up-to-speed & I was on the level with the vendor in the discussion! :-)

Obviously, Russ White and Shawn Zandi did a great job based on their real-life hands-on experience (they use whitebox switches @ LinkedIn).

During Cisco Live Europe 2017 (where I got thanks to the Tech Field Day crew kindly inviting me) I had a nice chat with Peter Jones, principal engineer @ Cisco Systems. We started with a totally tangential discussion on why startups fail, and quickly got back to flexible hardware and why one would want to have it in a switch.

Last year Cisco launched a new series of Nexus 9000 switches with table sizes that didn’t match any of the known merchant silicon ASICs. It was obvious they had to be using their own silicon – the CloudScale ASIC. Lukas Krattiger was kind enough to describe some of the details last November, resulting in Episode 73 of Software Gone Wild.

For even more details, watch the Cisco Nexus 9000 Architecture Cisco Live presentation.

One of my readers wondered what the difference between fabric extenders and leaf-and-spine fabrics is:

We are building a new data center for DR and we management is wanting me to put in recommendations to either stick with our current Cisco 7k to 2k ToR FEX solution, or prepare for what seems to be the future of DC in that spine leaf architecture.

Let’s start with “what is leaf-and-spine architecture?”

When Facebook announced 6-pack (their first chassis switch) my reaction was “meh” (as well as “I would love to hear what Brad Hedlund has to say about it”). When Facebook announced Backpack I mostly ignored the announcement. After all, when one of the cloud-scale unicorns starts talking about their infrastructure, what they tell you is usually low on detail and used primarily as talent attracting tool.

Do you need large buffers in data center switches or not? If you’re a vendor your take obviously depends on whether you have them or not, and then there are people saying “it’s bullshit” (mostly agree) and “look, I have a shinier toy” (get lost).

Unfortunately, it’s really hard to get someone who would know what he’s talking about, and be relatively unbiased.