The services-routing object applies cluster-wide routing configurations, including metrics to each of the ME service routing tables (media, SIP, H.323, and STUN) and gateway health checks. Metrics define the cost associated with each route, controlling how services are load-balanced across the cluster.
There are four service routing table types:
Media: Used for allocating media resources across the cluster
SIP: Used for routing SIP packets on each ME
H.323: Used for routing H.323 packets on each ME
STUN: Used for allocating STUN requests
When you configure an IP interface, the ME installs both a network route and a host route into the generic routing table, along with a metric (preference) for the route. If there are services configured under the interface (e.g., media, SIP, H.323, or STUN), the route is also installed in the specific service routing table. In addition, each service route table can have subtables that are created when a routing-tag is associated with an IP interface. See Tag-Based Route Selection for a description of these tag-based tables.
Each service route entry has five metric fields that serve as tie breakers to determine route preference. You can assign different metric types to each of the five metric fields, controlling the preference of one route server over another. Given that there may be multiple paths available to reach a destination, using service route table metrics allows the ME to consider routes differently depending on their purpose. The lower the metric value, the higher the preference.
For each service route table (and therefore, application), you can set different criteria for route selection. For example, to influence media anchoring route selection, you can assign metrics to the media table. By default, if two or more routes exist with equivalent metric values, these routes are considered equal-cost routes. The ME uses a round-robin algorithm through all equal-cost routes when distributing a service across a cluster. You can assign metric types to a service route table using the five metric fields to prefer one route over another.
To select the most preferred route(s), the ME applies these table-specific metrics. If two or more routes exist to reach a destination, the ME then compares metric1, and so on, up to metric5, or until a route is preferred based on a metric. If all five metrics are equivalent, the routes are considered equal cost.
By default, the ME uses the user-metric value. This value is used as the first tiebreaker (metric1 field), and the remaining fields default to none.
The frequency with which the ME updates the value for calculated metrics (for all service metric tables) is set with the vsp > services-routing > metric-timer property. You select the metric type for a service under the media-service-routing, sip-service-routing, h323-service-routing, and stun-service-routing objects. Note that any configuration changes to the assignment of metric types causes an immediate recalculation of that service's route table. Use the show services-routing-metrics command to display the metric assignments.
The following lists and describes the valid metric types.
none: The metric field is not used during route selection.
user-metric: A user-defined static metric that can be associated with a specific IP interface or static route. This static metric can be used to determine the preference of a route. The user-metric value can be thought of as the cost associated with a route, the lower the cost the more preferred the route.
For an IP interface this metric value is configured under box > interface > ip > metric. For a static route this metric value is configured under box > interface > ip > routing > route > metric.
intf-thruput: A route that is associated with an IP interface. This metric type uses the dynamic throughput, in kilobits per second, of the physical interface that a particular route is associated with to determine route preference. The lower the intf-thruput value, the more preferred the route.
box-cpu-load: A route that is associated with an ME. This metric type uses the ME-wide CPU load to determine route preference. The lower an ME's CPU load is, the more preferred the route.
box-memory: A route associated with an ME. This metric type indicates the percentage of memory allocated from the SIP Process' maximum heap. The lower the box-memory, the more preferred the route.
box-media-load: This metric type is currently unused.
On the ME, services routing distributes the load of a service using either a round-robin (RR) or a weighted-round-robin (WRR) load balancing algorithm. The RR algorithm loops through a set of equal cost routes, distributing the load equally across the set of routes. When dynamic metrics such as an ME's CPU utilization is used to balance the load, the RR algorithm can lead to an uneven distribution of the load. The WRR load balancing algorithm is a better choice when using dynamic metrics such as an ME's CPU utilization.
For each type of service routing, there are five service routing metric fields named metric1 through metric5. Each of the metrics can be configured to use a specific metric type to determine the services route preference.
You configure each metric to determine which load balancing algorithm, either round-robin or weighted-round-robin, is used using the load-share-scheme property. The default algorithm is round-robin.
When all metric fields are configured for RR, the ME determines which routes are part of an equal cost route set. If all metric fields configured for RR are of equal value for two or more routes, those routes are considered equal cost.
The following table shows an example. Route 1 and Route 3 are considered equal cost because metric1 and metric2 are configured as RR and both metrics have the same values. Route 2 would be a secondary route because a metric 2 value of 20 is less-preferred than Route 1 and Route 3.
If one or more metrics are configured as WWR, then those metrics are used to calculate the load-share for each route in an equal cost set. Each metric configured for WRR has a dynamic weight that is calculated based on how close a metric is to its upper bound. A route's weight is then used to calculate its load share across an equal cost route set. Services routing then balances the load across the equal cost route set based on the load share values calculated for each route.
The following table shows an example. Routes 1-3 are considered equal cost because their round robin metrics are all of equal value. Metric2 is configured to use box-cpu-load (% of CPU utilized) as a weighted-round-robin. Based on these WRR values, the routes are assigned a load-share. Since Route 1 is the least loaded, it is assigned the highest load-share (75) while route 3 receives the lowest load-share (25). Once the load-share of the equal cost route is calculated, the load is distributed appropriately across the route set. In this example, Route 1 should receive twice as much load as Route 3, and 25% more load than route 2. For example, if 150 requests are made, 75 are distributed using Route 1, 50 by Route 2, and 25 by Route 3. These values are based on the calculated loadshare value.
Table 37-2 Determining WRR Routes
| Route Name | Metric1: user-metric RR | Metric2: box-cpu-load WRR |
|---|---|---|
|
Route 1 |
1 |
25 (load-share 75) |
|
Route 2 |
1 |
50 (load-share 50) |
|
Route 3 |
1 |
75 (load-share 25) |
The values of a route's metric fields are updated periodically based on the vsp > services-routing > metric-time property. Each time this metric-time expires, the load-shares are recalculated based on the latest metric values. Also, anytime an equal cost route is added or removed from an equal cost route set, new load-share values are calculated.
Configures VSP routing to control routing in a cluster of one or more ME devices. For example, you can set the interval with which metrics used for route selection are updated. When this interval expires, the ME recalculates the selected metrics for each table and distributes the value throughout the cluster. At that point, the ME recalculates the preference of each route affected by a metric change. In addition, the subobjects provide access to the metric selection for each of the service routing tables.
This object configures gateway health checks for static routes, verifying reachability of a gateway. (When configuring a static route, you must supply a gateway address as the next-hop for forwarding packets to reach the destination network.) The ME sends ARP requests to each configured gateway, from each configured interface using that gateway. If a gateway is configured on multiple interfaces, the ME verifies reachability from each interface.
The ME uses a configurable timer and a maximum failure count to determine when a gateway is considered unreachable. The timer controls how often a health check is performed. The maximum failure count controls how many consecutive health checks must fail before the gateway is considered unreachable. For example, if the gateway health timer is set to ten seconds, and the gateway maximum failure count is set to three, a gateway would become unreachable after three consecutive health check failures or thirty seconds. When a gateway fails its health check on a particular IP interface, the ME considers any static routes configured with that gateway on that IP interface unreachable.
metric-timer: Sets the interval (in seconds) with which the system updates service-routing metrics. This interval, which applies to all route service tables, controls how quickly the system can propagate a change in a metric value throughout the cluster service route tables.
A value of 0 disables the gateway health check feature.
Default: 60
Values: Min: 0 / Max: 86400
Example: set metric-timer 90
gateway-health-timer: Sets the frequency with which the system sends ARP requests to a gateway. This interval applies to all gateways configured on the box. See Gateway Health Checks for more information.
A value of 0 disables the gateway health check feature.
Default: 0
Values: Min: 0 / Max: 86400
Example: set gateway-health-timer 90
gateway-max-failures: Specifies the number of consecutive health checks that must fail before the system considers a gateway unreachable. See Gateway Health Checks for more information.
Default: 3
Values: Min: 1 / Max: 1000
Example: set gateway-max-failures 5
cpu-sample-interval: Sets the sampling interval (in seconds) in which to calculate the CPU usage of the system. For example, if the cpu-sample-interval is 10 seconds, then 10, one second samples will be used to calculate the CPU usage. The result of this calculation is a CPU usage percentage between 0 and 100. The calculated CPU usage value is used as the box-cpu-load metric.
Default: 60
Values: Min: 1 / Max: 3600
Example: set cpu-sample-interval 100
cpu-sample-divisor: Normalizes the box-cpu-load metric. To do so, the raw CPU usage percentage is divided by this value and the result is used as the box-cpu-load metric. This provides better control of how services are load balanced, and results in a better load balancing distribution. For example, if three boxes have a CPU usage of 21, 22, and 23 percent respectively, without normalization of box-cpu-load metric, the box with CPU usage of 21 would be preferred over the other two boxes. By normalizing the CPU usage percentage using the default divisor of 10, the metric values for all three boxes becomes two. The load will then be balanced across all three boxes.
Default: 10
Values: Min: 1 / Max: 100
Example: set cpu-sample-divisor 20
Sets the basis for route evaluation when selecting routes from the media service routing table. The ME uses these metrics, which set route precedence, when anchoring media.
In an ME cluster, media can be load balanced across two or more media MEs. The decision as to which ME handles the media is determined based on the signaling address from the initial INVITE. A services routing lookup is performed in a cluster-wide basis using this signaling address to determine which the ME should handle the media. Once a media ME is selected, all the media resources for the session are allocated locally from that media ME.
In a Delayed-offer topology, local media ports must be configured on the signaling ME. If you want to have the signaling ME handle only signaling and no media, you can load balance the media across the media ME. This is accomplished by configuring each of the signaling interfaces with a higher metric than any of the media interfaces on the two media MEs. Any static routes configured under these signaling interfaces should also be configured with the same higher metric. This is configured under the ip > routing > route > metric <cost> property. By configuring the media interfaces on the media ME with a lower metric, they are always preferred over the signaling MEs., allowing all media to load balanced across the media SBCs only.
metric1 <metric-type><load-share-scheme>: Sets the first type of metric considered by the system when it selects a route for media traffic.
Default: user-metric round-robin
Example: set metric1 intf-throughput weighted-round-robin
metric2 <metric-type><load-share-scheme>: Sets the second type of metric considered by the system when it selects a route for media traffic.
Default: none round-robin
Example: set metric2 user-metric weighted-round-robin
metric3 <metric-type><load-share-scheme>: Sets the third type of metric considered by the system when it selects a route for media traffic.
Default: none round-robin
Example: set metric3 box-cpu-load weighted-round-robin
metric4 <metric-type><load-share-scheme>: Sets the fourth type of metric considered by the system when it selects a route for media traffic.
Default: none round-robin
Example: set metric2 box-memory weighted-round-robin
metric5 <metric-type><load-share-scheme>: Sets the fifth type of metric considered by the system when it selects a route for media traffic.
Default: none round-robin
Example: set metric5 user-metric weighted-round-robin
Sets the basis for route evaluation when selecting routes from the SIP service routing table. The ME uses these metrics, which set route precedence, for SIP signaling. See Understanding the Application of Route Metrics for a description of using metrics for route selection.
metric1 <metric-type><load-share-scheme>: Sets the first type of metric considered by the system when it selects a route for SIP signaling traffic.
Default: user-metric round-robin
Example: set metric1 intf-throughput weighted-round-robin
metric2 <metric-type><load-share-scheme>: Sets the second type of metric considered by the system when it selects a route for SIP signaling traffic.
Default: none round-robin
Example: set metric2 user-metric weighted-round-robin
metric3 <metric-type>< load-share-scheme>: Sets the third type of metric considered by the system when it selects a route for SIP signaling traffic.
Default: none round-robin
Example: set metric3 box-cpu-load weighted-round-robin
metric4 <metric-type><load-share-scheme>: Sets the fourth type of metric considered by the system when it selects a route for SIP signaling traffic.
Default: none round-robin
Example: set metric2 box-memory weighted-round-robin
metric5 <metric-type><load-share-scheme>: Sets the fifth type of metric considered by the system when it selects a route for SIP signaling traffic.
Default: none round-robin
Example: set metric5 user-metric weighted-round-robin
Sets the basis for route evaluation when selecting routes from the H.323 service routing table. The ME uses these metrics, which set route precedence, for H.323 signaling. See Understanding the Application of Route Metrics for a description of using metrics for route selection.
metric1 <metric-type><load-share-scheme>: Sets the first type of metric considered by the system when it selects a route for H.323 signaling traffic.
Default: user-metric round-robin
Example: set metric1 intf-throughput weighted-round-robin
metric2 <metric-type><load-share-scheme>: Sets the second type of metric considered by the system when it selects a route for H.323 signaling traffic.
Default: none round-robin
Example: set metric2 user-metric weighted-round-robin
metric3 <metric-type><load-share-scheme>: Sets the third type of metric considered by the system when it selects a route for H.323 signaling traffic.
Default: none round-robin
Example: set metric3 box-cpu-load weighted-round-robin
metric4 <metric-type><load-share-scheme>: Sets the fourth type of metric considered by the system when it selects a route for H.323 signaling traffic.
Default: none round-robin
Example: set metric2 box-memory weighted-round-robin
metric5 <metric-type><load-share-scheme>: Sets the fifth type of metric considered by the system when it selects a route for H.323 signaling traffic.
Default: none round-robin
Example: set metric5 user-metric weighted-round-robin
Sets the basis for route evaluation when selecting routes from the STUN service routing table. The ME uses these metrics, which set route precedence, when sending requests to a STUN server. See Understanding the Application of Route Metrics for a description of using metrics for route selection.
metric1 <metric-type><load-share-scheme>: Sets the first type of metric considered by the system when it selects a route for STUN server traffic.
Default: user-metric round-robin
Example: set metric1 intf-throughput weighted-round-robin
metric2 <metric-type><load-share-scheme>: Sets the second type of metric considered by the system when it selects a route for STUN server traffic.
Default: none round-robin
Example: set metric2 user-metric weighted-round-robin
metric3 <metric-type><load-share-scheme>: Sets the third type of metric considered by the system when it selects a route for STUN server traffic.
Default: none round-robin
Example: set metric3 box-cpu-load weighted-round-robin
metric4 <metric-type><load-share-scheme>: Sets the fourth type of metric considered by the system when it selects a route for STUN server traffic.
Default: none round-robin
Example: set metric2 box-memory weighted-round-robin
metric5 <metric-type><load-share-scheme>: Sets the fifth type of metric considered by the system when it selects a route for STUN server traffic.
Default: none round-robin
Example: set metric5 user-metric weighted-round-robin