Dear Internet,

I am writing some automation code in Go to create client-ssl templates on an A10 load balancer running AXAPI version 2. It’s going as swimmingly as it can with the v2 API, but one area of non-complete API coverage has led to another issue and I’m wondering if anybody has seen the same thing.

Background – Disabling SSLv3

SSL access to VIPs on the A10 load balancer is controlled by means of client-ssl templates which define which certificates should be presented and the ciphers and protocols supported for the incoming connection. In this case therefore, disabling SSLv3 is accomplished in the client-ssl template (unfortunately there is no global switch to turn SSLv3 off by default). A typical template might look like this in the configuration:

slb template client-ssl mytemplate
   cert my_certificate
   key my_private_key
   chain-cert some_chain_cert
   disable-sslv3
!

As it turns out, all aspects of the client-ssl template are exposed via the API except for “disable-sslv3” which shows neither as a returned property of the template (highly annoying), nor as a property which can be set when creating a template (also annoying). Thus to replicate a template like the one above, I choose to set everything I can using the JSON client-ssl template object, then – and this is the bit that grinds my grits – I have to make a second API call to the CLI in order to then issue commands thus:

slb template client-ssl mytemplate
   disable-sslv3

If you’re thinking this sounds lame, then you’ve just understood why at Tech Field Day events, a common question asked of vendors is “does your API have 100% configuration coverage?”

Communicating With AXAPI

In order to use the A10’s API, it’s necessary first to authenticate to the device. In return, the A10 provides a session_id token which has to then be provided in the URI of every subsequent request during that session. Consequently every API call looks similar to this:

https://a10.fqdn/services/rest/V2.1/?session_id=[SESSION_ID]&format=json&method=slb.client_ssl.search

This works well and is pretty fast. To enter configuration lines the same paradigm is used, consisting of an HTTP POST to:

https://a10.fqdn/services/rest/V2.1/?session_id=[SESSION_ID]&format=json&method=cli.deploy

The body of the POST is simply the commands to be entered, as if they were to be cut and paste in configuration mode. Most of the time this works ok, but I have noticed when testing against my vThunder (a virtualized A10 load balancer) I get this error back:

Invalid username/password

Obviously, the username and password are just fine, because I authenticated before any of this began, and the local account I’m logging into (for testing purposes only; production devices use RADIUS of course) has CLI rights as well as API rights. In fact it must be correct because most of the time it works and SSLv3 is disabled. But sometimes, more frequently than I’d like, the command fails with this error.

It’s possible to override the session_id and provide a username and password for the cli.deploy method in the URI as well; I’ve tried this and it’s no better.

Has anybody else seen this and found a solution? I’ll do some testing using a RADIUS admin account shortly in case the type of login makes a difference, and failing that I guess I’ll raise a support case with A10 as this smells awfully like a bug. I was just rather hoping there was a workaround meanwhile!

Long term the solution is to move to the v3 API which promises 100% command coverage, which is something I’m working on in parallel. For the moment, though this is generating instability in a process I’d really like to be solid, and it seemed rude of me not to share my frustration with you on a Friday afternoon. Enjoy your weekend!