pppoe uplink goes down several times a day, what is wrong

pppoe uplink goes down several times a day, what is wrong

[Jelle de Jong]

[-- Attachment #1: Type: text/plain, Size: 851 bytes --]

Hello everybody,

I got a PPPoE uplink to a big Dutch internet service provider, and I
am having stability issues. My uplink is going down for very short
times but it happens several times a day.

I just had major network move and the physical copper line changed so
I think I can rule out bad coper connections now. I had the same
issues on the old location though.

The modem I use is a DrayTek Vigor 3100V (latest firmware) in PPPoE
bridge mode (1) it behaves complete transparent, so I let the Linux
server do as much as possible.

I am wondering what I am doing wrong, is there something I should
change on the software side? Should I change the modem configuration?
Stop using PPPoE?

Please see the attachment for the configuration and debug information.

1) http://imagebin.ca/img/aSt5Wc-c.png

Any help is appreciated,

Best regards,

Jelle


[-- Attachment #2: setup-sammy-pppoe-debug01.txt --]
[-- Type: text/plain, Size: 4392 bytes --]

------------------------------------------------------------------------

# pppoe uplink goes down several times a day, what is going wrong?

------------------------------------------------------------------------

# grep -i pppd /var/log/syslog
Dec 21 06:37:24 sammy pppd[2954]: No response to 4 echo-requests
Dec 21 06:37:24 sammy pppd[2954]: Serial link appears to be disconnected.
Dec 21 06:37:24 sammy pppd[2954]: Connect time 2681.4 minutes.
Dec 21 06:37:24 sammy pppd[2954]: Sent 198282561 bytes, received 314194095 bytes.
Dec 21 06:37:30 sammy pppd[2954]: Connection terminated.
Dec 21 06:37:30 sammy pppd[2954]: Modem hangup
Dec 21 06:37:50 sammy pppd[2954]: PPP session is 6
Dec 21 06:37:50 sammy pppd[2954]: Using interface ppp0
Dec 21 06:37:50 sammy pppd[2954]: Connect: ppp0 <--> eth5
Dec 21 06:37:54 sammy pppd[2954]: PAP authentication succeeded
Dec 21 06:37:54 sammy pppd[2954]: peer from calling number 00:50:7F:DB:D3:48 authorized
Dec 21 06:37:54 sammy pppd[2954]: Cannot determine ethernet address for proxy ARP
Dec 21 06:37:54 sammy pppd[2954]: local  IP address 188.201.xxx.xxx
Dec 21 06:37:54 sammy pppd[2954]: remote IP address 62.12.4.28
Dec 21 06:37:54 sammy pppd[2954]: primary   DNS address 213.75.63.36
Dec 21 06:37:54 sammy pppd[2954]: secondary DNS address 213.75.63.70
Dec 21 08:32:56 sammy pppd[2954]: No response to 4 echo-requests
Dec 21 08:32:56 sammy pppd[2954]: Serial link appears to be disconnected.
Dec 21 08:32:56 sammy pppd[2954]: Connect time 115.1 minutes.
Dec 21 08:32:56 sammy pppd[2954]: Sent 10170461 bytes, received 28994956 bytes.
Dec 21 08:33:02 sammy pppd[2954]: Connection terminated.
Dec 21 08:33:02 sammy pppd[2954]: Modem hangup
Dec 21 08:33:22 sammy pppd[2954]: PPP session is 6
Dec 21 08:33:22 sammy pppd[2954]: Using interface ppp0
Dec 21 08:33:22 sammy pppd[2954]: Connect: ppp0 <--> eth5
Dec 21 08:33:27 sammy pppd[2954]: PAP authentication succeeded
Dec 21 08:33:27 sammy pppd[2954]: peer from calling number 00:50:7F:DB:D3:48 authorized
Dec 21 08:33:27 sammy pppd[2954]: Cannot determine ethernet address for proxy ARP
Dec 21 08:33:27 sammy pppd[2954]: local  IP address 188.201.xxx.xxx
Dec 21 08:33:27 sammy pppd[2954]: remote IP address 62.12.4.28
Dec 21 08:33:27 sammy pppd[2954]: primary   DNS address 213.75.63.36
Dec 21 08:33:27 sammy pppd[2954]: secondary DNS address 213.75.63.70

------------------------------------------------------------------------

# grep -i e1000 /var/log/syslog
Dec 21 06:35:19 sammy kernel: [557976.760139] e1000: eth5 NIC Link is Down
Dec 21 06:35:21 sammy kernel: [557978.616469] e1000: eth5 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX
Dec 21 06:35:24 sammy kernel: [557982.236149] e1000: eth5 NIC Link is Down
Dec 21 06:35:27 sammy kernel: [557984.468468] e1000: eth5 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX
Dec 21 08:30:41 sammy kernel: [564898.420139] e1000: eth5 NIC Link is Down
Dec 21 08:30:42 sammy kernel: [564900.372459] e1000: eth5 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX
Dec 21 08:30:46 sammy kernel: [564903.892134] e1000: eth5 NIC Link is Down
Dec 21 08:30:48 sammy kernel: [564906.156460] e1000: eth5 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX

------------------------------------------------------------------------

# cat /etc/ppp/peers/dsl-provider
# Minimalistic default options file for DSL/PPPoE connections

noipdefault
defaultroute
replacedefaultroute
hide-password
#lcp-echo-interval 30
#lcp-echo-failure 4
noauth
persist
#mtu 1492
maxfail 0
holdoff 20
plugin rp-pppoe.so eth5
usepeerdns
user "KPN1"

------------------------------------------------------------------------

# ifconfig -a ppp
ppp0      Link encap:Point-to-Point Protocol
          inet addr:188.201.124.57  P-t-P:62.12.4.28  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:614021 errors:0 dropped:0 overruns:0 frame:0
          TX packets:502294 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:691562515 (659.5 MiB)  TX bytes:67199257 (64.0 MiB)

------------------------------------------------------------------------

# cat /etc/network/interfaces
auto dsl-provider
  iface dsl-provider inet ppp
  pre-up /sbin/ifconfig eth5 up
  provider dsl-provider

------------------------------------------------------------------------

Re: pppoe uplink goes down several times a day, what is wrong

[James Carlson]

Jelle de Jong wrote:
> I am wondering what I am doing wrong, is there something I should
> change on the software side? Should I change the modem configuration?
> Stop using PPPoE?

Your debug log shows the following:

Dec 21 06:37:54 sammy pppd[2954]: primary   DNS address 213.75.63.36
Dec 21 06:37:54 sammy pppd[2954]: secondary DNS address 213.75.63.70
Dec 21 08:32:56 sammy pppd[2954]: No response to 4 echo-requests
Dec 21 08:32:56 sammy pppd[2954]: Serial link appears to be disconnected.
Dec 21 08:32:56 sammy pppd[2954]: Connect time 115.1 minutes.

That indicates that your link was up and working for almost two hours,
and then was torn down because the ISP's server suddenly stopped
responding to LCP Echo-Request messages from your system.

If it happens this way every time, then I would suspect that your ISP
may have set a time limit on connections.  Some ISPs are known for doing
such things, especially those that have a dial-up background.  They view
their service as being "on-demand" and thus an always-connected client
is one that's abusing the terms of service.  (That having everyone
connected all the time costs no more than having them connect on demand
doesn't seem to factor into those calculations.  There's no technical
accounting for business rules ...)

If it seems to be "random" rather than a fixed interval, then that's
probably not the problem.  It's possible that the ISP's server is
crashing occasionally or that it's experiencing some sort of
communications problem or that the path between you and that server (the
ATM network) is itself unreliable.  The key information that's needed to
identify such a problem would be on the ISP's systems (or may need some
investigation and analysis).

The bottom line, I think, is that your ISP is the only entity that can
investigate and solve the problem properly.  If your ISP doesn't take
your complaints about reliability seriously, then it's time to find a
new one.

(As for PPPoE, I'd certainly recommend avoiding that if you can.  It's a
horrible mess as a protocol.  In this case, though, I don't think it's
to blame for your problems.)

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: pppoe uplink goes down several times a day, what is wrong

[Jelle de Jong]

Hi James,

Thank you for taking the time to look at my problems.

James Carlson wrote, on 21-12-09 14:49:
> Jelle de Jong wrote:
>> I am wondering what I am doing wrong, is there something I should
>> change on the software side? Should I change the modem configuration?
>> Stop using PPPoE?
> 
> Your debug log shows the following:
> 
> Dec 21 06:37:54 sammy pppd[2954]: primary   DNS address 213.75.63.36
> Dec 21 06:37:54 sammy pppd[2954]: secondary DNS address 213.75.63.70
> Dec 21 08:32:56 sammy pppd[2954]: No response to 4 echo-requests
> Dec 21 08:32:56 sammy pppd[2954]: Serial link appears to be disconnected.
> Dec 21 08:32:56 sammy pppd[2954]: Connect time 115.1 minutes.
> 
> That indicates that your link was up and working for almost two hours,
> and then was torn down because the ISP's server suddenly stopped
> responding to LCP Echo-Request messages from your system.
> 
> If it happens this way every time, then I would suspect that your ISP
> may have set a time limit on connections.  Some ISPs are known for doing
> such things, especially those that have a dial-up background.  They view
> their service as being "on-demand" and thus an always-connected client
> is one that's abusing the terms of service.  (That having everyone
> connected all the time costs no more than having them connect on demand
> doesn't seem to factor into those calculations.  There's no technical
> accounting for business rules ...)

The disconnection interval seems random, as you can see the logs
showed two disconnects this day.

# grep -i pppd /var/log/syslog | grep -i time
Dec 21 06:37:24 sammy pppd[2954]: Connect time 2681.4 minutes.
Dec 21 08:32:56 sammy pppd[2954]: Connect time 115.1 minutes.

The connection is a G.SHDSL 2048:2048 1:1 business connection very
expensive by the biggest ISP in our country (not saying the ISP is
good) I don't think they have a connection time limit?

> If it seems to be "random" rather than a fixed interval, then that's
> probably not the problem.  It's possible that the ISP's server is
> crashing occasionally or that it's experiencing some sort of
> communications problem or that the path between you and that server (the
> ATM network) is itself unreliable.  The key information that's needed to
> identify such a problem would be on the ISP's systems (or may need some
> investigation and analysis).

I changed the Siemens 5890 provided by the ISP with a DrayTek Vigor
3100. The Siemens modem did NAT and was not transparent enough. But by
doing this the support level provided by the ISP drops to a minimum...

> The bottom line, I think, is that your ISP is the only entity that can
> investigate and solve the problem properly.  If your ISP doesn't take
> your complaints about reliability seriously, then it's time to find a
> new one.

I got a vendor locking, The current DSL is pre-fibre solution because
the completion of the fibre internet connection is taking longer then
anticipated, and the ISP is the only fibre capable provider in the
Netherlands for the location of the new office.

> (As for PPPoE, I'd certainly recommend avoiding that if you can. It's a
> horrible mess as a protocol. In this case, though, I don't think it's
> to blame for your problems.)

Is there a way to be more sure about PPPoE not being the issue. Can
there be something wrong with the LCP Echo-Request messages?

I know PPPoE is a horrible mess. I prefer 1483 bridged IP LLC, but I
can't use it in this case.

Thanks in advance,

Best regards,

Jelle

Re: pppoe uplink goes down several times a day, what is wrong

[James Carlson]

Jelle de Jong wrote:
>> If it happens this way every time, then I would suspect that your ISP
>> may have set a time limit on connections.  Some ISPs are known for doing
>> such things, especially those that have a dial-up background.  They view
>> their service as being "on-demand" and thus an always-connected client
>> is one that's abusing the terms of service.  (That having everyone
>> connected all the time costs no more than having them connect on demand
>> doesn't seem to factor into those calculations.  There's no technical
>> accounting for business rules ...)
> 
> The disconnection interval seems random, as you can see the logs
> showed two disconnects this day.
> 
> # grep -i pppd /var/log/syslog | grep -i time
> Dec 21 06:37:24 sammy pppd[2954]: Connect time 2681.4 minutes.
> Dec 21 08:32:56 sammy pppd[2954]: Connect time 115.1 minutes.
> 
> The connection is a G.SHDSL 2048:2048 1:1 business connection very
> expensive by the biggest ISP in our country (not saying the ISP is
> good) I don't think they have a connection time limit?

OK; that certainly narrows things down.

>> If it seems to be "random" rather than a fixed interval, then that's
>> probably not the problem.  It's possible that the ISP's server is
>> crashing occasionally or that it's experiencing some sort of
>> communications problem or that the path between you and that server (the
>> ATM network) is itself unreliable.  The key information that's needed to
>> identify such a problem would be on the ISP's systems (or may need some
>> investigation and analysis).
> 
> I changed the Siemens 5890 provided by the ISP with a DrayTek Vigor
> 3100. The Siemens modem did NAT and was not transparent enough. But by
> doing this the support level provided by the ISP drops to a minimum...

If this is a commercial application (rather than something you just hack
around with), I'd certainly recommend staying with whatever the ISP is
best equipped to support.

I understand the appeal of getting unadulterated packets right to your
system -- most of those stand-alone NAT devices can be downright evil --
but when you run into a problem like this that requires the ISP's
involvement, you're bound to run into trouble.

Just the same, it's well worth asking for help from them in tracking
down the problem.

>> The bottom line, I think, is that your ISP is the only entity that can
>> investigate and solve the problem properly.  If your ISP doesn't take
>> your complaints about reliability seriously, then it's time to find a
>> new one.
> 
> I got a vendor locking, The current DSL is pre-fibre solution because
> the completion of the fibre internet connection is taking longer then
> anticipated, and the ISP is the only fibre capable provider in the
> Netherlands for the location of the new office.

I see.

>> (As for PPPoE, I'd certainly recommend avoiding that if you can. It's a
>> horrible mess as a protocol. In this case, though, I don't think it's
>> to blame for your problems.)
> 
> Is there a way to be more sure about PPPoE not being the issue. Can
> there be something wrong with the LCP Echo-Request messages?

You could trace all of the packets on the wire with something like
ethereal or tcpdump.  It'll likely change timing enough that the problem
won't happen anymore, and it'll be hard to examine in any case, but
without help from your ISP, I don't see much alternative.

The information your ISP could provide would be any error messages they
see on their servers or from their ATM gear that corresponds with the
approximate time you're seeing the disconnect.

They should be able (and willing) to do at least that without having to
have any sort of special gear on your site.  If they're not willing to
examine their own log files, are you sure you want to do business with them?

> I know PPPoE is a horrible mess. I prefer 1483 bridged IP LLC, but I
> can't use it in this case.

I understand the pain.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>