Category: switching

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.

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.

When LinkedIn announced their Project Falco I knew exactly what one of my future Software Gone Wild podcasts would be: a chat with Russ White (Mr. CCDE, now network architect @ LinkedIn).

It took us a long while (and then the summer break intervened) but I finally got it published: Episode 62 is waiting for you.

One of my readers has customers that already experienced performance challenges with Tomahawk-based data center switches. He sent me an email along these lines:

My customers are concerned about buffer performance for packets that are 200 bytes and under. MORE IMPORTANTLY, a customer informed me that there were performance issues when running 4x25GE connections when one group of ports speaks to another group.

Reading the report Mellanox published not so long ago it seems there really is something fishy going on with Tomahawk.

Russ White made an excellent remark while discussing the news that the CloudRouter pushed 650 Gbps through commodity hardware: “If this is software defined networking, then we’ve been doing this since sometime in the 1990’s, perhaps even earlier…”

He’s absolutely right – the first routers (like AGS or IGS from Cisco) did all packet forwarding in software, so as I explained during the Introduction to SDN webinar while reaching dozens of gigabits with software-based packet forwarding is exciting, calling it SDN doesn’t make much sense.

Some people conflate SDN with whitebox switches preferably running Linux. So what exactly is software-hardware disaggregation, and how do whitebox switches and third-party network operating systems fit into the bigger picture?

I tried to answer these questions in the SDN is not whitebox switching part of (free) Introduction to SDN webinar.

Imagine you want to have an IPv6-only access network and transport residual IPv4 traffic tunneled across it. Sounds great, but you need to terminate those tunnels and encapsulate/decapsulate IPv4 traffic at multi-gigabit rate.

There are plenty of reassuringly-expensive hardware solutions that can do that, or you could work with really smart people and get software-based solution that can do 20 Gbps per CPU core.