Every once in awhile someone reaches out to me wondering if the older HP Provision switch they have is OF capable or should they just through it in the garbage.
One of the easiest way to decide on blog post is “If you’ve been asked the same question more than three times…”.
EDIT: These switches can all run OpenFlow1.3. Table sizes vary per model. Check the release notes and product documentation for specifics around what of the optional OF1.3 spec is covered. (hint: None of these switches support MPLS )
Stackable Swiches
HP 3500yl
HP 6600
HP 2920
HP 3800
Chassis Switches
HP 5400zl
HP 8200zl
Getting OpenFlow Code
So pretty much all of these switches have the HP warranty, which means you should be able to get code for all of them from the HP support website. Easiest way is to go to http://www.hp.com/networking/support and should be good to go. It may be that all of these switches are covered under the warranty, but I didn’t verify, so I’ll leave that you to. 🙂
There’s definitely a hierarchy to the world of network engineers and sometimes it looks a little like the following
As a former Voice Engineer, I’ve definitely been the victim of this good natured jockeying for positioning. As a former voice engineer, I have to admit that I’ve even participated in the ribbing of my former voice peers. Being a voice engineer is kinda like being the Rodney Dangerfield of the networking world. ( You know the tag line )
I’ve even been told on more than one occasion that my CCIE “doesn’t count” because I did Voice. I’ve always taken it as the joke it is. I’ve got digits just like everyone else who’s ever passed a lab. But some people out there might not have the same thick skin I’ve developed over the years. ( Thick skin is something else Voice Engineers get. I think it’s all the exposure to end-users ).
For the record, I have the upmost respect for voice engineers. It is one of the toughest gigs in networking. You have to have skills in so many areas, not to mention the constant human interaction that comes with the job. And we all know that not every network engineer handles constant human interaction well.
I spent some great twitter conversations reminiscing about the past and I realized that it just might be that voice engineers might just be the most well positioned to really make things happen in the new world. I think if we look at any past experience, there are skills which are transferable if you just look at them in the right way.
There’s a lot of network engineers of all stripes and colours out there who are busy asking themselves the questions “ How do I make myself relevant in the new SDN world?”. I think the first part of answering this question is to identify which of your current skills are transferable. Once you’ve got that figured out, you identify what’s missing and then hit the books.
So here’s the list of why I think Voice engineers will have a great shot of making themselves quickly indispensable in the new world order.
Why Voice Engineer will rule the world
Experience with Controller-Based Networking
When explaining the concept of controller based networking, people always jump to the obvious analogy of wireless controllers with FIT APs. But it occurred to me last night that a potentially better example is the voice PBX. Especially in a world where VMWare’s NSX is quickly becoming part of the conversation, the parallels become even stronger. Voice is the original overlay.
Voice has it’s own addressing scheme (E.164) independent of the underlay infrastructure. There’s a centralized controller ( Callmanager ) who has completely knowledge of the state of every endpoint ( phone ) in the network. As voice engineers, we’re so used to looking at symptoms of a problem with no direct linkages between the overlay and the underlay other than our knowledge. I believe this experience is going to come in very handy for those of us who chose to make the jump.
System-Level Thinking
Voice Engineers think in terms of the entire PBX as a system. There’s something just different about the approach of voice engineers as opposed to traditional R&S engineers. R&S guys have a great ability to focus in on the individual device they are working on. The are so used to living in a distributed state system that they can comfortably skip into the shoes of any device on the network and quickly analyze that particular devices perspective. As a voice engineer, having the ability to see things from the perspective of one particular voice gateway and analyze dial-patters is important, but been able to understand the entire system is what makes us fundamentally different.
Operating System Skills
I have no idea how this happens. But I’ve actually seen REALLY good network guys who actually struggled to statically define an IP address on a Windows box. As a network management advocate now, I’ve seen the feet that a GUI can place in the eyes of a packet head one to many times to dismiss how valuable all the exposure to operating systems was. As a voice engineer, I had to work with Windows NT4 ( Callmanager 2.4 ), Windows 2000 ( Callmanager 3+), Linux ( Callmanager 5+), VXWORKS (3Com NBX), Linux ( 3Com VCX), not to mention all the client machines that I had to install the original Cisco Softphone ( oh! the pain!) the IP Communicator, or any of the other soft phone clients that have come along the ways.
I’m comfortable on OS’s. And when I’m asked to install the HP VAN SDN on Ubuntu, or want to play with the OpenDayLight or NOX or Floodlight or any other controller out there right now. I’m not intimidated in the least. I wouldn’t call myself a Linux expert, but I’ll jump right in and figure it out.
Programming skills
The CCIE Voice is one of the only ( THE only?) Lab which has ever forced candidates to do java programming. For those of you who’ve never done it, ACD programming in an IPCC environment is based on java beans. Digit translations are based on RegEx. And trouble shooting complex number translations through an entire dial patter with AAR turned on will force you into a boolean mindset whether you actually understand that term or not.
People Skills
Voice Engineers have to interact with people. A lot. In fact we probably have to interact with people more than any other sub-genre in the networking profession. We have to learn various IT dialects to communicate with the legacy voice people. The hard-core network people. The “real” programmers who are going to do the complex ACD scripts for us. Not to mention the actual end-users who are experiencing difficulties with one-way audio or making a fax go through. ( Yes – People still use fax machines ).
Strong communications skills and the ability to quickly shift vocabulary to effectively communicate between the different stockholders in an SDN environment is going to probably be one of the most important skills as the silos start to break down.
Strong Networking Skills
As much as people like to make fun of voice engineers, most of them have an unbelievable level of foundational networking. They may not be the strongest in BGP or MPLS, but in my experience they understand the basics of networking at a level that most of the other sub-genre’s don’t get to. You don’t ever want to get into an argument about QoS with a voice engineer. We understand spanning-tree like nobodies business. In fact, because of the complete lack of tolerance of RTP for any packet loss or delay, we have had to become really, really good at performance tuning the network to ensure that every packet arrives in order in less than 150ms ( G.114 standard people!).
Wrapping it up
To be honest, I believe every network person who wants to is going to make it into the new world. I think that we spend so much time talking about whether or not that SDN is going to force people to become programers that we haven’t spent enough identifying what skills we already have that are going to serve us in the new world.
Do you believe that one of the other network sub-professions above are better equipped to move into the SDN world? I challenge you to write the blog and make a better case.
I was at an internal event this week where we were going over some of the amazing things that HP is working on, some which will come to market soon, and some which may never make it out of the labs.
To answer the obvious question: No, I’m not going to talk about that.
But during one of the sessions, an interesting conversation took place which I wanted to put some additional thoughts down on paper, or e-paper as it were.
As is the case so much in the industry right now, the conversation came down to a discussion around this question
What is SDN?
The speakers statement, which I’ll look at below, was that programatic NMS is NOT SDN. Now he is a very smart guy and I do have to say that his presentation was very good, but I had to object to that particular point. I’m still not sure if I’m right or wrong, but I think it’s worth at least examining the point.
So first I’ll refer to Martin Casado’s slideshare presentation which you should check out as I’m going to take parts of it out of it’s context in an attempt to make my point. ( As they say, when you take the text out of the context, all you’re left with is a con ).
For those of you who didn’t check it out, the presentation focuses on the idea that the true benefit of SDN is the power of abstractions. The idea that abstractions allow for much greater flexibility and evolution because you don’t have to worry about the fundamental underlying complexity.
Imagine if all the software in the world had to be written in assembler. I’ll wait while your body works out the sudden urge to scream and jump out a window.
So one of the fundamental tenants of SDN is that
Abstractions are the way forward.
I agree with this 100%. Abstractions take away the underlying complexity and allows us to concentrate on the task at hand.
So the slideshare preso above deals primarily with the idea of control plane abstraction in the sense that OpenFlow’s purpose is to allow for instructions sets abstractions to be sent to OpenFlow enabled switches which will allow them to bypass all the current control plane complexities that we all know and love in the current network paradigm.
I’m 100% in agreement with that.
But what is of particular interest to me is the idea of management plane abstractions. Now for those who don’t know already, I’m an HPN Solutions Architect and an avid evangelist of HPN’s NMS platform, HP IMC. ( Full Disclosure ). So I will be attempting to make this argument in context of what IMC is providing now and where I see it going.
DISCLOSURE: I AM NOT PLM AND I AM NOT REPRESENTING HP IN ANY CAPACITY, OFFICIAL OR OTHERWISE, THIS IS STRICTLY THE THOUGHTS BOUNCING AROUND IN MY HEAD ).
If one of the core ideas behind SDN is the idea that abstractions NEED to be created in the networking world to allow us to evolve past the current “protocol-per-problem” paradigm that we are all living in,
It seems to me that allowing management plane abstractions should also have value and should qualify as a type of software defined networking.
I fully admit that this will not be as revolutionary as the idea of a complete control-plane abstraction like what OpenFlow is promising in the next 2-10 years. ( I’m not holding my breath ). But I do strongly believe that there is some pretty amazing benefits that can be gained today IF the management abstractions are in place.
As well, I also believe that this could easily be the current missing-link that will allow us to bridge the gap between where we are and where we want to be.
Example
So let’s look at the following simple example so I can try and make my case.
Imagine, if you will, you are running a dual-vendor strategy. I know you all are, Gartner said it’s a good thing, right? But now you have discovered that MOST of the current networking hardware manufacturers are offering NMS platforms that limited to managing their own devices.
So let’s imagine that you are running Cisco and HP equipment in your network and you want to deploy a new VLAN across your data centre.
Assuming that your NMS’s are single-vendor NMSs ( like Cisco Prime LMS ). You’re stuck You MIGHT be able to login in to your Cisco Prime LMS interface and deploy VLANs, or you might be able to rely on VTP or GVRP/MVRP to take care of this for you.
Now if you were using HP IMC, we have already abstracted the management layer to allow you to just say ” DEPLOY VLAN 15″ and the programatic NMS actually takes care of the rest.
Check out this video for a demo.
So how does this work?
ABSTRACTIONS
Let’s take the a step further and look at this in the context of SDN. Imagine the following scenario if you will.
A user plugs in to the switch. What happens
1) The dot1x supplicant kicks in and says ” Hey NAC ( sorry BYOD ) server; Is this guy allowed?”
2) RADIUS server says ” Yup, but he’s a sales user, so he needs to go in VLAN 15
So far, this is pretty standard, right? RADIUS server responds back with the tunnel-group attribute or some other proprietary VSA and the switch puts the user in the right VLAN, right?
Wrong.
The NAC software has no knowledge of whether or not that particular VLAN is actually present on switch where the user is plugged in.
So imagine if there was a programatic interface, like the eAPI in HP’s IMC that would allow the conversation to go like this.
1) User plugs in to a switch, dot1X process takes place, switch contacts NAC software through RADIUS protocol and the RADIUS server says ” This user should be in VLAN 15 “
2) The NAC software checks with the NMS to see whether or not the VLAN which we are trying to deploy is actually present on the switch in question.
3) The Programatic NMS would then check the VLAN database to see if that specific VLAN is present on the switch in question. In this case, the the NMS will respond with a no.
4) So now the NAC program knows that the user authentication is going to fail because the underlying infrastructure does not have the necessary services in place ( the VLAN ) to be able to complete the transaction, so it then asks the programatic NMS to deploy the VLAN in question to that switch.
5) The programatic NMS would then connect to the switch, and add the VLAN. The NMS would check the bridge MIB, or whatever other MIB might be present to verify that the transaction was completed successfully.
6) After some arbitrary time value, the NAC program would then ask the NMS if the VLAN is present on the switch.
7) The NMS would then respond with a resounding ” Yes! It’s there!”
8) The NAC program would then complete the RADIUS request, place the user in the right VLAN and everything is great, right?
The best part of this, no human intervention, the program is able to request a service from the network, the network is able to respond that it’s not present and reconfigure itself to meet the needs of the application.
So where’s the abstractions?
Look at the flow above. The NAC program asked ” Is this VLAN present” it didn’t say “When I run the command show VTP Database, after you parse through it, is VLAN 15 present?” which of course would not work on a juniper or hp switch.
The NAC program uses the self-describing RESTful API calls like
note: I don’t have the eAPI SDK in front of me, so I’m making up those calls, I’ll try and fix them later with the real syntax when I have a chance.
And then the really cool part happens.
If it’s a Cisco IOS based Switch, it uses the Cisco IOS switch device adapters which define the specific commands or SNMP OIDS to set the VLAN on that particular platform.
If it’s an HP Comware switch, it uses the HP Comware switch device adapters which define the specific commands or SNMP OIDS to set the VLAN on that particular platform.
If it’s an HP Procurve switch, it uses the HP Procurve switch device adapters which define the specific commands or SNMP OIDS to set the VLAN on that particular platform.
ABSTRACTIONS
No matter what kind of switch that user is connected to, HP’s Intelligent Management Center will hide all of the underlying complexity from the NAC program and respond to the same specific RESTFull API call.
So instead of all the device specific syntax, it’s almost like a simple conversation.
NAC Program to HP IMC ” Is VLAN 15 present? “
HP IMC to NAC Program ” Nope”
NAC Program to IMC ” Can you please add it for me?”
HP IMC to switch ” Add VLAN 15 to your configuration “
HP IMC to switch ” You done yet? “
NAC Program to HP IMC ” You done yet? “
HP IMC to NAC Program ” I’m done”
Now are their other failure modes which should probably be checked? Absolutely, off the top of my head, you would also have to check the dot1q trunks between the device and the L3 interface for that particular VLAN to ensure that you have end2end L2 connectivity and you’re not going to create an isolated orphan VLAN which dumps you user into no connectivity, but that’s just adding more logic to the program.
So back to the original question: Does a programatic NMS qualify as SDN or not?
Let me through out the following description.
A paradigm where a application can request a specific service from the network and the network is able to dynamically reconfigure itself to respond to the applications specific requirements.
That kinds sound like software defined networking to me.
What do you think? Is it the law-of-physic changing paradigm that much of the media would have you believe is coming? Nope. But does it have value? I’ll let you decide.
Recently I’ve seen HP taking some flack around it’s Openflow announcements. The criticisms basicaly smack of accusing HP of jumping on the Openflow bandwagon and this bugs me because HP was out in front of this on the hardware side for quite sometime, not to mention working with Stanford directly on the actual protocol implementation. Again, there are a lot of criticisms that could be argued against any company, but sometimes we just have to look at the record to get to the truth.
The Perception:
I’d like to point out a couple of recent quotes on HP’s Openflow strategy from some VERY smart people that I have a lot of respect for:
“”HP *has* an OpenFlow story. Honestly, hadn’t caught that before – but to hear them tell it they have been working with OpenFlow founders since it started as a science experiment in someone’s basement (no, not really a basement- well, maybe a basement). “
“Why does this matter? Um, because in my opinion, if these guys are doing it, the reality is OpenFlow is here and looking for a place to settle in.”
“They claim they’ve been working on OpenFlow technology for years, but when they talk about it, they use baseline open-source controllers to demonstrate the supposed benefits of OpenFlow “
Again, my point here is people seem to be thinking that HP is jumping on the Openflow bandwagon.
Now we all know that @etherealmind is ahead of the curve. I believe the packetpushers show has done more for getting great information out to the networking profession than probably any single podcast or blog *ever*. Greg, Ethan, Ivan, Matt, Tom, Amy, Mrs. Y are all personalities which we all feel like we kinda know now.
So when Lin Neese from HP is explaining openflow at the time and Greg is saying
” I’m looking at a webpage here. I’ve been furiously searching here while I’m talking to you. So Openflow is not Netflow or sFlow? it’s something completely different?”
” This is all new to me. I’ve sort of seen this talked about a lot, but I haven’t managed to drill into this in any level of detail to comprehend how it works in detail, so I’m sort of.. .my mind is spinning over this trying to come up with it…” ( laughs) ” take a break. “
Considering all that the packetpushers have done to educate the world on SDN and Openflow in particular ( check out @cloudtoad blogs!!!) It’s telling that a guy from HP Networking was the guy who first brought this to the Packetpushers audience.
I’m going to let the marketing department get into defending strategy and announcements and everything else, all I”m really concerned with is the idea that HPs just jumping on the bandwagon.
Now let me make myself 100% clear, this is not a criticism of any of the people who are mentioned in this blog. They are all incredibly smart people who are lending their experience to all of us on a daily basis. But they just seemed to have missed this one…
I’m pretty sure I’m going to take some flack over this piece, so let me start by saying that I’m not going to respond to any comments at all on anything other than the topic at hand. 🙂 As I said, I’ll let the marketing machine take on HPs official position. This blog is my personal blog, and I’ll let the company defends it’s own stance.
He makes some very interesting comments and observations, none of which I can actually disagree with.
SDN is a business dream; Where they can buy commodity hardware, do away with high priced router-jockeys, stop paying a premium for mid-range value products, and just focus on whatever their core business actually is.
Unfortunately, I think there’s a lot more to this discussion that I haven’t seen a lot of people address yet. I’m not saying I have any answers here, but I do have a few questions. Hopefully, some of you will post in the comments as to how you see this playing out, because my crystal ball is getting pretty foggy these days. 🙂
1) Skills Gap: It’s been 20 +/- years since the fallacies of distributed computing were laid out. And yet, we’re seeing the past repeat itself again and again. I was asking about the DevOps trend with a customer a few weeks ago and he laughed at the question. They had already tried it he said.
And it failed miserably.
These guys are a startup doing some pretty impressive stuff with BigData ( Hadoop ) and they have a lot of talented coders on staff. This really got me curious. So I asked him “Why?”
His response, which I think applies equally to SDN as it does to DevOps, was the following
” It took you 10-15 years to become a really good network guy. It took them” pointing over shoulder
” 10-15 years to become really good programmers.”
” I’ll guess you aren’t a good coder, but I can TELL you that they aren’t good network people.”
This has been racing around in my brain for weeks now. Other than the odd exception like @lynxbat
I think it’s safe to say that 99% of the network engineers I know are capable of nothing more than rudimentary scripting, and most of that is regurgitated code from examples downloaded off the Internet.
I have a hard time calling someone who downloads a perl script and hacks in a couple of locally significant values a programmer, And yet this is very much the world we are all talking about moving to.
So where are these new breed of GUI-jockeys going to come from? With the hybrid of both coder and network knowledge that they will deliver us from our current state of one-protocol-per-problem. Because sadly, I see a shortage of good network folk in general, let alone good network folk with coding skills.
We’ve been slowly automating out all the jobs that green networks kids used to cut their teeth on. So where are these new wizards of SDN going to get their network experience to learn the valuable “just because you can…” lessons that all of us have over the years?
More than likely, they are going to make some snide comment, as the young are prone to do, on how our ipv4 knowledge, just doesn’t apply here anymore. Offer us a piece of tin can with a string, and offer to write us a new protocol.
all I can tell you for sure?
“Not on my network.” : )
Is it just me? does anyone else see this as a problem? And if so, what are you doing to prepare yourself for the coming divide?
