evolix/wiki
22
0
Fork 0
Code Releases Activity

Syntaxe

Browse source
This commit is contained in:
jdubois 2023-04-27 17:04:05 +02:00
parent 4c93390de4
commit e898b1e0a6
1 changed files with 3 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
HowtoOpenBSD/CARP.md
View file

@ -251,11 +251,11 @@ Lorsque que l'on a un firewall en BACKUP, il est important de pouvoir le redéma
Conséquences de cela :
* Si on reconfigure une interface CARP MASTER, elle va passer en BACKUP pendant `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 reconfigure une interface CARP MASTER, elle va passer en BACKUP pendant `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é.
* 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.
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`.