[patch] error on "Temporarily disable CARP" with IPv6

[mfedv]

(20.7.8, also older opnsense versions)

Hi,
   
when using any IPv6 for CARP Virtual IPs, clicking "Temporarily Disable
CARP" ( Interfaces / Virtual IPs / Status ) on the MASTER machine
produces the following error message in the GUI:
   
    CARP has detected a problem and this unit has been demoted to BACKUP status.
    Check link status on all interfaces with configured CARP VIPs.
           
and the following in /var/log/system.log:
           
    Jan 20 22:08:32 opnsense1 opnsense[10333]: /carp_status.php: The command `/sbin/ifconfig 'vtnet2' -alias '2001:db8:381c:abc::3'' failed to execute
    Jan 20 22:08:32 opnsense1 opnsense[10333]: /carp_status.php: The command `/sbin/ifconfig 'vtnet3' -alias '2001:db8:391c:abc::3'' failed to execute

and ipv6 carp addresses stay configured:

    # ifconfig | grep -e "^vtnet" -e vhid | grep -B 1 vhid
    vtnet2: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
            inet6 2001:db8:381c:abc::3 prefixlen 64 vhid 4
            carp: INIT vhid 4 advbase 1 advskew 0
    vtnet3: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
            inet6 2001:db8:391c:abc::3 prefixlen 64 vhid 6
            carp: INIT vhid 6 advbase 1 advskew 0


the patch below fixes this, copying ipv6 handling from the 'ipalias'
case to the 'carp' case (ifconfig syntax is different for ipv4 and
ipv6).

I also added a 2 second delay before redirecting the client browser to
refresh the status overview, to allow carp to settle. This avoids
display of a transient state (sometimes shows a mix of "BACKUP" and
"MASTER" states).
             
Regards         
Matthias Ferdinand   

[franco]

Hi Matthias,

Thanks for the report. Took a slightly different route (also down the rabbit hole apparently) trying to fold it into less code:

https://github.com/opnsense/core/commit/00e6895821ed

There are probably more missing "inet6" spots and a lot of loose "ifconfig" calls which we need to look at.

I'm not sure about adding the delay. The basic issue is 2 seconds may be enough but what if not so maybe there is another mechanism we could use?


Cheers,
Franco

[mfedv]

Hi,

this fold is much more elegant, I had missed the optional third argument
to legacy_interface_deladdress().

Yes, the fixed 2 second delay is almost like cheating. It only works for
me and perhaps most other installations because the default carp
interval is 1 second, so after 2 seconds (+ gui network latency) carp
should be settled.

Not sure what a proper solution would look like, there are so many
tuning knobs to consider.

Perhaps postpone the client redirect until
    1 + min(configured carp intervals)
seconds have passed, then waiting for some limited additional time after
that for a consistent carp state. But carp state might even become
inconsistent while we wait because of some real failure.

Or have a few (3 - 5) client refreshs, live-watching carp state changes.

Regards
Matthias Ferdinand