[RP-PPPoE] pppoe-server efficiency (was Re: IPv6 support)
Insane Laughing Clown
mike-rppppoe at tiedyenetworks.com
Tue Jul 30 15:07:20 EDT 2013
On 07/30/2013 11:13 AM, David F. Skoll wrote:
> On Tue, 30 Jul 2013 14:11:03 -0400
> "David F. Skoll"<dfs at roaringpenguin.com> wrote:
>
>> That's true. count_sessions_from_mac isn't called unless you use the
>> -x option, and pppoe_free_session is only called when a session
>> terminates, not for each control frame.
>
>>
Actually PADT was what I was referring to.
Nevertheless, on a busy server those functions {c,sh}ould be changed
>> to use hash lookups.
>
> Ah... actually, pppoe_free_session could be made to run in constant time
> by using a doubly-linked list of sessions instead of a singly-linked
> list. That just leaves count_sessions_from_mac that would need a
> hash table.
>
There's some general design issues. For example, a bad client or herd of
them all shitting out padi can overrun the server since there's no
sanity checking on the number of outstanding requests in flight. PADT
processing pays the lookup performance penalty every time one is
received wether it's valid or not. PADR isn't limited in any way and bad
clients can flood the server causing unlimited numbers of pppd's to be
created until the tables are full. All of this actually occurs on
production networks and the value of using hash keys is not so much that
it's elegant or anything, it's that going to the next level and enabling
the enforcing of effective limits on clients which protects the server
and allows it to continue serving legitimate requests, which presently
is not done in rp-pppoe and making it trivial to induce the dreaded 'no
client slots available' condition. Personally, there should be both
numerical limits on the number of sessions as well as the rate as which
any given client is allowed to create or terminate sessions and the only
way to do that would be with a hash table.
-ILC
More information about the RP-PPPoE
mailing list