As a follow on from my post on Cisco’s acquisition of Tail-f and Cisco’s commitment to open standards, by chance I happened to need to grab the XML schema for a Nexus 5020 so I could figure out a few commands I’d like to send to a device using NETCONF.
The XML in this case acts as a kind of public API for the Nexus, and it’s just the kind of thing that we’re looking for in today’s (and tomorrow’s) automated network.
Additional Entitlement Required
Firstly, I don’t like that I have to login to CCO to download an XML schema. I have a general distaste for companies hiding documentation beyond an account login when in my opinion that documentation should be public. Still, at least in theory a CCO account is free and I do have one, so I logged in.
Apparently though the XML Schema is so freaking top secret that my account rights are insufficient:
To be fair, the account I’m using has little beyond my CCIE associated with it (yet more demonstration that the CCIE certification gets you no special treatment on CCO), but I did not expect to need a paid service contract just to see an XML schema. I’m relatively new to this whole NETCONF game so maybe there’s a good reason to keep the XML schema locked down behind a paywall; if you can educate me, I’m happy to learn. Anybody?
Hi John – For Junos, the XML schema and all related documentation can be found on the open techpubs website. First go here:
https://www.juniper.net/techpubs/
Then select “Junos OS”.
Then select your version of Junos.
Then look for the section called “Junos API and Scripting”.
There are two documents, one that is the operational commands, and another that describes the configuration XML. Note these are not the actual XML schema definition files (XSD).
But reading these docs is not a joy. So I use the Junos CLI to dump what I need. For example, any CLI command can be exposed using the “| display xml rpc” and “| display xml” filters. For example “show route | display xml rpc” will give you the command, and “show route | display xml” will give you the result of the command in XML. For the configuration, you can use “| display xml” as well.
There are very few cases where folks really *need* the XSD files. These are generally for tool companies (like Tail-F) that need to programmatically process these files. Juniper does provide these files on our download page, here:
http://www.juniper.net/support/downloads/?p=junosxml#sw
Alas, I just checked this, and these files are behind a user-login as well.
So there are options:
(1) Techpubs – open, but file is PDF/HTML
(2) Junos CLI – requires you to have a Junos product (or Junosphere)
(3) Software download – requires a portal login
HTH,
— Jeremy
Thanks for the information and thoughts, Jeremy!
Funnily enough, I didn’t even look for the Juniper schema because of the “| display xml rpc” command as a handy shortcut. I know the XSD files aren’t normally bedtime reading for most people, but it still makes little sense to me to lock them away. I don’t like, but understand, the desire to put files behind a CCO / Juniper login for competitive reasons, but once you’re in there I don’t see why the XSD would require a paid service contract of some sort.
Hi John – I suspect the XSD files posting to the software site are a function of the normal build/publish environment. I’ll rattle some cages with folks I know to see what’s possible. I’ll also see if there are any other options to get these files that do not require a login.
Hey John – you can use the following debug to produce the XML required for configuration changes on NXOS. Similar to JunOS’ “display xml rpc”:
debug cli force xml-output
*SMH* Buried in a debug? That is awesome! Thank you for the tip – I will try that out. That said, Cisco XML RPC seems to be pretty straightforward in what seems to be a rather weak kind of way – take each word in the command and pretend it’s a tag, e.g.:
<show> <mac> <address-table> <address> 1234.1234.1234 </address> </address-table> </mac> </show>To me that’s an unpleasant kind of pseudo-XML structure, but whatever works I guess. The output (xml reply) on the other hand is Hideous with a capital “OMG that’s HIDEOUS”.
j.
Hi John,
If the formation of the XML is “regular” in such a way, then it is entirely possible to use metaprogramming techniques to auto-build the XML commands 🙂 I use metaprogramming techniques with PyEZ, in a similar (but different) way. So in PyEZ you can do something like:
>> dev.rpc.get_chassis_inventory()
The method “get_chassis_inventory” does not actually exist in the PyEZ, it is metaprogrammed on the fly.
For Cisco, perhaps one could do something similar:
>> dev.rpc.show__mac__address_table(address=”192.168.10.27″)
Just a thought.
That’s kind of the direction I’m taking. I can cope with whatever the XML is, as it’s consistent and I can programmatically insert the relevant arguments. It doesn’t mean that as a human I like it, but for code, I can probably handle it! Once coded, I hope never to have to see it again.