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

XMLRPC sync errors since upgrade to 2.4.4

Scheduled Pinned Locked Moved HA/CARP/VIPs
64 Posts 13 Posters 12.9k Views
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.
  • N
    netblues
    last edited by Jan 24, 2019, 4:49 AM

    Now I know why I have kill states on gateway failover.
    sip states!!
    Without that, sip registrations don't work after failover until states are cleared manually.
    Funny thing is that current calls via pf aren't lost and keep working via the f/o peer.
    However new calls don't work.
    Obviously at the same time sip host can ping all sip remote gw via pfsense just fine.

    I believe we need an exclusion here. Sync interface is a special use interface, and doesn't have a gateway too.
    How about a feature of not clearing states on interfaces that do NOT have a gateway?
    Will that break anything ?
    (it would be better to fix sip issue as it dates back years too)

    1 Reply Last reply Reply Quote 0
    • J
      jimp Rebel Alliance Developer Netgate
      last edited by Jan 24, 2019, 5:29 PM

      The only way that happens is if you have a gateway somewhere that is down. The sync interface wouldn't normally be considered at all, it's just an innocent bystander. Look at your gateway list and see what shows as 'down', and fix that.

      Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

      Need help fast? Netgate Global Support!

      Do not Chat/PM for help!

      N 1 Reply Last reply Jan 24, 2019, 5:57 PM Reply Quote 0
      • N
        netblues @jimp
        last edited by Jan 24, 2019, 5:57 PM

        @jimp Innocent it is. however it does produce lots or noise emails.
        As for the gateways, well, nothing is down apart from openvpn bound to carp interfaces that go up when secondary node kicks in.
        So.. it is technically down but it cannot be "fixed" since it aint broken :)

        I understand, its a feature, but......

        1 Reply Last reply Reply Quote 0
        • J
          jimp Rebel Alliance Developer Netgate
          last edited by Jan 24, 2019, 6:47 PM

          Unless you are using those OpenVPN gateways in a gateway group, you can disable monitoring for them so they are always considered up, and thus would not trigger the state kill.

          Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

          Need help fast? Netgate Global Support!

          Do not Chat/PM for help!

          N 1 Reply Last reply Jan 24, 2019, 7:01 PM Reply Quote 0
          • N
            netblues @jimp
            last edited by Jan 24, 2019, 7:01 PM

            @jimp As a matter of fact I do, but it starts to feel too limited anyway, don't you think?
            Especially when this was "fixed" in 2.4.4
            And what if one has pppoe interfaces bound to carp vips, which is much more common, and also needs gateway monitoring?

            1 Reply Last reply Reply Quote 0
            • J
              jimp Rebel Alliance Developer Netgate
              last edited by Jan 24, 2019, 9:24 PM

              Again, nothing changed here in 2.4.4. If it worked at all before, it was by coincidence. This has always been the expected behavior of state killing on gateway failure when you have gateways that are down.

              Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

              Need help fast? Netgate Global Support!

              Do not Chat/PM for help!

              1 Reply Last reply Reply Quote 0
              • N
                netblues
                last edited by Jan 24, 2019, 11:11 PM

                I totally agree that this was the EXPECTED behaviour.
                Moving forward, the situation is simple.
                Whoever has state killing on gateway failure and an active/standby pair faces constant xml rpc sync errors on primary on every change, (and by mail too), which do raise concerns even to experienced net admins.

                There are good reasons to have state killing on (voip being the main one) and it is not always possible not to have gateways that are down in an active/standby setup, by design. (since pppoe is too dominant to ignore)
                So I humbly request a feature enhancement that will eliminate the errors (making an exception of the sync interface from state clearance being probably the most straight forward solution)

                1 Reply Last reply Reply Quote 0
                • J
                  jimp Rebel Alliance Developer Netgate
                  last edited by Jan 25, 2019, 12:02 AM

                  It is avoidable if you configure it as I stated above. The sync interface has nothing to do with it. It isn't nearly as "simple" as you imply. The states are flushed entirely, as they must be, there is no way to make an exception for any interface in pfctl.

                  If you want that, make a feature request upstream for pfctl in FreeBSD.

                  Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                  Need help fast? Netgate Global Support!

                  Do not Chat/PM for help!

                  N 1 Reply Last reply Jan 25, 2019, 12:14 AM Reply Quote 0
                  • N
                    netblues @jimp
                    last edited by Jan 25, 2019, 12:14 AM

                    @jimp Killing me softly with these words :)

                    1 Reply Last reply Reply Quote 0
                    • T
                      talaverde
                      last edited by Mar 8, 2020, 10:11 PM

                      This post is deleted!
                      1 Reply Last reply Reply Quote 0
                      • First post
                        Last post
                      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                        [[user:consent.lead]]
                        [[user:consent.not_received]]