[cisco-bba] PPPOE attempts overwhelming Radius

[Dennis Peng]

In 12.3(2)T or later, a generic call admission control mechanism
exists which allows you to specify that only <n> number of sessions
can be established per time interval <t>. You can do this by
configuring:

call admission limit <n>
call admission load 0 32
call admission pppoe 1 <t>

If we ever exceed the load limit, wee will ignore any PADI's received.

Calculation of the current load is actually broken up into two parts,
one is the load caused by new sessions, the second is the "system"
load due to existing sessions.

With the "call admission pppoe <x> <y>" command, you are declaring
that each new PPPoE session puts a load of <x> for <y> seconds on the
box. Besides PPPoE, we also support declaring the load for PPPoA and
VPDN sessions.

The load of existing sessions is measured by the CPU utilization and
looking for buffer starvation. "call admission load <x> <y>" takes the
average of the CPU utilization and buffer utilization (which is either
0% or 95% depending on whether any public buffer pools have total >
permanent) and multiplies (scales) it by <x> to get the "system"
load. We poll the CPU/buffer stats every <y> seconds.

In my above example, I've ignored the system load by setting the
scaling factor to 0. Without declaring any session type load factors
(for PPPoE/PPPoA/VPDN), we simply look at the "system" load. You'll
have to tune the parameters to meet the capabilities of you network.

Dennis

Sam Meftahi [SAF at sonofon.dk] wrote:
> During an IOS upgrade, and reload many customers were unable to connect
> and some did but no IP address was assigned.
> 
> I suspect this is due to Radius not coping with BAS demand. Is there any
> ways to fine tune this process on BRAS? 
> 
>  
> 
> Thanks in advance
> 
>  
> 
> Sam
> 
>  
> 
>  
> 

> _______________________________________________
> cisco-bba mailing list
> cisco-bba at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-bba