The Avi Load Balancer continually assesses the health of each virtual service. This health information is available for viewing in both summary and detailed form.
Each virtual service has a health score, which shows the virtual service health as both a color code and a set of numeric scores. The final health score is comprised of a positive performance score and three penalties.
The security penalty provides insight into a current security related issue (such as a current DoS attack) or potential risk (such as SSL configuration which leaves the site vulnerable to the POODLE attack).
Ideally, the security penalty must be zero, which means that it is not detracting from the health or risk of a virtual service. A non-zero security penalty can be due to an issue with SSL or a DDoS attack event. The following section explores the components that could generate a security penalty.
View Security Insights
To view a security insights for a virtual service:
Click the icon of the virtual service shown on the Dashboard.
Click the virtual service name.
Click Security on the menu bar.
Detailed security information for the virtual service is shown in two panes:
SSL information (left pane)
DDoS information (right pane)
Security Insights for the virtual service are organized into the following main categories:
SSL Distribution: The SSL section in the default security page shows details of the most relevant SSL data about client connections terminated on SEs within the selected period of time. If SSL termination is not performed on the virtual service, this section will have no data.
SSL Score: The SSL Score section in the default security page shows details of major factors affecting the SSL Score.
DDoS: The DDoS section in the default security page breaks down distributed denial of service data for the virtual service into the most relevant layer 4 and layer 7 attack data.
For more information on DDOS attack mitigation, Rate Limiters and Datascripts, see DDoS Attack Mitigation topic in the VMware Avi Load BalancerConfiguration Guide.
Rate Shaping and Throttling Options
The Avi Load Balancer includes many options for rate shaping and throttling of traffic. This can be applied at the virtual service, pool-server, or client level. These options exist in many places throughout the UI, depending on the specific object they are applied against. Additionally, DataScripts can be used to create customized limits.
Virtual Service Limits
Within the tab, the following options allow specifying limits to connections and requests for the specific virtual service.
Rate Limit Number of New TCP Connections: Set the maximum Threshold of new connections from all clients that can be created for this virtual service over the configured period. Though the Report action generates logs for excessive connections, it allows them to proceed as normal. Drop SYN silently discards the client SYN, and RST sends a connection reset back to the client.
Rate Limit Number of New HTTP Requests: Set the maximum Threshold of HTTP requests from all clients for this virtual service over the configured period. Though the Report action generates logs for excessive requests, it allows them to proceed as normal. Close TCP Connection sends a connection RST to the client. Send Local Response allows the Avi Load Balancer to respond with a simple web page and appropriate status code. Send HTTP Redirect forwards excessive requests to another URI or destination.
Max Throughput: Specify the maximum amount of bandwidth for the virtual service in bits per second for each SE. For instance, if the virtual service is scaled-out to 3 SE, each SE throttles after 1Gbps, effectively making it 3 Gbps in total. So, throughput also scales horizontally when the virtual service is placed on more number of SE. Traffic that exceeds this limit will be discarded and might require retransmission by either the client or server. When this limit is set, the Analytics tab of the Virtual Service Details page shows a dashed horizontal line on the Throughput metric chart that shows the current throughput versus the maximum allowed throughput.
Max Concurrent Connections: Specify the maximum number of concurrent open connections. Connection attempts that exceed this number are either reset (TCP) or dropped (UDP) until the total number of concurrent connections falls below the threshold. When this limit is set, the Analytics tab of the Virtual Service Details page shows a dashed horizontal line on the Open Connections metric chart that shows the current open connections versus the maximum number of allowed connections.
Server Pool Limits
Within the tab, the following option can be used to set server concurrent connection limits.
Max Connections per Server: Specify the maximum number of concurrent connections allowed for a server. If all servers in the Pool reach this maximum limit, then the virtual service sends a reset for TCP connections or silently discard new UDP streams unless explicitly specified in the Server Down Settings described above. As soon as an existing connection to the server is closed, that server is eligible to receive the next client connection. Valid values are 0, which disables the connection limit or any number from 50 to 10,000.
Client Limits
Within the tab, create a new policy with the action set to rate limit.
Rate Limit: Restrict clients from opening greater than the specified number of connections per second in the Maximum Rate field. Clients that exceed this number will have their excessive connection attempts silently discarded. If Burst Size is enabled, clients can burst above the Max Rate ,provided that they have not recently been opening connections. This feature can be applied to TCP or UDP. All clients that match the Match criteria are treated as one bucket. For instance, if no Match is defined, all IP addresses increment the Max Rate counter. Throttling occurs for all new connecting clients. Individual limits can be applied to separate networks, geographies, or IP and port criteria.
Within the tab, a number of options are available through the drop-down menu from the Rate Limit HTTP and TCP Settings.
Rate Limit Connections from a Client: Rate limit all connections made from any single client IP address to the virtual service.
Rate Limit Requests from a Client to all URLs: Rate limit all HTTP requests from any single client IP address to all URLs of the virtual service.
Rate Limit Requests from all Clients to a URL: Rate limit all HTTP requests from all client IP addresses to any single URL.
Rate Limit Requests from a Client to a URL: Rate limit all HTTP requests from any single client IP address to any single URL.
Rate Limit Failed Requests from a Client to all URLs: Rate limit all requests from a client for a specified period of time once the count of failed requests from that client crosses a threshold for that period. Clients are tracked based on their IP address. Requests are deemed failed based on client or server side error status codes, consistent with how the Avi Load Balancer logs and metrics subsystems mark failed requests.
Rate Limit Requests from all Clients to a URL: Rate limit all requests to a URI for a specified period once the count of failed requests to that URI crosses a threshold for that period. Requests are deemed failed based on client or server side error status codes, consistent with how the Avi Load Balancer logs and metrics subsystems mark failed requests.
Rate Limit Failed Requests from a Client to a URL: Rate limit all requests from a client to a URI for a specified period once the count of failed requests from that client to the URI crosses a threshold for that period. Requests are deemed failed based on client or server side error status codes, consistent with how the Avi Load Balancer logs and metrics subsystems mark failed requests.
Rate Limit Scans from a Client to all URLs: Automatically track clients and classify them into three groups: Good, Bad, and Unknown. Clients are tracked based on their IP address. Clients are added to the Good group when the Avi Load Balancer scan detection system builds history of requests from the clients that complete successfully. Clients are added to the Unknown group when there is insufficient history about them. Clients with history of failed requests are added to the Bad group and their requests are rate limited with stricter thresholds than the Unknown clients group. The Avi Load Balancer scan detection system automatically tunes itself to make the Good, Bad, and Unknown client IPs group members change dynamically with changes in traffic patterns through the ADC. In other words, if a change to the website causes mass failures (such as 404 errors) for most customers, the Avi Load Balancer adapts and does not mark all clients as attempting to scan the site.
Rate Limit Scans from all Clients to all URLs: Similar to the previous limit, but restricts the scanning from all clients as a single entity rather than individually. Once a limit is collectively reached by all clients, any client that sends the next failed request is reset.
Rate-Limiting Clients Based on Header or Cookie: The Avi Load Balancer can rate-limit clients based on a header or cookie. The Avi Load Balancer tracks the number of requests that have been seen for the header or cookie value. If the specified threshold value is exceeded, the client is rate-limited.
