Blog Posts in February 2016
Everyone talks about public or hybrid clouds, whitebox switching with home-grown networking operating system, or SDN nirvana, but whenever I talk with enterprise-focused architects, consultants or vendor SEs, I see a totally different story.
Here's a typical response I'm getting from engineers in this group: “I work with multinational financial customers, and in this group hybrid cloud is not even a topic. They do private cloud projects, with some of them looking into public cloud deployments of isolated projects on base AWS functionality.”
Imagine you get a routing outage in your network resulting in three minutes of traffic blackholing. After a few tense minutes it goes away and life is good, but you desperately want to know what went wrong. Can you figure it out? Well, you could if you were using PacketDesign tools, as Cengiz Alaettinoglu explained on Episode 51 of Software Gone Wild.
I somewhat expected that the leaf-and-spine fabrics designs webinar won’t be as short as I initially planned it to be, but when I started developing the scenarios and talking with guest speakers the whole thing exploded into a four-session saga (or maybe we’ll end up with the fifth session of a four-part trilogy).
Here’s a short update on what’s planned and where we are at the moment:
My friend Christoph Jaggi, the author of fantastic Metro Ethernet and Carrier Ethernet Encryptors documents, sent me this question when we were discussing the Data Center Fabrics Overview workshop I’ll run in Zurich in a few weeks:
When you are talking about large-scale VLAN-based fabrics I assume that you are pointing towards highly populated VLANs, such as VLANs containing 1000+ Ethernet addresses. Could you provide a tipping point between reasonably-sized VLANs and large-scale VLANs?
It's not the number of hosts in the VLAN but the span of a bridging domain (VLAN or otherwise).
One of the engineers watching the vSphere 6 Networking Deep Dive found it particularly useful:
There were pearls of knowledge in there which expanded my understanding of ESX and gave me more than a few "aha!" moments […] The course is worth the money and time for sections "uplink redundancy & load balancing" and "VLAN based virtual networks" alone.
Are there real use cases for BGP-LS and PCEP? Are they really useful? Personally I do not think they will ever be used by ISP in their (large) networks.
There are some ISPs that actually care about the network utilization on their expensive long-distance links.
After explaining why you’d want to use BGP-LS and PCEP in your network, Julian Lucek did a quick deep dive into the intricacies of BGP-LS, including printouts relating BGP-LS updates to IS-IS topology database.
This part of the PCEP/BGP-LS webinar is already public, to watch the rest of it fill in a short form on the webinar description page.
A lot of people love to talk about ASICs and merchant silicon, but very few really understand the basics. Now there’s a quick way to fix that: watch the excellent Tech Field Day video with Dave Zacks from Cisco Systems.
Mr. A. Anonymous left this comment on my BGP in the data centers blog post:
BGP is starting to penetrate into servers as well. What are your thoughts on having BGP running from the servers themselves?
Finally some people got it. Also, welcome back to the '90s (see also RFC 1925 section 2.11).
Here’s another interesting coincidence:
- A few days ago I listened to excellent Full Stack Journey podcast with Scott Lowe and Matt Oswalt in which they discussed how some engineers fear moving into adjacent technologies because they would have to (yet again) start from scratch;
- This morning I was cleaning up some old presentations and stumbled upon a diagram I’ve “never seen before” (in the middle of a presentation I created – how’s that for reliable memory) which led me to an interesting article explaining how we have to jump into unknown territories to retain the thrill we get from mastering new skills.
Homework for today: listen to the podcast, read the article, and start exploring some new technology (network automation immediately comes to mind).
A while ago someone posted a link to an article that links to LinkedIn’s blog post describing their switch-building efforts to the LinkedIn SDN group (how’s that for a circular reference?), and a consultant from Brocade felt compelled to share his wisdom with the world. Unfortunately he got most of the facts wrong.
Found this on Quora:
Money spoiled blogging. Why? Because people moved from doing great things for money and then talking about them on their free blogs, to people doing nothing but talking on their monetized blogs.
It’s not just blogs, and it’s not just cooking (the author's focus).
Several subscribers told me they’d need more details on leaf-and-spine fabric designs. As they say: your wish is my command – the upcoming update session of the leaf-and-spine fabric architectures webinar will have more details on all possible combinations of layer-2 and layer-3 fabrics.
The first session (on March 3rd) will cover layer-3 fabrics. We’ll start with the basics:
A few months ago VMware launched NSX version 6.2, and I asked my friend Anthony Burke to tell us more about the new features. Not surprisingly, we quickly started talking about troubleshooting, routing problems, and finished with route-health-injection done with a Python script. The end result: Episode 50 of Software Gone Wild. Enjoy!
With symmetric fabric… does it make sense for a node to know every bit of fabric info or is reachability information sufficient?
Let’s ignore for the moment that large non-redundant layer-3 fabrics where BGP-in-Data-Center movement started don’t need more than endpoint reachability information, and focus on a bigger issue: is knowledge of network topology (as provided by OSPF and not by BGP) beneficial?
While the large data centers increasingly use BGP as the routing protocol within their fabrics, the enterprise engineers tend to shy away from that idea because they think BGP is too complex/scary/hard-to-configure/obsolete/unknown/whatever.
It’s time to fix that.
A while ago I answered a few questions that Dan Novak from University of Maryland sent me, and as they might be relevant to someone out there decided to publish the answers.
Dan started with a soft one:
What circumstances led you to choosing network engineering for a career?
It was pure coincidence.
Julian Lucek did a fantastic job describing how NorthStar controller uses BGP-LS and PCEP, so I asked him whether he’d be willing to do a deep dive on these two topics. He gracefully agreed, and the results are already online.
I spent most of last year developing SDN-related content, resulting in pretty successful 2-day workshop and 20+ hours of online content. However, I fully agree with Matt Oswalt that network automation matters even more than lofty centralized ideas, so it was time to focus on that area.
Five years after the SDN hype exploded, it remains as meaningless as Cloud, and it seems that all we’re left with is a plethora of vendors engaged in SDN-washing their products.
Even when a group of highly intelligent engineers considering these topics on a daily basis gets together they don’t get very far apart from a great question: “what business problem is it supposed to solve?” (or maybe they got distracted by irrelevant hot-air opinions).
Is it still worth trying to find a useful definition of SDN? It seems it’s easier to list what SDN is not like I’ll be doing in the free Introduction to SDN webinar on February 10th. Let’s see:
It all started with a tweet by Stephane Clavel:
Trying to fit my response into the huge Twitter reply field I wrote “Tracking Seq# on FW should be mostly irrelevant with modern TCP stacks” and when Gal Sagie asked for more elaboration, I decided it’s time to write a blog post.
If vShield API is no longer supported, how does a small install (6-8 ESXi hosts) take care of east/west IPS without investing in NSX?
Short answer: It depends, but it probably won’t be cheap ;) Now for the details…