An interesting tweet popped up in my timeline the other day and my reply was:
I think the distinction between an actual capability and how and with what it is being achieved gets lost in a lot of cases. When you define “connectivity” as a capability there are many options to choose from in how to achieve that. But in essence none of those should have a vendor name attached to it. An architect should be holistic, but at the same time should know how an actual network operates. This mix is not always logical especially in the lower layers of the OSI-model.
Very extremely put: there’s no such thing as a “<insert vendor> architect” How can you as a customer expect a holistic and agnostic view from someone who works for a company which goal is to sell products which answer the “what” question.
I visited the Juniper Self-Driving Network (snarky acronym BTW..) Summit yesterday in Eindhoven (The Netherlands). And it was one of those events that gave me a small glimmer of hope that there are luckily still some vendors around who are realistic about the actual adoption of automation and orchestration in the network. One speaker was clear, this process will take maybe 5 – 10 years to be fully adopted, but at the same time we can make small steps in the right direction towards a more programmable architecture. It was good to see the focus of this wasn’t to shove a “all-in-one, one-size-fits-all, plug-and-play” solution down ones throat. I know that Juniper isn’t the company to act that way and it that sense I was pleasantly surprised.
On the other hand the whole Self-Driving Network concept is still a bit vague to me. It seems (also based on their website and podcasts like this one and this one) that the whole SDN concept is a combination of several existing tools, methods and software thrown together with some machine learning in the mix. (RFC1925 rule 5 anyone?) It is promising, but we still have a long way to go in terms of standardization and processes (ITIL!) to reach that point. DevNetops is all nice, but at the end of the day changes are still cumbersome in most enterprises due to strict change control processes. At least, in my experience with infrastructure. If you fail, you fail hard and with a large blast-radius.. But I digress..
While preparing a presentation on SDN for my co-workers I am contemplating the current state of SDN in the market. The original premise of the presentations I did in the past is that SDN originated from a need to increase the agility of providing network services using a centralized model and utilizing a programmatic approach to the problem. Solutions like Cisco ACI and VMWare NSX are the prime solutions one comes to mind when talking about SDN, but when looking at the market right now, I see the following trends:
- Application modelling (one of the original premises of the Cisco ACI solution) is still a few (or many..)bridges too far for most enterprises. Most of them are still stuck with a network centric approach. Nevertheless beneficial as it increases control and speed of deployment, but it’s not using the full capabilities the product has to offer. I leave the modelling an IT landscape of over 1000 applications into security groups or EPG’s as an exercise to the reader. Every CISO wants microsegmentation, up until the point the cost become clear..
- Generic orchestration is still a big unknown. There are products out there, but it’s not clear if they are able to orchestrate a multi-vendor platform. This is something I’d like to dive into more.
- Adoption of public cloud seems to negate the need for on-site solutions. If the footprint of your local DC decreases, why invest in a complex SDN solution? Enter the whitebox. Cheap, simple and modulair. And with the adoption of AWS or Azure SDN “ships in the night” so to say. You already use it, but its abstracted away and somebody else’s problem.
My current client uses IBM mainframes running Z/OS and they run OSPF from their LPAR’s (LPAR’s are VM’s before VMWare made them hip and happening.. ) to the network. In order to get rid of some old infrastructure we want to have those LPAR’s talk OSPF to the Nexus 7710’s for redundancy.
The option to use dynamic routing over VPC is a feature with is available on the Nexus 7000 platform from version 7.2(0)D1(1) on F2E and F3 modules.
See this link for more info. There is a catch though: if you use specific M3 cards in the same chassis, you are forced to use version 8.1(1). See the matrix here for an overview. Even when you are using a combination of M3 and F3 cards you still need the latest (Early Deployment) release to make dynamic routing over VPC possible. Even if the actual vPC member links are connected to F3 cards. The fact that there are also M3 cards in the chassis makes this a neccesity.
Is this a problem? Not if you plan to go into production with a shiny new NX-OS codebase. Problem is that the recommended NX-OS release for the NX7710 is 6.2(16). Which doesn’t support M3 cards anyway. So going for 7.3(0)DX(1) is your only option. But this version is also an Early Deployment (ED) release.
Seems like your stuck between a rock and a hard place. We are testing version 7.3 right now and we don’t expect too much issues, but it is an ED version, so there is some associated risk. We might be using separate L3 links to connect the mainframe after all.
After reading this thread at Reddit I I thought about work/life balance and I want to share some of the lessons I learned during the years that helped me achieving some sort of healthy balance. And with the imminent birth of my third child being there for my wife and kids is all the more important.
First of all, I love what I do.. But at the same time I try to make sure the bad stuff which comes along with it is minimized to the max. That is one of the reasons I chose to work for a consultancy/contracting firm. I maximize the opportunities I have to work for a wide range of clients and minimize all the corporate BS that sometimes come with it.
Communication is key. Not only to your employer or client, but also to your wife, friends or family. I do engage in professional activities outside of normal working hours and sometimes this does take its toll on my private life. I try to check my schedule and that of my wife at the start of each week so we know if we have some special stuff going on. Sometimes I cancel after work activities as to be with my family.
If you think you need help, ask for it. I have struggled too long, wasted too many sleepless nights to try to solve stuff myself.. There are no stupid questions. No one is perfect. As an introvert it is sometimes hard to reach out, but I am getting better at it.
Choose or be chosen
This comes back to the first statement regarding passion. Passion also means focus. Saying “no” is also an answer. Especially when working for clients or freelance there seems to a tendency to say “yes” to everything as to not damage your own or your companies reputation. Well, if reputation is your problem then saying “yes”will definitely hurt it and get you into a world of pain.
I need exercise to keep me sane. I’m not one of those “I run to clear my mind” types. On the contrary, I think a lot when I’m jogging, but when I get home after a 10K run I somehow feel better and more positive.
This year’s annual Interop ITX conference was the second year I attended this event in Las Vegas. And while I am preparing a presentation for an upcoming debriefing to my colleagues I am trying to summarize the content and try to come to some sort of conclusion. What do I take back to my colleagues and clients? What are the relevant trends I see we need to take into account? Many thanks to the PacketPushers team for the two day Future of Networking summit. A lot of valuable insights were gained during these two days.
- Automation and programmability are becoming an important skillset for the networking engineer in the years to come. I am reluctant to say they are “essential”. It’s still too early how the market and products will evolve. Will everything really be abstracted behind a shiny intent or intuitive based GUI or are hardcore coding skills necessary to glue it all together? I think we still have a long way to go. Especially in Enterprise IT where networks are far from standardized. Let’s put it differently: If scripting skills are needed in Enterprise IT infrastructure to program anything, they will be used to script deployments to the public cloud. Where networking is abstracted away to the point it just works and your typical developer can’t be bothered.
- Closely related to automation and standardization are the actual standards. Not only standards like YANG or RESTCONF, but also standardization in design and of interfaces.
- SDN is becoming a race between an programmable underlay (like Cisco ACI) or overlay (like VMWare NSX). And apart from the fact the choice between the two is never definitive or a winner takes all situation as it very much depends on your own IT infrastructure, I do think that in the end the underlay becomes less relevant (hence the advent of white box switches becoming cheaper). In the future one will have a simple programmable underlay (but with a simple design programmed) and a complex overlay. Just as the cloudscale companies are presumably doing it now. I think it will take a few lifecycles (of three to five years) for enterprise IT to reach this level. But then again, in enterprise IT a lot of factors come into play which are mostly non-technical. I will create a blog post “Control of your network in an outsourced environment” somewhere in the near future around this subject.
- SD-WAN is interesting and can solve a lot of headaches large hub-spoke networks introduce with the networking community. Although cost is far less a driver in Western Europe and Holland specifically, ease of management and application awareness is an interesting factor. Currently, I don’t know of any large scale deployments here in Holland. Correct me if I’m wrong in the comments.
- Network security. Short story: Firewalls are useless 😉 Long story: Firewalls are somewhat useful, but in many scenarios the risk you want to mitigate does not involve a firewall as we know it. Protection from lateral attacks are becoming more and more important and so micro-segmentation and host based solutions are becoming increasingly important. But how do you manage this in a scalable way. RFC1925 rule 6 can rear its ugly head.
Odds and ends
- Cloud; interesting to hear some reallife use cases. Different drivers to move to cloud and it’s not always cost to start with (although companies might move back due to rising cost, but that’s another discussion). Interesting to hear that moving to public cloud to really leverage the innovative capabilities is a main driver. At the same time this is the reason why shadow IT and public cloud are so intertwined sometimes.
- Orchestration of it all.. This is for me still uncharted territory. I have looked into Cisco’s Cloudcenter (used to be Cliqr) and that certainly has some potential. I see also ServiceNow as an interesting product used and off course Openstack’s Heat. But as said, I am too far removed from this specific subject to know the dirty little details. Definitely something to know more about!
Interop ITX itself is positioned as a vendor independent conference. And although the sponsors (VMWare among others) are far from independent, they were able to attract a wide variety of speakers. In that lies an important value. But if I have to believe my Twitterfeed and compare the Cisco Live US stream with that of Interop I wonder if it is able to live up to the vendor conferences. I don’t think they have to have that goal, but getting behind the curve can create a negative spiral in less attendees, which means a smaller event and maybe less speakers. Let’s hope it doesn’t go that way. We need vendor independence, it is the raison-de-etre of the company I work for and I think my customers need this objective view to make the right business and IT decisions.