You can use administrative tasks to configure HTTP or Session Initiation Protocol (SIP) rules
for the on demand router (ODR) routing policy.
The following rules are the preferred way to configure routing
policies, but you can also configure multi-cluster routing policy
(MCRP) custom properties. See Configuring the on demand router for multi-cluster failover
and load balancing routing
for
more information.
One advantage of using the following rules to configure routing
policies is you can use an expression to determine which requests
are affected by the policy, whereas MCRP custom properties only allow
filtering by an application or an application's Web module. Another
advantage of using these rules is you can select the target (routingLocations)
by cluster, server, or Web module as opposed to selecting the target
by cluster only.
You can specify
SIP or HTTP
protocols in the commands.
addRoutingRule
The
addRoutingRule command adds a routing policy rule.
Required parameters
- -protocol
- Specifies the name of the protocol to associate with a rule. (String,
required)
- -priority
- Positive integer value representing the priority of a rule. Zero
is the highest priority. (String, required)
- -expression
- Specifies the rule expression. The expression must be enclosed
in double quotes. For more information about specifying the parameters
for the rule expression, refer to the SIP
operands topic and the HTTP operands topic. (String, required)
- -actionType
- Specifies the type of action to associate with a rule. (String,
required)
The following list contains the types of actions to associate
with HTTP rules:
- permit: Permit routing to servers not in
a maintenance mode.
- redirect: Redirect the request to the URL
specified by the redirectURL option.
- reject: Reject routing with return code
specified by the errorcode option.
- permitsticky: Permit routing to servers
not in maintenance mode and perform active affinity; that is, affinity
is always preserved even when not requested by the application.
- permitMM: Permit routing to servers in
maintenance mode.
- permitstickyMM: Permit routing to servers
in maintenance mode and perform active affinity.
The following list contains the types
of actions to associate with SIP rules:
- permit: Permit routing to
- reject: Reject routing with return code
Optional parameters
- -odrname
- Specifies the name of the ODR to which the routing policy work
class applies. The -odrname parameter is required
only if you modify an ODR.
- -nodename
- Specifies the name of the node on which the ODR resides. The -nodename parameter
is required only if you modify an ODR.
- -clustername
- Specifies the name of the cluster to which the rule applies. The -clustername parameter
is required only if you modify an ODR cluster.
- -multiclusterAction
- Specifies the method to route requests if multiple routing location
clusters are matched. The -multiclusterAction parameter
applies to any of the permit actionTypes, and is required only if actionType is
equal to permit, permitsticky, permitMM,
or permitstickyMM.
- Failover: Find the first cluster with an
available server and load balance across that cluster. The order of
a dynamically generated list of clusters is undefined.
- WRR: Weighted Round Robin load balance.
For UDP retransmission, maintain affinity.
- WLOR: Weighted least outstanding request.
Best practice: The recommendation is to use the
WLOR value
instead of the
WRR value.
bprac
The following list contains the possible
values for SIP rules:
- Failover: Find the first cluster with an
available server and load balance across that cluster. The order of
a dynamically generated list of clusters is undefined.
- WRR: Weighted Round Robin load balance.
For UDP retransmission, maintain affinity.
- Error: If there are multiple clusters,
to select from it throws an error. It expects one and only one cluster.
- -routingLocations
- Specifies a list of target locations to route requests. The -routingLocations parameter
is required only if actionType is equal to any
of the permit actionTypes.
Each operand in
the list follows one of three formats, and can contain a wildcard
* value, which matches any value:
- cluster=cellName/clusterName
- server=cellName/nodeName/serverName
- module=cellName/applicationName/applicationVersion/moduleName
With SIP routing rules only, you can
alternatively define target clusters through a rule expression. The
valid operators are AND, OR, NOT and parenthetical grouping. Format
according to the following list:
- cluster=cellName/clusterName
- server=cellName/nodeName/serverName
- modules=cellName/applicationName/applicationVersion/moduleName
- server maintenance mode=true or false
- node maintenance mode=true or false
- protocol=PROTO_VALUE:
- PROTO_SIP = sip
- SIP over TCP
- PROTO_SIPS = sips
- SIP over SSL and TCP
- PROTO_SIPU = sipu
- SIP over UDP
- PROTO_SIPX = sipx
- SIP over XMEM
Note: For applications that have no applicationVersion value,
leave the applicationVersion value blank: module=cellName/application//moduleName.
- -errorcode
- Integer error code to reject request. The -errorcode parameter
is required only if actionType is equal to reject.
Batch mode example
usage
The following example shows a failover of all applications
in a cell to a generic server cluster that points to another cell:
- Using Jacl:
$AdminTask addRoutingRule {-odrname odr -nodename node1 -protocol SIP -priority 0 -expression "request.method = 'getOperation'" -actionType permit -multiclusterAction Failover -routingLocations cluster=*/*}
- Using Jython string:
AdminTask.addRoutingRule('[-odrname odr -nodename node1 -protocol HTTP -priority 0 -expression "request.method = \'INVITE\'" -actionType permit -multiclusterAction Failover -routingLocations "module=*/*/*/*,cluster=myCell/myFailoverGSCThatPointsToAnotherCell"]')
![[Version 6.1.1 and later]](../images/v611x.gif)
The following example creates a MCRP
rule for a new application edition. If you have MCRP rules defined
for existing application editions, you must create and define a new
MCRP rule for each new edition. MCRP rules apply only to specific
editions as opposed to all of the editions for an application.
- Using Jacl:
$AdminTask addRoutingRule {-odrname odr -nodename node1 -protocol HTTP -priority 0 -expression "uri LIKEIN {'/contextRoot','/contextRoot/%'}" -actionType permit -multiclusterAction Failover -routingLocations cluster=cellName/clusterName}
- Using Jython string:
AdminTask.addRoutingRule('[-odrname odr -nodename node1 -protocol HTTP -priority 0 -expression "uri LIKEIN ('/contextRoot','/contextRoot/%')" -actionType permit -multiclusterAction Failover -routingLocations cluster=cellName/clusterName]')
Interactive mode example usage
- Using Jacl:
$AdminTask addRoutingRule {-interactive}
- Using Jython string:
AdminTask.addRoutingRule ('[-interactive]')
changeRoutingDefaultRulesAction
The
changeRoutingDefaultRulesAction command changes the routing policy
default action for a rule.
Required
parameters
- -protocol
- Specifies the name of the protocol to associate with a rule. (String,
required)
Optional parameters
- -odrname
- Specifies the name of the ODR to which the routing policy work
class applies. The -odrname parameter is required
only if you modify an ODR.
- -nodename
- Specifies the name of the node on which the ODR resides. The -nodename parameter
is required only if you modify an ODR.
- -clustername
- Specifies the name of the cluster to which the rule applies. The -clustername parameter
is required only if you modify an ODR cluster.
- -multiclusterAction
- Specifies the method to route requests if multiple routing location
clusters are matched. The -multiclusterAction parameter
applies to any of the permit actionTypes, and is required only if actionType is
equal to permit, permitsticky, permitMM,
or permitstickyMM.
- Failover: Find the first cluster with an
available server and load balance across that cluster. The order of
a dynamically generated list of clusters is undefined.
- WRR: Weighted Round Robin load balance.
For UDP retransmission, maintain affinity.
- WLOR: Weighted least outstanding request.
Best practice: The recommendation is to use the
WLOR value
instead of the
WRR value.
bprac
The following list contains the possible
values for SIP rules:
- Failover: Find the first cluster with an
available server and load balance across that cluster. The order of
a dynamically generated list of clusters is undefined.
- WRR: Weighted Round Robin load balance.
For UDP retransmission, maintain affinity.
- Error: If there are multiple clusters,
to select from it throws an error. it expects one and only one cluster.
- -routingLocations
- Specifies a list of target locations to route requests. The -routingLocations parameter
is required only if actionType is equal to any
of the permit actionTypes.
Each operand in
the list follows one of three formats, and can contain a wildcard
* value, which matches any value:
- cluster=cellName/clusterName
- server=cellName/nodeName/serverName
- module=cellName/applicationName/applicationVersion/moduleName
With SIP routing rules only, you can
alternatively define target clusters through a rule expression. The
valid operators are AND, OR, NOT and parenthetical grouping. Format
according to the following list:
- cluster=cellName/clusterName
- server=cellName/nodeName/serverName
- modules=cellName/applicationName/applicationVersion/moduleName
- server maintenance mode=true or false
- node maintenance mode=true or false
- protocol=PROTO_VALUE:
- PROTO_SIP = sip
- SIP over TCP
- PROTO_SIPS = sips
- SIP over SSL and TCP
- PROTO_SIPU = sipu
- SIP over UDP
- PROTO_SIPX = sipx
- SIP over XMEM
Note: For applications that have no applicationVersion value,
leave the applicationVersion value blank: module=cellName/application//moduleName.
- -errorcode
- Integer error code to reject request. The -errorcode parameter
is required only if actionType is equal to reject.
Batch mode example
usage
Interactive mode example usage
- Using Jacl:
$AdminTask changeRoutingDefaultRulesAction {-interactive}
- Using Jython string:
AdminTask.changeRoutingDefaultRulesAction ('[-interactive]')
changeRoutingRuleAction
The
changeRoutingRuleAction command changes a routing policy action for
a rule.
Required parameters
- -protocol
- Specifies the name of the protocol to associate with a rule. (String,
required)
- -priority
- Positive integer value representing the priority of a rule. Zero
is the highest priority. (String, required)
Optional parameters
- -odrname
- Specifies the name of the ODR to which the routing policy work
class applies. The -odrname parameter is required
only if you modify an ODR.
- -nodename
- Specifies the name of the node on which the ODR resides. The -nodename parameter
is required only if you modify an ODR.
- -clustername
- Specifies the name of the cluster to which the rule applies. The -clustername parameter
is required only if you modify an ODR cluster.
- -multiclusterAction
- Specifies the method to route requests if multiple routing location
clusters are matched. The -multiclusterAction parameter
applies to any of the permit actionTypes, and is required only if actionType is
equal to permit, permitsticky, permitMM,
or permitstickyMM.
- Failover: Find the first cluster with an
available server and load balance across that cluster. The order of
a dynamically generated list of clusters is undefined.
- WRR: Weighted Round Robin load balance.
For UDP retransmission, maintain affinity.
- WLOR: Weighted least outstanding request.
Best practice: The recommendation is to use the
WLOR value
instead of the
WRR value.
bprac
The following list contains the possible
values for SIP rules:
- Failover: Find the first cluster with an
available server and load balance across that cluster. The order of
a dynamically generated list of clusters is undefined.
- WRR: Weighted Round Robin load balance.
For UDP retransmission, maintain affinity.
- Error: If there are multiple clusters,
to select from it throws an error. it expects one and only one cluster.
- -routingLocations
- Specifies a list of target locations to route requests. The -routingLocations parameter
is required only if actionType is equal to any
of the permit actionTypes.
Each operand in
the list follows one of three formats, and can contain a wildcard
* value, which matches any value:
- cluster=cellName/clusterName
- server=cellName/nodeName/serverName
- module=cellName/applicationName/applicationVersion/moduleName
With SIP routing rules only, you can
alternatively define target clusters through a rule expression. The
valid operators are AND, OR, NOT and parenthetical grouping. Format
according to the following list:
- cluster=cellName/clusterName
- server=cellName/nodeName/serverName
- modules=cellName/applicationName/applicationVersion/moduleName
- server maintenance mode=true or false
- node maintenance mode=true or false
- protocol=PROTO_VALUE:
- PROTO_SIP = sip
- SIP over TCP
- PROTO_SIPS = sips
- SIP over SSL and TCP
- PROTO_SIPU = sipu
- SIP over UDP
- PROTO_SIPX = sipx
- SIP over XMEM
Note: For applications that have no applicationVersion value,
leave the applicationVersion value blank: module=cellName/application//moduleName.
- -errorcode
- Integer error code to reject request. The -errorcode parameter
is required only if actionType is equal to reject.
Batch mode example
usage
- Using Jacl:
$AdminTask changeRoutingRuleAction {-odrname odr -nodename node1 -protocol SIP -priority 0 -multiclusterAction Failover -routingLocations cluster=*/*}
- Using Jython string:
AdminTask.changeRoutingRuleAction('[-odrname odr -nodename node1 -protocol HTTP -priority 0 -multiclusterAction WRR -routingLocations "cluster=myCell/*"]')
Interactive mode example usage
- Using Jacl:
$AdminTask changeRoutingRuleAction {-interactive}
- Using Jython string:
AdminTask.changeRoutingRuleAction ('[-interactive]')
changeRoutingRuleExpression
The
changeRoutingRuleExpression command changes a routing policy rule
expression.
Required parameters
- -protocol
- Specifies the name of the protocol to associate with a rule. (String,
required)
- -priority
- Positive integer value representing the priority of a rule. Zero
is the highest priority. (String, required)
- -expression
- Specifies the rule expression. The expression must be enclosed
in double quotes. For more information about specifying the parameters
for the rule expression, refer to the SIP
operands topic and the HTTP operands topic. (String, required)
Optional parameters
- -odrname
- Specifies the name of the ODR to which the routing policy work
class applies. The -odrname parameter is required
only if you modify an ODR.
- -nodename
- Specifies the name of the node on which the ODR resides. The -nodename parameter
is required only if you modify an ODR.
- -clustername
- Specifies the name of the cluster to which the rule applies. The -clustername parameter
is required only if you modify an ODR cluster.
Batch mode example
usage
- Using Jacl:
$AdminTask changeRoutingRuleExpression {-odrname odr -nodename node1 -protocol SIP -priority 0 -expression "request.method = 'getOperation0'"}
- Using Jython string:
AdminTask.changeRoutingRuleExpression('[-odrname odr -nodename node1 -protocol HTTP -priority 0 -expression "request.method = \'INVITE\'"]')
Interactive mode example usage
- Using Jacl:
$AdminTask changeRoutingRuleExpression {-interactive}
- Using Jython string:
AdminTask.changeRoutingRuleExpression ('[-interactive]')
changeRoutingRulePriority
The
changeRoutingRulePriority command changes a routing policy rule priority.
Required parameters
- -protocol
- Specifies the name of the protocol to associate with a rule. (String,
required)
- -priority
- Positive integer value representing the priority of a rule. Zero
is the highest priority. (String, required)
- -expression
- Specifies the rule expression. The expression must be enclosed
in double quotes. For more information about specifying the parameters
for the rule expression, refer to the SIP
operands topic and the HTTP operands topic. (String, required)
Optional parameters
- -odrname
- Specifies the name of the ODR to which the routing policy work
class applies. The -odrname parameter is required
only if you modify an ODR.
- -nodename
- Specifies the name of the node on which the ODR resides. The -nodename parameter
is required only if you modify an ODR.
- -clustername
- Specifies the name of the cluster to which the rule applies. The -clustername parameter
is required only if you modify an ODR cluster.
Batch mode example
usage
- Using Jacl:
$AdminTask changeRoutingRulePriority {-odrname odr -nodename node1 -protocol SIP -priority 0 -expression "request.method = 'getOperation0'"}
- Using Jython string:
AdminTask.changeRoutingRulePriority('[-odrname odr -nodename node1 -protocol HTTP -priority 0 -expression "request.method = \'INVITE\'"]')
Interactive mode example usage
- Using Jacl:
$AdminTask changeRoutingRulePriority {-interactive}
- Using Jython string:
AdminTask.changeRoutingRulePriority ('[-interactive]')
createRoutingRules
The
createRoutingRules command creates a routing policy rule list.
Required parameters
- -protocol
- Specifies the name of the protocol to associate with a rule. (String,
required)
Optional parameters
- -odrname
- Specifies the name of the ODR to which the routing policy work
class applies. The -odrname parameter is required
only if you modify an ODR.
- -nodename
- Specifies the name of the node on which the ODR resides. The -nodename parameter
is required only if you modify an ODR.
- -clustername
- Specifies the name of the cluster to which the rule applies. The -clustername parameter
is required only if you modify an ODR cluster.
Batch mode example
usage
- Using Jacl:
$AdminTask createRoutingRules {-odrname odr -nodename node1 -protocol SIP}
- Using Jython string:
AdminTask.createRoutingRules('-odrname odr -nodename node1 -protocol SIP')
Interactive mode example usage
- Using Jacl:
$AdminTask createRoutingRules {-interactive}
- Using Jython string:
AdminTask.createRoutingRules ('[-interactive]')
listRoutingRules
The
listRoutingRules deletes a dynamic cluster from the configuration.
Required parameters
- -protocol
- Specifies the name of the protocol to associate with a rule. (String,
required)
Optional parameters
- -odrname
- Specifies the name of the ODR to which the routing policy work
class applies. The -odrname parameter is required
only if you modify an ODR.
- -nodename
- Specifies the name of the node on which the ODR resides. The -nodename parameter
is required only if you modify an ODR.
- -clustername
- Specifies the name of the cluster to which the rule applies. The -clustername parameter
is required only if you modify an ODR cluster.
Batch mode example
usage
- Using Jacl:
$AdminTask listRoutingRules {-odrname odr -nodename node1 -protocol SIP}
- Using Jython string:
AdminTask.listRoutingRules('-odrname odr -nodename node1 -protocol SIP')
Interactive mode example usage
- Using Jacl:
$AdminTask listRoutingRules {-interactive}
- Using Jython string:
AdminTask.listRoutingRules ('[-interactive]')
removeRoutingRule
The
removeRoutingRule command removes a routing policy rule.
Required parameters
- -protocol
- Specifies the name of the protocol to associate with a rule. (String,
required)
- -priority
- Positive integer value representing the priority of a rule. Zero
is the highest priority. (String, required)
- -expression
- Specifies the rule expression. The expression must be enclosed
in double quotes. For more information about specifying the parameters
for the rule expression, refer to the SIP
operands topic and the HTTP operands topic. (String, required)
Optional parameters
- -odrname
- Specifies the name of the ODR to which the routing policy work
class applies. The -odrname parameter is required
only if you modify an ODR.
- -nodename
- Specifies the name of the node on which the ODR resides. The -nodename parameter
is required only if you modify an ODR.
- -clustername
- Specifies the name of the cluster to which the rule applies. The -clustername parameter
is required only if you modify an ODR cluster.
Batch mode example
usage
- Using Jacl:
$AdminTask removeRoutingRule {-odrname odr -nodename node1 -protocol SIP -expression "request.method = 'getOperation'"}
- Using Jython string:
AdminTask.removeRoutingRule('[-odrname odr -nodename node1 -protocol HTTP -expression "request.method = \'INVITE\'"]')
Interactive mode example usage
- Using Jacl:
$AdminTask removeRoutingRule {-interactive}
- Using Jython string:
AdminTask.removeRoutingRule ('[-interactive]')