Back in 2008 I rewrote part of the CAC for the C10000 router in 12.2SB, I dont know if regular IOS took that over into 15.x but the documentation of it still applies I wrote at the time. The new-model however referenced may nor may not be in your version of SW.
Any case see if this helps:
First Published: June, 2008
Last Updated: June, 2008
The Call Admission Control for broadband describes the application of Call Admission Control (CAC) to the session establishment for PPPoE, PPPoA and VPDN aggregation methods in Cisco IOS.
CAC limits the number of session establishments based on CPU and Session charges that a router can establish.
The router must be able to setup broadband sessions normally without Call Admission Control. Refer to the configuration guide for L2TP/VPDN and PPPoE and PPPoA for more details on setting up basic sessions to a BRAS router.
Call Admission Control (CAC) affects the way the router admits Broadband (BB) calls to the router. High scaling routers may deal with a large number of session setup attempts per second during peak hours or after a router reboot.
Often the authentication is outsourced to an external device such as RADIUS to complete the authentication request. Such an external device potentially may not be able to deal with the number of authentication requests a BB router may send. Therefore need to throttle the number of requests the router sends to this external device.
When the BB aggregation router is dealing with a high number of sessions, the CPU may rise to high levels. Upon which it become less efficient to complete the number of session attempts coming in.
Call admission control allows us to throttle the number of incoming call requests based on CPU thresholds of the router and or on Sessions per second. This document outlines the “old” method of call admission control available in any Cisco IOS release and the new-model available in 12.2(31)SB13 and 12.2(33)SB2
When call admission control is not enabled, the router will accept any incoming call attempt originating from PPPoE, PPPoA and VPDN.
Call admission control will create a charge for CPU and or sessions as per configuration and measures that against a configured limit value.
Whenever there is an incoming call attempt, this charge is verified against the limit and the CAC mechanism will provide a ADMIT or DENY to the requesting subsystem.
Depending on the flavor of the call, the following actions are undertaken as per table 1:
Flavor of call | Type of device | Incoming FSOL | Action Admit | Action Deny |
PPPoE | PTA/LAC | PADI | respond with PADO | no response to request |
PPPoA | PTA/LAC | LCP CONFREQ | respond with CONFACK/NAK/REJ | no response to request |
VPDN | LNS | ICRQ | respond with ICRP | no response to request |
FSOL is “first sign of life”
The way the charge is computed differs in between the old model and the new model.
The charge is composed of the following resource utilization parameters:
- Session charges
- CPU charges
- Buffer utilization
Configuration Parameters
- Call admission pppoe <charge> <lifetime>
- Defines the charge and lifetime for a PPPoE type call
- Call admission pppoa <charge> <lifetime>
- Defines the charge and lifetime for a PPPoA type call
- Call admission vpdn <charge> <lifetime>
- Defines the charge and lifetime for a VPDN type call
- Call admission load <multiplier> <lifetime>
- Defines the charges to be added based on the CPU utilization
- Call admission limit <value>
- Defines the limit to which the total charge is compared to make a decision on admit or deny an incoming call request.
"call admission limit <limit>" sets the maximum charge the system can have upon which CAC will reject the sessions and effectively enables CAC.
In this section the different types of charges are explained.
When verifying the “show buffers” command we can see the buffer utilization for small, middle, big, very big and large buffers.
There is a permanent amount and a used amount.
Whenever one of the buffer pools is using its maximum amount, the charge is set to a high value effectively telling the CAC mechanism to stop accepting calls.
As per high scaling configuration recommendations for Cisco BB routers, we’d set the buffers to large permanent values (see section: Configuration recommendations for large scaling routers in the Cisco 10000 series configuration guide) effectively reducing the effect of buffer utilization of the CAC charge computation.
"call admission load 100 1" This command sets the value that the CPU is going to add
to the total charge of the system.
Formula used:
In most cases (as long as the buffer total >= permanent) the formula applies:
(Pcpu+95)*L/200
Where Pcpu is the process cpu visible in the "show proc cpu"
command and L is 100 (from "call admission load 100 1" command).
Example 1:
With a CPU load of 50% the calculated load charge would be
(50+95)*100/200 = 145/2 = 72.5
Setting the call admission limit to 72 would prevent the acceptance of additional connections with a CPU Load of 50%.
"call admission <calltype> <per-session-charge> <duration-of-charge>"
This command sets the charge to be added for each individual session that is of the configured type.
Default charge of a session is 0. This means there is no added charge for each session type.
Example 2:
"call admission limit 300"
"call admission vpdn 10 1"
will define that each VPDN call adds a charge of 10, which will be added to the load calculation for the duration of 1 lifetime bucket.
In combination with the call admission limit of 300, this will allow 30 VPDN calls per second.
Default session charges are 0 per 0 second (no session charge)
The current load charge can be viewed with the command
"show call admission stat"
If we set the vpdn call charges to 0 ( so no added session load for each session)
According to the formula, if we want to limit the cpu of the system to 80% then
(80+95)*100/200 ~ 88
means config of call admission load 100 1 and call admission limit 90
call admission limit 400
call admission vpdn 10 1
call admission load 100 1
The cpu will not reach a 100% now by far it won't so say for instance it would reach to 50% CPU, the added charge would be: ~48
Effectively giving you a cps rate of about 35 calls per second with this config.
The existing implementation is a composite metric of the previously mentioned 3 parameters of session charges, cpu charges and buffer utilization.
In live deployments we tend to use the CPU based charges to protect the RP of the BRAS router. The Session based charges is used to pace the incoming call rate to protect external peripherals such as RADIUS from being overloaded.
Because typically the charge for session charges is relatively high, that means that the effects of a higher CPU on the total charge are relatively small. This means that eventhough the CPU is high, we still might admit a descend number of sessions.
Decreasing the limit value to allow the cpu to take more effect will reduce the regular sessions per second admission which then will affect the over Calls Per Second (CPS) rate.
Research has shown that we want to dynamically measure and separately verify the charges of sessions and CPU against separate configured limits.
That is where the new-model of CAC focuses on.
The New-model allows us to measure the cpu against a separate limit from the session charges.
This section describes and elaborates on the configuration tasks associated with enabling Call Admission Control for Broadband routers.
Call admission limit 100
Sets the limit of the total charge upon which CAC should start rejecting calls
Call admission pppoe 10 1
Sets the charge per call type
Call admission load 100 1
Sets the multiplier and lifetime of the cpu based charges
Call admission new-model
Enables new model
Call admission limit 200
Sets the limit for the session charges
Call admission cpu-limit 60
Sets the limit of the cpu upon which the router should start rejecting calls
Call admission pppoe 10 1
Sets the charge per, in this example pppoe type, call.
C10k5-LAC#show call admission statistics
Call Admission Control is not operational
Show call admission statistics:
C10k5-LAC#show call admission statistics
Cac New Model (SRSM) is INACTIVE
Total call admission charges: 0, limit 0
Total calls rejected 11, accepted 101
Load metric: charge 0, unscaled 0%
Cac New Model (SRSM) is INACTIVE | New model is not operational |
Total call admission charges: 0, limit 0 | Current charges computed based on cpu and session charges and the configured maximum limit |
Total calls rejected 11, accepted 101 | Number of calls accepted or rejected by CAC |
Load metric: charge 0, unscaled 0% | CPU effects on the total charge. the charge value is the computed metric of cpu load as per formula above and unscaled is the actual cpu utilization in % |
C10k5-LAC#show call admission statistics
Cac New Model (SRSM) is ACTIVE
Total call Session charges: 0, limit 0
Total calls rejected 11, accepted 101
Reject reason: CPU-limit: 11 SessionCharges 0
Load metric: charge 1, unscaled 1%
Current actual CPU: 1%, Limit: 5%
Hardware CAC is currently not active
Explanation of fields:
Cac New Model (SRSM) is ACTIVE | Shows us that NEW-MODEL is configured and active |
Total call Session charges: 0, limit 0 | Shows the current session charges and the configured limit |
Total calls rejected 11, accepted 101 | The number of Calls that have been accepted and rejected by CAC |
Reject reason: CPU-limit: 11 SessionCharges 0 | New model explains the reject reason in cpu and session charges |
Load metric: charge 1, unscaled 1% | Computed load metric based on the CPU charges |
Current actual CPU: 1%, Limit: 5% | Actual CPU utilization and the configured limit |
Hardware CAC is currently not active | If a particular cisco router is enabled to add CAC support in Hardware it will show us the current status of the Routers hardware CAC status |
