PPPOE

This topic contains 5 replies, has 0 voices, and was last updated by  mdemel 2 years, 6 months ago.

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #43549

    mdemel
    Member

    First off thanks to Fulvio for this project.

    I will try to explain the best I can on what is happening. For a while now I have been having trouble with PPPOE and the FailoverNetbalancer.

    Current setup is:
    Zeroshell Release 2.0.RC2
    P4 box with 3 nics

    ISP1 – Wireless to Ethernet always on (ETH01)
    ISP2 – DSL modem attached to ETH02 with PPPoE (PPP0)
    1 – LAN (ETH00)

    NAT is enabled for both ISP interfaces.
    Default route is set to PPP0
    Netbalancer is configured with ETH01 and PPP0 as the gateways.
    Failover Monitor is set with default timeout and Immediately restart PPPoE enabled
    Failover IP Addresses are populated with valid external addess.

    Everything works perfectly until ZS detects a fault on the PPP0. The link goes down as expected but will never come back up.
    I have witnessed the PPP0 redialreconnect in the “Network” tab, with an IP address from the peer so I believe that ZS is trying to reconnect but the FailoverNetbalancer is not re-enabling the gateway when the modem is redialed. I can also verify when this event occurs that the PPP0 gateway can not ping the ips in the “Failover IP Addresses” when I click the “TEST” button (see the Code section). This interface will stay like that, however I can click “save” under the “NET BALANCER” tab and the link will come back to life. In the code section at the time stamps 04:47:23 and 17:01:19 is where I clicked “save”.

    So in short ZS is redailing the modem and receives an IP address but the Net Balancer Failover is not seeing the connection so that it can ping the ips in the failover list to bring the interface back up.

    I have tried many different settings and even wiped the system and started over and have the same issue. I have read the documentation and the forum and if I’m missing something, for the life of me I can not find what I have done wrong.
    I’m willing to try a statrupcron job or change some settings that you can suggest.

    04:41:04 	[ICMP] Failover monitor has started
    04:44:24 (TEST) ==============================================================
    04:44:24 (TEST) GATEWAY : DEFAULT GATEWAY (ppp0)
    04:44:25 (TEST) => [8.8.8.8] : Success (Round Trip Time: 339 ms)
    04:44:25 (TEST) => [4.2.2.2] : Success (Round Trip Time: 362 ms)
    04:44:25 [ICMP] Failover monitor has started
    04:44:25 (TEST) => [74.125.227.110] : Success (Round Trip Time: 267 ms)
    04:44:25 (TEST) GATEWAY : ERF (ETH01)
    04:44:26 (TEST) => [8.8.8.8] : Success (Round Trip Time: 68.4 ms)
    04:44:26 (TEST) => [4.2.2.2] : Success (Round Trip Time: 26.9 ms)
    04:44:26 (TEST) => [74.125.227.110] : Success (Round Trip Time: 23.8 ms)
    04:44:26 (TEST) ==============================================================
    04:44:27 [ICMP] Failover monitor has started
    04:45:54 Default Route has been changed: nexthop dev ETH01 weight 1 realm 102
    04:46:58 [ICMP] No link detected with the gateway (DEFAULT GATEWAY)
    04:46:58 [ICMP] FAULT: DEFAULT GATEWAY (Interface: ppp0) [Last Uptime: 6m 22s]
    04:47:23 [ICMP] Failover monitor has started
    04:47:23 [ICMP] RECOVERED: DEFAULT GATEWAY (Interface: ppp0) [Last Downtime: 25s]
    04:47:24 Default Route has been changed: nexthop dev ppp0 weight 1 realm 100 nexthop dev ETH01 weight 1 realm 102
    06:25:11 [ICMP] No link detected with the gateway (DEFAULT GATEWAY)
    06:25:11 [ICMP] FAULT: DEFAULT GATEWAY (Interface: ppp0) [Last Uptime: 1h 37m 48s]
    06:25:11 Default Route has been changed: nexthop dev ETH01 weight 1 realm 102
    16:54:36 (TEST) ==============================================================
    16:54:36 (TEST) GATEWAY : DEFAULT GATEWAY (ppp0)
    16:54:36 (TEST) => [8.8.8.8] : ERROR
    16:54:36 (TEST) => [4.2.2.2] : ERROR
    16:54:36 (TEST) => [74.125.227.110] : ERROR
    16:54:36 (TEST) GATEWAY : ERF (ETH01)
    16:54:37 (TEST) => [8.8.8.8] : Success (Round Trip Time: 117 ms)
    16:54:37 (TEST) => [4.2.2.2] : Success (Round Trip Time: 216 ms)
    16:54:37 (TEST) => [74.125.227.110] : Success (Round Trip Time: 51.2 ms)
    16:54:37 (TEST) ==============================================================
    16:54:37 [ICMP] Failover monitor has started
    17:00:05 (TEST) ==============================================================
    17:00:05 (TEST) GATEWAY : DEFAULT GATEWAY (ppp0)
    17:00:05 (TEST) => [8.8.8.8] : ERROR
    17:00:05 (TEST) => [4.2.2.2] : ERROR
    17:00:05 (TEST) => [74.125.227.110] : ERROR
    17:00:05 (TEST) GATEWAY : ERF (ETH01)
    17:00:06 (TEST) => [8.8.8.8] : Success (Round Trip Time: 124 ms)
    17:00:06 (TEST) => [4.2.2.2] : Success (Round Trip Time: 99.8 ms)
    17:00:06 (TEST) => [74.125.227.110] : Success (Round Trip Time: 51.9 ms)
    17:00:06 (TEST) ==============================================================
    17:00:06 [ICMP] Failover monitor has started
    17:00:52 (TEST) ==============================================================
    17:00:52 (TEST) GATEWAY : DEFAULT GATEWAY (ppp0)
    17:00:56 (TEST) => [8.8.8.8] : ERROR
    17:01:00 (TEST) => [4.2.2.2] : ERROR
    17:01:04 (TEST) => [74.125.227.110] : ERROR
    17:01:04 (TEST) GATEWAY : ERF (ETH01)
    17:01:04 (TEST) => [8.8.8.8] : Success (Round Trip Time: 50.4 ms)
    17:01:04 (TEST) => [4.2.2.2] : Success (Round Trip Time: 38.9 ms)
    17:01:04 (TEST) => [74.125.227.110] : Success (Round Trip Time: 34.0 ms)
    17:01:04 (TEST) ==============================================================
    17:01:04 [ICMP] Failover monitor has started
    17:01:19 [ICMP] Failover monitor has started
    17:01:20 [ICMP] RECOVERED: DEFAULT GATEWAY (Interface: ppp0) [Last Downtime: 10h 36m 8s]
    17:01:20 Default Route has been changed: nexthop dev ppp0 weight 1 realm 100 nexthop dev ETH01 weight 1 realm 102
    17:01:26 (TEST) ==============================================================
    17:01:26 (TEST) GATEWAY : DEFAULT GATEWAY (ppp0)
    17:01:26 (TEST) => [8.8.8.8] : Success (Round Trip Time: 92.6 ms)
    17:01:26 (TEST) => [4.2.2.2] : Success (Round Trip Time: 80.8 ms)
    17:01:26 (TEST) => [74.125.227.110] : Success (Round Trip Time: 83.7 ms)
    17:01:27 (TEST) GATEWAY : ERF (ETH01)
    17:01:27 (TEST) => [8.8.8.8] : Success (Round Trip Time: 41.6 ms)
    17:01:27 (TEST) => [4.2.2.2] : Success (Round Trip Time: 49.9 ms)
    17:01:27 (TEST) => [74.125.227.110] : Success (Round Trip Time: 47.6 ms)
    17:01:27 (TEST) ==============================================================
    17:01:27 [ICMP] Failover monitor has started
    #52615

    zgypa
    Member

    mdemel,

    i have the same exact situation, and i’ve had it ever since ZS 1 beta 15 or so: i’ve had it with a satellite modem, and three different kinds of DSL modems. I’ve had it with new and old profiles: link goes down and comes back up, however NetBalancer doesn’t realizes it’s back up until i manually de-activate it and re-activate it, which defeats the entire purpose of having the FailOver feature in the first place. I’m still using NetBalancer for IP address based routing.

    Did you figure something out?

    #52616

    gastone
    Member

    Hello,

    I’m an user of the Italian forum and I spend lot of times trying to solve this issue.

    Finally I discovered that with ZS 3.2.1 the problem is solved, but it’s necessary to use the most recent kernel 3.4.90-ZS

    Infact with the “standard” kernel 3.14.21-ZS (delivered with ZS 3.2.1) this issue was still there.

    By default the ZS image contain kernel version 3.14.21-ZS, as far as I know it’s necessary an active subscription to upgrade ZS 3.2.1 with Kernel version 3.4.90-ZS.

    Hope it helps

    #52617

    zgypa
    Member

    gastone,

    how about the 3.14.31-ZS stock kernel from 3.3.2? I haven’t tested it yet. The older 3.4.90 kernel is no longer available.

    #52618

    imported_fulvio
    Participant

    Hi,
    for the release 3.3.2 it is available a fix into repository.
    Regards
    Fulvio

    #52619

    gastone
    Member

    Hello Fulvio,

    thank you for your fix #23320.

    Your correction works well if ICMP failover checking is enabled, but it seems to have the same identical behaviour (PPPoE back available but stay “down” forever in NetBalancer) if ICMP failover checking is disabled.

    I remember in older version the ICMP failover checking was not mandatory… Can you please make a double check?

    Thank you very much for the time you dedicate to this excellent job. 😛

    #52620

    WaltonQuake
    Member

    @gastone wrote:

    Hello Fulvio,

    thank you for your fix #23320.

    Your correction works well if ICMP failover checking is enabled, but it seems to have the same identical behaviour (PPPoE back available but stay “down” forever in NetBalancer) if ICMP failover checkout the pics of venapro which is disabled.

    I remember in older version the ICMP failover checking was not mandatory… Can you please make a double check?

    Thank you very much for the time you dedicate to this excellent job. 😛

    Hey Gastone, I just noticed the same thing when I tried it. I take it there was no fix?

Viewing 7 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.