Acme Packet SBC and the “register-grace-timer” sip-config Option

Posted: 24th January 2012 by Mark in Acme Packet, BroadWorks, SBC, SIP
0

The Acme Packet SBC contains an optional parameter that may be added to the configuration which helps avoid a SIP avalanche from occurring.  One instance of a SIP avalanche is when a very large number of SIP endpoints consecutively send SIP registrations to an SBC which then forwards them to a SIP registrar. This can be dangerous for both the registrar and the SBC depending on how many endpoints are attempting to register. Assuming DDoS is applied to the SBC configuration, it will protect itself as well as the SIP registrar from being negatively impacted by the avalanche.

The following scenario shows how endpoints typically behave when they NAT through a firewall. Normally the firewall will NAT the layer 3 IP address but the layer 7 (SIP) address remains the private address. Upon receiving the NAT’d registration the SBC forwards the register message to a SIP register platform and after an exchange of a few messages between the registrar and endpoint a 200OK is sent from the registrar back to the endpoint with a register expires of 3600 seconds (default for Broadworks). The SBC knows the SIP endpoint is behind NAT and changes this timer from 3600 to something shorter (60 seconds is common).

Envision a scenario where the Internet is experiencing a route flap which is causing endpoints to lose connectivity to the SBC. If the endpoints should register every 60 seconds and they fail to do so, the SBC will delete them from the registration cache. If perhaps five minutes later the Internet is restored and the endpoints are able to communicate with the SBC again they would have to complete the entire registration process again. This would trigger a SIP avalanche that may negatively impact the core SIP network.

By implementing the option register-grace-timer parameter to the global SIP config and specifying a number of seconds, the SBC will retain the cached entries rather than let them expire even if the endpoint registration isn’t received. Once the endpoints come back after the Internet outage is resolved and they send a SIP registration to the SBC, the SBC will not forward this to the core because the previous registration remains valid in the SBC cache. This prevents the SBC from having to go through the entire registration process thus reducing the overhead involved on both the SBC and SIP registrar.

In this example the timer is set to 300 seconds. If endpoints are supposed to send their registration every 60 seconds but the SBC is not receiving them, it will retain the reg cache entry for another five minutes.

 

The diagram above demonstrates that even though the Internet is restored and endpoint registrations are reaching the SBC, there is no need for the SBC to forward these registrations to the SIP registrar since the reg-cache was retained during the outage. This prevents CPU cycles from being unnecessarily used on both the SBC and SIP registrar.

Acme Packet SBC and Media Aggregation

Posted: 9th November 2011 by Mark in Acme Packet, SIP
4

The Acme Packet 3800 and 4500 series Session Border Controllers come with an NIU (Network Interface Unit) that includes four Gigabit ports.  In rare cases one may need to support Media Aggregation where two of the Gigabit interfaces need to be look like they are “bonded” to accommodate a large number of calls (with media anchored).  For example, a wholesale SIP Peering Service Provider may need to handle upwards of 16,000 concurrent calls on one single Realm on the SBC.  If  calls are using the G.711 codec this would require 1.5GB of bandwidth.

The process used to support Media Aggregation is to assign the same Realm name to two different Steering Pools.  For example, on the realm Access it would have more than one steering pool which would reference two different network-interfaces.  The same is true for the Core.  In the following example NIU ports 0 and 1 are used for Access (public facing) and 2 and 3 are used for Core (private).  Note the NIU is considered slot 0 and the ports are 0, 1, 2, 3.

 

The next step is to verify you have your Access and Core realms configured.

The final step is to create the Steering Pools and define the network-interfaces for each.

At this point the SBC will utilize two ports assigned to Access and two ports assigned to Core to support media thus providing Media Aggregation. SIP signaling continues to only traverse on the sip-interfaces assigned to the Access and Core realms (s0p0 and s0p2) .

At this point the Acme Packet SBC is fully prepared to handle traffic that exceeds 1GB on a single Realm.

Acme Packet SBC “load-limit” Command Option

Posted: 9th November 2011 by Mark in Acme Packet, SIP, Unix
2

The Acme Packet SBC has an optional parameter that may be added under sip-config that allows the SBC to gracefully handle traffic in the event the SBC’s main processor reaches a certain threshold. There are several reasons as to why this may occur, but at the most basic level it’s a good idea to draw a line in the sand and define at what point to you want to start gracefully rejecting calls if the CPU reaches a certain threshold. Every SIP appliance should have this option but unfortunately most do not.

What separates the Acme Packet SBC from others is that when this threshold is reached the SBC will reply with a SIP 503 Service Unavailable message which tells the originator to try an alternate destination.  In most other SIP appliances once the CPU threshold reaches a certain point the traffic is disrupted by means of calls dropping, loss of RTP (if media is flowing through), or registrations becoming corrupted.

It is worth mentioning that the purpose of setting the load-limit is to avoid an unforeseen event that would cause any network device to experience excessive utilization and effect production traffic.  This is not a replacement for proper SROP (SIP Registration Overload Protection) and DDoS (Distributed Denial of Service) configuration on the SBC.  With the proper SROP and DDoS settings you are ensuring the Acme Packet SBC is running optimally and protecting your network while gracefully shedding unwanted or dangerous traffic.

The following is a shortened output of my sip-config with no options applied.  Adding the load-limit option is a matter of entering the following command.

At this point the Acme Packet SBC will gracefully reject incoming calls if the CPU reaches or exceeds 90%. Of course this value may be set higher or lower.  More than likely more options will be applied in your sip-config. If you follow the same process to add another option it will overwrite the option that already exists.  Prepending the + symbol in front of the option will add it in addition to any existing options.

In this example the load-limit is the first configured option. In addition, the max-udp-length is going to be set to 0 which allows the SBC to fragment UDP packets. Otherwise the maximum size a UDP packet may be is 1500 bytes before having to use SIP TCP.  Setting this in sip-config applies globally on the SBC but it is possible to configure this on a per sip-interface basis if desired.  The last option is reg-cache-mode=none which tells the SBC to retain the userinfo (post NAT) in the Contact. In most environments (such as Broadsoft BroadWorks) none is the value to use. This is also required when configuring SIP Registration Overload Protection (this will be a separate blog post in the near future).

Based on applying the load-limit to the sip-config this provides one additional line of defense that safeguards your platform from suffering a total outage. There have been many occasions noted in the past where other platforms do not employee this method and the end result is a complete and total network outage.  Once the outage starts it becomes very difficult to recover because endpoints will begin retransmitting. Using this feature in combination with alarm-thresholds plus the appropriate SROP and DDoS settings, there is always awareness of what’s occurring on the network while at the same time gracefully handling any overflow.

Acme Packet SBC: sag-lookup-on-redirect

Posted: 27th October 2011 by Mark in Acme Packet, SBC, SIP
1

In most cases a SIP Redirect Server simply responds to a SIP Invite with a 302 Moved Temp message and provides multiple contacts in the Contact Header.  When this occurs, the device receiving the 302 Moved Temp message (such as an Acme Packet SBC) will attempt to contact (ie. send a SIP Invite) the first address in the Contact Header.  If that fails, it will send a SIP Invite to the next address, and if that fails, the process will continue until there are no more addresses remaining.  Although this provides some form of redundancy it is not necessarily the best approach. Utilizing call flow this way means there is no control over how calls could potentially be load balanced if desired (or required).  Also, if one of the devices in the Contact Header is offline, there is no knowledge of this by the SBC and it will continue to send SIP Invites regardless and wait for the timers to expire. Definitely a less than desirable behavior.  The last item to note is that if you need to send SIP Invites to a potentially large group of servers (20 or more) there is a chance the Contact Header will become so large this is going to cause the SIP message to become fragmented.  All of these pitfalls may be easily avoided.

The Acme Packet SBC has a feature called sag-lookup-on-redirect. Simply put, the Redirect Server provides just one address in the Contact Header and the SBC will match that to a Session Agent Group in its configuration.  The result is calls may be load balanced (Hunt, Round Robin, Least Utilized, Least Busy, Proportional Distribution) and the SBC has the benefit of knowing when a target address (Session Agent) is alive and healthy which means it is in-service, or if the target is offline or unhealthy and therefore the SBC demotes it to an out-of-service state.  When a Session Agent is in an out-of-service state the SBC will not to send SIP Invites to that particular destination.

The feature sag-lookup-on-redirect is enabled through sip-config.

PHOENIX# configure terminal
PHOENIX(configure)# session-router
PHOENIX(session-router)# sip-config
PHOENIX(sip-config)# sag-lookup-on-redirect enabled
PHOENIX(sip-config)# done

In order for the SBC to pro-actively determine if a Session Agent is in-service or out-of-service, configure OPTIONS ping for each Session Agent.

session-agent
…
ping-method                     OPTIONS;hops=0
ping-interval                      60
ping-send-mode                 keep-alive

To view what Session Agents are in-service execute the following command:

PHOENIX# show sipd agents

Now, when the SBC receives a 302 Moved Temp message it will load balance based on the chosen scheme.  If any Session Agents are out of service the SBC will not attempt to send a SIP Invite.  The SBC waits until three successful OPTIONS pings are received before declaring an agent in service again.  This is great as it helps prevent an endpoint from flapping on the network.

Answer to Seizure Ratio-Based Routing on the Acme Packet SBC

Posted: 25th October 2011 by Mark in Acme Packet, SBC, SIP
0

Answer to Seizure Ratio (ASR) is a term used in Telecommunications and helps determine when new call setup attempt should be routed to an alternate destination. The definition of ASR is the number of successfully answered calls divided by the total number of calls attempted (seizures) multiplied by 100. The formula is (Answer / Seizure) * 100 = AnswerSeizureRatio.

Normally when an SBC initiates a SIP Invite to a peer and receives a SIP 503 Service Unavailable message in return the SBC will attempt another call setup to a secondary destination (Session Agent) automatically.  However, using an example such as busy signals, they not considered “failures” by a SIP device, yet there could be an upstream outage somewhere causing an unexplained amount of SIP 600 Busy messages being returned that is starving the Telecom network from completing calls. Since the Acme Packet SBC has the ability to route based on a configured ASR threshold, call may easily be routed to another destination if the configured ASR value falls below a specified threshold. Nice!

The place to configure ASR is within a Session Agent.  By defining a minimum (acceptable) ASR value, the SBC computes ASR as it makes routing decisions.  Using the formula first mentioned above, the SBC is calculating the number of successfully answered calls on a Session Agent and dividing by the total number of calls attempted. If the ASR constraints are exceeded, the Session Agent goes out of service for a configurable period of time and all traffic is routed to a secondary Session Agent (via a Local Policy which has the same Next-Hop but with a higher cost).

The two ASR parameters within a Session Agent are minimum seizure and minimum ASR.

Minimum Seizure determines if the Session Agent is within it’s normal constraints. For example, if 5 call attempts (seizures) have been made to a Session Agent and none have been answered, and the min seizures is set to 5, then on the 6th failed attempt the Session Agent will be marked as having exceeded its constraints and will be marked out of service.

Minimum ASR is considered when making routing decisions. If some or all of the calls to the Session Agent have been answered, the min ASR value is considered to make the routing decision. For example, if you set the Minimum ASR to 50% and the Session Agent’s ASR for that window falls below 50%, the Session Agent is marked as having exceeded its constraints and calls will not be routed to it until the time-to-resume has elapsed.

The time-to-resume element tells the SBC how long (in seconds) a Session Agent should be considered out of service once constraints have been exceeded.

Possible values for min-seizures range from 1 to 999999999. The default value is 5.

Possible percentage values for min-asr range from 0 to 100. The default is set to 0.

Networks where two or more egress paths exist on the VoIP network should consider using ASR based routing to provide the greatest level of network availability during a potential network congestion-outage related issue.

Acme Packet SBC “packet-trace” Command (capturing SIP signaling)

Posted: 21st October 2011 by Mark in Acme Packet, SBC, SIP
1

The packet-trace command allows the Acme Packet SBC (Session Director) to capture SIP signaling communication between two endpoints and send the capture to external server such as Wireshark.The SBC uses the network interfaces (ie. media interfaces) to send the capture.  The wancom management interface is not supported in this case.

The first step is to configure a capture receiver.  This tells the SBC what interface is used for the mirrored packets and the target IP of the Wireshark server. The network-interface is the SBC’s network-interface and sub-port ID.

The next step is to identify what IP and ports the SBC should listen to in order to send the packets to Wireshark. If no ports are identified then the SBC listens on all ports.

 

 

Even though it is not required to specify the local and remote TCP/UDP ports  it’s always a good idea to be as specific as possible when defining captures so only the required data is captured. At this point any calls coming into the SBC that involve the IP 217.154.63.10 on TCP or UDP port 5060 are going to trigger the capture and packets will be sent to Wireshark. Sixteen concurrent traces can be running at once.

One thing to note is the capture is sent to Wireshark using RFC 2003 (IP to IP encapsulation) as opposed to relaying SIP on port 5060. This means Wireshark needs to be configured to listen for RFC 2003 packets and then it will decode them. Use the ip.src filter to display only the encapsulated SIP packets.

Verifying and Loading an SSL Certificate on the Acme Packet SBC

Posted: 27th August 2011 by Mark in Acme Packet, SIP, Unix
1

SIP TLS (Transport Layer Security) is used to encrypt SIP signaling between SIP endpoints.  In order for this to function properly it is required that certain devices in the network import an SSL certificate.  Before importing the certificate into a device such as an Acme Packet SBC it is important to know if the certificate is from a CA (Certificate Authority) or perhaps self-generated in which case it would be considered a non-CA certificate.  Occasionally users have indicated the certificate is from a CA when in fact it is not.  This may generate an error if importing a non-CA certificate as a CA certificate.  Below is a quick procedure to verify the certificate using Mac OS X (or Linux).

$ openssl verify -verbose CertFile.crt
server.crt: OK

If the output is anything other than server.crt: OK then the provided certificate is not from a valid Certificate Authority.  For example:

$ openssl verify -verbose CertFile.crt
CallManagerAug22.crt: /CN=TESTCCM/OU=CISCOMCS7800/O=FPI/L=MANILA/ST=MAKATI/C=PH
error 18 at 0 depth lookup:self signed certificate
OK

Another alternative to verify a certificate is using Mac OS X’s Keychain Access application. Simply import the certificate and you will see something like this:

If using a CA based certificate here are the steps to generate a certificate request and load the certificate on the Acme Packet SBC

PHOENIX# configure terminal
PHOENIX(configure)# security
PHOENIX(security)# certificate-record

PHOENIX# generate-certificate-request markholloway

Generating Certificate Signing Request. This can take several
minutes…
—–BEGIN CERTIFICATE REQUEST—–
MIIDHzCCAoigAwIBAgIIAhMCUACEAHEwDQYJKoZIhvcNAQEFBQAwcDELMAkGA1UE
BhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBKb3NlMQ4w
DAYDVQQKEwVzaXBpdDEpMCcGA1UECxMgU2lwaXQgVGVzdCBDZXJ0aWZpY2F0ZSBB
dXRob3JpdHkwHhcNMDUwNDEzMjEzNzQzWhcNMDgwNDEyMjEzNzQzWjBUMQswCQYD
VQQGEwJVUzELMAkGA1UECBMCTUExEzARBgNVBAcTCkJ1cmxpbmd0b24xFDASBgNV
BAoTC0VuZ2luZWVyaW5nMQ0wCwYDVQQDEwRhY21lMIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQCXjIeOyFKAUB3rKkKK/+59LT+rlGuW7Lgc1V6+hfTSr0co+ZsQ
bHFUWAA15qXUUBTLJG13QN5VfG96f7gGAbWayfOS9Uymold3JPCUDoGgb2E7m8iu
vtq7gwjSeKNXAw/y7yWy/c04FmUD2U0pZX0CNIR3Mns5OAxQmq0bNYDhawIDAQAB
o4HdMIHaMBEGA1UdEQQKMAiCBnBrdW1hcjAJBgNVHRMEAjAAMB0GA1UdDgQWBBTG
tpodxa6Kmmn04L3Kg62t8BZJHTCBmgYDVR0jBIGSMIGPgBRrRhcU6pR2JYBUbhNU
2qHjVBShtqF0pHIwcDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWEx
ETAPBgNVBAcTCFNhbiBKb3NlMQ4wDAYDVQQKEwVzaXBpdDEpMCcGA1UECxMgU2lw
aXQgVGVzdCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHmCAQAwDQYJKoZIhvcNAQEFBQAD
gYEAbEs8nUCi+cA2hC/lM49Sitvh8QmpL81KONApsoC4Em24L+DZwz3uInoWjbjJ
QhefcUfteNYkbuMH7LAK0hnDPvW+St4rQGVK6LJhZj7/yeLXmYWIPUY3Ux4OGVrd
2UgV/B2SOqH9Nf+FQ+mNZOlL7EuF4IxSz9/69LuYlXqKsG4=
—–END CERTIFICATE REQUEST—–;

PHOENIX# save-config
PHOENIX# activate-config

 

Once the certificate is received by the CA it needs to be imported on the Acme Packet SBC

PHOENIX# import-certificate [try-all|pkcs7|x509] [cert-file-name]

PHOENIX# import-certificate try-all markholloway

Please enter the certificate in the PEM format.
Terminate the certificate with “;” to exit…….
—–BEGIN CERTIFICATE—–
MIIDHzCCAoigAwIBAgIIAhMCUACEAHEwDQYJKoZIhvcNAQEFBQAwcDELMAkGA1UE
BhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBKb3NlMQ4w
DAYDVQQKEwVzaXBpdDEpMCcGA1UECxMgU2lwaXQgVGVzdCBDZXJ0aWZpY2F0ZSBB
dXRob3JpdHkwHhcNMDUwNDEzMjEzNzQzWhcNMDgwNDEyMjEzNzQzWjBUMQswCQYD
VQQGEwJVUzELMAkGA1UECBMCTUExEzARBgNVBAcTCkJ1cmxpbmd0b24xFDASBgNV
BAoTC0VuZ2luZWVyaW5nMQ0wCwYDVQQDEwRhY21lMIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQCXjIeOyFKAUB3rKkKK/+59LT+rlGuW7Lgc1V6+hfTSr0co+ZsQ
bHFUWAA15qXUUBTLJG13QN5VfG96f7gGAbWayfOS9Uymold3JPCUDoGgb2E7m8iu
vtq7gwjSeKNXAw/y7yWy/c04FmUD2U0pZX0CNIR3Mns5OAxQmq0bNYDhawIDAQAB
o4HdMIHaMBEGA1UdEQQKMAiCBnBrdW1hcjAJBgNVHRMEAjAAMB0GA1UdDgQWBBTG
tpodxa6Kmmn04L3Kg62t8BZJHTCBmgYDVR0jBIGSMIGPgBRrRhcU6pR2JYBUbhNU
2qHjVBShtqF0pHIwcDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWEx
ETAPBgNVBAcTCFNhbiBKb3NlMQ4wDAYDVQQKEwVzaXBpdDEpMCcGA1UECxMgU2lw
aXQgVGVzdCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHmCAQAwDQYJKoZIhvcNAQEFBQAD
gYEAbEs8nUCi+cA2hC/lM49Sitvh8QmpL81KONApsoC4Em24L+DZwz3uInoWjbjJ
QhefcUfteNYkbuMH7LAK0hnDPvW+St4rQGVK6LJhZj7/yeLXmYWIPUY3Ux4OGVrd
2UgV/B2SOqH9Nf+FQ+mNZOlL7EuF4IxSz9/69LuYlXqKsG4=
—–END CERTIFICATE—–;

PHOENIX# save-config
PHOENIX# activate-config

 

From here there are quite a number of steps to perform in order to support SIP TLS and sRTP. The following example shows how to create a TLS profile for encrypted SIP signaling.

PHOENIX# config t
PHOENIX(configure)# security
PHOENIX(security)# tls-profile

Enter a name for the profile, name of the trust CA certificate record, and the tls-version (TLSv1 or SSLv3)

PHOENIX(tls-profile)# exit
PHOENIX(security)# exit

Now apply the TLS profile to the sip-interface that will be used.

PHOENIX(configure)# session-router
PHOENIX(session-router)# sip-interface
PHOENIX(sip-interface)# select

<SIP INTERFACE>

PHOENIX(session-interface)# sip-ports
PHOENIX(sip-port)# <ENTER>
PHOENIX(sip-interface)# transport-protocol tls
PHOENIX(sip-interface)# tls-profile <profile>

To view information about certificates loaded in the Acme Packet SBC:

PHOENIX# show security certificates [ brief | detailed ] <CERT>

certificate-record:markholloway
Certificate:
Data:
Version: 3 (0×2)
Serial Number:
04:55:32:55:50:84:45:71
Issuer:
C=US
ST=Arizona
L=Phoenix
O=sipit
OU=STCA
Subject:
C=US
ST=AZ
L=Phoenix
O=Engineering
CN=mh

Install Cisco Unified Communications Manager 8 (CUCM 8.x) in VMWare

Posted: 1st August 2011 by Mark in Cisco
16

The following VMWare specifications should be used when installing Cisco Unified Communications Manager 8 (Callmanager) as a virtual machine. This has been tested on both VMWare Fusion 3 for Mac and VMWare Workstation 7 for Linux. Note that it is best to pre-allocate your hard drive space if possible in order to get the best performance. Cisco is very generous with their VM licensing and permits three VM instances to form a 3 node cluster (one publisher, two subscribers) as well as 150 DLU’s which depending on your end point type will support 8 or more phones.  When I studied for my CCIE Voice (blueprint v3) I only used the demo license on CUCM with one publisher and one subscriber and the accommodated all of my lab requirements.  Thank you, Cisco!

The following screen shot shows the settings for VMWare Fusion but they are also identical for VMWare Workstation.

At the time the installation was performed the shipping version of CUCM was v8.02.  Shortly after, v8.03 began to ship and the requirements are the same. I have successfully upgraded from v8.02 to v8.03 in VMWare as well as upgrade to the newest v8.6.  One thing to note about installing CUCM 8 is you will need a working NTP server IP address. This may be a router in your lab, Linux server running NTP, an NTP IP on the Internet, or if you are planning to use DNS simply point to pool.ntp.org.

Configuring Historical Data Recording (HDR) on the Acme Packet SBC

Posted: 10th June 2011 by Mark in Acme Packet, SIP, Unix
0

Gathering metrics on a VoIP network is crucial and the Acme Packet Session Director (SBC) has a feature that comes standard with the platform called Historical Data Recording (HDR).  The purpose of HDR is to enable a set (or sets) of categories ranging from CPU and Memory utilization to SIP errors, enum statistics,  ACL status, etc., and have the SBC create CSV files which are then sent off to an external FTP/SFTP server where the data can be mined.  This provides the convenience and ability to measure network performance, plan for additional capacity before reaching a critical state, or aid in troubleshooting customer related issues.

Historical Data Recording covers a wide range of collection objects and multiple HDR groups may exist in the SBC where data may be sent to different servers or broken out by different groups. The following is a list of groups available for data collection. Each group contains dozens of element statistics that will be gathered. The element list is very long so it is not posted here, but the complete element list for each group is available in the ACLI Configuration Guide.


The place to configure HDR is system > system-config > collect

The group-settings command allows the SBC to only report on specific data rather than everything. If no group-settings are defined then the SBC automatically provides data for all elements (as shown below).

Data is being sent to 172.16.24.4 using FTP.  The server resides on the same subnet as the Management interface of the SBC. The FTP username is ossadmin since this is also the same server CDR’s are delivered to from the SBC. A folder named hdr was created in the ossadmin home directory which is the destination FTP folder for the SBC to send HDR files to. Within that directory the SBC automatically creates a new directory PHOENIX which is the hostname of the SBC.  If additional SBC’s exist on the network and they are sending to the same destination FTP hdr folder then each SBC creates its own directory based on its hostname. Within the SBC directory the SBC creates sub-directories for each of the categories the HDR send reports on.

From this point we navigate to a folder and see the CSV files that have been uploaded to the server.  The sample-interval within the system > system-config > collect menu context is set to 5 minutes and the push-interval set to 15 minutes. This means a new file is sent every 15 minutes with three sampled intervals of data in each CSV.

In this example we navigate to the space folder which tells us how much space is used and how much is available in the SBC’s localized storage.

Notice there are three sampled intervals contained in one file. This correlates to the sample-interval and push-interval mentioned earlier.

It is worth noting that HDR typically consumes less than 1% of total CPU Utilization. It also has the ability to support redundancy so files may be sent to additional FTP/SFTP servers if necessary in the event the primary FTP server is unreachable.

 

The Importance of the “alarm-threshold” Command on the Acme Packet SBC

Posted: 23rd May 2011 by Mark in Acme Packet, SBC, SIP
0

The alarm-threshold command gives the Acme Packet SBC the ability to send minor, major, or critical alarms when CPU, Memory, Rfactor, Space (/ramdrv), and Session count reach a specific threshold based on % usage. Each element is monitored individually so the alarm is sent only for the violating element. Setting these values is a great step towards monitoring your network for health and capacity.

In the following example the SBC is being configured through the ACLI to monitor the number of simultaneous Sessions and will send a major alarm when the SBC is using 75% of its session capacity.  For example, if this SBC supports 16,000 sessions and 12,000 sessions are currently in use, the SBC will send a major alarm to the configured SNMP trap-receiver.

 

Adding the alarm-threshold settings to your configuration is essential to following Acme Packet’s Best Current Practice for the platform.

Older Entries