Relecture, ajout d'infos et réorganisation
This commit is contained in:
tpilat
parent
d5e0a9cc77
commit
c387b1198c
|
|
@ -3,48 +3,38 @@ categories: openbsd network
|
|||
title: Howto CARP sous OpenBSD
|
||||
---
|
||||
|
||||
CARP est un protocol réseau qui se veut être 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 de partager
|
||||
une adresse IP sur plusieurs machines d'un même réseau.
|
||||
CARP (Common Address Redundancy Protocol) est un protocol réseau qui se veut être 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 réseau de niveau 2, de partager une même adresse IP. L'objectif principal du protocol est de permettre une bascule réseau sur un équipement secondaire en cas d'incident.
|
||||
|
||||
Le principe est d'avoir une interface sur 2 machines (ou plus). Cette interface est configurée pour être dans un état MASTER ou SLAVE.
|
||||
L'interface MASTER émet régulièrement des paquets à destination du SLAVE pour prouver qu'elle fonctionne bien.
|
||||
Le choix SLAVE/MASTER est effectué grâce à des priorités configurables.
|
||||
Si le SLAVE ne reçoit pas un paquet dans les temps (ou qu'il reçoit un paquet inférieur à sa priorité), il passera MASTER.
|
||||
Une interface réseau d'un des équipements membres est configurée pour être dans un état MASTER ou SLAVE. L'interface MASTER émet régulièrement des paquets à destination de l'interface SLAVE pour prouver son bon fonctionnement. Le choix SLAVE/MASTER est effectué grâce à des priorités configurables. Si le SLAVE ne reçoit pas un paquet dans les temps (ou si il reçoit un paquet inférieur à sa priorité), il passera en MASTER.
|
||||
|
||||
En plus de la man page
|
||||
[carp(4)](http://man.openbsd.org/OpenBSD-current/man4/carp.4), la FAQ
|
||||
d'OpenBSD comporte une
|
||||
[section spécialement pour CARP](https://www.openbsd.org/faq/pf/carp.html).
|
||||
En plus de la man page [carp(4)](http://man.openbsd.org/OpenBSD-current/man4/carp.4), la FAQ d'OpenBSD comporte une [section spécialement pour CARP](https://www.openbsd.org/faq/pf/carp.html).
|
||||
|
||||
## Création manuelle
|
||||
## Configuration
|
||||
|
||||
### manuellement
|
||||
|
||||
Sur le MASTER :
|
||||
|
||||
~~~
|
||||
# sysctl net.inet.carp.allow=1 && echo "net.inet.carp.allow=1" >> /etc/sysctl.conf
|
||||
# ifconfig carp0 create
|
||||
# ifconfig carp0 vhid 1 pass PASSWORD carpdev bnx0 \
|
||||
advskew 1 192.0.2.30 netmask 255.255.255.224
|
||||
# ifconfig carp0 vhid 1 pass PASSWORD carpdev bnx0 advskew 1 192.0.2.30 netmask 255.255.255.224
|
||||
~~~
|
||||
|
||||
Sur le SLAVE :
|
||||
|
||||
~~~
|
||||
# sysctl net.inet.carp.allow=1 && echo "net.inet.carp.allow=1" >> /etc/sysctl.conf
|
||||
# ifconfig carp0 create
|
||||
# ifconfig carp0 vhid 1 pass PASSWORD carpdev bnx0 \
|
||||
advskew 128 192.0.2.30 netmask 255.255.255.224
|
||||
# ifconfig carp0 vhid 1 pass PASSWORD carpdev bnx0 advskew 128 192.0.2.30 netmask 255.255.255.224
|
||||
~~~
|
||||
|
||||
## Création définitive
|
||||
### persistante
|
||||
|
||||
Sur le MASTER :
|
||||
|
||||
~~~
|
||||
# cat /etc/hostname.carp0
|
||||
192.0.2.30/27 carpdev bnx0 pass PASSWORD vhid 1 advskew 1
|
||||
# sh /etc/netstart carp0
|
||||
~~~
|
||||
|
||||
Sur le SLAVE :
|
||||
|
|
@ -52,66 +42,12 @@ Sur le SLAVE :
|
|||
~~~
|
||||
# cat /etc/hostname.carp0
|
||||
192.0.2.30/27 carpdev bnx0 pass PASSWORD vhid 1 advskew 128
|
||||
# sh /etc/netstart carp0
|
||||
~~~
|
||||
|
||||
## Bascule CARP
|
||||
### Création d'une interface CARP dans un VLAN
|
||||
|
||||
Pour des raisons de maintenance, on peut vouloir forcer une bascule CARP.
|
||||
Pour faire cela, sur le master, on peut faire :
|
||||
|
||||
~~~
|
||||
# ifconfig carp0 down
|
||||
~~~
|
||||
|
||||
ou
|
||||
|
||||
~~~
|
||||
# ifconfig -g carp carpdemote 50
|
||||
~~~
|
||||
|
||||
|
||||
Normalement, le master va générer un paquet CARP avec la priorité 255 ce qui doit avoir comme conséquence
|
||||
que le SLAVE va immédiatemment passer MASTER. Ce paquet peut être observé avec `tcpdump proto carp`
|
||||
|
||||
Note : avec `ifconfig carp0 down` nous avons eu parfois des soucis de bascule non immédiate,
|
||||
on recommande donc d'observer ce qui se passer avec `tcpdump proto carp` et éventuellement
|
||||
de privilégier la bascule via carpdemote qui semblerait plus sûre (à confirmer).
|
||||
|
||||
|
||||
## Optimisation CARP au (re)boot d'un BACKUP
|
||||
|
||||
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 si il ne reçoit pas d'annonce d'un MASTER. Ce comportement
|
||||
est aussi présent lors de la (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 à la valeur du paramètre _advbase_ (par défaut à 1 seconde).
|
||||
|
||||
Conséquences de cela :
|
||||
|
||||
* Si on reconfigure une interface CARP MASTER, elle va passer en
|
||||
BACKUP pendant _advbase_ secondes ! Il est donc judicieux avant
|
||||
d'intervenir sur une machine qui est CARP MASTER, de vérifier et si
|
||||
besoin ajuster le paramètre _advbase_ à une valeur très faible.
|
||||
|
||||
* 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 qui prend 50 secondes par défaut sur
|
||||
un switch CISCO par exemple). L'interface va donc se déclarer en
|
||||
MASTER après son temps d'attente, et lorsque le réseau sera activera
|
||||
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é.
|
||||
|
||||
## Création d'une interface CARP dans un VLAN
|
||||
|
||||
On peut rattacher une interface CARP à une interface VLAN. L'instance carp0 sera alors isolée dans le VLAN auquel il est rattaché.
|
||||
On peut attacher une interface CARP à une interface VLAN. L'interface carp0 sera alors isolée dans le VLAN auquel elle est attachée.
|
||||
|
||||
Pour la création d'un VLAN, voir [VLAN](VLAN)
|
||||
|
||||
|
|
@ -126,7 +62,62 @@ vlandev bnx0 description "VLAN42"
|
|||
192.0.2.30/27 carpdev vlan42 pass PASSWORD vhid 1 advskew 128
|
||||
~~~
|
||||
|
||||
## Stats
|
||||
## Le droit de préemption
|
||||
|
||||
Sur des équipements réseau de type firewall pour lesquels l'ensemble des interfaces devoient se trouver dans le même état (toutes MASTER ou BACKUP), on activera le paramètre kernel preempt :
|
||||
|
||||
~~~
|
||||
# sysctl net.inet.carp.preempt=1
|
||||
# echo 'net.inet.carp.preempt=1' >> /etc/sysctl.conf
|
||||
~~~
|
||||
|
||||
L'activation de ce paramètre permet notamment la bascule de l'ensemble des interfaces d'un groupe CARP dans le cas d'un changement d'état d'une interface. En cas de bascule d'une interface, le compteur carpdemote sera incrémenté de 1 sur le groupe entrainant une bascule de l'ensemble des membres du groupe CARP.
|
||||
|
||||
## Informations utiles
|
||||
|
||||
### Bascule CARP
|
||||
|
||||
Pour des raisons de maintenance, on peut vouloir forcer une bascule CARP.
|
||||
Pour faire cela, il y a plusieurs possibilités. Sur le master, on peut faire :
|
||||
|
||||
~~~
|
||||
# ifconfig carp0 down
|
||||
~~~
|
||||
|
||||
ou
|
||||
|
||||
~~~
|
||||
# ifconfig carp0 advskew XXX (avec XXX supérieur à l'actuel backup)
|
||||
~~~
|
||||
|
||||
ou encore
|
||||
|
||||
~~~
|
||||
# ifconfig -g carp carpdemote 50
|
||||
~~~
|
||||
|
||||
Le master va générer un paquet CARP avec la priorité 255 et le SLAVE va ainsi immédiatemment passer MASTER. Ce paquet peut être observé avec `tcpdump proto carp`
|
||||
|
||||
Note : avec `ifconfig carp0 down` nous avons eu parfois des soucis de bascule non immédiate, on recommande donc d'observer ce qui se passer avec `tcpdump proto carp` et éventuellement de privilégier la bascule via carpdemote qui semblerait plus sûre (à confirmer).
|
||||
|
||||
|
||||
### Optimisation CARP au (re)boot d'un BACKUP
|
||||
|
||||
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 si il ne reçoit pas d'annonce d'un MASTER. Ce comportement est aussi présent lors de la (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 à la valeur du paramètre _advbase_ (par défaut à 1 seconde).
|
||||
|
||||
Conséquences de cela :
|
||||
|
||||
* Si on reconfigure une interface CARP MASTER, elle va passer en BACKUP pendant _advbase_ secondes ! Il est donc judicieux avant d'intervenir sur une machine qui est CARP MASTER, de vérifier et si besoin ajuster le paramètre _advbase_ à une valeur très faible.
|
||||
|
||||
* 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 qui prend 50 secondes par défaut sur un switch CISCO par exemple). L'interface va donc se déclarer en MASTER après son temps d'attente, et lorsque le réseau sera activera 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é.
|
||||
|
||||
Note : Lors d'un reboot plannifié 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 :
|
||||
|
||||
~~~
|
||||
# sh /etc/netstart carp0 carp1
|
||||
~~~
|
||||
|
||||
## Statistiques
|
||||
|
||||
On peut avoir des statistiques en utilisant netstat(1)
|
||||
|
||||
|
|
@ -149,3 +140,11 @@ carp:
|
|||
0 send failed due to mbuf memory error
|
||||
35 transitions to master
|
||||
~~~
|
||||
|
||||
## Logs
|
||||
|
||||
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.
|
||||
|
||||
~~~
|
||||
# sysctl net.inet.carp.log=X (valeur X comprise entre 0 et 7)
|
||||
~~~
|
||||
Loading…
Reference in a new issue