A few days after the Networking Field Day 9 event Nick Buraglio organized a virtual meetup with Brandon Carroll, Brandon Mangold, Bob McCouch and myself, and we discussed the presentations from NEC, Cumulus, Cisco and Brocade. Nick recorded the conversation and so Episode 26 of Software Gone Wild was born.

Just in case you're new to IPv6 and struggle with the essentials: here's an excellent cheat sheet by Jeff Carrell… and don't forget to check the amazing Cheat Sheet Library @ packetlife.net.

The fantastic Troopers 15 conference is in full swing… and I’m done with the presentations ;) The last talk I had during the conference focused on automating network security. The slides are already online; I’ll add the link to the recording when they upload the videos.

Christoph Jaggi, the author of Metro Ethernet and Carrier Ethernet Encryption Market Overview published an awesome follow-up document: an evaluation guide that lists most of the gotchas one has to be aware of when considering encryption gear, from deployment scenarios, network overhead and key exchange details to operational considerations. If you have to deal with any aspect of network encryption, this document is a must-read.

I had a great SDN-focused conversation with Terry Slattery during last Interop New York, ago and of course we came to the argument that the CLI is the root of all evil, which started my usual rant. Guess what: not surprisingly that wasn’t what Terry had in mind. He was using the “CLI mentality is bad” as a synonym for “we’re used to configuring our networks one box at a time” (so we should really be talking about box-focused mentality).

Achieving 40 Gbps of forwarding performance on an Intel server is no longer a big deal - Juniper got to 160 Gbps with finely tuned architecture - but can you do real-time optimization of a million concurrent TCP sessions on that same box at 20 Gbps?

Juho Snellman from Teclo Networks explained how they got there in Episode 25 of Software Gone Wild… and you’ll learn a ton of things about radio networks on the way.

Enjoy the show!

One of my readers decided to build an extensive DMVPN network with BGP as the WAN routing protocol (good choice!) and configured BGP SNMP traps with snmp-server enable traps bgp command on the hub router to detect spoke router failures. It turns out that’s not exactly a good idea.

Even though I wrote about the challenges of routing from VXLAN VNI to VLAN segment on a certain popular chipset a while ago, many engineers obviously still find the topic highly confusing (no surprise there, it is).

Maybe a video is worth a thousand words ;) – I published the part of recent VXLAN webinar where I described the issue in as many details as I could.

One of my readers left this comment to the Four Paths to SDN blog post:

You didn't mention Cumulus. SDN protocols become much less important when you have an open Linux switch platform. You can compile and install your own management daemon and implement whatever protocol best suits the task (and blend local and remote control).

Here’s my usual response to this line of thinking:

One of my readers sent me this question:

I have an Internet edge setup with two routers connected to two upstream ISPs and receiving full BGP routing table from them. I’m running iBGP between my Internet routers. Is there a formula to estimate convergence time if one of my uplinks fail? How many updates will I need to get the entire 512K routes in BGP table and also how much time it would take?

As always, the answer is it depends.

How many times have you received exact specifications of the traffic the e-commerce platform you have to deploy will generate? How do you buy a load balancer (application delivery controller in marketese) to support that (somewhat unknown) amount of traffic? In most cases, you buy a box that’s several times too big for the traffic the site is receiving most of the time, and still crashes under peak load.

In mid-February a blog post on Cisco’s web site announced stretched ACI fabric (bonus points for not using marketing grammar but talking about a shipping product). Will it work better than other PowerPoint-based fabrics? You bet!

What’s the Big Deal?

Cisco’s ACI fabric uses distributed (per-switch) control plane with APIC controllers providing fabric configuration and management functionality. In that respect, the ACI fabric is no different from any other routed network, and we know that those work well in distributed environments.

Want to know more about SDN and network automation/programmability, but don’t know where to start? Why don’t you try the free Introduction to SDN and Network Automation training available on ipSpace.net – you’ll get seven hours of high-quality content that will help you understand where it might make sense to use SDN technologies in your network and what SDN, OpenFlow, NFV, NETCONF, Ansible, YAML, Jinja and a few other acronyms are all about.

My good friend Tom Hollingsworth wrote a great blog post about hypermyopia in the networking industry. I agree with most everything he wrote (I have to – I’m always telling people to focus on business needs and to change their mentality before relying on shiny new gizmos), but I still think it’s crucial to consider the technology used in products we’re looking at.

Whenever I get asked about QoS in the data center, my stock reply is “bandwidth is cheaper than QoS-induced complexity.” This is definitely true in most cases, and ideally the elephant problems should be solved higher up in the application stack, not with network-layer kludges, but are there situations where you actually need data center QoS?