[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