[aklug] Re: router issues with ACS

On Sat, 5 Sep 2009, Lee wrote:

> I've discovered this also. With any of the wireless routers (I've got Buffalo and Asus).
>
> I think ACS has made some sort of change or changes to their system in the last 8
> months or so because things worked just fine for years before the last 8 months or so.
> Since then, good to sporadic to pathetic. But plug the modem directly into the demarc
> AND plug laptop directly into modem, and things work fine. Makes no sense, I know, but
> can't explain otherwise.
>
>> Thanks for the tip on poorly behaving routers. It turns out my Linksys
>> WRT54 GL is my conection problem. I plugged the ACS modem, in bridge
>> mode, directly into my box and use pppoe from there. No issues. This is
>> the second router that doesn't do well, with ACS pppoe stuff ?
>
> ---------
> To unsubscribe, send email to <aklug-request@aklug.org>
> with 'unsubscribe' in the message body.

All of the ACS redbacks use/offer a PPP payload MTU of 1460, and have
since at least 2003. These days with a very few exceptions 1492 could be
supported, 1460 came about to allow for L2TP overhead and a number of
broken home routers.

The redback will use 1460 facing the CPE, and it also does a "frag
anyway", to work around broken firewalls that drop ICMP frag needed. A
1500 payload with DF set headed to the customer will be fragmented even
with DF set.

On the upstream, if the CPE doing PPPoE ignores the offered MTU and uses
its own internal default (some of them are broken this way), any value up
to 1492 will generally work.

One thing that comes to mind is PPP keepalives via LCP echo. There are
some routers out there that when under load have trouble responding the
LCP echo requests the redbacks send. Too many failures in a row and the
session is dropped.

Session keepalives were activated (IIRC) 3 years back to deal with the
issue of hanging sessions, where a customer would reset the CPE and
be unable to reconnect because the redback still had a "live" session with
them.

I would have to check the exact values, but as I recall the timing and
fail count was very forgiving, there is no good reason for a PPPoE speaker
to miss even one echo responce, let along enough to cause a session drop,
but we do see it from time to time.

I had a first gen wireless linksys years back that did this. 960 down
through NAT and firewalling was fine, but if I had wired to wireless or
wireless to wireless transfers on the back side maxing out the 802.11 side
it maxed out the router CPU and it would start dropping about 1 out of
1000 packets on the DSL side, and more important stop responding to LCP
echo for 20 - 30 seconds at a time. I switched to running a seperate
PPPoE speaker and AP.

What type of modem do you have??

If your are running one of the little black paradyne ADSL1/2/2+ (6381-A2
or later) modems they are a TI based linux box, I know I tested routing on
them to at least 5m/1m a few years back (I have seen them running in
routed mode up to 10m/1m without issue, but I only recall doing extensive
testing up to 5m).

---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Sat Sep 5 23:35:12 2009