Navigation

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

    Most CARP VIPs work one doesnt (Both think they are master) - any ideas?

    HA/CARP/VIPs
    2
    4
    2619
    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.
    • G
      gabrielpc1190 last edited by

      I have the same problem with one of 9 VIPs. But my log is full  ::) of this on the two boxes:

      Act         Time                       If         Source   Destination  Proto
      Blocked, Oct 16 15:31:26 6WAN2MB   172.16.0.18   224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 100, authtype none, intvl 1s, length 36, addrs(7) VRRP

      If I clic on the red X it shows=
      @11 scrub in on ste0 all fragment reassemble
      @11 block drop in log quick proto carp from (self:26) to any

      I haven't found any rule that match this.  :(

      My two pfsense boxes are directly connected through the pfsync interface with a cable from one to another.
      If the other 8 VIPs works why this not?  ???

      I also noticed that the monitored gateway on that VIP is having Packetloss, 50% on each box. That VIP is a WAN and can't be used because of this.

      If I do tcpdump -i re0_vlan6 -ttt -n proto CARP I get this:

      First box (Master):
      00:00:00.011262 IP 172.16.0.18 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 100, authtype none, intvl 1s, length 36
      Second box (Slave):
      00:00:00.382580 IP 172.16.0.18 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 100, authtype none, intvl 1s, length 36
      Should it be in this way?  ???

      My problematic VIP is :172.16.0.18,
      first box has 172.16.0.19,
      second has 172.16.0.20.

      If you need any other info to check this please ask it.
      Thank you

      1 Reply Last reply Reply Quote 0
      • G
        gabrielpc1190 last edited by

        @gabrielpc1190:

        I have the same problem with one of 9 VIPs. But my log is full  ::) of this on the two boxes:

        Act          Time                       If          Source    Destination  Proto
        Blocked, Oct 16 15:31:26 6WAN2MB   172.16.0.18   224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 100, authtype none, intvl 1s, length 36, addrs(7) VRRP

        If I clic on the red X it shows=
        @11 scrub in on ste0 all fragment reassemble
        @11 block drop in log quick proto carp from (self:26) to any

        I haven't found any rule that match this.  :(

        My two pfsense boxes are directly connected through the pfsync interface with a cable from one to another.
        If the other 8 VIPs works why this not?  ???

        I also noticed that the monitored gateway on that VIP is having Packetloss, 50% on each box. That VIP is a WAN and can't be used because of this.

        If I do tcpdump -i re0_vlan6 -ttt -n proto CARP I get this:

        First box (Master):
        00:00:00.011262 IP 172.16.0.18 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 100, authtype none, intvl 1s, length 36
        Second box (Slave):
        00:00:00.382580 IP 172.16.0.18 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 100, authtype none, intvl 1s, length 36
        Should it be in this way?  ???

        My problematic VIP is :172.16.0.18,
        first box has 172.16.0.19,
        second has 172.16.0.20.

        If you need any other info to check this please ask it.
        Thank you

        Just a couple of minutes I upgraded the slave box from 2.0 to 2.0.1-RELEASE (i386) and I am seen that in the Master box the log below on the firewall logs is gone:
        Act          Time                       If          Source    Destination  Proto
        Blocked, Oct 16 15:31:26 6WAN2MB   172.16.0.18   224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 100, authtype none, intvl 1s, length 36, addrs(7) VRRP

        On the slave recently updated actually it does appear but not in the master 2.0-RELEASE (i386).
        Just I wanted to note this before upgrading the master.

        1 Reply Last reply Reply Quote 0
        • jimp
          jimp Rebel Alliance Developer Netgate last edited by

          I split this into its own topic. The other topic was sufficiently answered and yours may or may not be the same thing.

          If it shows that it's blocking from "self" that implies you have a network loop somewhere, or two interfaces on the same firewall plugged into the same switch/vlan.

          Dual master situations are almost always switch/layer 2 related, as mentioned in the other thread.

          1 Reply Last reply Reply Quote 0
          • G
            gabrielpc1190 last edited by

            @jimp:

            I split this into its own topic. The other topic was sufficiently answered and yours may or may not be the same thing.

            If it shows that it's blocking from "self" that implies you have a network loop somewhere, or two interfaces on the same firewall plugged into the same switch/vlan.

            Dual master situations are almost always switch/layer 2 related, as mentioned in the other thread.

            Maybe is a layer 2 problem.
            Today, after the two boxes are upgraded to 2.0.1-stable the log is not anymore on the two boxes.
            Now the Master is the Master on the problematic VIP and the Slave is as Slave. That seems to be ok, but the slave cannot communicate with the gateway on that VIP.

            I have two physical boxes with two nics each one.
            One nic is used for pfsync and the other is splitted into 11 vlans.
            That nic is connected to a trunk port on a layer 2 switch.
            The Gateway is connected to an access port on the same switch on vlan6 with ip 172.16.0.17/29
            The first box has on vlan6 ip 172.16.0.19/29
            The second box has on vlan6 ip 172.16.0.20/29
            Bot share VIP 172.16.0.18/29

            172.16.0.17 can ping two boxes ip but 172.16.0.20 can't ping gateway nor master on vlan6.
            Each box uses 172.16.0.18 as source when they ping to 172.16.0.17. I am really confused with this  :(

            Also I did tcpdump -i re0_vlan6 -ttt -n proto CARP and get this on two boxes:
            Master
            00:00:01.017627 IP 172.16.0.19 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 0, authtype none, intvl 1s, length 36
            Slave
            00:00:01.017052 IP 172.16.0.19 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 0, authtype none, intvl 1s, length 36

            Yesterday before the upgrade I had:
            First box (Master):
            00:00:00.011262 IP 172.16.0.18 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 100, authtype none, intvl 1s, length 36
            Second box (Slave):
            00:00:00.382580 IP 172.16.0.18 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 100, authtype none, intvl 1s, length 36

            1 Reply Last reply Reply Quote 0
            • First post
              Last post

            Products

            • Platform Overview
            • TNSR
            • pfSense Plus
            • Appliances

            Services

            • Training
            • Professional Services

            Support

            • Subscription Plans
            • Contact Support
            • Product Lifecycle
            • Documentation

            News

            • Media Coverage
            • Press
            • Events

            Resources

            • Blog
            • FAQ
            • Find a Partner
            • Resource Library
            • Security Information

            Company

            • About Us
            • Careers
            • Partners
            • Contact Us
            • Legal
            Our Mission

            We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

            Subscribe to our Newsletter

            Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

            © 2021 Rubicon Communications, LLC | Privacy Policy