I haven’t done an update on what Avaya was doing in the data center space for years, so I asked my good friend Roger Lapuh to do a short presentation on:
- Avaya’s data center switches and their Shortest Path Bridging (SPB) fabric;
- SPB fabric features;
- Interesting use cases enabled by SPB fabric.
A while ago (in the time of big-versus-small buffers brouhaha) I asked JR Rivers to do a short presentation focusing on buffering requirements of data center switches. He started by describing typical buffer architectures you might find in data center switches.
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.
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! :-)
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.
We did several podcasts describing how one could get stellar packet forwarding performance on x86 servers reimplementing the whole forwarding stack outside of kernel (Snabb Switch) or bypassing the Linux kernel and moving the packet processing into userspace (PF_Ring).
Now let’s see if it’s possible to improve the Linux kernel forwarding performance. Thomas Graf, one of the authors of Cilium claims it can be done and explained the intricate details in Episode 64 of Software Gone Wild.
One of the common taglines parroted by SDN aficionados goes along the lines of “The cost to acquire and manage server and storage architectures has declined over time while networking stays stubbornly expensive.” (I took it straight from an anonymous blog comment).
Let’s see how well it matches reality.
It took us a long while (and then the summer break intervened) but I finally got it published: Episode 62 is waiting for you.