inetdoc.net

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)') 

  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

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.

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.

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.