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.
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 Routage inter-VLAN et protocole 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)') if [[ "${msg}" =~ "bytes from" ]] && [[ ! -e /tmp/${neighbor}_up ]]; then ip route add default via ${neighbor} touch /tmp/${neighbor}_up keepalive_debug "${neighbor} is reachable, default route added" fi if [[ "${msg}" =~ "100% packet loss" ]] && [[ -e /tmp/${neighbor}_up ]]; then ip route del default via ${neighbor} rm -f /tmp/${neighbor}_up keepalive_debug "${neighbor} is not reachable, default route deleted" fi sleep ${delay} done
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 :
" La réponse stockée dans la variable |
|
Suivant le contenu de la variable |
|
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 |
|
Le fichier |
|
Les deux scripts utilisent une fonction de journalisation
système embryonnaire |
|
Dans le cas de cette maquette, le délai a été fixé à 10 secondes
par l'intermédiaire de la variable |
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.
-
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 -
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.pcapLe 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
etISP
qui était utilisé avant la désactivation de l'interfaceeth1.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.
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
etISP
: le VLAN101
. -
La courbe rouge correspond à l'utilisation du lien entre
R3
etISP
: le VLAN103
. -
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