6. Tolérance aux pannes réseau sur les flux descendants - customized keepalive

Dans la section précédente, qui traite aussi de la tolérance aux pannes réseau, on a uniquement caractérisé les flux sortants de l'aire OSPF. Autrement dit, cette tolérance n'est effective que pour les flux émis à partir des hôtes présents dans cette aire. Ces hôtes sont donc nécessairement assimilés à des clients dans le modèle client/serveur.

Considérons maintenant le cas où ces hôtes sont des serveurs dont le contenu doit être accessible depuis l'Internet. Le trafic correspondant transite toujours par le routeur ISP mais celui-ci ne dispose d'aucun moyen de détection de l'état des liens vers les routeurs R1 et R3.

Les fonctions de détection de l'état des liens sont intrinsèques aux protocoles de routage de type link-state. Une fois que la convergence initiale est atteinte, les nouveaux calculs de topologie n'interviennent que si un lien connu au préalable est désactivé ou réactivé. La section 4.3 du standard RFC2328 OSPF Version 2 définit les 5 types de paquets du protocole de routage. Le type 1 est justement le Hello packet dont la fonction est de découvrir et de maintenir les adjacences avec les routeurs OSPF voisins. Sur un réseau de diffusion, comme dans le cas de cet article, ces paquets sont émis toutes les 10 secondes et utilisent une adresse IP destination multicast propre au protocole : 224.0.0.5.

Comme le routeur ISP n'appartient pas au même domaine d'administration que les trois autres routeurs de l'aire OSPF, aucune adjacence n'est formée sur les deux liens de sortie de cette aire. On se propose donc de compenser l'absence de contrôle d'état à l'aide de scripts maison.

6.1. Scripts de contrôle d'état de lien - keepalive shell scripts

L'objectif ici n'est pas de reproduire un fonctionnement aussi sophistiqué que celui offert par un protocole de routage dynamique, mais de trouver une solution à moindre coût qui permette de manipuler les routes par défaut des routeurs R1 et R3 à partir des réponses aux requêtes ICMP de type 8 (echo).

Avant d'aller plus loin dans la présentation de la technique utilisée ici, il faut rappeler que l'architecture étudiée ne comprend que des interfaces Ethernet sur lesquelles transitent des trames avec balises IEEE 802.1Q. On ne dispose donc pas d'informations provenant de la couche physique sur le fonctionnement de ces interfaces. Si les deux liens à contrôler étaient de type série, les scripts présentés ci-dessous seraient totalement inutiles puisque les composants contrôleurs des liaisons série détectent directement les interruptions de transmission.

Il faut aussi ajouter que, même avec des réseaux locaux Ethernet, d'autres solutions existent. Ainsi, il est possible d'utiliser le protocole PPPoE qui offre toutes les fonctions du protocole PPP sur des liaisons Ethernet. Pour un exemple de mise en œuvre, voir l'article Modélisation d'un lien WAN avec PPPoE.

Avec l'architecture correspondant à la vue topologie logique présentée au début à la Section 2, « Présentation de la topologie réseau étudiée », on place deux scripts développés en langage shell qui fonctionnent en permanence sur les routeurs R1 et R3. Le code ce ces deux scripts est donné dans l'Annexe E, Scripts de contrôle d'état de liens.

La partie intéressante de ces deux scripts est extraite ci-dessous.

while $(true) ; do
  msg=$(/bin/ping -W 2 -n -c 1 ${neighbor} 2>&1 | egrep '(bytes from|100% packet loss)') 1

  if [[ "${msg}" =~ "bytes from" ]] && [[ ! -e /tmp/${neighbor}_up ]]; then 2
    ip route add default via ${neighbor} 3
    touch /tmp/${neighbor}_up 4
    keepalive_debug "${neighbor} is reachable, default route added" 5
  fi

  if [[ "${msg}" =~ "100% packet loss" ]] && [[ -e /tmp/${neighbor}_up ]]; then 6
    ip route del default via ${neighbor} 7
    rm -f /tmp/${neighbor}_up 8
    keepalive_debug "${neighbor} is not reachable, default route deleted" 9
  fi

  sleep ${delay} 10
done

1

La collecte du message d'information ICMP se fait à l'aide d'une seule requête dont on a limité le temps d'attente de réponse à 2 secondes. En fonction de cette réponse on extrait deux chaînes de caractères : "bytes from" si la réponse est positive ou "100% packet loss" si aucune réponse n'a été obtenue dans le temps imparti.

La réponse stockée dans la variable ${msg}.

2 6

Suivant le contenu de la variable ${msg} et de l'état précédemment enregistré du lien, on ajoute ou supprime la route par défaut vers le routeur ISP.

3 7

La commande d'ajout et de suppression de la route par défaut suppose que le propriétaire du processus a la capacité à utiliser cette instruction.

La variable ${neighbor} contient l'adresse IP de la passerelle à atteindre.

4 8

Le fichier /tmp/${neighbor}_up est utilisé comme variable d'état. Il est créé lors de l'ajout de la route par défaut lorsque le lien vers le routeur ISP est à nouveau actif. Il est effacé lorsque ce même lien est perdu.

5 9

Les deux scripts utilisent une fonction de journalisation système embryonnaire keepalive_debug qui permet d'enregistrer les mouvements sur les liens. Une copie des messages générés à l'aide de cette fonction est donnée à la fin de la section suivante sur l'analyse réseau.

10

Dans le cas de cette maquette, le délai a été fixé à 10 secondes par l'intermédiaire de la variable ${delay}. L'idée étant d'avoir un comportement qui se rapproche de la période des Hello packets du protocole OSPF.

6.2. Analyse réseau sur le routeur ISP avec tolérance aux pannes sur les flux entrants

Pour caractériser la tolérance aux pannes sur les flux entrants dans l'aire OSPF via le routeur ISP, on suit la séquence d'instructions suivante.

  1. Sur le système hôte, on créé un petit script de téléchargement en boucle que l'on exécute dans un terminal dédié.

    $ cat download.sh 
    #!/bin/bash
    
    while true
    do
      wget http://10.1.20.2/debian-6.0.3-amd64-CD-1.iso
      rm debian-6.0.3-amd64-CD-1.iso
    done
    
    $ screen sh -x download.sh
    
  2. Sur le routeur ISP, on commence par lancer la capture de trafic dans un terminal dédié. Ensuite, on désactive puis réactive les interfaces réseau connectées aux liaisons avec l'aire OSPF.

    $ screen tshark -i eth1 ! port 22 -a filesize:8192000 -w /var/tmp/failover-host-inbound.pcap
    

    Le choix du lien à désactiver dépend de l'enregistrement des communications après marquage des paquets provenant de l'aire OSPF. Dans le cas ci-dessous, c'est le lien entre R1 et ISP qui était utilisé avant la désactivation de l'interface eth1.101.

    # conntrack -L
    tcp      6 299 ESTABLISHED src=192.0.2.1 dst=10.1.20.2 sport=50403 dport=80 \
                               src=10.1.20.2 dst=192.0.2.1 \
                               sport=80 dport=50403 [ASSURED] mark=101 use=1
    <snipped/>
    # ip link set dev eth1.101 down
    <attendre au moins 10s/>
    # conntrack -L
    tcp      6 299 ESTABLISHED src=192.0.2.1 dst=10.1.20.2 sport=50405 dport=80 \
                               src=10.1.20.2 dst=192.0.2.1 \
                               sport=80 dport=50405 [ASSURED] mark=103 use=1
    <snipped/>
    # ip link set dev eth1.101 up
    <attendre au moins 10s/>
    # conntrack -L
    tcp      6 299 ESTABLISHED src=192.0.2.1 dst=10.1.20.2 sport=50405 dport=80 \
                               src=10.1.20.2 dst=192.0.2.1 \
                               sport=80 dport=50405 [ASSURED] mark=103 use=1
    <snipped/>
    # ip link set dev eth1.103 down
    <attendre au moins 10s/>
    # conntrack -L
    tcp      6 299 ESTABLISHED src=192.0.2.1 dst=10.1.20.2 sport=50405 dport=80 \
                               src=10.1.20.2 dst=192.0.2.1 \
                               sport=80 dport=50405 [ASSURED] mark=101 use=1
    <snipped/>
    # ip link set dev eth1.103 up
    

Comme le téléchargement est effectué entre le système hôte et une instance de machine virtuelle, les débits disponibles sont importants et le volume de trafic capturé pour caractériser le basculement d'un lien sur l'autre augmente très rapidement. Le graphique ci-dessous est un extrait obtenu à partir d'une capture d'environ 1.2Go.

Caractérisation graphique de la tolérance aux pannes réseau.

Les choix de couleurs de courbes sont les mêmes que dans la section précédente.

  • La courbe noire correspond à l'utilisation du lien entre R1 et ISP : le VLAN 101.

  • La courbe rouge correspond à l'utilisation du lien entre R3 et ISP : le VLAN 103.

  • La courbe verte est là pour indiquer que les interruptions de trafic correspondent à la rotation des fichiers téléchargés sur le système hôte depuis le serveur web installé sur l'hôte host.

Suite aux manipulations effectuées sur les interfaces du routeur ISP, les journaux système des deux routeurs en vis-à-vis donnent les résultats suivants.

  • Vu du routeur R1 :

    $ cat /var/log/r1-keepalive.log
    janv. 04 22:05:01: START
    janv. 04 22:05:01: daemonize ./r1-keepalive.sh
    janv. 04 22:05:01: daemonized ./r1-keepalive.sh
    janv. 04 22:05:01: alive_ping
    janv. 04 22:05:01: 10.1.30.2 is reachable, default route added
    janv. 04 22:12:36: 10.1.30.2 is not reachable, default route deleted
    janv. 04 22:13:11: 10.1.30.2 is reachable, default route added
    
  • Vu du routeur R3 :

    $ cat /var/log/r3-keepalive.log 
    janv. 04 22:06:34: START
    janv. 04 22:06:34: daemonize ./r3-keepalive.sh
    janv. 04 22:06:34: daemonized ./r3-keepalive.sh
    janv. 04 22:06:34: alive_ping
    janv. 04 22:13:29: 10.1.30.10 is not reachable, default route deleted
    janv. 05 16:26:22: 10.1.30.10 is reachable, default route added