Forum Discussion

Kenny_Barnt's avatar
Icon for Altostratus rankAltostratus
Jan 08, 2019

iControl REST Token Limits and VE Lab Edition

We are currently working to implement an Ansible-based solution for configuring for our BIG-IP LTM/APM environments and have hit a stumbling block.

We have a playbook that we're executing to create all the LTM objects in the environment, but when we run it against our staging environment (running on VE Lab Edition VMs) and have a significant number of objects to create, we eventually get the following error from one of the tasks:

fatal: [bigip_host]: FAILED! => {"changed": false, "msg": "Unable to connect to bigip_host on port 443. The reported error was \"400 Unexpected Error: Bad Request for uri: https://bigip_host:443/mgmt/shared/authn/login\nText: u'{\"code\":400,\"message\":\"user admin_user_used_by_ansible has reached maximum active login tokens\",\"originalRequestBody\":\"{\\\\\"username\\\\\":\\\\\"admin_user_used_by_ansible\\\\\",\\\\\"loginProviderName\\\\\":\\\\\"tmos\\\\\",\\\\\"generation\\\\\":0,\\\\\"lastUpdateMicros\\\\\":0}\",\"referer\":\"\",\"restOperationId\":7307267,\"kind\":\":resterrorresponse\"}'\"."}

We'd found a GitHub Issue that referenced a similar issue, but it was closed and indicated that this shouldn't be an issue with the version of Ansible (2.7.5) we're running. An important point that this issue brought to light is that when the Ansible modules are making calls against the API, they are getting new login tokens for each task.

Out of curiosity, we tried running the same playbook against the hardware BIG-IP appliances that will be our new production environment, and we've yet to run into this issue, even running the playbook several times in quick succession.

So it seems like the VE Lab Edition has a limit on how many API login tokens a user can have that isn't present for non-Lab licensed instances. We're hoping to get some feedback on a few points:

  1. Are we right about the Lab Edition having a limit?
  2. If there is a limit on the Lab Edition, what is it?
  3. Does anyone have thoughts for how we might be able to work around this limit?

Some searching brought me to this previous question, which talks about adjusting the timeout on tokens, but from the standpoint of wanting them to be longer-lived, and when using the iControl API directly, rather than via a tool like Ansible. Maybe if we could adjust that default timeout to something smaller? Otherwise it seems like we'd have to either look into building our own custom fork of the Ansible modules, or seriously reconsider how we're going to approach this.

1 Reply

  • A non-admin user can have maximum 100 tokens at one point in time. A request for the 101-th token will give you the error 'user foo has reached maximum active login tokens. If I remember correctly, the feature was introduced in BIG-IP 13.1.0. Check the versions in your environments.

    I am not aware of license dependency. If you suspect the license is the source of issue, please consider contacting F5 support.

    Check the number of tokens you created by accessing /mgmt/shared/authz/tokens when you get the error.

    Workarounds I can think of are ...

    • Use admin (it does not have a limit to my knowledge).

    • Changing the lifespan of a token to much shorter time (the default is 20 min), so that the used token automatically disappears and makes a room for a new one.

    • Use multiple users.

    • Request just one or a few tokens and reuse it for all the transactions (recommended).