Traffic Manager UI Features

Enabling and Disabling the API

To enable or disable the REST service, click System > Security > REST API in the Traffic Manager Admin UI. You can additionally use this page to set the TCP port that the service listens on. The default port is 9070, however any unreserved port can be used here provided it does not conflict with other services already running on the Traffic Manager system. Click Update to apply any changes.

ATTENTION
The REST API is currently not available in conjunction with the Traffic Manager’s Multi-Site Manager (MSM) feature. Attempts to enable the REST service whilst MSM is operational are denied. Equally, attempting to enable MSM whilst the REST service is running triggers an error. The current state of the Traffic Manager remains unchanged in either of these situations.

To manually restart the REST API service, click System > Traffic Managers and then, in the Software Restart section, click Restart REST API.... The Traffic Manager asks you to confirm the restart on the next screen. Note that any existing connections are lost while the service restarts.

Controlling Timeout Events

The System > Security > REST API page provides a number of settings to control how the Traffic Manager responds to certain timeout events that occur through use of the REST API. These are:

Setting	Description
rest!auth_timeout	The timeout period, in seconds, for the REST Authentication cache. As REST does not include the concept of a "session", each request must include user and password credentials. These credentials are validated each time; however, to save requesting repeated external authentications for the same user (from the same IP address), a cache of recent authentications is maintained. This timeout is the maximum amount of time a given user's credentials can stay in the cache. A setting of 0 (zero) disables the cache, forcing every REST request to be authenticated as it is received. However, this affects the performance of the API. (Default: 120 seconds)
rest!replulltime	This is the lull time for configuration replication using REST. This is the time, in seconds, of inactivity through the REST API before configuration replication starts. Increasing this value delays configuration replication among a cluster of Traffic Managers. (Default: 5 seconds)
rest!repabstime	This is the absolute timeout prior to configuration replication using REST. This is the longest time, in seconds, before configuration replication using REST starts, regardless of activity through the API. (Default: 20 seconds)
rest!reptimeout	The configuration replication duration timeout using REST. This is the time, in seconds, allowed for the process of configuration replication to complete. On a system with slow cluster communications or a very large configuration, increasing this value improves replication reliability. (Default: 10 seconds)

Configuring the IP Addresses That the REST API Listens On

System > Security > REST API contains a setting, rest!bindips, that can be used to control the IP address(es) that the REST API listens on for connections. This can be a space-separated or comma-separated list of IPv4 or IPv6 addresses. Alternatively, it can contain an entry of "*", in which case the REST API listens on all IP addresses.

If you configure the Traffic Manager to use a management IP address during initial configuration, rest!bindips defaults to this same IP address. You can, however, override this later with a separate IP address or list of IP addresses specific to the REST API.

ATTENTION
rest!bindips is a machine-specific setting and is not included in the cluster configuration that is replicated out to joining Traffic Manager instances. If you intend to join an unrestricted Traffic Manager into a cluster that has been previously configured to use a management IP address, you must ensure rest!bindips is set on the new instance before you join the cluster to avoid exposing unintended access.

The addresses that are bound to are listed in the error log. Addresses to which the REST API cannot be bound are also logged. If no addresses can be bound, the REST API shuts down.

Restricting Access to Trusted Users

In addition to username/password access, click System > Security > Restricting Access to further restrict access to the administrative capabilities of your Traffic Manager system to a set of trusted IP addresses, CIDR subnets, or DNS wildcards. Access to the REST API is also affected by this capability.

Log Messages in the Traffic Manager

The Event Log

A number of specific API-related messages might be found in the Traffic Manager event log under certain conditions:

•“REST API started: https://<URI>”

Raised when the REST Daemon starts.

•“REST API is shutting down”

Raised when the REST Daemon closes down.

•“On IPv6 host but cannot set unspecified ip address to ::”

Raised when the REST Daemon can't set itself up to listen on the IPv6 wildcard address.

•“Could not open Traffic Manager PID file for read: <error>”

Raised when REST Daemon can't identify the Traffic Manager PID, and so can't signal it to reload its config after a change has been made via the REST API.

•“Could not open Traffic Manager PID file: <error>”

Raised when REST Daemon can't identify the Traffic Manager PID, and so can't signal it to reload its config after a change has been made via the REST API.

•“Failed to write to audit log: <error>”

Raised when the REST Daemon can't add lines to the audit log.

The Audit Log

The audit log records login attempts, configuration changes, and user logouts. It also records changes made using the Traffic Manager Control API, and through the Traffic Manager Command-Line Interface (CLI). Configuration changes made through the REST API follow the same behavior.

In addition to the typical configuration messages entered into the audit log, the Traffic Manager also provides the ability to track user activity in the REST API. It does this by grouping REST request/response exchanges made in close succession from a given user into a "session".

The Traffic Manager logs the first request in a group of one or more requests from a particular user/ip address combination in the audit log as a "session start". Requests received after the initial request are deemed to be part of the same user session. Then, after a specified timeout interval since the most recent request was received from the same user, a "session end" is logged.