cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
329
Views
5
Helpful
0
Replies
Highlighted
Beginner

Bug: ASA REST-API bulk operation fail leaves API in inconsistent state

Hey,

using the bulk API functionality ("/api") on my test ASAv, I tried to add the same rule twice to a new ACL.

The API call failed, as expected, with HTTP 400 and this message:

{

  'commonMessages': [

   {

      'level': 'Error',

      'code': 'DUPLICATE',

      'context': 'objectId',

      'details': '2113552303'

    }

  ],

  'entryMessages': []

}

So far, as expected. But after this fail, the API and the ASA itself were no longer in a consistent state.

A "show access-list" on the ASA did not show any of the rules created, neither the unique one nor the duplicate.

A call to "/api/objects/extendedacls/TEST/aces/" however shows all rule as existing that were processed before the duplicate rule.

At this point, only three ways I found to "fix" it:

1. Reboot the ASA. It will then start with neither of the rules existent in the CLI nor the API

2. Manually creating a valid rule via the CLI. All the said-to-be succesfully created rules from the API will disappear, and only the new rule will exist. It seems that here the CLI will overwrite the state in the API.

3. Successfully(!) creating another rule via the API. This will cause the new API rule to exist in the ASA config, as well as those rules from bulk creation, that before only existed in the API. It seems that here the API try to match all of the rules it thinks should exist with the config, late-creating even those it failed to create in the bulk call before.

However, this behaviour does not seem to be expected.

Version info:

Cisco Adaptive Security Appliance Software Version 9.6(2)

Device Manager Version 7.6(2)

REST API Agent Version 1.3.2

Everyone's tags (4)