Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

PPPOE Session

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!!

2 ACCEPTED SOLUTIONS

Accepted Solutions
Cisco Employee

You can use the command on

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 :)

Xander Thuijs CCIE #6775 Principal Engineer ASR9000, CRS, NCS6000 & IOS-XR
Cisco Employee

Back in 2008 I rewrote part

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:

 

Call Admission Control for Broadband


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.

 

Prerequisites for Call Admission Control

 

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.

 

Information About Call Admission Control

 

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

 

 

 

 

How it works

 

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 Control example mode of operation:

 

Enabling Call admission control

 

"call admission limit <limit>"  sets the maximum charge the system can have upon which CAC will reject the sessions and effectively enables CAC.

 

Charges

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.

CPU based charges


 
"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%.

 


 

Session based charges


 
"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

 

Example 3:


 
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.

 

 

Old Model vs New Model

 

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.

 

 

 

 

Configuration Tasks

 

This section describes and elaborates on the configuration tasks associated with enabling Call Admission Control for Broadband routers.

 

Configuration tasks old Model

 

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

 

Configuration tasks new Model

 

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.

 

 

Verification of operation

 

Not enabled:

 

C10k5-LAC#show call admission statistics

Call Admission Control is not operational

 

Old Model

 

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 %

 

 

 

New Model

 

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

Xander Thuijs CCIE #6775 Principal Engineer ASR9000, CRS, NCS6000 & IOS-XR
13 REPLIES
Cisco Employee

You can use the command on

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 :)

Xander Thuijs CCIE #6775 Principal Engineer ASR9000, CRS, NCS6000 & IOS-XR
New Member

Hi xanderI khnow That 7200 's

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

Cisco Employee

Back in 2008 I rewrote part

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:

 

Call Admission Control for Broadband


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.

 

Prerequisites for Call Admission Control

 

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.

 

Information About Call Admission Control

 

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

 

 

 

 

How it works

 

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 Control example mode of operation:

 

Enabling Call admission control

 

"call admission limit <limit>"  sets the maximum charge the system can have upon which CAC will reject the sessions and effectively enables CAC.

 

Charges

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.

CPU based charges


 
"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%.

 


 

Session based charges


 
"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

 

Example 3:


 
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.

 

 

Old Model vs New Model

 

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.

 

 

 

 

Configuration Tasks

 

This section describes and elaborates on the configuration tasks associated with enabling Call Admission Control for Broadband routers.

 

Configuration tasks old Model

 

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

 

Configuration tasks new Model

 

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.

 

 

Verification of operation

 

Not enabled:

 

C10k5-LAC#show call admission statistics

Call Admission Control is not operational

 

Old Model

 

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 %

 

 

 

New Model

 

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

Xander Thuijs CCIE #6775 Principal Engineer ASR9000, CRS, NCS6000 & IOS-XR
New Member

hi dear xthuijs,Thank u for

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?

Cisco Employee

suspecting you are using lcp

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
 

Xander Thuijs CCIE #6775 Principal Engineer ASR9000, CRS, NCS6000 & IOS-XR
New Member

I want to define rate limit

I want to define rate limit by default, to users who are not able to get rate limit from radius, will be allocated. What is this command?
----where is set "avpair" command?
Cisco Employee

in that case define a service

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

Xander Thuijs CCIE #6775 Principal Engineer ASR9000, CRS, NCS6000 & IOS-XR
New Member

hi dear xander,ios router

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??

Cisco Employee

hard to tell without debugs

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

Xander Thuijs CCIE #6775 Principal Engineer ASR9000, CRS, NCS6000 & IOS-XR
New Member

hi xander,do you say me how

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

 

Cisco Employee

This functionality is called

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

Xander Thuijs CCIE #6775 Principal Engineer ASR9000, CRS, NCS6000 & IOS-XR
New Member

hi mr alexander,how i can

hi mr alexander,

how i can reduce sss manager process in router 7200 ?that when it is pppoe ras router

Cisco Employee

you mean its cpu util? you

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

Xander Thuijs CCIE #6775 Principal Engineer ASR9000, CRS, NCS6000 & IOS-XR
462
Views
0
Helpful
13
Replies
CreatePlease to create content