pppoe uplink goes down several times a day, what is wrong
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
------------------------------------------------------------------------
# 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
------------------------------------------------------------------------
Quoted 3 lines · Jelle de Jong
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.)
Signature · 1 line
James Carlson 42.703N 71.076W <[email protected]>
Hi James,
Thank you for taking the time to look at my problems.
James Carlson wrote, on 21-12-09 14:49:
Quoted 17 lines
Quoted 3 lines · Jelle de Jong
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.
Quoted 8 lines
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?
Quoted 7 lines
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...
Quoted 4 lines
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.
Quoted 3 lines
(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
Quoted 12 lines · Jelle de Jong
Quoted 8 lines
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.
Quoted 7 lines
# 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.
Quoted 11 lines
Quoted 7 lines
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.
Quoted 9 lines
Quoted 4 lines
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.
Quoted 6 lines
Quoted 3 lines
(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?
Quoted 2 lines
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.
Signature · 1 line
James Carlson 42.703N 71.076W <[email protected]>