Mailing List Archive

We came up against the same problem a few weeks ago running 12.3(4)T9 on
7204VXR using PPPoA/L2TP VPDN.

Thanks for the info Dennis. Does not seem to be a pppoa command for the
version we are running. :(

Was forwarded the following from TAC:

http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_
guide09186a00800f4b47.html

Mark


-----Original Message-----


Message: 2
Date: Tue, 9 Aug 2005 15:42:19 -0700
From: Dennis Peng <dpeng@cisco.com>
Subject: Re: [cisco-bba] PPPOE attempts overwhelming Radius
To: Sam Meftahi <SAF@sonofon.dk>
Cc: cisco-bba@puck.nether.net
Message-ID: <20050809224214.GG19864@dhcp-171-69-89-146.cisco.com>
Content-Type: text/plain; charset=us-ascii

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@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@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-bba



------------------------------

Message: 3
Date: Thu, 11 Aug 2005 10:07:54 -0700
From: Dennis Peng <dpeng@cisco.com>
Subject: Re: [cisco-bba] ip local pool default
To: Mark Tohill <Mark@u.tv>
Cc: cisco-bba@puck.nether.net
Message-ID: <20050811170748.GB12591@dhcp-171-69-89-146.cisco.com>
Content-Type: text/plain; charset=us-ascii

No, that won't work.

Dennis

Mark Tohill [Mark@u.tv] wrote:
> Hi,
>
>
>
> Is it ok to add address space using something like:
>
>
>
> ip local pool default xxx.xxx.xxx.xxx yyy.yyy.yyy.yyy
>
>
>
> to the default local pool which is already populated with numerous
/24,
> for example.
>
>
>
> Than, remove the address space to be reclaimed from the pool with:
>
>
>
> no ip local pool default aaa.aaa.aaa.aaa bbb.bbb.bbb.bbb
>
>
>
> Has anyone tried this?
>
>
>
> Thanks
>
>
>

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



------------------------------

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


End of cisco-bba Digest, Vol 27, Issue 15
*****************************************