Configuration de Vyatta 5400 pour la haute disponibilité

La haute disponibilité de Vyatta est prise en charge à l'aide du protocole VRRP (Virtual Routing Redundancy Protocol). Chaque groupe de passerelles possède deux adresses IP VRRP principales, une pour le côté privé et l'autre pour le côté public des réseaux.

Seuls les systèmes Vyatta privés utilisent le protocole VRRP privé.

Ces adresses IP sont les adresses IP cible de l'infrastructure de réseau permettant de router tous les sous-réseaux des réseaux locaux virtuels qui sont associés aux membres de passerelle. Ces adresses IP VRRP ne sont en cours d'exécution que pour un système Vyatta à la fois. Pour les autres membres du groupe de passerelles, elles sont arrêtées administrativement.

La configuration peut être synchronisée entre les deux systèmes Vyatta avec les commandes de configuration config-sync. Cette configuration autorise un membre à envoyer la configuration d'options spécifiques à l'autre système Vyatta d'un groupe, de manière sélective. Vous pouvez envoyer uniquement les règles de pare-feu ou uniquement la configuration IPsec, ou n'importe quelle combinaison de jeux de règles.

Il est déconseillé d'envoyer des adresses IP ou d'autres configurations de réseau car config-sync valide instantanément vos modifications sur les autres systèmes Vyatta, en mettant ces interfaces en ligne. Si vous voulez activer des interfaces et des services de manière dynamique, vous pouvez utiliser des scripts de transition pour effectuer cette action en cas de basculement. De plus, il est recommandé d'utiliser davantage d'adresses IP VRRP pour vos adresses IP de passerelle sur des réseaux locaux virtuels associés, afin de faciliter la gestion du basculement.

Votre configuration VRRP de base sur les deux machines ressemble à l'exemple de configuration suivant :

interfaces {
bonding bond0 {
address 10.28.94.213/26
duplex auto
hw-id 06:d6:f8:f0:fb:ee
smp_affinity auto
speed auto
vrrp {
vrrp-group 1 {
advertise-interval 1
}
preempt false
priority 254
sync-group vgroup10
rfc3768-compatibility
virtual-address 192.168.10.1/24
}
}
}
bonding bond1 {
address 50.23.184.5/26
duplex auto
hw-id 06:05:09:41:fb:cb
smp_affinity auto
speed auto
vrrp {
vrrp-group 1 {
advertise-interval 1
}
preempt false
priority 254
sync-group vgroup10
rfc3768-compatibility
virtual-address 50.23.184.27/26
}
}
}
loopback lo {
}
}

VRRP nécessite qu'une adresse IP réelle soit d'abord liée à une interface virtuelle avant de pouvoir envoyer des notifications VRRP. Dans la plupart des cas, il suffit d'ajouter une adresse IP à partir du sous-réseau principal, mais cela peut être incompatible avec de futures mises à disposition. Ou bien, vous pouvez envisager de router un réseau local virtuel dont chaque adresse IP de sous-réseau principal est déjà allouée à un serveur. Pour contourner le problème, vous pouvez utiliser une paire d'adresses IP hors bande sur les deux systèmes Vyatta afin de leur permettre de communiquer. Exemple :

Sur le premier système Vyatta :

set interfaces bonding bond0 vif 1000 address 172.16.0.10/29
set interfaces bonding bond0 vif 1000 vrrp vrrp-group 10 sync-group vgroup10
set interfaces bonding bond0 vif 1000 vrrp vrrp-group 10 priority 200
set interfaces bonding bond0 vif 1000 vrrp vrrp-group 10 virtual-address 192.168.10.1/24

Sur le deuxième système Vyatta :

set interfaces bonding bond0 vif 1000 address 172.16.0.11/29
set interfaces bonding bond0 vif 1000 vrrp vrrp-group 10 sync-group vgroup10
set interfaces bonding bond0 vif 1000 vrrp vrrp-group 10 priority 199
set interfaces bonding bond0 vif 1000 vrrp vrrp-group 10 virtual-address 192.168.10.1/24

Dans ce cas, les deux systèmes Vyatta ont leur propre adresse IP et il n'y a aucun risque de conflit avec le sous-réseau alloué. Vous pouvez sélectionner presque toutes les plages privées de votre choix. Sélectionnez simplement un petit sous-réseau qui n'entrera pas en conflit avec d'autres routes que vous utilisez, par exemple une plage de sous-réseaux sur un tunnel IPsec, ou une adresse 10.0.0.0/8 en conflit avec SoftLayer.

Ajoutez aussi un nom sync-group. Toutes les adresses VRRP doivent appartenir au même groupe sync-group. Ainsi, toute défaillance dans une interface entraîne le basculement de toutes les interfaces qui se trouvent dans le même groupe sync-group. Sinon, vous pourriez vous retrouver avec des interfaces de type MASTER et d'autres de type BACKUP. Utilisez le même nom dans la configuration de réseau local virtuel natif bond0 et bond1.

La configuration VRRP bond0 et bond1 peut comporter une ligne pour la compatibilité rfc3768. Celle-ci n'est pas nécessaire pour VRRP dans une interface VIF, mais uniquement pour le réseau local virtuel natif bond0 et bond1.

Dans une paire de passerelles nouvellement mise à disposition, la configuration de config-sync est minimale :

config-sync {
remote-router 10.28.94.195 {
password ****************
sync-map syncme
username vyatta
}

Vous devez ajouter des règles pour déterminer les branches de configuration vers lesquelles migrer. Par exemple, si vous voulez que la configuration de pare-feu et la configuration d'IPsec soient envoyées, ajoutez les commandes suivantes :

set system config-sync sync-map syncme rule 1 action include
set system config-sync sync-map syncme rule 1 location firewall
set system config-sync sync-map syncme rule 2 action include
set system config-sync sync-map syncme rule 2 location "vpn ipsec"

Une fois ces commandes validées, toute modification apportée à la configuration de pare-feu ou à la configuration d'IPsec est envoyée sur l'autre système Vyatta lors de la validation.

sync-group et sync-map sont deux concepts différents. La configuration sync-map permet aux règles de propager les modifications de configuration vers un autre Vyatta. sync-group permet aux IP VRRP d'effectuer un basculement en tant que groupe au lieu de le faire individuellement. La configuration de l'un n'a aucune incidence sur l'autre.