[RP-PPPoE] PADT Flood?

[Insane Laughing Clown]

Christian Costa wrote:
>  Hi ILC,
>
> That makes perfect sense in our situation here. We have a big wireless 
> network that at the moment behaves like a big lan. We are currently 
> planning to create VLANs and subnets  to try decreasing the amount of 
> broadcast traffic we currently have. With one pppoe server instance 
> per VLAN things should behave better.
> I've increased the lcp-echo-failure to 5 as opposed to 2 that we had 
> before.
> I don't think most clients are being affected by the flood happens but 
> it does generate spikes on all switch ports and I can see some clients 
> reconnect after the flood is gone.
> Many thanks for you reply.
You're welcome ;-)

Lots of wireless networks start out as a lan topology and work fine as 
long as the number of clients are low. At your scale however (800 - 900 
connected clients you said), this doesn't work so good. You can 
investigate using pppoe-relay at one or more strategic locations within 
your network - perhaps at a backhaul location or so. What this would do 
is make it so your pppoe traffic is directed at the mac address of the 
relay so the loss of one or more clients behind the relay won't result 
in mac address aging out and allowing pppoe frames to be flooded 
anywhere. The down side is that it makes server side management harder 
because any client behind a relay will show up as all the same mac, 
confounding tcpdump for example.

Your choice of wireless client gear also has an effect on this problem. 
A lot of stuff has no settings or knobs to tweek and so you get what you 
get. Motorola Canopy on the other hand has a strict mac address 
filtering policy so that the AP _does not_ forward unknown unicast 
traffic to subscribers which do not have that mac address in their 
table. This breaks a few minor use cases but results in very clean 
networking too and avoids this and other similar issues.

Your message here reminded me of a solution I was looking at earlier. 
The idea is that the client should regularly be sending _something_ back 
to the server - such as lcp-echo-request or actual ip layer traffic - 
and if we don't see anything then we should just stop talking (but not 
kill the session). I think this would go a long, long ways twords 
addressing this problem of aged out mac addresses. If that were 
implemented, then the next step would be to set lc-echo-failure to 
something on the order of a few thousand in order to allow clients a few 
days to have their sessions up before automatically terminating them. 
I'll see about that.

-ILC