Blog Posts in March 2015
The video of my Automating Network Security talk @ Troopers 15 has been published on YouTube. They used fixed camera and the slides are a bit hard to read; you’ll find a better copy of the slide deck on my content web site.
For a bit of fun, turn on closed captions (CC) – public cloud became public lout.
The IPv6 Security Summit at the Troopers conference always has a few awesome IPv6 presentations (many people claim Troopers is the conference to attend if you’re serious about IPv6), and this year was no exception. A day after the MLD bashing, Enno Rey delivered a great in-depth presentation on DHCPv6 features and shortcomings.
It seems the DHCPv6 intricacies presented in that talk were too much for some of the attendees – that afternoon I accidentally stumbled upon a visibly distressed gentleman who started our chat with “How could anyone expect us to deploy IPv6 in a production environment?”
VM NIC firewalls have been around for years (they’re also the reason I got my first invitation to the awesome Troopers conference), but it sounds so much better when you call them Microsegmentation (not the one I talked about @ Troopers this year).
Marketing gimmicks aside, VMware NSX includes an interesting in-kernel stateful firewall, and Brad Hedlund was kind enough to explain the intricacies of that feature in Episode 27 of Software Gone Wild
Multicast Listener Discovery (MLD) protocol is well hidden deep in the bowels of IPv6 protocol stack and most of us tend to gloss over it when we discuss IPv6 neighbor discovery process… until MLD raises its ugly head to bite an unsuspecting network administrator.
The problems with MLD are not new (and I wrote exhaustively about them a while ago), but it’s always nice to see other people raise awareness of broken IPv6 features like Enno Rey and his security team did during the IPv6 Security Summit (part of Troopers 15 conference).
Amazon Web Services was (AFAIK) one of the first products that introduced availability zones – islands of infrastructure that are isolated enough from each other to stop the propagation of failure or outage across their boundaries.
Not surprisingly, multiple availability zones shouldn’t rely on a central controller (as Amazon found out a few years back), and there are only few SDN controller vendors that are flexible enough to meet this requirement. For more details, watch the free Availability Zones video on my web site (part of Scaling Overlay Virtual Networking webinar).
A few weeks ago HP announced that they’d start selling branded whitebox (brite-box) switches, and as expected the industry press was immediately full of opinions. As always, it makes sense to follow the money (or, in this case, the R&D budget) to understand what’s going on behind the scenes.
I was speaking with a participant of the recent SDN event in Zurich after the presentations, and he made an interesting comment: whenever he experienced serious troubleshooting problems in his career, it was due to lack of understanding of networking fundamentals.
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.
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?
One of my readers decided to build a large 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. 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).
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.