It’s been some time since I wrote about Cisco’s onePK. In this post, I’ll look at some of the good and the bad of onePK and also show an example of how to add a route to a device running onePK to help make a few points along the way.
With other acquisition rumors floating around, I figured I would add my own 2 cents and do some speculating.
It’s not uncommon to hear that VMware might acquire Cumulus. Like others, it’s one acquisition that I’ve speculated about for a while. There is already an interesting dynamic between Cisco and VMware, but as both companies continue to go to market with their Software Defined Networking (SDN), or controller based solutions, VMware still needs to run over a physical data center network. The physical network market is still largely dominated by Cisco though. Does VMware want or need to control the physical network?
Last week I had the pleasure of speaking at Interop in NYC. It wasn’t the best turn out for a conference, but all of the sessions that were about automation, APIs, DevOps, and programmability seemed to do fairly well. For those that didn't attend, the title of the presentation was A Practical Look at Network Automation --- the deck is posted below.
Many vendors collect their own data that is more than likely a little skewed and biased. As I prepare for a few upcoming presentations, I thought it would be great to get some REAL data from REAL people doing great things or even those just starting on their automation journey.
If you would be kind enough, there is a link to a survey below that asks a few questions pertaining to network automation and programmability. No personal information is required.
Network Automation & Programmability Survey
If you wish to see the results, please fill the survey out :)
Thanks in advance,
Cumulus Networks has been talking a lot about Prescriptive Topology Manager (PTM). A great overview of PTM can be found here, but the high level is that PTM ensures “wiring rules are followed by doing a simple runtime verification of connectivity.” This means that as a user, you can define what the physical topology, or wiring, is supposed to be and compate it against what it really is by leveraging LLDP. The PTM daemon (PTMd) is what does this analysis on each switch running Cumulus Linux. There is even integration with routing protocols such that if two switches are improperly cabled, no routing adjacencies will be permitted on that link. You can check out the PTM code since it is available under the Eclipse Public License (EPL).
Last month I wrote about using the Cisco Nexus NX-API to extract stats from a Nexus switch while using Ansible. For some reason, last night I finally went on to tackle how to integrate with the Twitter API and then integrated the two together. Integrating with Twitter has always been top of mind, but just put it on the back burner. Funny enough though, it was a pretty quick integration thanks to the great people at Google.
I’ve spent the last few days getting briefed by several vendors in Silicon Valley. They include A10, Big Switch, Brocade, Cisco, Gigamon, Nuage, Pluribus, Spirent, and Thousand Eyes. Over the next few weeks, I’ll try and get a few posts out about the briefings, but for the first one I wanted to focus on Spirent. Many are probably aware that Spirent provides packet generators and while that’s what they sell and are really good at, it’s the strategy, vision, and software integration with their products that was extremely intriguing.
At the end of the day, any announcement that is NON networking focused NEEDS a networking focus. I just attended the UCS Grand Slam launch where there were a few announcements for UCS including the new UCS mini, capacity optimized UCS, and the UCS modular chassis (M series). The latter was of the most interest to me.
With some downtime this weekend, I was able to watch a few documentaries on NetFlix. There were a few great ones on Mark Zuckerberg, Warren Buffet, Mark Cuban, and Steve Jobs. Many of them came from the Bloomberg Game Changers series, but for Steve Jobs, I watched the Steve Jobs: The Lost Interview that was filmed in 1995, lost for almost two decades and then was released in 2012. I highly recommend all of them, but for this post, I want to highlight something Jobs said nearly 20 years ago.
It’s an interesting time in networking, isn’t it? I can probably quote myself saying that for as long as I’ve been blogging and about a year before that. Supposedly 2015 is the year of POCs, bakeoffs, and seeing which startups continue to get funding, and which ones slowly dissolve. As we start to see who the winners and losers may be, I thought it would be good to highlight the last 7 years and where the major focuses areas have been and see what could be next.
I had a conversation recently with someone who has more of a sysadmin background. We started talking about the intersection of DevOps and networking and while his environment wasn’t large, there was one pain point he talked about – he doesn't have access to the network switches to ensure they are configured properly for “his” servers and to ensure packets aren't being dropped, etc. when there are issues with the application, server, or network. And by the way, he really doesn't want access to the data center switches, because after all, many fear logging into network devices that are in production.
Could DevOps and network automation help here?
There was a recent blog by Mark Burgess, founder and creator of CFEngine. It is a must read (on his personal blog). He really makes you think where we are as an industry, question if we are on the right path, and quite frankly calling out certain technologies as pity attempts compared to what is needed. Regardless of all that, we cannot forget one key point, the industry is in fact moving forward right now.
Over the past few months, I’ve been posting on using Ansible for network automation. Changing things up a bit, this post will cover using Ansible for server automation and I’ll share a few Ansible playbooks that I’ve built and have been using to bootstrap servers and prep them for various applications such as OpenStack and NSX deployments.
Over the past few years, I’ve had the opportunity to work with best and the brightest in the industry. The reach started with my co-workers, partners, and vendors, but gradually expanded due to the likes of maintaining a blog and occasionally being on Twitter. In a recent exchange with someone who gave me a massive pivot and jump start in my career almost 10 years ago, it reminded me of a presentation this same person gave back then.
In my previous post about Docker, I focused on an introduction to networking with Docker. That post had a fair amount of traction mainly due to it being #dockercon the week it was published, and seemingly, people had an interest in learning more about it. Following the post, there were a few folks (@hartley and others) that pointed me to some great links about more advanced concepts in Docker and a site that validated what I was speculating with leveraging overlay tunnels as means for connectivity between nodes running Docker.
There has been a ton of information out there on Docker over the last week. Because the impact on networking is often overlooked for new technologies, I figured I’d get a head start to understand the basics of Docker Networking. This post documents the steps I took to test docker analyzing the network constructs that are automatically configured during container creation.
Automating the configuration, provisioning, and management of particular workflows for cloud gets a lot of attention these days. While automation makes perfect sense for deploying workloads faster, there are also other areas where automation can be leveraged to improve the overall operational efficiency of the IT Ops team.
If you read this site often, you already know I’ve been doing quite a bit of work with Ansible specifically as it pertains to networking. While I will be showing another video very soon in a follow up post, I wanted to take a step back and cover a few things before doing so. The focus here is less about the technology and more my general mindset around automation PLATFORMS, code, open source, and why I do it. Just something I’d like to share because I’m occasionally asked questions around these topics.
When networks are deployed in a box by box model, network admins know exactly what, where, and how something is being configured. In highly dynamic environments, this may not be the case. This is why it’s crucial to understand what is really going on behind the scenes. In OpenStack, there are several components that together are comprised to make OpenStack Networking (aka Neutron). These include the Neutron server, dhcp agent, metadata agent, L3 agent, and then the agents that would reside in the infrastructure to be programmed (on either physical and/or virtual switches). For example, in Open vSwitch deployments, there would be a Neutron OVS agent on each host/server. And this could vary based on which particular vendor plugin is being used too!
[Special and huge thanks to Scott Lowe for answering an endless amount of questions I had while writing this post and testing with NSX/OVS over the last few days. Thanks to Deepesh as well who I bounced OVS questions off of when I needed to give Scott a break. ]
In Open vSwitch 101, I described the three main components that make up Open vSwitch (OVS) from an architectural standpoint, namely ovs-vswitchd, ovsdb-server, and the fast path kernel module. If you start to work with OVS, the first thing you realize is that it takes quite a bit more knowledge to really understand it. This post will focus on some design principles and options when running OVS on a hypervisor like KVM in conjunction with a network virtualization solution.
There is so much discussion on if network engineers need to be programmers that I was almost getting pissed off last week. It was an odd and funny feeling. Anyway, I've written in the past here and here about the use of Ansible for networking. In this post and video, the goal is to show why network engineers don’t need to be "hardcore programmers."
In the last post, I talked about how Ansible could be used for various forms of network automation. In the comments, Michael asked if Ansible could also be used for network test automation and verification. Since I’m just starting to explore Ansible, I figured why not try it out. The short answer is, it’s possible. Let’s take a look at an example proving this out.
[This article is the outcome of some great conversations and exchanges I’ve had recently with Jeremy Schulman (@nwkautomaniac) around automation and Devops in the world of networking. Thank you to Jeremy for those late tweaks before getting this posted! Thanks to Kirk Byers (@kirkbyers) as well - he was also gracious enough to respond to clarify a few things and assisted with this post indirectly.]
There have been numerous articles written that describe the what and the why of Devops. Reading through a few of these, you find references to CAMS --- you’ll read how “Devops is about CAMS.” CAMS stands for Culture, Automation, Measurement, and Sharing. Imagine working in an environment where automation is embraced? We know most networks are not leveraging nearly any type of automation. While we usually talk about engineers (of all types) not embracing automation, is the harsh reality most organizations are from having the right culture to embrace automation?
You can’t listen to an interview or podcast, an industry panel, or read a Q&A about the future of networking that doesn't involve skill sets. The biggest question of them all – what skills should network engineers focus on so they don’t become irrelevant? If you really want to know what skills make sense, why ask, when you can do an easy search to see what skills companies are looking for these days in a variety of roles. Combine SDN with DevOps into your search criteria and the results may surprise you. They sure surprised me.
It’s been two weeks since I attended my 3rd consecutive Open Networking Summit (ONS) and I’m glad to say, I finally found some time to get some notes and thoughts on paper about the conference. Here are some on SDN at Google and Microsoft, and how they compare and contrast to industry incumbents’ solutions, but also how programmable NFV can be game changing in the Enterprise. I also include thoughts on how Embrane and Big Switch play into this.