This is a project-as-a-tag.
Details
Yesterday
Tue, Apr 28
Mon, Apr 27
We noticed that Windriver is unable to ping the public IP addresses of router-002 and router-003. However, GRE tunnel creation is successful, and tunnel connectivity works with router-002, although pinging its public IP is still unsuccessful.
When creating a GRE tunnel to the alias IP of ysul as an endpoint the tunnel is unpingable however when creating the GRE tunnel using the public IP of ysul, GRE tunnel responds well to ping.
I suspect that the problem might come from using an alias IP as GRE endpoint that might cause this as it suggest encapsulation/decapsulation issues
Sun, Apr 26
I created and tested a Salt reactor that listens for the carp/master event sent by the routers. For now, the reactor only runs a test command on Ysul and Windriver to confirm that the event is correctly received and that the master can trigger actions on those hosts.
Test to validate Salt event emission and reception on the master :
Fri, Apr 24
Thu, Apr 16
Mar 24 2026
Mar 23 2026
Mar 22 2026
Ah, that's now what we need, nice for the script!
The file /usr/local/etc/devd/carp.conf :
You can directly use variables in the action to pass interface and state with $subsystem and $type
notify 0 {
match "system" "CARP";
match "subsystem" "[0-9]+@[0-9a-z.]+";
match "type" "(MASTER|BACKUP)";
action "/usr/local/scripts/carp-test.sh";
};For all CARP external documentation, I think I've found the threshold where information is outdated in that man page:
According carp(4) (man carp) examples section, the name has changed.
@dereckson I first tried to redefine the devd rule by matching specific IFNET event types such as LINK_UP, LINK_DOWN, UP and DOWN, but none of them were triggered during CARP state changes in my tests.
notify 0 {
match "system" "IFNET";
match "subsystem" "vmx1";
action "logger CARP state change detected";
};A dedicated devd file was placed in /usr/local/etc/devd because this directory is usually used for custom configurations added by administrators, while /etc/devd contains the default system rules from FreeBSD. It makes the setup cleaner, avoids mixing custom logic with system configuration, and makes future maintenance or upgrades easier.