10-29-2014 12:17 AM
Hi,
I have a Cisco 7206 Bras Router,
when the amount of pppoe request increase,The CPU of Router increases too,How can I stop Establishing pppoe session when Its going to Hang!!
Solved! Go to Solution.
11-04-2014 11:14 AM
You can use the command on the BBA group to limit the number of sessions globally/box wide total, or per vlan/per mac etc.
Another option is also to use call admission control with which you can throttle and stop accept new sessions when the memory, cpu etc are at defined levels.
regards
xander
ps. this is the XR OS forum, 7200's dont run XR, not a problem, but just so you know :)
11-08-2014 04:28 AM
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:
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:
Configuration Parameters
"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 |
11-04-2014 11:14 AM
You can use the command on the BBA group to limit the number of sessions globally/box wide total, or per vlan/per mac etc.
Another option is also to use call admission control with which you can throttle and stop accept new sessions when the memory, cpu etc are at defined levels.
regards
xander
ps. this is the XR OS forum, 7200's dont run XR, not a problem, but just so you know :)
11-07-2014 11:37 PM
Hi xander
I khnow That 7200 's dont run XR,How I can configure Call admission control in 7200 to stop accept new sessions when the cpu are at defined levels?
please help me,
regards
yasin
11-08-2014 04:28 AM
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:
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:
Configuration Parameters
"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 |
11-16-2014 10:51 AM
hi dear xthuijs,
Thank u for help it to solve this problem,
now i have new problem in BRAS Router,
the radius server sometimes does not set rate limit in some virtual-access users,but virtual template in Bras default set non rate limit per user,this problem makes some users rate limit is free,i khnow this problem comeback to radius but do we set default rate limit per user when is not taking rate limit from radius?
11-16-2014 01:25 PM
suspecting you are using lcp:interface-config=rate limit or similar type of avpair.
this creates full vai's. (eg virtual-access10), whereas for scale and in general you will want to use sub vais (eg virtual-access2.8).
so you configure a policy-map in IOS with a policer on it and then apply it via the avpair: cisco-avpair=ip:sub-qos-policy-out=NAME_OF_PMAP
if not, will need to see a debug sss feat name <feature> ev/er and debug radius
xander
11-16-2014 02:09 PM
11-16-2014 03:49 PM
in that case define a service policy like this
policy-map DEFAULT_SERVICE
class class-default
police rate <X> burst <whatever>
and then on the virtual-template do this:
int virtual-template 1
service-policy out DEFAULT_SERVICE
Define more policy-maps with different rates and apply them for those users via radius like this:
test Password="cisco"
Framed-Protocol=PPP,
Service-Type=Framed-User,
Framed-IP-Address=255.255.255.254,
Cisco-avpair="ipv4:dns-servers=1.2.3.4",
Cisco-avpair="subscriber:sub-qos-policy-out=DIFF_POLICE_SVC"
xander
11-18-2014 12:38 AM
hi dear xander,
ios router 7206 is (C7200P-JS-M), Version 12.2(31)SB18,
i want to run automatically change rate limit per user in Bras Router,
My radius server is linux based and connect to Bras,
just its not too change automatically when radius is set to another rate limit,
my aaa configuration is:
aaa authentication ppp ibs group radius
aaa authorization network ibs group radius
aaa accounting delay-start
aaa accounting suppress null-username
aaa accounting update periodic 3
aaa accounting network ibs start-stop group radius
!
aaa nas port extended
aaa server radius dynamic-author
client 128.140.1.7
server-key 7 0257510F5951
auth-type any
ignore session-key
ignore server-key
!
aaa session-id common
interface Virtual-Template1
mtu 1492
ip unnumbered Loopback0
ip access-group 101 in
no ip proxy-arp
ip mtu 1492
ip tcp adjust-mss 1436
ip policy route-map expire-users
no logging event link-status
no peer default ip address
no snmp trap link-status
keepalive 15 10
ppp mtu adaptive
ppp authentication pap ibs
ppp authorization ibs
ppp accounting ibs
vpdn authorization ibs
---------------------------------------
radius-server attribute 44 include-in-access-req
radius-server host X.X.X.X auth-port 1812 acct-port 1813
radius-server source-ports extended
radius-server retransmit 4
radius-server key 7 XXXXXXXXX
radius-server authorization default Framed-Protocol ppp
radius-server vsa send accounting
radius-server vsa send authentication
-----------------------------------------------------
whats wrong this config that automatically doesnt work??
11-18-2014 04:49 AM
hard to tell without debugs or what precisely is not working on a partial config too... if this is all aaa config, then I think I am missing the aaa group server radius ibs that pulls in your radius-server host.
or move to the following configuration:
aaa authentication ppp default group radius
aaa authorization network default group radius
int virtual-template 1
ppp authen pap
ppp author default
xander
11-19-2014 11:49 AM
hi xander,
do you say me how to config bras router (aaa config) for have automatically change rate limit per user,when user accounting is change priodic time?
please help me
11-20-2014 04:31 AM
This functionality is called ISG, you can use COA methodology to change the users service policy for QOS. This is nicely documented when you google for "ISG use case examples". there are some sample COA profiles, and IOS configs for that.
Also check asr9000 change of authorization via google on the support forums to download some COA tools.
cheers!
xander
12-15-2014 12:29 PM
hi mr alexander,
how i can reduce sss manager process in router 7200 ?that when it is pppoe ras router
12-15-2014 12:40 PM
you mean its cpu util? you can't... the SSS process is the integral part of all subscriber handling. it is the component that handles the interaction between access protocols, features (eg qos, acl etc), connection/disconnection and interfaces etc.
if there is high cpu on it, it is likely due to heavy churn or heavy feature combination. a quick debug on sss event may help understand what the heck it is doing and from there we can see if we can alleviate something, but other then that, it is just CAC (admission control) that can only help relieving the cpu during subscriber termination.
cheers
xander
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: