[RP-PPPoE] PADT Flood?

[Insane Laughing Clown]

Christian Costa wrote:
>  Hi there,
>
> We run a PPPoE server that has an average of 800-900 clients connected 
> to it.
> It seems that every so often lots of clients are dropped off and I 
> find the following in the log files:
>
>
>
> Aug 16 08:20:44 apollo pppoe-server[16156]: PADT for session 2935 
> received from 00:25:9C:0D:20:F1; should be from 00:16:B6:8F:34:73
> Aug 16 08:20:44 apollo pppoe-server[16156]: PADT for session 2185 
> received from 00:25:9C:0B:8F:9F; should be from 00:19:CB:F9:7B:7B
> Aug 16 08:20:44 apollo pppoe-server[16156]: PADT for session 221 
> received from 00:25:9C:0D:20:F1; should be from 00:15:6D:DC:27:8D
> ...
>
> By analyzing it further I found out that 8 different devices seem to 
> be causing it. I say causing it because that's where the packets come 
> from. It seems 8 devices are flooding the server with PADT messages 
> for all the other MAC addresses on the network.
> Has anyone one come across something like that before? I did lots of 
> research but couldn't find anything about it other than the same 
> question.
> Any help would be appreciated.


Yep, I hear your pain. I too have experienced this problem and in my 
case what happens is that if some client such as a netgear or linksys 
router is able to hear pppoe frames belonging to someone else, they 
respond this way.  The underlaying reason is that the network has lost 
the path to those mac addresses - for example, the real client 'went 
away' and the bridging tables are cleared of the client's mac address, 
but the pppoe server keeps sending to that mac not knowing the session 
is dead. The rules for switching are that if you don't know what port a 
destination mac address is on, you have to flood, which is the mechanism 
whereby other clients on your network can hear stray pppoe frames 
belonging to others.

What you want of course is for the server to cut any session off that 
really is dead, but the only officially supported way to know is for 
pppd to use lcp-echo requests and after some number of dropped requests 
to simply close the session. This has two edges tho - if you make the 
tolerances too tight (lcp-echo-interval some low number), you're wasting 
bandwidth. If you have lcp-echo-failure some low number like 2 for 
example, you aren't being forgiving enough in light packet loss 
scenarios and creating needless disconnections. You should use something 
and not omit these from your configuration, and it'll help, but it's not 
a complete solution.

Depending on your network (wireless??) you may be able to employ tricks 
like adjusting the mac address table aging timers in your equipment to 
go longer before aging out any mac address. This will reduce the 
mobility of mac addresses in your network but decrease the scope of the 
problem in an outage condition for you.

-ILC