Network Developer: A network engineers Journey into Python

Like most other people in the networking industry, I’ve been struggling with answering the question as to whether or not Network Engineers need to become programmers. It’s not an easy question to answer and after a few years down this SDN journey, I’m still no closer to figuring out whether or not network engineers need to fall into one of the following categories

Become Full-Time Software Developers

DaveTucker

For those of you who don’t know @dave_tucker, he was a talented networking engineer who choose to make the jump to becoming a full time programmer. Working on creating consumption libraries using python for the HP VAN SDN Controller, contributing to the OpenDayLight controller, and now joined up with @networkstatic, another great example. and @MadhuVenugopal   to form SocketPlane focused on the networking stack in Docker. 

Gain some level of proficiency in a modern programming language

One of the people that i think has started to lead in this category is @jedelman8. Jason is a CCIE who glimpsed what the future may hold for some in our profession and has done a great job sharing what he’s been learning on his journey on his blog at http://www.jedelman.com/.  Definitely check it out if you haven’t already. 

This is also where I’ve chosen to be for now. The more I code, I think it’s possible that I could go full programmer, but I also love networking too much. I guess the future will tell with that one. 

For this category, this will mean putting in extra time on nights and weekends to focus on learning the craft.  As someone once told me, it takes about 10 years to become a really good network engineer, no one can be expected to become a good programmer in a year, especially not with a full time day-job. 

On the bright side there are a lot of resources out there like

Coursera.org – Just search for the keyword “python” and there are several good courses that can help you gain the basics of this language.

CodeAcademy.com – CodeAcademy has a focused python track that will allow you to get some guided hands on labs as long as you have an internet connection.

 pynet.twb-tech.com – @kirkbyers has put together an email led python course specifically for network engineers over at   He’s also got some great blogs  that discuss how to use python for different functions that are specifically related to network engineers day-to-day jobs. Having something relevant always helps to make you’re live easier. 

Gain the ability to think programmatically and articulate this in terms software developers understand

I don’t have any really good examples of this particular category.  For some reason, that has so far eluded me, there just isn’t many network engineers in this category. If you know of any great examples, please comment below and I’ll be happy to update the post!

This is where I was a coupe of years ago. I knew logic. I could follow simplistic code if it was already written, and I could do a good enough job communicating to my programming friends enough to ensure that the bottle of tequila I was bribing them with would most likely result in something like what I had in my head. 

 

Stay right where they are today. 

The star fish is one of the few creatures in the history of evolution that went “ Hmmm. I think I’m good! “   This isn’t a judgement, but you need to decide where you want to be and if Star Fish is it… you might find your future career prospects limited. 

starfish

 

 

Journey Ahead

 

As I get back into actually posting, I’m planning on sharing some of the simplistic code that I’ve been able to cobble together. I make no claims as to how good this code is, but I hope that it will inspire some one else reading this to take some classes, find a project, and then write and share some small script or program that makes their life just a little bit easier. Guys like Jason have done this for me. I recently hit a place where I finally have enough skills to be able to accomplish some of the the goals I had in mind. My code is crap, but it’s so simplistic that it’s easy to understand exactly what I’m doing.  And that’s where I think the value comes from sharing right now.

 

Comments or thoughts? Please feel free to comment below!

 

 

Advertisements

Rethinking Change Control in a SDN world

I had the opportunity to attend the Open Networking User Group event (ONUG) in New York recently and had a chance to talk through some of my musings around change management in an SDN world with some very smart, knowledgable people from a range of different backgrounds.

Let’s talk a little about change control

In a nutshell, people screw things up when left to their own devices. Individuals will inevitably type a wrong command, misplace a decimal point, not have sufficient information, or just plain not-think-something-through.

People are frail, fragile and error prone. But when people come together in groups, share information, share experience, and double check each other’s work, then the error-rate per change tends to drop significantly and changes start to be implemented in a much higher quality fashion.

Change Policy in Modern Organizations

Most modern organizations have some change management process in place. Whether they have succumbed to a full ITIL based process, gone the DevOps route of continual integration, or fall somewhere in between, people have generally figured out that change management is a good thing.

I’ve seen good change management that promotes healthy growth, and I’ve seen bad change managements that restricts the business into stagnation because nothing is ever allowed to change in the organization. ( There’s another word for something that never changes – dead. 🙂

Change Control in a SDN environment

One of the major issues I see in SDN environments is that many of the changes that we are not only capable, but advocating, are currently heavily restricted through the existing organizations change policies.

To make this example more concrete, let’s talk about an app from Guardicore that uses SDN to detect potential advanced persistent threat attacks in the data center and then uses OpenFlow and the HP VAN SDN Controller to dynamically keep the session alive and re-route ( re-bridge?) the flow directly to a Honeypot which is capable of performing further analysis on that particular session to see if that particular flow is trying to do anything more interesting like trying to execute shell code or some other dubious shenanigans.

Now imagine how the Change Advisory Board is going to react to this request. I imagine it could go something like this.

” What? You want to reconfigure the edge, distribution and core of my data center based on an unknown event at an unknown time because something may or may not be going on?”

How do you think that’s going to go?

ITSM Pre-Approved Changes

There is a concept in ITSM frameworks like ITIL and MOF that allow for a common change to be pre-approved. The change request still has to be fed into the system, but the approvals are automatic and no one has to actively log into a system and click the ” I Approve “

One of the approaches I’ve been advocating is the possibility of repurposing the pre-approved change to allow for dynamic flow modification based on known conditions. This seems to be the simplest way for us to allow the ITSM structures in well-run IT organizations to continue to work without having to scrape the whole change approval process.

This is new ground and I think that this topic requires a lot more discussion that we are currently giving it.

What do you think? Is pre-approved change the way to go? Is there another better way? Is your organization currently using SDN and found a way to rationalize this to the Change Advisory Board?

Please blog it up or post in the comments below.

Voice Engineers Will Rule the SDN World

Voice Engineers take a lot of crap.

 

There’s definitely a hierarchy to the world of network engineers and sometimes it looks a little like the following

 

NewImage

 

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. 

 

Comments, as always, encouraged and welcome!

 

@netmanchris

A different kind of SDN? Programatic NMS with Management Layer Abstractions

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.

Screen Shot 2012 08 23 at 3 08 07 PM

 

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

http://127.0.0.1:8080/GetVLAN device id15

And the NMS responds with an XML output which does not contain that VLAN ID.

Then the NAC program sends an HTTP post to the NMS and says 

http://127.0.0.1:8080/addVLAN:15?devID15

 

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. 

Another eAPI post – What can you do with a QR tag?

So we’ve had some ambitious little engineers with too much caffeine and some new toys to play with.

For those of you who are interested, I’m going to post the source over to

which is the new IMC forum site that @neelixx setup. This code was not created by a professional code, but at least it’s a proof of concept of what you can do with a little bit of time and some knowledge.

P.S.  If you don’t have a QR code reader on your phone yet, and you didn’t just click on the image…. that’s   www.netopscommunity.net

@netmanchris

A Network Services Platform

So things are starting to get interesting with the HP IMC eAPI that was recently released. It’s really amazing to see the types of creative projects when technical people are presented with new toys. 🙂

So for those of you who didn’t read my last eAPI blog post, let me catch you up. The eAPI is a RESTFul inteface that allows programmers, or scripters to leverage the various network services that HP IMC presents.

Thanks@ioshintsfor a quick look at SNMP vs. RESTfull interface

Basically it looks a little like this.

note: This is not a full list of the IMC modules or services. Check out the HP website for a complete list.

The RESTfull inteface presents the services in a XML format which is consumable to any programming language that can parse XML. ( I’m not a programmer, but that’s pretty much all of the current ones from what I understand ).

Those services are then applied to specific devices. But what’s COOL about this, is the following.

Say you want to change a VLAN on a bunch of ports. Some of those happen to be HP Comware switches, some of them happen to be HP Procurve Switches, and some of them happen to be Cisco switches. The IMC device adapters at the bottom do all the work for you, providing a device abstraction layer so that you can just say ” add VLAN” rather than having to worry about the syntax of all the individual devices.

So what’s actually available in the HP IMC eAPI? Well you can checkout @neelixx’s blog for the documentation. This is the first release, but I’m told that the eAPI will continue to grow with each future release of the platform AND the modules.

But I think what’s a LOT more interesting is some of the projects that have started to creep up.

For example

1) Wouldn’t it be cool if when you sent someone an outlook invite for a meeting in your office that your network access control system would automatically create guest accounts for the day of the meeting and send them to your guests?

2) Wouldn’t it be cool if when your support desk could simply click on a user in Microsoft Lync and automatically see where they have been logged in the network? Check out what access service is assigned to them. Maybe they are having trouble accessing some resources and you want to make sure they are in the right VLAN.

I’ve also started to see other apps pop up such as an application that searches the entire network for the mac addresses of lost laptops and locates the interface they are plugged into. Pretty handy for a hospital where a lost laptop with patient data is a nightmare. Or something as simple as an app for a a College which allows the teacher to shut down all the interfaces for the switches which are in their classroom, and then to turn them all back on with a click of the button.

No login to the NMS.

No call to the help desk.

Just shutting down the ports when the students aren’t listening, and turning them back on when it’s time to work.

What about you guys? HP has given you some color. What are YOU going to paint?

HP IMC’s New eAPI

Now that I got rum-pooh out of my system…  on to a slightly more technical post.

Not sure if anyone of you caught the recent announcements about the new eAPI from HP’s Intelligent Management center.  In a nutshell, this is a RESTful API which allows programatic access to almost all ( maybe all?) of the IMC functions through an HTTP(s) interface.

Now I’m not a programer at all, but I like to think I have a working knowledge of programing logic. At least enough to give a half-decent programmer enough information to get the job done.

So when I had a co-worker present me with a problem earlier this week, I thought “Hey, I wonder what this new eAPI can really do?”.  I did mention I’m not a programer right?  After this little exercise, I’m thinking I might just have to pick up some scripting skills this year. 🙂

So what’s the value of the eAPI? It functionally allows IMC to act as the progamatic upper layer APIs and abstracts the actual management task from the underlying hardware devices.

In less complicated terms; it means that a program can say  “Hey, IMC change the VLAN on this port” and IMC, assuming IMC actually supports that particular device, it will change the VLAN on that port.

INDEPENDANT OF THE ACTUAL VENDOR

Yup. That’s right.  IMC doesn’t care if that device is a HP 5500EI ( comware ), a HP 3800 ( procurve), or even a Cisco Catalyst 3560.  From the perspective of the developer on the other side. It’s as simple as “Hey, IMC change the VLAN on this port”.

So the actual challenge I was given was the following.

” A customer wants to take a bar-code reader, scan in the MAC address of a device, plug it into the network, push a button and then have IMC automatically put it in the right VLAN”.

Now first I had to break that down into the various components.

1) Bar-code reader scans the MAC address

2) Program has to capture the MAC address for use in the %mac-address% variable in the script.

3) Find the device in the network

Hmmm… this could be more difficult than I thought.

So, I need to mock this up, so I break out to a windows CMD prompt.

Ping a known address ( my Synology NAS — LOVE THIS PRODUCT ).  And then put do a arp -a  to get the following output

10.101.0.51           00-11-32-10-03-8b

Now if I was using the IMC web-interface, I would just use the   Resource-Terminal Access-Real-Time Location feature which will, you guessed it, locate a host in real-time using the mac-address or the IP address.

Hmmm… that kinda sucks for output for the script to leverage.  So I went and looked at the eAPI documentation and came out with this little baby

The eAPI call is the following  ( if you wanted to search for an IP address you would use type=2 instead of 1 )

( Don’t click this, it won’t take you anywhere)

http://10.101.0.201:8080/imcrs/res/access/realtimeLocate?type=1&value=00-11-32-10-03-8b

The return is the following

<?xml version=”1.0″ encoding=”UTF-8″ standalone=”yes” ?>

<list>

<realtimeLocation>

<locateIp>00:11:32:10:03:8b</locateIp>

<deviceIp>10.101.0.221</deviceIp>

<ifDesc>GigabitEthernet1/0/21</ifDesc>

</realtimeLocation>

</list>

Yup. Good old XML. Easy to apply transforms or grab variables.  Programmers love this stuff.

4) So now I have the device IP (switch) that this is plugged into, and the ifDesc which is the actual interface it’s located on. So now I have to figure out how to apply the VLAN to this interface. So I break out the trusty eAPI documentation and start looking for the VLAN section.

Hmmm… I have the devIP and the ifDesc.. not the devID and the ifIndex

note to self: Feedback to the developers to have the first command return the devID and the ifIndex variables

So now I have to find the devID and the ifIndex for that devIP and intDesc

5a) Now if I was on the trusty IMC web interface, I would go to the device resource page… hmmm… that doesn’t appear to be there. I guess instead, let’s go to the eAPI documentation and look for something that looks like a dev query.

Yup. It’s actually called devquery. And it looks like I can filter based on the device IP.

Cool. So now I can search for the specific device IP and hope we get the devID variable back that we need for the VLAN call.

http://10.101.0.201:8080/imcrs/plat/res/device?ip=10.101.0.221

The return is the following

  <?xml version=”1.0″ encoding=”UTF-8″ standalone=”yes” ?>

<list>

<device>

<id>15</id>     ———————————————- This is the device ID that we need to reference later

<label>HP_5500EI</label>

<ip>10.101.0.221</ip>

<mask>255.255.255.0</mask>

<status>1</status>

<statusDesc>Normal</statusDesc>

<sysName>HP_E5500EI</sysName>

<contact>HP Montreal</contact>

<location>Marlborough, MA 01752 USA</location>

<sysOid>1.3.6.1.4.1.43.1.16.4.3.36</sysOid>

<sysDescription>HP_5500EI</sysDescription>

<devCategoryImgSrc>Switch</devCategoryImgSrc>

<topoIconName>stack</topoIconName>

<categoryId>1</categoryId>

<symbolId>1022</symbolId>

<symbolName>HP_5500EI</symbolName>

<symbolType>3</symbolType>

<symbolDesc>HP_5500EI</symbolDesc>

<symbolLevel>3</symbolLevel>

<parentId>1003</parentId>

<typeName>3Com S4800G PWR 24-Port</typeName>

<mac>00:1e:c1:dc:fc:01</mac>

<link op=”GET” rel=”self” href=”http://10.101.0.201:8080/imcrs/plat/res/device/15” />

</device>

</list>

There it is.  DevID is  “15”.

5b) So now we need to figure out that ifIndex value associated with <ifDesc>GigabitEthernet1/0/21</ifDesc> that we pulled above.

If I was in the webinterface, I would simply go to the device ( 10.101.0.221 ), click on the interface list, click on interface Gig 1/0/21 and I would pull out the ifIndex from the interface…

But again, those programmers don’t want HTML, they want an easy XML output that they can play with. So let’s find that…

http://10.101.0.201:8080/imcrs/plat/res/device/15/interface?start=1&size=100

This returns a whole bunch of data for all the interfaces on the switch, but I’m sure that any decent programmer can write a regex expression to only return the one who’s ifDesc value is for Gig 1/0/21, right?

<interface>

<ifIndex>21</ifIndex>      ——————————————–In this case, the ifindex value is the same as the port number. That’s not always going to be true. This is the other variable for the set VLAN

<ifType>6</ifType>

<ifTypeDesc>ETHERNETCSMACD</ifTypeDesc>

<ifDescription>GigabitEthernet1/0/21</ifDescription>

<adminStatus>1</adminStatus>

<adminStatusDesc>Up</adminStatusDesc>

<showStatus>2</showStatus>

<statusDesc>Down</statusDesc>

<operationStatus>2</operationStatus>

<operationStatusDesc>Down</operationStatusDesc>

<ifspeed>10000000</ifspeed>

<appointedSpeed>-1</appointedSpeed>

<ifAlias>GigabitEthernet1/0/15 Interface</ifAlias>

<phyAddress>00:1e:c1:dc:fc:4f</phyAddress>

<mtu>1522</mtu>

<lastChange>4 day(s) 21 hour(s) 39 minute(s) 50 second(s) 990 millisecond(s)</lastChange>

<lastChangeTime>42359099</lastChangeTime>

<filterTrapStatus>0</filterTrapStatus>

</interface>

So now we have the DevID     15     and the ifIndex    for the actual interface where that MAC-address is located.

So let’s go back to the set that VLAN

Let’s assume that you wanted to put the device in VLAN 20,   you would run the following

http://10.101.0.201:8080/imcrs/vlan/20?devId=15&ifIndex21

That’s about it for the task. Now any decent programmer is going to have to put in some checking and error handling, for instance, you might want to check whether or not that VLAN actually EXISTS on the switch. ( Can’t put a VLAN on a port if the VLAN doesn’t exist on the switch, right? ) or maybe return an error if the MAC-address is actually seen on two interfaces, but in a nutshell that’s it.

note: I would also suggest that the dev actually bounce the port to make sure that the device hasnt’ gotten locked in with a DHCP address on the wrong subnet.

/plat/res/device/{deviceId}/interface/{ifIndex}/down   to down the interface

so for use that would be  /plat/res/device/15/interface/21/down

and then immediately do a

/plat/res/device/{deviceId}/interface/{ifIndex}/up

or again for us  /plat/res/device/15/21/up

Now whether the actual switch commands are “switchport acces vlan 20 ”  or ” port access vlan 20 ” or some other variation on a theme doesn’t actually matter to your devOps team. They just write the code to follow the steps and IMC and the eAPI will take care of the rest.

Pretty cool stuff. 🙂

@netmanchris