Why parsing display commands with Ansible can often provide a 100% hit rate

Not everyone is blessed with a switch estate built on an OS that has a strong ansible module integration. Some of us (comware users) can but dream of making something happen with a module specifically created for that task with just populating the right parameters standing between us and config nivarna. Even for those who choose an automation supporting OS sometimes have to fall back to sending a display command directly and parsing the return.

I recently created a playbook to scour the comware estate for where uplinks were using DAC cables as opposed to fibre. This was part of an investigation into Interface errors linked with poor quality DACs. To find this information by hand I would issue a display (show) command on the CLI and grep/filter the result to only show copper SFP+. Something like:

display transceiver interface ten1/0/49 | i COPPER

Given that positive results would mean further work I hoped to get few replies. The command worked perfectly on the CLI of a couple of test stacks. I inserted into a playbook using the comware_command module so as to quickly check the other x hundred. I ran the script and waited for the results.

I got a 100% hit rate. As in every switch reported finding copper DAC interfaces for its uplinks. This meant a huge amount of work and expense. The power of ansible had delivered bad news in less than five minutes.

However, something wasn’t right. I knew there were lots of examples of fibre uplinks. Most edge stacks were in different buildings to their uplink routers. So I enabled a debug to see what was going on. Using a switch I knew to have LR fibre connections I asked ansible to display the result of the display command. Here is an example:

<switch1>display transceiver interface ten1/0/49 | i COPPER
<switch1> 

You can see from this that the command went to the CLI and the response was ‘null’. The switch is saying there is no string COPPER in the result of the display command. So why was ansible saying that there was a response with the string COPPER in it?

It took too long to realise the problem was that the output from the switch includes the command being sent. The output from the switch isn’t just the answer, it is the question and answer. So in every case where your ‘when’ statement searches for a string that is present in the display command you’ll get a 100% hit rate.

The solution is simple. Make the conditional search in the playbook longer than the filter in the display command.

Using my example above, if the display command was:

display transceiver interface ten1/0/49 | i COPP

and the conditional in the task was:

when: ‘”COPPER” in registered_var’

…then you would only see matches where the ‘answer’ included the search string. This concept is relevant for all sorts of tasks where you search for a thing and parse the response. If you get 100% hit rate then double check if the returned output includes the command sent from ansible.