[CARP (Common Address Redundancy Protocol)](https://man.openbsd.org/man4/carp.4) est une alternative libre et sécurisée aux protocoles [VRRP](https://www.ietf.org/rfc/rfc3768.txt) et [HSRP](https://www.ietf.org/rfc/rfc2281.txt). Il permet à plusieurs équipements, sur un même segment réseau, de partager une même adresse IP. L'objectif principal du protocole est de permettre une bascule réseau sur un équipement secondaire en cas d'incident.
**Principe :** Une interface réseau d'un des équipements est configurée pour être dans un état MASTER ou BACKUP. L'interface MASTER émet régulièrement des paquets à destination de l'interface BACKUP pour prouver son bon fonctionnement. Le choix MASTER/BACKUP est effectué grâce à des priorités configurables. Si le BACKUP ne reçoit pas un paquet dans les temps (ou si il reçoit un paquet inférieur à sa priorité), il passera en MASTER.
`advskew` est un des paramètres pour jouer sur le choix de qui est master. Entre deux hôtes avec des valeurs de `advskew` différentes, c'est celui avec la valeur la plus petite qui sera `MASTER`.
Par défaut, toutes les interfaces CARP sont dans le même groupe `carp`. Chaque groupe a un compteur `carpdemote` qui lui est propre et affectant toutes les interfaces membres du groupe.
Si une interface physique sur laquelle une interface CARP est configurée passe down, alors le compteur `carpdemote` du ou des groupes auquel appartient l'interface CARP sera incrémenté de 1, et toutes les interfaces CARP membres des mêmes groupes basculeront en même temps.
S'il n'est pas souhaité que toutes les interfaces CARP de la machine basculent en même temps, il peut être souhaité de créer des groupes distincts, et de les lever du groupe par défaut `carp`. Par exemple, sur 2 firewalls ayant 3 interfaces CARP, on peut vouloir que `carp0` et `carp1` basculent ensemble en cas d'erreur d'une seule des 2 interfaces, mais que `carp2` soit indépendante :
Le paramètre `preempt` permet à une machine membre d'une interface CARP de préempter l'état MASTER, c'est-à-dire d'automatiquement basculer MASTER, si ses paramètres `advbase` et `advskew` sont meilleurs.
Si ce paramètre n'est pas activé et que celui qui a les meilleurs paramètres `advbase` et `advskew` est backup, alors il le restera tant qu'aucune bascule manuelle n'est effectuée.
Pour des raisons de maintenance, on peut vouloir forcer une bascule CARP. ATTENTION, cela bascule **toutes** les interfaces du groupe carp, c'est à dire, toutes les interfaces carp.
Le MASTER va générer un paquet CARP avec la priorité 255 et le BACKUP va ainsi immédiatemment passer MASTER. Ce paquet peut être observé avec `tcpdump proto carp`
**Important** : Si le compteur carpdemote n'a pas la même valeur sur tous les membres CARP, alors le membre ayant la valeur carpdemote la plus faible (re)passera automatiquement master, même en forçant l'état.
À noter que l'on peut également faire `ifconfig carp0 down` ou `ifconfig carp0 advskew XXX` (avec XXX supérieur à l'actuel backup) mais c'est moins optimum (bascule non immédiate, perte de trafic pendant quelques secondes…)
Si on a coupé une interface carp en faisant `ifconfig carpX down`, pour la remettre en place, on vérifie que le `advskew` est bien supérieur à celui où le master est actuellement pour ne pas basculer directement en tant que MASTER. Si ce n'est pas le cas, on peut corriger avec `ifconfig carpX advskew xxx`. Lorsque c'est OK, il reste juste à faire `ifconfig carpX up`.
Attention, si le droit de préemption est activé, il faut penser à le désactiver avec `sysctl net.inet.carp.preempt=0` avant de réactiver l'interface CARP pour éviter que toutes les CARP changent de statut en cas de problème. Le réactiver une fois l'interface CARP correctement remise en place avec `sysctl net.inet.carp.preempt=1`.
Le master va alors immédiatement passer en backup. On modifie le paramètre advskew pour qu'il soit plus élevé que sur fw01, pour s'assurer que fw00 reste backup à la réactivation des interfaces. Le déplacement des fichiers de configuration CARP évite que les interfaces ne remontent lors de redémarrages. On peut désormais lancer la mise à jour et effectuer notre redémarrage.
Lorsque que l'on a un firewall en BACKUP, il est important de pouvoir le redémarrer sans que cela n'impacte le MASTER. Pour cela, il faut bien comprendre le comportement de CARP au démarrage : pendant un certain temps, il va toujours rester en BACKUP pour voir s'il ne reçoit pas d'annonce d'un MASTER. Ce comportement est aussi présent lors de sa (re)configuration même si le CARP était MASTER initialement. S'il n'a rien reçu, il passe en MASTER. Ce temps est d'attente correspond à 3 fois la valeur du paramètre _advbase_ (par défaut à 1 seconde).
* Si on reconfigure une interface CARP MASTER, elle va passer en BACKUPpendant _3\*advbase_ secondes ! Il est donc judicieux après être intervenu sur une machine qui est CARP MASTER de forcer le retour à l'état master avec `ifconfig carp0 state master`. À noter que si l'autre firewall a eu le temps de passer MASTER, cette commande ne le refera pas passer backup.
* Si on redémarre une machine avec des CARP BACKUP, il est probable que son réseau ne soit pas opérationnel immédiatement ([synchronisation _Spanning Tree_](/SwitchCisco#synchro-immédiate-spanning-tree-portfast) qui prend 30 secondes par défaut par exemple). L'interface va donc se déclarer en MASTER après son temps d'attente 3\*advbase, et lorsque le réseau sera activé il y aura donc un conflit entre les deux MASTER. Il faut donc bien ajuster _advbase_ pour qu'il soit bien supérieur au temps d'arrivée du réseau. Une manière de faire est d'avoir une configuration en dur avec _advbase_ à 60 secondes par exemple, ce qui permet d'avoir des reboots transparents, puis on reconfigure manuellement _advbase_ à 10 secondes par exemple quand tout est redémarré.
Dans ce deuxième cas, il est important de ne pas augmenter la valeur _carpdemote_ du firewall ayant la valeur _advbase_ la plus basse. En effet, si fw01 est master avec advbase à 10 et que fw00 est backup avec advbase à 60, et que l'on veut (re)passer fw00 master en augmentant la valeur carpdemote de fw01, alors il y aura un conflit : toutes les 10 secondes, fw00 recevra un paquet de fw01 lui disant que le carpdemote de fw01 est plus élevé que le sien ; fw00 passera alors master, et fw01 passera backup. Cependant, après 3\*advbase secondes, soit 3\*10 secondes, fw01 passera de nouveau master puisqu'il n'aura reçu aucun paquet de fw00 lui indiquant que c'est lui le master, étant donné que fw00 n'envoie ses paquets que toutes les 60 secondes. Après ces 60 secondes, fw01 aura reçu un nouveau paquet de fw00 et repassera backup, mais pendant seulement 3\*10 secondes après lesquelles il passera de nouveau master, et ainsi de suite.
> *Note :* Lors d'un reboot planifié on peut également décider de commenter l'ensemble des lignes présentes dans le(s) fichier(s) `/etc/hostname.carpX` : une fois la machine de nouveau disponible, il suffira de décommenter la configuration et recréer les interfaces via `sh /etc/netstart carp0 carp1`.
Sous OpenBSD, plusieurs services sont capables de s'activer en fonction du statut d'une interface CARP : si l'interface est en BACKUP, une partie du service ne s'active pas, mais il s'active automatiquement si l'interface passe en MASTER. On peut notamment citer [OpenBGPD](OpenBGPD), [relayd](http://man.openbsd.org/relayd.8), [OSPFD](http://man.openbsd.org/ospfd) ou encore [sasyncd](sasyncd)
Les changements d'états des interfaces sont notés dans `/var/log/messages`. On peut augmenter la valeur du paramètre kernel `net.inet.carp.log` (par défaut à 2) afin d'avoir des traces plus parlantes.