Packets that cause a direct SBC fault can lead to a catastrophic failure of an SBC service, which is known as a packet-stimulated fault avalanche. These packets appear for various reasons, such as: the SBC adds a new Session Initiation Protocol (SIP) endpoint, upgrades or replaces a peering endpoint or gateway (GW), changes a configuration on a peer, or introduces a new call scenario. The SBC does not currently check for double faults, which is when the SBC has a failover and then another failover. Double faults cause call loss.
The goal of Avalanche Fault Detection and Control is not to prevent individual crashes, but to detect and control continuous "avalanche" faults that can lead to complete service outages. This feature uses the information from the existing faults to attempt to prevent future faults.
The fault avalanche feature does not:
The fault avalanche feature tracks potentially problematic values of key types in SIP packets (see Tracking for more information). To track these values the fault avalanche feature extracts and saves values from the following fields of the SIP packet that causes a crash:
Each key type associates with a threshold value. The threshold value indicates the maximum amount of crashes allowed for a particular value of the key type before the SBC blocks that key value (see Blocking for more information). The SBC defines the threshold values so that they ensure the threshold for more specific blocks trigger before less specific blocks. The following table shows the default key type thresholds.
The SBC determines the calling party for a SIP packet in the following order:
The SBC obtains the called party for a SIP packet from either a Request URI of a SIP request, or the To header URL of a SIP response.
The SBC cannot monitor the fault count for user(s) if no usable calling party information is available. However, the SBC can control faults based on the source IP.
Ribbon recommends that you set the thresholds according to how strict (or lenient) you prefer to be with faults in a cluster. If you do not want the SBC to block a specific key element or source, you can instruct the SBC using CLI commands.
The Layer 3 source IP address of the packet determines the peer IP address.
Use the following command to set and configure the faultAvalancheControl
parameter.
% set system faultAvalancheControl callIdThreshold <0-999> calledPartyThreshold <0-999> callingNCalledPartyThreshold <0-999> callingPartyThreshold <0-999> sourceIpThreshold <0-999> faultRecAgeingTimeOut <15-60>
Use the following command to enable or disable the faultAvalancheControl
parameter.
% set system faultAvalancheControl facState <disabled | enabled>
If you disable the facState
flag, the system:
The following command is an example of how to set and configure faultAvalancheControl
.
% set system faultAvalancheControl callIdThreshold 2 calledPartyThreshold 5 callingNCalledPartyThreshold 2 callingPartyThreshold 5 sourceIpThreshold 5 faultRecAgeingTimeOut 35
The following command is an example of how to enable faultAvalancheControl
.
% set system faultAvalancheControl facState enabled
The following command is an example of how to view faultAvalancheControl
.
> show status system faultAvalancheControl