Bug #1072

Issues with increased CARP VHID limits

Added by Chris Buechler over 8 years ago. Updated over 8 years ago.

Virtual IPs
Target version:
Start date:
Due date:
% Done:


Estimated time:
Affected Version:
Affected Architecture:


The increase to 65535 VHIDs has made firewall_virtual_ip_edit.php very slow. Aside from that, having 65535 VHIDs would be 65Kpps in announcement traffic which would be problematic (at best). Need different solution here aside from just fixing the GUI. Maybe a quick work around would suffice for 2.0, allowing an advanced option to increase the VHID limit, as we do not want something like this added at such a late stage.


#1 Updated by Alexander Kalashnikov over 8 years ago

vhid field in CARP packet is one byte long, so this GUI change does not make any sense.

#2 Updated by Jim Pingle over 8 years ago

We have a patch in the builds which expands the field to two bytes.

#3 Updated by Alexander Kalashnikov over 8 years ago

So the pfSense is not compatible with *BSD.
And I understood why CARP is broken now.

#4 Updated by Alexander Kalashnikov over 8 years ago

Does anyone looking into the issue with broken CARP?

#5 Updated by Chris Buechler over 8 years ago


#6 Updated by Alexander Kalashnikov over 8 years ago

According to packet dump

carp vhid=1 > VRRPv2, Advertisement, vrid 1, prio 0, authtype #128, intvl 1s, length 36, addrs(7):,,,,,,
0x0000: 0100 5e00 0012 0000 5e00 0101 0800 4510
0x0010: 0038 d66a 4000 ff70 0000 c0a8 fcfe e000
0x0020: 0012 2101 0007 8001 b7a9 6b5f 108e 590b
0x0030: 0401 1c6a 76f8 952b 0cd4 94c3 d7f6 fcbd
0x0040: b975 38fd 3d05

carp vhid=256 > VRRPv2, Advertisement, vrid 0, prio 0, authtype simple, intvl 1s, length 36, addrs(7):,,,,,,[|vrrp]
0x0000: 0100 5e00 0012 0000 5e00 0100 0800 4510
0x0010: 0038 8271 4000 ff70 0000 c0a8 fdfe e000
0x0020: 0012 2100 0007 0101 5dc9 8907 1f92 eedf
0x0030: 0a51 5af1 d6d0 3b2d 9a7c 40d8 e30b 7526
0x0040: cd09 1a13 56d0

seems like there is something wrong with bit shifting for vhidx field (previously it was known as "carp_pad1" field).
When interface's vhid<=255 - it's allways 10000000b (0x80) and only when interface's vhid>=255 everything works as expected.

2ALL: Temporary workaround for this situation is to use VHID greater than 255.

#7 Updated by Erik Fonnesbeck over 8 years ago

In the patch file, I saw this change that commented out this line:

-     ch.carp_pad1 = 0;     /* must be zero */
+     //ch.carp_pad1 = 0;     /* pfSense HACK */

In the part just before that, carp_vhidx (renamed from carp_pad1) is not initialized to 0 in the <= 255 case, so it likely does not get initialized at all. (this may be the cause of the issue) Rather than this (about line 923, if I calculated right from the diff):

    if (sc->sc_vhid <= 255)
        ch.carp_vhid = sc->sc_vhid;
    else {
        ch.carp_vhid = sc->sc_vhid & 0xff;
        ch.carp_vhidx = sc->sc_vhid >> 8;

It should probably be this:

    if (sc->sc_vhid <= 255)
        ch.carp_vhid = sc->sc_vhid;
        ch.carp_vhidx = 0;
    else {
        ch.carp_vhid = sc->sc_vhid & 0xff;
        ch.carp_vhidx = sc->sc_vhid >> 8;

There also may be a MAC conflict for vhid's of <= 255 and the ones in the range of 256 - 511. There are some cases like the following example that either set a value to 1 or the upper 8 bits, and the upper 8 bits equal that same value for the 256 - 511 range. Something probably needs to be done about that (assuming the patch is even left in).

            if (sc->sc_vhid <= 255) {
                eh->ether_shost[4] = 1;
                eh->ether_shost[5] = sc->sc_vhid;
            } else {
                eh->ether_shost[4] = sc->sc_vhid >> 8;
                eh->ether_shost[5] = sc->sc_vhid & 0xff;

#8 Updated by Ermal Lu├ži over 8 years ago

  • Status changed from New to Closed

This is not anymore present in builds.

Also available in: Atom PDF