With Joe Marcus Clarke
Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to learn and ask questions how to optimize devices using network embedded automation and programmability with distinguished support engineer Joe Marcus Clarke. This event will cover Cisco technologies like the Embedded Event Manager, Tcl programming, NETCONF, onePK, and Python scripting available in our IOS, XE, XR, and NX-OS platforms. We will discuss your technical questions, problems you want to solve, and your ideas about embedded automation and programmability
Joe Marcus Clarke is a Distinguished Support Engineer at Cisco. Joe has contributed to network management by finding and fixing bugs, as well as implementing maintenance and troubleshooting components in Cisco Prime, Cisco's flagship network management suite. Joe helps to support and enhance the embedded automation and programmability technologies in IOS, such as the Embedded Event Manager and Tcl. He is a top-rated speaker at Cisco's annual user conference, CiscoLive as well as a leading contributor on the Cisco Support Community and founding member of the CSC Hall of Fame. Clarke has authored numerous technical documents on Cisco network management products and technologies and co-author books. Joe is co-author of four Cisco patents, including one on leveraging XMPP as a network management protocol. He holds several Certifications such as the CCIE in Routing and Switching (#5384), Sun System Administrator, Sun Network Administrator, Sun Security Administrator, Sun Java certified, and VMware Certified Professional.
Remember to use the rating system to let Joe know if you have received an adequate response.
Joe might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation on the Network Infastructure sub-community discussion forum shortly after the event. This event lasts through through July 27, 2012. Visit this forum often to view responses to your questions and the questions of other community members.
I have been looking at the tcl scripting every once in a while when I was at sites where some of the equipment was able to run this. I did not know also python was supported. I feel like learning that language.
I wondered why cisco did not follow the approach like with the other technologies like energywise, smart install, etc, to create a dashboard where one can see which devices in the DCR are actually able to participate, and if not if this is due to soft or hardware incompatibility.
From there, to create a dashboard to centralise the distibution and management of these scripts would seem like a logical next step.
This combined with some basic examples would get a lot of people started I think.
I would expect a lot of people to get exited if they could use the script to detect a situation on the device and then get LMS to react on that.
Do you think something like that could be part of NCS 1.2 or 2.0?
Thanks for the post, Michel. Currently, Python is only available on the Nexus 3K line; however, it's coming to the 7K as well. We ran a survey on our Cisco Beyond site (http://www.cisco.com/go/ciscobeyond) and Python is tracking second to Perl. We will likely see a new IOS scripting language, too.
In all honestly, EEM was never marketed as well as it could have been. Yes, the IOS guys did get some EEM hooks into LMS, but they were never really used. We should have done more concerted things to promote EEM usage, and then those LMS features may have seen more use.
Cisco Beyond has become our central location for scripts (and now conversations). But there is no LMS tie-in. As we migrate more of the LMS features to NCS, I'll see what we can do to at least add some callout to Cisco Beyond (likely NCS 2.1).
I will say that we have had some casual conversations about where we could use EEM to augment some of the centralized management we do. Thus far, those remain conversations :-(.
We recently transitioned our Cisco Beyond forum over to Cisco Support Community. If you go to http://www.cisco.com/go/ciscobeyond that will redirect you to the CSC community where you can find lots of Cisco and customer-contributed example scripts as well as a place to ask questions and get advice/code to help you with your embedded automation solutions.
EEM is an automation layer provided on-box. It doesn't add much in the way of "magic" or deep IOS internal introspection. Instead, you are able to automate existing configuration and CLI tasks using various events. This is not to say EEM is not powerful. It is extremely powerful. By simply adjusting the configuration of a device based on an event such as a syslog message, one can achieve a new feature in IOS.
onePK, on the other hand, is an API. onePK has hooks into EEM (for some of its event-driven components), but it takes device programmability to another level. Using onePK, one can plug into device and network-level functionality in a common way. That is, you can manipulate the rotuing table or add an access policy across IOS, IOS-XR, and NX-OS using the exact same function or method calls; no domain-specific CLI is needed.
onePK also exposes aspects of the device's data path to an application. You can inspect the traffic traversing a network, add new capabilities to data flows, or change flows in line. This allows one to take all of the rich experiences and capabilities provided by Cisco OSes and layer on customized capabilities in an interative manner.
By combining the event capabilities of EEM with the deep API layers of onePK, there will be very little one cannot do with a Cisco network.
onePK will be available in three different deployment models. One mode is to deploy your applications off-box on a Linux host. The app will connect to the network element (or elements) using a secure RPC connection. Another deployment is on a service blade within the device. This deployment method would likely be used with ISRs. The final method is on-box in a container space. This is possible on platforms like the ASR that run IOS-XE.
How an app is deployed will depend on the app's intended scope and on performance needs one has. Clearly the closer you can get to the network element, the better the performance will be for certain APIs.
onePK rides on top of EEM for its eventing layer. So there will be some commonality and convergence there where it makes sense. However, they will solve some different problems and provide different solutions.
If you go to http://www.cisco.com/go/ciscobeyond you will see a survey there. The majority of our customers want Perl or Python (in addition to the Tcl scripting we have today), and it looks like Python already has an edge since we are already supporting Python scripting on the Nexus 3000 switches. I would suggest you stay tuned to Cisco Beyond as we will announce any new scripting support there as we make it available.
Been playing around with the EEM script, that was posted here:
Everything works brilliant and we have various customer installations where it has become a part of the standard switch template, makes live a lot eaiser to troubleshoot and verify, as well as having constant updated descriptions.
But I was thinking if it would be possible to get an IP address of the neighbor device?
Have been looking at the configuration guide of EEM 3.2, and can see there is no variable of IP address, so my question is if that variable can be expected in future releases, or there is another way to get the IP address of the neighbor included into the description string on a interface?
You could use CLI to do this:
action 001 cli command "enable"
action 002 cli command "show cdp nei $_nd_local_intf_name detail"
action 003 regexp "IP address: ([0-9\.]+)" $_cli_result match ip
action 004 if $_regexp_result eq 0
action 005 set ip 0.0.0.0
action 006 end
Then use the variable $ip as the entry's IP address.