Application-Centric API Reference
This document provides detailed reference information for the Application-Centric API model in NetScaler Next-Gen API.
Application Types
Next-Gen API allows users to configure different types of applications from the simple applications that consist of one VIP/port to more sophisticated applications that feature multiple VIPs/Ports and multiple backend server groups.
Simple Applications
For a simple application listening on one virtual IP and one port, you can create one with the following sample JSON payload:
{
"application": {
"name": "my_app",
"virtual_ip": "70.122.23.11",
"port": 443,
"default_certificate_ref": "cert1",
"servers_port": 8080,
"servers": [
"192.168.10.11",
"192.168.10.14"
]
}
}
The payload directly specifies the virtual IP and port as well as the backend servers and their port. Notice that we didn't specify the VIP's protocol. In this case, it is assumed to be the default protocol "HTTPS". Actually, even the VIP's port number is optional in this case: If not specified, it defaults to the protocol's default port (for HTTPS, it is 443). So we could rewrite our payload simply as:
{
"application": {
"name": "my_app",
"virtual_ip": "70.122.23.11",
"default_certificate_ref": "cert1",
"servers_port": 8080,
"servers": [
"192.168.10.11",
"192.168.10.14"
]
}
}
You don't have to use the compact notation "server_ip". If you want to be clear and explicit, you can use the following expanded format for specifying each server's ip and port through explicit attributes:
{
"application": {
"name": "my_app",
"virtual_ip": "70.122.23.11",
"port": 443,
"default_certificate_ref": "cert1",
"servers_port": 8080,
"servers": [
{
"ip": "192.168.10.11"
},
{
"ip": "192.168.10.14"
},
{
"ip": "192.168.10.15"
},
{
"ip": "192.168.10.16",
"port": 8181
}
]
}
}
You can also mix both styles when specifying servers as shown in the example below:
{
"application": {
"name": "my_app",
"virtual_ip": "70.122.23.11",
"port": 443,
"default_certificate_ref": "cert1",
"servers_port": 8080,
"servers": [
"192.168.10.11",
"192.168.10.14",
"192.168.10.15",
{
"ip": "192.168.10.16",
"port": 8181
}
]
}
}
}
Notice that the last server, we specified a port attribute that overrides the default servers_port attribute value.
Which notation to use (compact vs expanded) is really a matter of style preference.
You can also specify the weight of a server, if you want a server to serve more requests than other servers by a certain factor. For example, in the example below, the first and the last server serve twice as many requests as the remaining servers:
"servers": [
{
"ip": "192.168.10.11",
"weight": 2
},
{
"ip": "192.168.10.14"
},
{
"ip": "192.168.10.15"
},
{
"ip": "192.168.10.16",
"port": 8181,
"weight": 2
}
]
Applications with one VIP and multiple ports
For applications that feature a VIP with multiple ports, we introduce the concept of a listener. Each port is modeled as a separate listener, as shown in the example below for an application that is listening on an HTTPS port and an HTTP port.
{
"application": {
"name": "app1",
"virtual_ip": "70.122.23.11",
"listeners": [
{
"name": "secure_listener",
"port": 443,
"protocol": "HTTPS",
"default_certificate_ref": "app1_cert",
},
{
"name": "http_listener",
"port": 80,
"protocol": "HTTP"
}
],
"servers_port": 8080,
"servers": [
"192.168.10.11",
"192.168.10.14",
"192.168.10.15",
"192.168.10.16",
"192.168.10.17",
"192.168.154.47"
]
}
}
Any requests received from either listener (HTTP/80 or HTTPS/443) will be load-balanced amongst the servers of this application.
You can also specify that any request received on the HTTP/80 port be redirected to the HTTPS port by setting the attribute http_to_https_redirect to true on the HTTPS listener.
{
"application": {
"name": "app1",
"virtual_ip": "70.122.23.11",
"listeners": [
{
"name": "secure_listener",
"port": 443,
"protocol": "HTTPS",
"default_certificate_ref": "app1_cert",
"http_to_https_redirect": true
}
],
"servers_port": 8080,
"servers": [
"192.168.10.11",
"192.168.10.14",
"192.168.10.15",
"192.168.10.16",
"192.168.10.17",
"192.168.154.47"
]
}
}
Since we only have one listener, we can also write the above payload more simply as:
{
"application": {
"name": "app1",
"virtual_ip": "70.122.23.11",
"protocol": "HTTPS",
"port": 443,
"default_certificate_ref": "app1_cert",
"http_to_https_redirect": true,
"servers_port": 8080,
"servers": [
"192.168.10.11",
"192.168.10.14",
"192.168.10.15",
"192.168.10.16",
"192.168.10.17",
"192.168.154.47"
]
}
}
Applications with multiple VIPs
Some applications have more than one virtual IP (VIP), maybe an external VIP and an internal VIP, but users want to view all these VIPs as part of the same application. To model each VIP in such applications, we introduce the concept of a frontend. Each frontend represents one VIP of the application. The frontend itself can have multiple listeners if there are multiple ports on that VIP as we have discussed in the previous section.
The following example shows an application with 2 frontends, the second frontend having an explicit listener. All requests to either frontend (VIP/port) are load-balanced amongst, and served by, the same set of backend servers.
{
"application": {
"name": "app1",
"frontends": [
{
"name": "admin_frontend",
"virtual_ip": "70.122.23.26",
"port": 443,
"protocol": "HTTPS",
"default_certificate_ref": "admin_cert"
},
{
"name": "customer_frontend",
"virtual_ip": "70.122.24.21",
"listeners": [
{
"name": "secure_listener",
"protocol": "HTTPS",
"port": 443,
"default_certificate_ref": "app6_cert",
"http_to_https_redirect": true
}
]
}
],
"servers_port": 8080,
"servers": [
"192.168.10.11",
"192.168.10.14",
"192.168.10.15"
]
}
}
For applications that have only one VIP as we saw earlier, you can think of them as having an implicit "default" frontend.
Applications with multiple backends
For applications where you want to route or switch requests to different groups of servers based on the characteristics of the request or the client (the "content switching" use case), you will need to specify different groups of backend servers and then specify how you route or switch traffic to different groups based on characteristics of the request or the client. For this purpose, we introduce 2 new concepts: backends and routes.
The following example shows an application with 2 backends, called respectively account_servers and billing_servers. The routes define the rules that govern which requests go to which backend. In this example, we want all requests that start with
/account to go to the account_servers and all the requests that start with /checkout go the billing_servers backend.
{
"application": {
"name": "app5",
"virtual_ip": "70.122.23.11",
"port": 443,
"protocol": "HTTPS",
"default_certificate_ref": "portal_cert",
"backends": [
{
"name": "account_servers",
"servers_port": 8080,
"servers": [
"192.168.10.11",
"192.168.10.14"
]
},
{
"name": "billing_servers",
"servers_port": 8080,
"servers": [
{
"ip": "192.168.11.11"
},
{
"ip": "192.168.11.14"
}
]
}
],
"routes": [
{
"name": "account_route",
"filter": "http.request.uri startswith '/account/'",
"backend_ref": "account_servers"
},
{
"name": "checkout_route",
"filter": "http.request.uri startswith '/checkout/'",
"backend_ref": "billing_servers"
}
]
}
}
For the previous application payloads where there was no explicit backend configured and we only specified the servers, you can think of them having an implicit "default" backend.
You also notice in the above payload that the criteria for routing or switching requests to a specific backend is specified using the "filter" attribute whose value is an expression that is easy to understand. These expressions follow the Wireshark Display Filters expression syntax, selected because many developers are familiar with Wireshark as a tool, and this syntax is easy to understand and remember. Section Wireshark Expressions covers the various expressions that can be used.
If you are already familiar with traditional NetScaler policy expressions (PI), you can still use the PIXL syntax rather than the Wireshark syntax by setting the filter_format attribute to pixl as shown below:
{
"name": "account_route",
"filter": "HTTP.REQ.URL.PATH.STARTSWITH(\"/account\")",
"filter_format": "pixl",
"backend_ref": "account_servers"
}
Applications with multiple VIPs and multiple backends
If an application requires both multiple VIPs and multiple backends then this application will have a set of frontends, a set of backends, and routes to determine how requests are routed between the frontends and backends.
In the following example, we have an application that has 2 frontends and 2 backends.
{
"application": {
"name": "app8",
"frontends": [
{
"name": "admin_frontend",
"virtual_ip": "70.122.23.26",
"port": 443,
"protocol": "HTTPS",
"default_certificate_ref": "admin_cert"
},
{
"name": "app_frontend",
"virtual_ip": "70.122.24.21",
"listeners": [
{
"name": "secure_listener",
"port": 443,
"protocol": "HTTPS",
"default_certificate_ref": "app8_cert"
},
{
"name": "http_listener",
"port": 80,
"protocol": "HTTP"
}
]
}
],
"backends": [
{
"name": "account_servers",
"port": 8080,
"servers": [
"192.168.10.11",
"192.168.10.14"
]
},
{
"name": "billing_servers",
"port": 8080,
"servers": [
"192.168.11.11",
"192.168.11.14"
]
}
],
"routes": [
{
"name": "account_route",
"filter": "http.request.uri startswith '/account/'",
"backend_ref": "account_servers"
},
{
"name": "checkout_route",
"filter": "http.request.uri contains '/checkout/'",
"backend_ref": "billing_servers"
}
]
}
}
This is similar to the previous example, except that requests received from either frontends will be routed through the same logic to the 2 backends.
In some cases however, we want to be more specific about routing such as routing requests only from a given frontend/listener. In this case, the route needs to explicitly reference the frontend/listener that it is targeting as shown below:
"routes": [
{
"name": "checkout_route",
"frontend_ref": "app_frontend",
"listener_ref": "secure_listener",
"filter": "http.request.uri contains '/checkout'",
"backend_ref": "billing_servers"
},
{
"name": "ad_route",
"frontend_ref": "app_frontend",
"listener_ref": "http_listener",
"filter": "http.request.uri startswith '/ad'",
"backend_ref": "advert_servers"
},
{
"name": "account_route",
"filter": "http.request.uri startswith '/account/'",
"backend_ref": "account_servers"
}
]
Requests received on the frontend app_frontend on listener secure_listener, are forwarded to the billing_servers backend if their URL starts with /checkout. If they are received on the same frontend but on listener http_listener instead, and their URL starts with /ad then they are forwarded to a different backend (advert_servers).
The third route in the example specifies that regardless of the frontend/listener on which the request is received, if the URL starts with /account, then these requests will be forwarded to the account_servers backend.
We will discuss later the filter attribute and the valid expressions that can be specified.
Note:
The routes are evaluated in the order they are listed. The first matched route is the one that takes effect. If a request doesn’t match any route, it gets dropped.
You can also omit the filter attribute from the route if you want to match all requests from a certain frontend/listener. For example, the following route matches ALL requests from the frontend app_frontend and listener secure_listener, and forwards these to the billing_servers backend.
{
"name": "checkout_route",
"frontend_ref": "app_frontend",
"listener_ref": "secure_listener",
"backend_ref": "billing_servers"
}
If you want to specify a default backend for a given frontend, where requests not matching any route would be routed to, you can do so using a default_backend_ref attribute as part of the frontend/listener:
{
"application": {
"name": "app8",
"frontends": [
{
"name": "admin_frontend",
"virtual_ip": "70.122.23.26",
"port": 443,
"protocol": "HTTPS",
"default_certificate_ref": "admin_cert",
"default_backend_ref": "ad_servers"
},
]
}
}
Of course, if you are using listeners, the same setting is available on a given listener.
LoadBalancing Settings
So far, we have covered how to specify the backend servers but we haven't discussed how you can tune the load balancing settings such as the LB algorithm or the persistence settings. This is handled by the load_balancing attribute.
{
"application": {
"name": "app4",
"virtual_ip": "70.122.23.11",
"protocol": "HTTPS",
"default_certificate_ref": "app1_cert",
"servers": [
"192.168.10.11",
"192.168.10.14"
],
"load_balancing": {
"algorithm": "LEASTCONNECTION",
"stickiness_type": "SOURCEIP",
"stickiness_timeout": "2hr"
},
"unavailable_redirect_url": "https://www.example.com"
}
}
The algorithm specifies the load balancing algorithm used to load balance traffic to the servers of this application. The stickiness_type specifies the persistence setting. In this case it is setup to SOURCE IP, which means that once a server is selected to serve a request from a specific client, then all subsequent requests from the same client (same source IP) will be served by the same server. The stickiness timeout specifies the duration for honoring the stickiness to the same server if a client becomes inactive for that period. The last setting is a redirect URL to send users to, if the application becomes unavailable (all servers are down).
If you have multiple backends in your application, you can define different load-balancing settings for each backend as shown in this example:
{
"application": {
"name": "app5",
"virtual_ip": "70.122.23.11",
"protocol": "HTTPS",
"default_certificate_ref": "portal_cert",
"backends": [
{
"name": "account_servers",
"port": 8080,
"servers": [
"192.168.10.11",
"192.168.10.14"
],
"load_balancing": {
"algorithm": "ROUNDROBIN",
"stickiness_type": "COOKIEINSERT"
}
},
{
"name": "billing_servers",
"port": 8080,
"servers": [
"192.168.11.11",
"192.168.11.14"
],
"load_balancing": {
"algorithm": "LEASTCONNECTION",
"stickiness_type": "SOURCEIP"
}
}
],
"routes": [
{
"name": "account_route",
"filter": "http.request.uri startswith '/account/'",
"backend_ref": "account_servers"
},
{
"name": "checkout_route",
"filter": "http.request.uri contains '/checkout/'",
"backend_ref": "billing_servers"
}
]
}
}
If you want to share the same load_balancing settings between multiple backends, you can define them once and reference them in multiple backends. The following example shows the definitions specified in the element load_balancing_defs. From each backend, we can reference the settings to use by using the attribute load_balancing_ref.
{
"application": {
"name": "app5",
"virtual_ip": "70.122.23.11",
"protocol": "HTTPS",
"default_certificate_ref": "portal_cert",
"backends": [
{
"name": "account_servers",
"port": 8080,
"servers": [
"192.168.10.11",
"192.168.10.14"
],
"load_balancing_ref": "standard_settings"
},
{
"name": "billing_servers",
"port": 8080,
"servers": [
{
"ip": "192.168.11.11",
"weight": 3
},
{
"ip": "192.168.11.14"
}
],
"load_balancing_ref": "experimental_settings"
}
],
"routes": [
{
"name": "account_route",
"filter": "http.request.uri startswith '/account/'",
"backend_ref": "account_servers"
},
{
"name": "checkout_route",
"filter": "http.request.uri contains '/checkout/'",
"backend_ref": "billing_servers"
}
],
"load_balancing_defs": [
{
"name": "standard_settings",
"algorithm": "ROUNDROBIN",
"stickiness_type": "SOURCEIP"
},
{
"name": "experimental_settings",
"algorithm": "LEASTCONNECTION",
"stickiness_type": "COOKIEINSERT"
}
]
}
}
Note:
If you don't specify any load_balancing settings, then the default algorithm (LEASTCONNECTION) is used, and no stickiness is configured.
Certificates
You might have noticed that in many previous examples, we have certificate references in our application payloads, such as in the following simple application example:
{
"application": {
"name": "app3",
"virtual_ip": "70.122.23.11",
"default_certificate_ref": "app3_cert",
"servers": [
"192.168.10.11",
"192.168.10.14"
]
}
}
The certificate app3_cert is a certificate that would have already been uploaded to NetScaler using the following Next-Gen API:
POST /mgmt/api/nextgen/v1/certificates
{
"certificate": {
"name": "app1_cert",
"public_cert": "-----BEGIN CERTIFICATE----- … -----END CERTIFICATE-----\n",
"private_key": "-----BEGIN PRIVATE KEY----- … -----END PRIVATE KEY-----\n",
"passphrase": "long secret phrase",
"ca_certs": [
"-----BEGIN CERTIFICATE----- … -----END CERTIFICATE-----\n",
"-----BEGIN CERTIFICATE----- … -----END CERTIFICATE-----\n"
]
}
}
In this API, you specify:
-
public_cert: Contents of the certificate public key in PEM format.
-
private_key: Contents of the certificate private key in PEM format.
-
passphrase: The passphrase used to decrypt the private key if one is used.
-
ca_certs: The intermediate/root certificates chain in PEM format. Each certificate should be in a separate string in this list.
In order to transform a PEM file to a JSON string so you can use it in the API payloads, you need to replace all the line feeds with the "\\n" character.
Note:
You can use the jq utility to help easily transform a PEM file to a JSON string:
> jq -sR . mycert.pem
If the API of uploading the certificate is successful, then you can make use of it by referencing your uploaded certificate when you create your application.
{
"application": {
"name": "app3",
"virtual_ip": "70.122.23.11",
"certificate_refs": ["app3_default_cert"],
"servers": [
"192.168.10.11",
"192.168.10.14"
]
}
}
In the above payload, we used the attribute certificate_refs to reference the SNI certificates used by our application. The application is only served to clients who provide a matching SNI (Server Name Indication) to one of the certificates during the SSL handshake.
If you want NetScaler to serve any client regardless of whether they provide a matching SNI or not, you can use the attribute default_certificate_ref (that we used in previous examples) rather than certificate_refs as shown below:
{
"application": {
"name": "app3",
"virtual_ip": "70.122.23.11",
"default_certificate_ref": "app3_default_cert",
"servers": [
"192.168.10.11",
"192.168.10.14"
]
}
}
If you want your application to be associated with one or multiple certificates, one for each domain, but also to have a default certificate in case the client doesn't provide an SNI, or the client provided SNI doesn't match any of the configured certificates, then you can combine both the SNI certificates with the default certificate as shown below:
{
"application": {
"name": "app3",
"virtual_ip": "70.122.23.11",
"certificate_refs": ["app3_domain1_cert", "app3_domain2_cert", "app3_domain3_cert"],
"default_certificate_ref": "app3_default_cert",
"servers": [
"192.168.10.11",
"192.168.10.14"
]
}
}
Note:
You can only delete a certificate if it not used (referenced) by any application.
TLS Settings
You can also configure the security settings of the TLS connections such as the TLS protocol versions supported and the specific ciphers that can be negotiated between clients/servers and the NetScaler.
A simple way to set the TLS security level for your application, is to set it to "HIGH", "MEDIUM" or "LOW", which translate to settings on protocol versions and ciphers settings. For example, the following configuration sets it to HIGH.
{
"application": {
"name": "app3",
"virtual_ip": "70.122.23.11",
"default_certificate_ref": "app3_cert",
"tls_settings": {
"security_level": "HIGH",
"session_reuse": true,
"session_timeout": "48s"
},
"servers": [
"192.168.10.11",
"192.168.10.14"
]
}
}
The setting "HIGH" of the security_level attribute translates to SSL Labs A+ rating and allows only TLS-1.3 protocol version to be negotiated, as well as the fixed list of TLS-1.3 ciphers:
-
TLS1.3-AES256-GCM-SHA384
-
TLS1.3-CHACHA20-POLY1305-SHA256
The setting "MEDIUM" allows both "TLS-1.2" and "TLS-1.3" protocol versions to be negotiated.
For TLS-1.2, the following ciphers are set by default:
-
TLS1.2-AES-256-SHA256
-
TLS1.2-AES-128-SHA256
-
TLS1.2-AES256-GCM-SHA384
-
TLS1.2-AES128-GCM-SHA256
-
TLS1.2-ECDHE-RSA-AES-256-SHA384
-
TLS1.2-ECDHE-RSA-AES-128-SHA256
-
TLS1.2-ECDHE-RSA-AES256-GCM-SHA384
-
TLS1.2-ECDHE-RSA-AES128-GCM-SHA256
-
TLS1.2-ECDHE-ECDSA-AES256-SHA384
-
TLS1.2-ECDHE-ECDSA-AES128-SHA256
-
TLS1.2-ECDHE-ECDSA-AES256-GCM-SHA384
-
TLS1.2-ECDHE-ECDSA-AES128-GCM-SHA256
For TLS1.3, the following ciphers are set by default in addition to the ciphers mentioned under HIGH security_level setting:
-
TLS1.3-AES128-GCM-SHA256
The lowest setting is "LOW" and this allows "TLS-1", "TLS-1.2" and "TLS-1.3". Note that the use of TLS-1 is discouraged and is considered a weak protocol from a security perspective. So, only set to "LOW" if you have clients requiring the use of "TLS-1".
The following ciphers are set by default for "TLS-1":
-
TLS1-AES-256-CBC-SHA
-
TLS1-AES-128-CBC-SHA
-
TLS1-ECDHE-RSA-AES256-SHA
-
TLS1-ECDHE-RSA-AES128-SHA
-
TLS1-ECDHE-ECDSA-AES256-SHA
-
TLS1-ECDHE-ECDSA-AES128-SHA
-
TLS1-DHE-RSA-AES-256-CBC-SHA
-
TLS1-DHE-RSA-AES-128-CBC-SHA
-
TLS1-DHE-DSS-AES-256-CBC-SHA
-
TLS1-DHE-DSS-AES-128-CBC-SHA
For TLS1.2 and TLS1.3, default cipher list is inherited from HIGH and MEDIUM security_level settings.
Older SSL protocols (SSLv3 and below) are not supported in the Next-Gen API.
You can also configure tls_settings on a frontend. Different frontends of an application could have different TLS settings.
If you want more granular control over the protocol versions and ciphers, you can specify the settings as follows:
{
"tls_settings": {
"tls_protocols": ["TLS-1"],
"tls_cipher_suites": [
"TLS1-EXP1024-RC4-SHA",
"TLS1-EXP1024-DHE-DSS-DES-CBC-SHA",
"TLS1-EXP1024-DHE-DSS-RC4-SHA",
"TLS1-EXP1024-RC4-MD5",
"TLS1-EXP1024-RC2-CBC-MD5"
],
"session_reuse": true,
"session_timeout": "48s"
}
}
This allows you to control exactly what protocol and ciphers you want to allow, as well as configure other TLS settings such as session reuse and session timeout:
Note:
If TLS Settings are not specified for an application, the default security level configured for the application is MEDIUM.
Health Checks
One of the main functions that NetScaler provides is the ability to monitor the health of your application servers. NetScaler provides rich functionality when it comes to health monitoring, with different types of health checks based on the application protocol.
Next-Gen API makes the use of this functionality simple and straightforward. You can currently specify the following health checks:
-
PING (ICMP)
-
HTTP
A simple health check of the application servers could consist of a regular PING to the servers to check their health. This can be configured as follows:
{
"application": {
"name": "app3",
"virtual_ip": "70.122.23.11",
"default_certificate_ref": "app3_cert",
"servers": [
"192.168.10.11",
"192.168.10.14"
],
"health_check": {
"type": "PING"
}
}
}
The health check settings all have default values if not specified. For example, the regular interval of PINGs sent to the backend server will default to the value of 5 seconds. If you want to change it to a different value, you can specify it as follows:
{
"application": {
"name": "app3",
"virtual_ip": "70.122.23.11",
"default_certificate_ref": "app3_cert",
"servers": [
"192.168.10.11",
"192.168.10.14"
],
"health_check": {
"type": "PING",
"interval": "10s"
}
}
}
For the HTTP health check, any probe request that returns an HTTP status code 200 is considered a healthy response. You can for example further tailor the behavior of the health check from the default behavior by specifying other attributes:
{
"application": {
"name": "app3",
"virtual_ip": "70.122.23.11",
"protocol": "HTTPS",
"default_certificate_ref": "app3_cert",
"servers": [
"192.168.10.11",
"192.168.10.14"
],
"health_check": {
"interval": "5s",
"type": "HTTP",
"probe_request_str": "GET /health",
"probe_healthy_response": {
"status_codes": ["200-399"]
},
"num_retries_on_failure": "3",
"num_retries_on_success": "5"
}
}
}
You can also specify multiple health checks for the same backend of servers. This means that if any of the health checks fails on the backend, the application is marked down.
{
"application": {
"name": "app3",
"virtual_ip": "70.122.23.11",
"default_certificate_ref": "app3_cert",
"servers": [
"192.168.10.11",
"192.168.10.14"
],
"health_checks": [
{
"name": "ping_mon",
"type": "PING"
},
{
"name": "http_mon",
"type": "HTTP",
"interval": "5s",
"probe_request": {
"path": "/health"
}
}
]
}
}
You can explore all the health check settings by referring to the OpenAPI specification of Next-Gen API.
Rate Limiting
The rate limiting feature of NetScaler enables you to set maximum traffic loads for your application and take real-time preventive actions based on traffic rates.
Next-Gen API makes the use of this functionality simple and straightforward.
A simple rate limiting configuration for an application could involve setting a maximum number of requests allowed within a specific time period. This can be configured as follows:
{
"application": {
"name": "app3",
"virtual_ip": "70.122.23.11",
"default_certificate_ref": "app3_cert",
"servers": [
"192.168.10.11",
"192.168.10.14"
],
"rate_limit_settings": {
"name": "rate_limit_1",
"max_requests": 10,
"time_period": "100ms",
"action": "DROP"
}
}
}
In the following example, the rate limiting settings specify that a maximum of 10 requests are allowed within a 100 ms time period. If this limit is exceeded, the requests will be dropped. Additionally, you can further refine the settings to apply rate limiting specifically to requests with the URL abc.com.
{
"application": {
"name": "app3",
"virtual_ip": "70.122.23.11",
"default_certificate_ref": "app3_cert",
"servers": [
"192.168.10.11",
"192.168.10.14"
],
"rate_limit_settings": {
"name": "rate_limit_1",
"max_requests": 10,
"time_period": "100ms",
"action": "DROP",
"additional_settings": {
"selectors": [
{
"field": "URL",
"value": "abc.com"
}
]
}
}
}
}
You can also configure rate limiting to distribute the load uniformly across a 10ms time slice. In this case, if there are more than 1 request within a 10 ms window, the rate limiting action is applied. By default, the limit_type is 'BURSTY', meaning the rate limiting action is applied when the maximum number of requests is breached within the specified time period. To achieve uniform distribution, you need to set the limit_type field to 'SMOOTH'.
{
"application": {
"name": "app3",
"virtual_ip": "70.122.23.11",
"default_certificate_ref": "app3_cert",
"servers": [
"192.168.10.11",
"192.168.10.14"
],
"rate_limit_settings": {
"name": "rate_limit_1",
"max_requests": 10,
"time_period": "100ms",
"action": "DROP",
"limit_type": "SMOOTH"
}
}
}
HTTP Responder
To configure NetScaler to respond to client requests on behalf of the backend servers for certain requests, use the HTTP Responder feature.
Case 1
Using the
raw_response field, you can configure NetScaler to return a raw response for requests that match the expression specified as a filter in the http_responder field.
In the following example, NetScaler responds with a "'404' Not Found" error for any request whose URL contains the "admin" string.
{
"application": {
"name": "app3",
"virtual_ip": "70.122.23.11",
"default_certificate_ref": "app3_cert",
"servers": [
"192.168.10.11",
"192.168.10.14"
],
"http_responder": {
"name": "admin_response",
"filter": "http.request.uri contains 'admin'",
"response": {
"raw_response": "'404' Not Found"
}
}
}
}
Case 2
Using the
responder_html_page_ref field, you can configure NetScaler to return the content of an HTML page for requests that match the expression specified as a filter in the http_responder field. To do so, you must first create an HTML page by using the following request:
POST /mgmt/api/nextgen/v1/responder_html_page/page1
{
"responder_html_page": {
"name": "page1",
"content": "PGh0bWw+PGhlYWQ+PHRpdGxlPkV4YW1wbGU8L3RpdGxlPjwvaGVhZD48Ym9keT48aDE+SGVsbG8sIFdvcmxkITwvaDE+PC9ib2R5PjwvaHRtbD4="
}
}
In the following example, NetScaler responds with the HTML content in page1 for any request whose URL contains the string “admin”.
{
"application": {
"name": "app3",
"virtual_ip": "70.122.23.11",
"default_certificate_ref": "app3_cert",
"servers": [
"192.168.10.11",
"192.168.10.14"
],
"http_responder": {
"name": "admin_response",
"filter": "http.request.uri contains 'admin'",
"response": {
"responder_html_page_ref": "page1"
}
}
}
}
The HTTP Responder settings can be scoped to handle requests to the whole application, to a frontend, to a listener or to a backend.
Request Transformation and Response Transformation
NetScaler provides powerful capabilities to transform both requests and responses. This feature allows you to modify the content of HTTP requests and responses to meet specific requirements, such as URL rewriting, header manipulation, and content modification.
Example: URL Rewriting
In this example, we rewrite the URL of incoming requests from
/old-path to /new-path.
{
"application": {
"name": "app3",
"virtual_ip": "70.122.23.11",
"default_certificate_ref": "app3_cert",
"servers": [
"192.168.10.11",
"192.168.10.14"
],
"request_transform": {
"name": "admin_response",
"filter": "http.request.uri.path equals '/old-path'",
"action": "replace_url_path",
"url_path": "/new-path"
}
}
}
HTTP Settings
The HTTP protocol has evolved over the years to contain a lot of features that address performance and security needs. NetScaler being an L7 proxy, one of the popular features is the ability to have fine-grained control over the processing of HTTP protocol and client connections, what features of HTTP are enabled/disabled, and set various optimization and security settings.
The following payload shows an application that is explicitly configuring some HTTP settings under the http_config section (all the possible settings that can be configured are shown in this example)
{
"application": {
"name": "app10",
"frontends": [
{
"name": "app_frontend",
"virtual_ip": "71.122.24.21",
"listeners": [
{
"name": "secure_listener",
"port": 443,
"protocol": "HTTPS",
"default_certificate_ref": "app3_cert",
"http_to_https_redirect": true,
"http_redirect_port": 81,
"http_config": {
"name": "app_http_settings",
"safety_settings": {
"drop_invalid_requests": false,
"drop_extra_crlf_lines_after_headers": true,
"drop_http_trace_requests": false,
"drop_noncompliant_rfc7230_requests": false,
"drop_connect_requests": false,
"drop_http_header_with_extra_whitespace": false,
"drop_extra_data_exceeding_content_length": false,
"max_header_length": "24820B",
"timeout_for_requests_with_incomplete_headers": "7s",
"timeout_for_receiving_complete_requests": "10s",
"adapt_timeout_value_based_on_traffic_conditions": false,
"action_on_incomplete_requests": "DROP"
},
"optimization_settings": {
"enable_reuse_pool_of_server_connections": true,
"reuse_pool_settings": {
"min_connections_in_pool": 0,
"max_connections_in_pool": 0,
"timeout_for_idle_connections": "1hr"
},
"max_requests_per_connection": 0,
"start_cmp_on_tcp_push_flag": false
},
"allowed_protocols": {
"websocket": false,
"http2": false,
"rtsp": false
},
"http2_settings": {
"strict_cipher_selection": false,
"max_header_list_size": "24576B",
"max_frame_size": "16384B",
"max_concurrent_streams": 100,
"initial_window_size_for_connections": "65535B",
"initial_window_size_for_streams": "65535B",
"max_header_cmp_table_size": "4096B",
"min_server_connections_before_multiplexing": 20,
"max_ping_frames_per_minute": 60,
"max_settings_frames_per_minute": 15,
"max_reset_frames_per_minute": 90,
"max_empty_frames_per_minute": 60
},
"grpc_settings": {
"enable_grpc_length_delimitation": true,
"max_size_for_packet_buffering": "131072B",
"max_time_for_packet_buffering": "1s"
},
"misc_settings": {
"web_logging": true,
"generate_adc_etag_for_response_etag": false
}
}
},
{
"name": "http_listener",
"port": 80,
"protocol": "HTTP"
}
]
}
],
"backends": [
{
"name": "advert_servers",
"servers_port": 8080,
"servers": [
"192.168.10.11",
"192.168.10.14"
]
},
{
"name": "billing_servers",
"servers_port": 8080,
"servers": [
{
"ip": "192.168.11.11",
"weight": 3
},
{
"ip": "192.168.11.14"
}
]
}
],
"routes": [
{
"name": "checkout_route",
"filter": "http.request.uri contains '/checkout/'",
"frontend_ref": "app_frontend",
"listener_ref": "secure_listener",
"backend_ref": "billing_servers"
},
{
"name": "ad_route",
"filter": "http.request.uri contains '/ad/'",
"frontend_ref": "app_frontend",
"listener_ref": "http_listener",
"backend_ref": "advert_servers"
}
]
}
}
Logging
Another important aspect of configuring the NetScaler device is audit logging. To enable user-defined logging, use the following CLI command:
set syslogparams -userDefinedAuditlog YES
Logging can be integrated with various network functions such as routes, HTTP redirects, HTTP responders, request transformations, and response transformations.
In the following example, logging is incorporated as part of the HTTP responder network function:
{
"application": {
"name": "app3",
"virtual_ip": "70.122.23.11",
"default_certificate_ref": "app3_cert",
"servers": [
"192.168.10.11",
"192.168.10.14"
],
"http_responder": {
"name": "admin_response",
"filter": "http.request.uri contains 'admin'",
"response": {
"raw_response": "'404' Not Found"
},
"audit_log_ref": "log_port"
},
"audit_log_defs": [
{
"name": "log_port",
"log_level": "INFORMATIONAL",
"message": "URL={{HTTP.HOST}}{{HTTP.REQUEST.URI}} SOURCE-PORT={{HTTP.REQUEST.TCP.SRCPORT}} DESTINATION-PORT={{HTTP.REQUEST.TCP.DSTPORT}}"
}
]
}
}
Wireshark Expressions
NetScaler features a powerful policy infrastructure language called Policy Infrastructure eXpression Language (PIXL) that allows for expressing rich filters on traffic in order to select a subset of traffic. Then various optimizations and security features available on the NetScaler can be applied to that subset.
In NetScaler configuration through CLI, Nitro API or NetScaler GUI, PIXL expressions are used in NetScaler policy rules and actions. The PIXL language flexibility and richness comes at the cost of ease of use, as users need to learn the syntax and structure of this language. For example, if we want to select HTTP URLs whose path start with "/home", we would need to write the following PIXL expression:
HTTP.REQ.URL.HOSTNAME.EQ("www.cloud.com")
Or if we want to select requests for which the user-agent header contains a certain string, the PIXL expression is going to be slightly more involved:
HTTP.REQ.HEADER("user-agent").CONTAINS("mobile")
In order to provide an easier language for filtering networking traffic in Next-Gen API, we adopted the Wireshark display filters language, which is more intuitive and well familiar to many networking professionals. For example, both examples above can be expressed respectively using the following 2 Wireshark expressions :
http.host == "www.cloud.com"
or
http.host eq "www.cloud.com"
and
http.request.header.user-agent contains "mobile"
This relative simplicity is more apparent when the expression requires combining multiple conditions with "and" and "or" logical operators. The following PIXL expression:
HTTP.REQ.URL.HOSTNAME.EQ("www.cloud.com") && HTTP.REQ.HEADER("user-agent").CONTAINS("mobile")
can be expressed as a Wireshark filter expression more simply:
http.host == "www.cloud.com" and http.request.header.user-agent contains "mobile"
If we want to compare regardless of case sensitivity, we can use the lower() or upper() helper functions as follows:
lower(http.host) == "www.cloud.com" and upper(http.request.header.user-agent) contains "MOBILE"
Note:
Currently, http.request expression with following attributes is supported:
-
Request Hostname (http.host)
-
Request Whole URL (http.request.uri)
-
Request URL Path (http.request.uri.path)
-
Request URL Query String (http.request.uri.query)
-
Request HTTP Method (http.request.method)
-
Request HTTP Cookie (http.request.header.cookie),
-
Request HTTP Headers (http.request.header.\<header-name>)
In terms of operators that can be used in expressions, the following operators are supported:
-
Equality: eq, ==
-
Inequality: ne, !=
-
Greater or Equal: >=, ge
-
Lesser or Equal: <=, le
-
Greater: >, gt
-
Lesser: <, lt
-
Substring test: contains
-
Substring test: startswith
-
Substring test: endswith
-
Converting to uppercase: upper
-
Converting to lowercase: lower
-
Logical AND: and
-
Logical OR: or
When we need to compare a field for a match against multiple values, one way to do this would be:
http.host == "www.site1" or http.host == "www.site2" or http.host == "www.site3"
This can lead to large and complex wireshark expressions if the list of values is large. Next-Gen API introduces an extension to wireshark expressions that allows you to do the following:
http.host equals_any valid_hostnames
Where valid_hostnames is a value set. Value sets are equivalent in function to NetScaler Patsets and Datasets use in Policy Expressions.
You can create value sets in Next-Gen API using the resource: /mgmt/api/nextgen/v1/filters/value_sets
For example, the following API creates the value set valid_hostnames that was used in the previous wireshark expression:
POST /mgmt/api/nextgen/v1/filters/value_sets
{
"value_set": {
"name": "valid_hostnames",
"type": "string",
"values": [
"www.site1",
"www.site2",
"www.site3"
]
}
}
The type attribute of a value set can take 4 possible values: string, number, ipv4, ipv6.
In wireshark expressions, the value sets use is possible through the following operators:
-
equals_any
-
contains_any
-
startswith_any
-
endswith_any
For users who prefer using NetScaler PIXL expressions, they can still do so by setting the attribute "filter_format" to "pixl". For example, the following configuration for an HTTP Responder uses PIXL rather a Wireshark expression:
{
"http_responder": {
"name": "admin_response",
"filter": "HTTP.REQ.URL.PATH_AND_QUERY.CONTAINS(\"admin\")",
"filter_format": "pixl",
"response": "'404' Not Found"
}
}
Which is equivalent to the following configuration that uses the wireshark filter expressions:
{
"http_responder": {
"name": "admin_response",
"filter": "http.request.uri contains 'admin'",
"response": "'404' Not Found"
}
}
Note:
Currently, when you use PIXL expressions in your API, Next-Gen API cannot validate these expressions until they are installed on the NetScaler data plane. This means that you have to query the config status to ensure that your PIXL expressions are valid and that the application configuration has been successfully accepted by the data plane.
HTTP Callouts
HTTP callouts allow NetScaler to send HTTP or HTTPS requests to an external application when specific criteria are met during policy evaluation. Using HTTP callouts, you can do the following tasks: stall policy evaluation, retrieve information, update databases, or modify web server content. To configure an HTTP callout, set up an application (HTTP callout agent) on the server to respond to the callout request, ensuring consistent response formats. Then, configure the HTTP callout on NetScaler as shown below:
POST /mgmt/api/nextgen/v1/http_callouts/is_ip_allowed
{
"http_callout": {
"name": "is_ip_allowed",
"callout_request": {
"method": "POST",
"scheme": "HTTPS",
"host": "1.2.3.4",
"port": 443,
"path_expression": "/check_valid_ip",
"headers": [
{
"name": "Version",
"value_expression": "1.0.0"
},
{
"name": "Content-Type",
"value_expression": "application/json"
},
{
"name": "api-key",
"value_expression": "8395-3c22-abj4-0a29"
}
],
"body_expression": "{\"client_ip\": \"{{http.request.ip.src}}\"}"
},
"callout_response": {
"return_value_expression": "http.response.code == 200",
"return_value_datatype": "boolean",
"cache_duration": "1min"
}
}
}
The HTTP callout can be used in filter expressions as shown below:
{
"http_responder": {
"name": "admin_response",
"filter": NOT HTTP_CALLOUT(is_ip_allowed),
"response": {
"raw_response": "'404' Not Found"
}
}
}
Application Health
To get the health of an application, use the following API call:
GET /mgmt/api/nextgen/v1/applications/{application-name}/health
This API call retrieves the health status of the specified application. The response includes the configured and operational states of the application, its frontends, listeners, backends, and servers. The response format differs according to the application types. Application's state is determined by the frontend & backend states. If there is at least one route where the frontend and backend are UP, then the app's
operational_state is marked as UP
Here is an example request and response for an application with multiple backends.
Example Request
GET /mgmt/api/nextgen/v1/applications/my_app/health
Example Response
{
"application": {
"name": "my_app",
"virtual_ip": "70.122.23.11",
"configured_state": "ENABLED",
"operational_state": "UP",
"backends": [
{
"name": "be1",
"configured_state": "ENABLED",
"operational_state": "UP",
"servers": [
{
"ip": "10.102.201.166",
"port": 80,
"configured_state": "ENABLED",
"operational_state": "UP"
},
{
"ip": "10.102.201.167",
"port": 80,
"configured_state": "ENABLED",
"operational_state": "UP"
}
]
},
{
"name": "be2",
"configured_state": "ENABLED",
"operational_state": "UP",
"servers": [
{
"ip": "10.102.201.70",
"port": 81,
"configured_state": "ENABLED",
"operational_state": "UP",
"health_checks": [
{
"name": "http_monitor",
"operational_state": "UP",
"total_probes": 518,
"failed_probes": 0,
"last_response_status": "Success - HTTP response code 200 received.",
"last_response_time": "0.683ms"
}
]
}
]
}
]
}
}
Application Statistics
To get the statistics of an application, use the following API call:
GET /mgmt/api/nextgen/v1/applications/{application-name}/statistics
The response includes the statistics of the application, its frontends, listeners, backends, and servers. The response format differs according to the application types.
Here is an example request and response for an application with multiple backends.
Example Request
GET /mgmt/api/nextgen/v1/applications/my_app/statistics
Example Response
{
"application": {
"name": "my_app",
"virtual_ip": "70.122.23.11",
"configured_state": "ENABLED",
"operational_state": "UP",
"hits": 23,
"hits_per_sec": 0,
"requests": 23,
"requests_per_sec": 0,
"responses": 23,
"responses_per_sec": 0,
"request_bytes": 16748,
"request_bytes_per_sec": 0,
"response_bytes": 295156,
"response_bytes_per_sec": 0,
"packets_rcvd": 199,
"packets_rcvd_per_sec": 0,
"packets_sent": 307,
"packets_sent_per_sec": 0,
"current_client_connections": 1,
"current_client_est_connections": 0,
"current_server_connections": 0,
"current_persistence_sessions": 0,
"current_backup_persistence_sessions": 0,
"spill_over_hits": 0,
"labeled_connection": 0,
"push_labeled_connection": 0,
"deferred_request": 0,
"deferred_request_per_sec": 0,
"invalid_request_or_response": 0,
"invalid_request_or_response_dropped": 0,
"down_backup_hits": 0,
"current_multipath_tcp_sessions": 0,
"current_multipath_tcp_subflows": 0,
"listeners": [
{
"name": "https_listener",
"protocol": "HTTPS",
"port": 443,
"configured_state": "ENABLED",
"operational_state": "UP",
"hits": 0,
"hits_per_sec": 0,
"requests": 0,
"requests_per_sec": 0,
"responses": 0,
"responses_per_sec": 0,
"request_bytes": 4740,
"request_bytes_per_sec": 0,
"response_bytes": 6064,
"response_bytes_per_sec": 0,
"packets_rcvd": 22,
"packets_rcvd_per_sec": 0,
"packets_sent": 22,
"packets_sent_per_sec": 0,
"current_client_connections": 0,
"current_client_est_connections": 0,
"current_server_connections": 0,
"current_persistence_sessions": 0,
"current_backup_persistence_sessions": 0,
"spill_over_threshold": 0,
"spill_over_hits": 0,
"labeled_connection": 0,
"push_labeled_connection": 0,
"deferred_request": 0,
"deferred_request_per_sec": 0,
"invalid_request_or_response": 0,
"invalid_request_or_response_dropped": 0,
"down_backup_hits": 0,
"current_multipath_tcp_sessions": 0,
"current_multipath_tcp_subflows": 0,
"apdex_for_client_response_times": 1,
"average_client_ttlb": 0
},
{
"name": "http_listener",
"protocol": "HTTP",
"port": 80,
"configured_state": "ENABLED",
"operational_state": "UP",
"hits": 23,
"hits_per_sec": 0,
"requests": 23,
"requests_per_sec": 0,
"responses": 23,
"responses_per_sec": 0,
"request_bytes": 12008,
"request_bytes_per_sec": 0,
"response_bytes": 289092,
"response_bytes_per_sec": 0,
"packets_rcvd": 177,
"packets_rcvd_per_sec": 0,
"packets_sent": 285,
"packets_sent_per_sec": 0,
"current_client_connections": 1,
"current_client_est_connections": 0,
"current_server_connections": 0,
"current_persistence_sessions": 0,
"current_backup_persistence_sessions": 0,
"spill_over_threshold": 0,
"spill_over_hits": 0,
"labeled_connection": 0,
"push_labeled_connection": 0,
"deferred_request": 0,
"deferred_request_per_sec": 0,
"invalid_request_or_response": 0,
"invalid_request_or_response_dropped": 0,
"down_backup_hits": 0,
"current_multipath_tcp_sessions": 0,
"current_multipath_tcp_subflows": 0,
"apdex_for_client_response_times": 1,
"average_client_ttlb": 0
}
],
"backends": [
{
"name": "colddrinks",
"configured_state": "ENABLED",
"operational_state": "UP",
"hits": 10,
"hits_per_sec": 0,
"requests": 10,
"requests_per_sec": 0,
"responses": 10,
"responses_per_sec": 0,
"request_bytes": 5170,
"request_bytes_per_sec": 0,
"response_bytes": 287415,
"response_bytes_per_sec": 0,
"http2_requests": 0,
"http2_requests_per_sec": 0,
"http2_responses": 0,
"http2_responses_per_sec": 0,
"packets_rcvd": 72,
"packets_rcvd_per_sec": 0,
"packets_sent": 226,
"packets_sent_per_sec": 0,
"current_client_connections": 0,
"current_client_est_connections": 0,
"current_server_connections": 0,
"current_persistence_sessions": 0,
"current_backup_persistence_sessions": 0,
"requests_in_surge_queue": 0,
"spill_over_threshold": 0,
"spill_over_hits": 0,
"labeled_connection": 0,
"push_labeled_connection": 0,
"deferred_request": 0,
"deferred_request_per_sec": 0,
"invalid_request_or_response": 0,
"invalid_request_or_response_dropped": 0,
"down_backup_hits": 0,
"current_multipath_tcp_sessions": 0,
"current_multipath_tcp_subflows": 0,
"apdex_for_client_response_times": 1,
"average_client_ttlb": 0,
"num_tcpconn_reasmq_75%_reached": 0,
"num_tcpconn_reasmq_flushed": 0,
"num_server_busy_error": 0,
"num_server_busy_error_per_sec": 0,
"request_retry_count": 0,
"max_retry_count_exceeded": 0,
"servers": [
{
"ip": "10.146.105.23",
"port": 80,
"configured_state": "ENABLED",
"operational_state": "UP",
"health_checks": [
{
"name": "http_monitor",
"operational_state": "UP",
"total_probes": 141,
"failed_probes": 0,
"last_response_status": "Success - HTTP response code 200 received.",
"last_response_time": "0.008ms"
}
],
"average_server_ttfb": 0,
"requests": 145,
"requests_per_sec": 0,
"responses": 145,
"responses_per_sec": 0,
"request_bytes": 11163,
"request_bytes_per_sec": 17,
"response_bytes": 40076205,
"response_bytes_per_sec": 81786,
"current_client_connections": 0,
"requests_in_surge_queue": 0,
"current_server_connections": 11,
"current_server_est_connections": 1,
"connection_reuse_pool": 1,
"num_tcpconn_reasmq_75%_reached": 0,
"num_tcpconn_reasmq_flushed": 0
},
{
"ip": "10.146.105.24",
"port": 80,
"configured_state": "ENABLED",
"operational_state": "UP",
"health_checks": [
{
"name": "http_monitor",
"operational_state": "UP",
"total_probes": 141,
"failed_probes": 0,
"last_response_status": "Success - HTTP response code 200 received.",
"last_response_time": "0.657ms"
}
],
"average_server_ttfb": 0,
"requests": 145,
"requests_per_sec": 0,
"responses": 145,
"responses_per_sec": 0,
"request_bytes": 11111,
"request_bytes_per_sec": 17,
"response_bytes": 40362330,
"response_bytes_per_sec": 81786,
"current_client_connections": 0,
"requests_in_surge_queue": 0,
"current_server_connections": 10,
"current_server_est_connections": 0,
"connection_reuse_pool": 0,
"num_tcpconn_reasmq_75%_reached": 0,
"num_tcpconn_reasmq_flushed": 0
}
]
},
{
"name": "hotdrinks",
"configured_state": "ENABLED",
"operational_state": "UP",
"hits": 13,
"hits_per_sec": 0,
"requests": 13,
"requests_per_sec": 0,
"responses": 13,
"responses_per_sec": 0,
"request_bytes": 6838,
"request_bytes_per_sec": 0,
"response_bytes": 1677,
"response_bytes_per_sec": 0,
"http2_requests": 0,
"http2_requests_per_sec": 0,
"http2_responses": 0,
"http2_responses_per_sec": 0,
"packets_rcvd": 13,
"packets_rcvd_per_sec": 0,
"packets_sent": 13,
"packets_sent_per_sec": 0,
"current_client_connections": 0,
"current_client_est_connections": 0,
"current_server_connections": 0,
"current_persistence_sessions": 0,
"current_backup_persistence_sessions": 0,
"requests_in_surge_queue": 0,
"spill_over_threshold": 0,
"spill_over_hits": 0,
"labeled_connection": 0,
"push_labeled_connection": 0,
"deferred_request": 0,
"deferred_request_per_sec": 0,
"invalid_request_or_response": 0,
"invalid_request_or_response_dropped": 0,
"down_backup_hits": 0,
"current_multipath_tcp_sessions": 0,
"current_multipath_tcp_subflows": 0,
"apdex_for_client_response_times": 1,
"average_client_ttlb": 0,
"num_tcpconn_reasmq_75%_reached": 0,
"num_tcpconn_reasmq_flushed": 0,
"num_server_busy_error": 0,
"num_server_busy_error_per_sec": 0,
"request_retry_count": 0,
"max_retry_count_exceeded": 0,
"servers": [
{
"ip": "10.146.105.25",
"port": 80,
"configured_state": "ENABLED",
"operational_state": "UP",
"health_checks": [
{
"name": "http_monitor",
"operational_state": "UP",
"total_probes": "141",
"failed_probes": "0",
"last_response_status": "Success - HTTP response code 200 received.",
"last_response_time": "0.766ms"
}
],
"average_server_ttfb": 0,
"requests": 153,
"requests_per_sec": 0,
"responses": 153,
"responses_per_sec": 0,
"request_bytes": 15378,
"request_bytes_per_sec": 17,
"response_bytes": 93020897,
"response_bytes_per_sec": 189835,
"current_client_connections": 0,
"requests_in_surge_queue": 0,
"current_server_connections": 9,
"current_server_est_connections": 0,
"connection_reuse_pool": 0,
"num_tcpconn_reasmq_75%_reached": 0,
"num_tcpconn_reasmq_flushed": 0
}
]
}
]
}
}