Différences

Ci-dessous, les différences entre deux révisions de la page.

--- benevoles:technique:carp [2021/10/11 16:17] – ↷ Page déplacée de atrier:technique:carp à benevoles:technique:carp ljf
+++ benevoles:technique:carp [2023/04/16 21:25] (Version actuelle) – [Scripts] ljf
@@ Ligne 30: / Ligne 30: @@
     * Sur chaque routeur de l'association, nous avons une interface réseau, configurée dans /etc/network/interfaces, qui représente le VLAN d'un abonné au service « hébergement de machines physiques ». Ce VLAN contient toutes les machines d'un abonné hébergées dans notre baie. Voir la section « IPv6 » ci-dessous pour avoir un exemple d'entrée pour un abonné dans /etc/network/interfaces.
-    * Nous avons également une interface réseau qui représente le VLAN de contrôle : c'est là que nous faisons circuler les battements de cœur CARP. Ce VLAN ne passe pas sur le lien direct entre nos machines (voir le câble bleu ici : [[atrier:technique:matos|Matériel]]) mais il remonte jusqu'au switch. L'idée étant de tester toute la chaîne jusqu'aux machines des abonnés soit nos deux routeurs et le switch. C'est aussi ce VLAN que l'on assigne aux admins ARN qui interviennent sur la baie. L'objectif étant d'avoir accès aux routeurs de l'association ainsi qu'à Internet (documentation...) même si l'opération de maintenance nécessite d'interrompre le fonctionnement de l'un des routeurs.
+    * Nous avons également une interface réseau qui représente le VLAN de contrôle : c'est là que nous faisons circuler les battements de cœur CARP. Ce VLAN ne passe pas sur le lien direct entre nos machines (voir le câble bleu ici : [[benevoles:technique:matos|Matériel]]) mais il remonte jusqu'au switch. L'idée étant de tester toute la chaîne jusqu'aux machines des abonnés soit nos deux routeurs et le switch. C'est aussi ce VLAN que l'on assigne aux admins ARN qui interviennent sur la baie. L'objectif étant d'avoir accès aux routeurs de l'association ainsi qu'à Internet (documentation...) même si l'opération de maintenance nécessite d'interrompre le fonctionnement de l'un des routeurs.
     * Sur chacune de ces interfaces, nous attribuons une IPv4 « 169.254.43.1/24 » et une IPv6 « fe80::43:1 ». Ce sont des adresses IP locales au lien : elles ne peuvent pas être routées au-delà du segment réseau. On peut donc les réutiliser sur chaque interface, pour chacun des abonnés !
@@ Ligne 62: / Ligne 62: @@
 Ucarp est livré brut de fonderie, sans iniscript sysvinit ni unit systemd. Le plus simple est d'utiliser une unit systemd.
-Créons l'unit dans /etc/systemd/system/ucarp.service. Son contenu est disponible sur [[http://gitlab.netlib.re/arn/arn-confs/blob/master/ucarp/ucarp.master.service|notre dépôt git]].
+Créons l'unit dans /etc/systemd/system/ucarp.service. Son contenu est disponible sur [[https://code.ffdn.org/arn/arn-confs/-/tree/master/ucarp|notre dépôt git]].
 Explications des paramètres que nous passons à ucarp :
@@ Ligne 108: / Ligne 108: @@
 Concernant la variable « IFLIST » :
-  * VLANIDREGEX nous permet de trouver facilement et sans erreur possible toutes les interfaces réseau qui représentent le VLAN d'un-e abonné-e car tous les VLAN ID que nous attribuons aux abonné-e-s sont compris entre 500 et 599. Voir [[atrier:technique:l2|L2]].
+  * VLANIDREGEX nous permet de trouver facilement et sans erreur possible toutes les interfaces réseau qui représentent le VLAN d'un-e abonné-e car tous les VLAN ID que nous attribuons aux abonné-e-s sont compris entre 500 et 599. Voir [[benevoles:technique:l2|L2]].
   * La regex utilisée avec grep sélectionne le nom des interfaces réseau que l'on reconnaît grâce à leur nom : h-<pseudo_abonné>, « h- » comme « hébergement ». iproute2 affiche les noms d'interface sous la forme : <nom_demandé_par_l'admin>@<interface_physique>. Exemple : h-glucas@eth0 est le nom de l'interface réseau qui représente le VLAN de l'auteur de cette doc' ;) . iproute2 ne reconnaît pas ce format pour le nom de l'interface dans les commandes que nous sommes amenés à lui filer. Il faut donc conserver uniquement le nom, sans le « @<interface_physique> ». C'est tout l'objet de la regex [[http://www.perlmonks.org/?node_id=518444|look-ahead]].
-Ces scripts sont disponibles sur [[http://gitlab.netlib.re/arn/arn-confs/tree/master/ucarp|notre dépôt git]] :
+Ces scripts sont disponibles sur [[https://code.ffdn.org/arn/arn-confs/-/tree/master/ucarp|notre dépôt git]] :
   * vip-down.sh : la machine devient « backup » et perd l'IP virtuelle
   * vip-up.sh : la machine devient « master » et possède l'IP virtuelle
@@ Ligne 146: / Ligne 146: @@
   * « proto housing » permet de retrouver toutes les routes concernant l'hébergement de machines physiques que nous proposons avec un simple « ip r sh proto housing ». Super pratique lors de séances debug. Il faut déclarer ce nom, « housing », dans /etc/iproute2/rt_protos avant de pouvoir l'utiliser.
-  * « 89.234.141.131 » et « 2a00:5881:8100::131 » sont les IP de notre routeur. Utiliser « src » force le routeur à causer aux machines hébergées avec son IP publique et n'ont pas avec une IP link-locale. C'est plus propre. Et, lors de debug, on sait à quoi s'attendre (on rend le comportement déterministe). Voir [[atrier:technique:routage#selection_de_l_ip_source|routage]]
+  * « 89.234.141.131 » et « 2a00:5881:8100::131 » sont les IP de notre routeur. Utiliser « src » force le routeur à causer aux machines hébergées avec son IP publique et n'ont pas avec une IP link-locale. C'est plus propre. Et, lors de debug, on sait à quoi s'attendre (on rend le comportement déterministe). Voir [[benevoles:technique:routage#selection_de_l_ip_source|routage]]