Change Details

Implement automatic reassignment of the public VIP to the physical MAC of the router currently in CARP MASTER state. This is done by reacting to CARP state changes using devd : when a specific event happened, it triggers a script that calls the OVH API to update the physical MAC associated with the VIP. Why ??? This avoids situations where the backup router receives traffic for the VIP while the other node is the actual CARP master. Steps : [x] 1. Understanding the event that devd receives when router switches to master or backup. ``` Mar 22 14:49:21 router-002 kernel: carp: 2@vmx1: BACKUP -> MASTER (master timed out) ``` [x] 2. Testing a rule to understand how devd works On the file /usr/local/etc/devd/carp.conf : ``` notify 0 { match "system" "IFNET"; match "subsystem" "vmx1"; action "logger CARP state change detected"; }; ``` ``` Mar 22 15:11:37 router-002 yousra[8464]: CARP state change detected Mar 22 15:11:37 router-002 kernel: carp: 2@vmx1: BACKUP -> MASTER (master timed out) ``` The FreeBSD kernel already writes a log when a CARP state change occurs, for example, when switching from BACKUP to MASTER, but this message is purely informational and doesn't trigger any automatic action. Using devd, we can detect this event and execute a custom action, such as running a script that automatically updates the MAC address associated with the VIP at OVH so that traffic always arrives on the master router.

Implement automatic reassignment of the public VIP to the physical MAC of the router currently in CARP MASTER state. This is done by reacting to CARP state changes using devd : when a specific event happened, it triggers a script that calls the OVH API to update the physical MAC associated with the VIP. Why ??? This avoids situations where the backup router receives traffic for the VIP while the other node is the actual CARP master. Steps : [x] 1 Observing the CARP state change through kernel logs. ``` Mar 22 14:49:21 router-002 kernel: carp: 2@vmx1: BACKUP -> MASTER (master timed out) ``` [x] 2. Testing a rule to understand how devd works On the file /usr/local/etc/devd/carp.conf : ``` notify 0 { match "system" "IFNET"; match "subsystem" "vmx1"; action "logger CARP state change detected"; }; ``` ``` Mar 22 15:11:37 router-002 yousra[8464]: CARP state change detected Mar 22 15:11:37 router-002 kernel: carp: 2@vmx1: BACKUP -> MASTER (master timed out) ``` The FreeBSD kernel already writes a log when a CARP state change occurs, for example, when switching from BACKUP to MASTER, but this message is purely informational and doesn't trigger any automatic action. Using devd, we can detect this event and execute a custom action, such as running a script that automatically updates the MAC address associated with the VIP at OVH so that traffic always arrives on the master router.

Implement automatic reassignment of the public VIP to the physical MAC of the router currently in CARP MASTER state. This is done by reacting to CARP state changes using devd : when a specific event happened, it triggers a script that calls the OVH API to update the physical MAC associated with the VIP. Why ??? This avoids situations where the backup router receives traffic for the VIP while the other node is the actual CARP master. Steps : [x] 1. Understand Observing the event that devd receives when router switches to master or backupCARP state change through kernel logs. ``` Mar 22 14:49:21 router-002 kernel: carp: 2@vmx1: BACKUP -> MASTER (master timed out) ``` [x] 2. Testing a rule to understand how devd works On the file /usr/local/etc/devd/carp.conf : ``` notify 0 { match "system" "IFNET"; match "subsystem" "vmx1"; action "logger CARP state change detected"; }; ``` ``` Mar 22 15:11:37 router-002 yousra[8464]: CARP state change detected Mar 22 15:11:37 router-002 kernel: carp: 2@vmx1: BACKUP -> MASTER (master timed out) ``` The FreeBSD kernel already writes a log when a CARP state change occurs, for example, when switching from BACKUP to MASTER, but this message is purely informational and doesn't trigger any automatic action. Using devd, we can detect this event and execute a custom action, such as running a script that automatically updates the MAC address associated with the VIP at OVH so that traffic always arrives on the master router.