Another day, another issue with an automation script.

Today’s task was to grab the configuration file from an A10 Thunder load balancer. I don’t want to use the GUI, and while I could – in theory – use ssh and expect to scrape the CLI, it’s not the way I’m trying to work now, presumably because I’m a masochist.

It all went smoothly, right?

A10 aXAPI

For those of us who love the continued pain of network automation, A10 offers aXAPI, a REST-based API by which to communicate with the load balancer. Wot, no NETCONF? That would be too much to hope for my bigger automation picture where everybody agrees to at least implement a mini-NETCONF, so that a generic NETCONF polling tool can be told that this device is an A10 and uses something other than XML RPC for management.

Back to the API. It seems to me that JSON is a more recent – and preferred – choice for the API, which means you have to specifically request JSON by including “format=json” in the URL, or you’ll get XML back. Worse, as I discovered, in some cases where aXAPI does not like the URL parameters you set, despite the inclusion of format=json, the error comes back in XML. So now I have to deal not only with the potential errors returned in JSON, but also detect when something went so badly wrong the error response comes back in XML instead. Let’s call this a bug, because it shouldn’t be by design, in my opinion.

Authentication

A10’s approach to security is interesting. When I’ve used REST/JSON to interact with JIRA, authentication is handled very simply using HTTP Basic Authentication – you include a username:password string (Base64 encoded) as an HTTP header. This makes sense to me because if REST is supposed to be stateless, each request can come in independently of any other request, and therefore each one should authenticate itself to confirm that you are allowed to issue the request, right? Well, sort of. While REST claims to be stateless (or at least, state is maintained by the client) it does allow some session state to be kept on the server, typically for authentication purposes. This is the approach that A10 have taken, and it means we need one additional step (well, actually two) in order to issue commands.

• Step 1: Authenticate to the A10. Receive a Session_ID in return. Your username and password are parameters passed in the URL. I really dislike that. Can’t I put them in the Basic Authentication field again? Or at least POST them to the A10 using JSON?
• Step 2: Include said Session_ID in every request from then on. Using the unique Session_ID references your cached authentication information which is used to confirm your permissions from then on. If anybody snags that Session_ID then, they can presumably issue commands with your permissions, even though they have not authenticated. It’s not clear yet whether the Session_ID is further tied to an IP or some other kind of device fingerprint, but it’s certainly not tied to, say, a browser – I was able to copy a session_id from a browser and use it from the shell in a curl script.
• Step 3: Close the session out. The default timeout is 10 minutes for an idle session, but from a security standpoint I want the session shut down immediately.

As a side note, the URL format for all the subsequent requests allows you to include a username and password, just as was done to authenticate. However, since a valid Session_ID becomes a required part of the URL, you can’t bypass Step 1 (authentication) simply by providing your credentials in every request.

Grabbing the Config

I’ve yet to find a specific REST method to simply grab the entire configuration (which isn’t to say there isn’t one, but simply that I haven’t found it yet), but there is a cli.show_info method which allows you to issue privileged exec commands as if you were typing at the CLI, and the response will be thrown back at you embedded within a JSON structure. This is a little bit like using CLI commands in Cisco’s NETCONF implementationl it feels like a total cheat, but it does at least seem to work. There’s also a cli.deploy method, by the way, which allows you to submit commands to be “typed” in configuration mode. So long as you get the sequence of commands correct, you can effectively type in a chunk of configuration and hope it works (and be ready to interpret the error response if there is one). This may sound familiar if you recall me having to do similar to configure a VLAN as “mode fabricpath” in NXOS because there is no native NETCONF command to do so.

Interesting (perhaps) side note: In addition to your user account needing aXAPI permissions, it will also need CLI permissions in order to issue these commands. That makes sense I suppose, but it might be nice to limit service accounts to aXAPI and not offer up SSH CLI as well.

Success

I did succeed in the end. I took a tool that I have been developing to automate JIRA tasks (I’ll talk about that shortly, as it was an interesting case study for me of how I ended up moving code into configuration files to make it more re-usable) and built the necessary templates to authenticate, issue a “show running-configuration” command and to close out the session. In fact it does so seamlessly, but right now only if I use HTTP. I’m working a support case with A10 currently to try and figure out why my HTTPS requests take about a minute each to complete. I have a suspicion it’s a Mac OSX Mavericks issue (with Perl as an additional layer of confusion on top of it), but we’re working to prove that. Still, I can get the configuration down from the A10 in a matter of seconds, all using aXAPI. Much nicer than SSH screen scraping!

Networking Field Day 8

By coincidence (truly) I note that A10 is a sponsor of Networking Field Day 8 (NFD8) this September. It’s a small world apparently, and I’m interested to see what topics A10 will choose to raise when they present to us. Naturally, I won’t harass them about my personal issues with aXAPI unless it’s being presented or is relevant in context, but I will be pleased if in addition to anything else they present, I get some insight into where they’re taking aXAPI in the future. Look for the schedule to be published for NFD8 nearer the date, and you can watch a live stream or catch up on published videos later, to see what A10 are up to.