Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    PPPoE Failover

    HA/CARP/VIPs
    2
    5
    4.4k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M
      mikishapiro
      last edited by

      Hi gents.

      been running CARP for a while, first ucarp on gentoo, theh OpenBSD, now pfSense dev 1.0.1 (definitely looks like the best of all worlds), just got one final thing I need to apparently hack manually.

      My modem - an ancient alcatel speedtouch home - will only do PPPoE bridging, it doesn't support establishing a PPPoE connection itself. Hence I need to set up PPPoE dialout on the firewalls.

      What I've done (quite successfully) in previous setups is rigged the become-carp-master and become-carp-slave scripts to either establish or drop the WAN PPPoE connection respectively, so the carp master is always the one who is dialing out.

      My question -
      a. where do the scripts that run on carp state-changes live (or when can I tie such in?)
      and
      b. how do I manually start and stop PPPoE from shell "the way the deve meant it to be done" from shell?

      Thanks!

      1 Reply Last reply Reply Quote 0
      • H
        hoba
        last edited by

        You probably can use dial on demand on both systems with a short idle timeout. This way when the master dies the backup will dial on demand out. If the master comes back it will grab the gateway at lan again. As the backupmachine doesn't have any traffic now it will drop the line after the timeout. This should work given that there is always some traffic from lan to wan. The failover to the slave should happen pretty quick, however falling back to master will depend on the timeout setting.

        1 Reply Last reply Reply Quote 0
        • M
          mikishapiro
          last edited by

          You probably can use dial on demand on both systems with a short idle timeout.

          That's a totally wrong way of doing it. It'll have them compete for the line instead of knowing at any given moment whether they should be dialing out or not, it opens the possibility of no-traffic-no-link-can't-ssh-in-from-the-outside scenario (can hacked around by keeping an active pinger, which also works only when the CARP link is a MASTER, but then it becomes hack-on-hack-on-hack).

          Sorry, I'd rather keep to KISS, and hacking the carp scripts to set the link in its correct state is much cleaner. Both my questions remain as yet unanswered… :-(

          1 Reply Last reply Reply Quote 0
          • M
            mikishapiro
            last edited by

            Maybe worth adding

            a. I run a full-blown FreeBSD distro underneath - compiler, ports, RAID1, the works. I don't want and don't need to keep the system stock-generic/Firmware-upgradeable/configured-via-webGui-only and while I consider the webgui a very useful, but not really mandatory tool.

            b. I'm a coder, sysadmin and among other things do very-high-level bourne work for a living. I can hack a dialout script. Honest. I'm simply asking for someone who knows the system to give me a general direction on how the mechanics work underneath instead of figuring it out myself, not asking anyone to actually do (or even provide the instructions how to do) the hacking for me.

            Cheerios.

            1 Reply Last reply Reply Quote 0
            • M
              mikishapiro
              last edited by

              To answer the first of my two questions, I just came up with this:

              http://kerneltrap.org/node/1021

              Which basically means you can't bind scripts to it, just monitor link status from cron and act upon it (MASTER -> dial out)

              Which brings back the second question.

              What's the proper way of initiating PPPoE dialout from shell?

              1 Reply Last reply Reply Quote 0
              • First post
                Last post
              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.