Binding of a LBPool and Group to a LBVirtualServer
Binding of a LBPool and Group to a LBVirtualServer
used to route application traffic passing through load balancers.
LBRule uses match conditions to match application traffic passing
through a LBVirtualServer using HTTP or HTTPS. Can bind
multiple LBVirtualServers to a Group. Each LBRule
consists of two optional match conditions, each match contidion defines a
criterion for application traffic. If no match conditions are
specified, then the LBRule will always match and it is used
typically to define default rules. If more than one match condition is
specified, then matching strategy determines if all conditions should
match or any one condition should match for the LBRule to be
considered a match. A match indicates that the LBVirtualServer
should route the request to the Group (parent of LBRule).
| Name | Description | Type | Notes |
|---|---|---|---|
| actions | Actions to be executed A list of actions to be executed at specified phase when load balancer rule matches. The actions are used to manipulate application traffic, such as rewrite URI of HTTP messages, redirect HTTP messages, etc. |
array of LBRuleAction (Abstract type: pass one of the following concrete types) LBConnectionDropAction LBHttpRedirectAction LBHttpRejectAction LBHttpRequestHeaderDeleteAction LBHttpRequestHeaderRewriteAction LBHttpRequestUriRewriteAction LBHttpResponseHeaderDeleteAction LBHttpResponseHeaderRewriteAction LBJwtAuthAction LBSelectPoolAction LBSslModeSelectionAction LBVariableAssignmentAction LBVariablePersistenceLearnAction LBVariablePersistenceOnAction |
Required Maximum items: 60 |
| display_name | Display name for LBRule A display name useful for identifying an LBRule. |
string | |
| match_conditions | Conditions to match application traffic A list of match conditions used to match application traffic. Multiple match conditions can be specified in one load balancer rule, each match condition defines a criterion to match application traffic. If no match conditions are specified, then the load balancer rule will always match and it is used typically to define default rules. If more than one match condition is specified, then match strategy determines if all conditions should match or any one condition should match for the load balancer rule to considered a match. |
array of LBRuleCondition (Abstract type: pass one of the following concrete types) LBHttpRequestBodyCondition LBHttpRequestCookieCondition LBHttpRequestHeaderCondition LBHttpRequestMethodCondition LBHttpRequestUriArgumentsCondition LBHttpRequestUriCondition LBHttpRequestVersionCondition LBHttpResponseHeaderCondition LBHttpSslCondition LBIpHeaderCondition LBSslSniCondition LBTcpHeaderCondition LBVariableCondition |
Maximum items: 60 |
| match_strategy | Match strategy for determining match of multiple conditions If more than one match condition is specified, then matching strategy determines if all conditions should match or any one condition should match for the LB Rule to be considered a match. - ALL indicates that both host_match and path_match must match for this LBRule to be considered a match. - ANY indicates that either host_match or patch match may match for this LBRule to be considered a match. |
string | Enum: ALL, ANY Default: "ANY" |
| phase | Load balancer processing phase Each load balancer rule is used at a specific phase of load balancer processing. Currently five phases are supported, HTTP_REQUEST_REWRITE, HTTP_FORWARDING, HTTP_RESPONSE_REWRITE, HTTP_ACCESS and TRANSPORT. When an HTTP request message is received by load balancer, all HTTP_REQUEST_REWRITE rules, if present are executed in the order they are applied to virtual server. And then if HTTP_FORWARDING rules present, only first matching rule's action is executed, remaining rules are not checked. HTTP_FORWARDING rules can have only one action. If the request is forwarded to a backend server and the response goes back to load balancer, all HTTP_RESPONSE_REWRITE rules, if present, are executed in the order they are applied to the virtual server. In HTTP_ACCESS phase, user can define action to control access using JWT authentication. In TRANSPORT phase, user can define the condition to match SNI in TLS client hello and define the action to do SSL end-to-end, SSL offloading or SSL passthrough using a specific load balancer server pool. |
string | Enum: HTTP_REQUEST_REWRITE, HTTP_FORWARDING, HTTP_RESPONSE_REWRITE, HTTP_ACCESS, TRANSPORT Default: "HTTP_FORWARDING" |