Dans la configuration de l'aire OSPF présentée dans la section précédente, les routeurs et les hôtes réseau en général disposent de deux liens vers le routeur de niveau supérieur ISP. Si les passerelles par défaut des deux routeurs de bordure R1 et R3 sont publiées via le protocole de routage dynamique à destination de tous les routeurs de l'aire, le routeur ISP, lui ne dispose pas de cette information.
Sans configuration particulière, le routage se fait principalement sur la base des adresses IP destination et le trafic sortant peut transiter aussi bien par R1 que par R3. Le trafic retour ou entrant transite exclusivement par ISP et il est nécessaire de renseigner les réseaux appartenant à l'aire OSPF dans sa table de routage. La technique usuelle dans le contexte de la topologie étudiée consiste à implanter une route de synthèse qui englobe la totalité des réseaux situés aux niveaux inférieurs.
Pour déterminer l'adresse réseau qui englobe les réseau de l'aire, on dispose de l'outil aggregate fourni avec le paquet du même nom. Voici deux exemples d'exécution sur le routeur R2 après affichage de la table de routage.
# ip route ls
default proto zebra metric 10
nexthop via 10.1.23.3 dev eth0.23 weight 1
nexthop via 10.1.12.1 dev eth0.12 weight 1
10.1.12.0/26 dev eth0.12 proto kernel scope link src 10.1.12.2
10.1.13.0/26 proto zebra metric 2
nexthop via 10.1.12.1 dev eth0.12 weight 1
nexthop via 10.1.23.3 dev eth0.23 weight 1
10.1.20.0/26 dev eth0 proto kernel scope link src 10.1.20.1
10.1.23.0/26 dev eth0.23 proto kernel scope link src 10.1.23.2
Dans le premier exemple ci-dessous, l'adresse 10.1.0.0/20 n'englobe que les réseaux 10.1.12.0/26 et 10.1.13.0/26 marqués avec le signe -. Le masque réseau /20 est donc insuffisant pour couvrir la liste complète des réseaux de niveau inférieur.
# (echo '10.1.0.0/20' ;\
ip route ls | grep -Eo '^([0-9]{1,3}\.){3}[0-9]{1,3}/[0-9]{2}') |\
aggregate -v
aggregate: maximum prefix length permitted will be 32
[ 1] 10.1.0.0/20
[ 2] - 10.1.12.0/26
[ 3] - 10.1.13.0/26
[ 4] 10.1.20.0/26
[ 5] 10.1.23.0/26
Dans le second exemple ci-dessous, l'adresse 10.1.0.0/19 englobe bien tous les réseaux de l'aire OSPF. Le masque réseau /19 permet de couvrir tous les réseaux de l'aire OSPF en une seule et unique entrée.
# (echo '10.1.0.0/19' ;\
ip route ls | grep -Eo '^([0-9]{1,3}\.){3}[0-9]{1,3}/[0-9]{2}') |\
aggregate -v
aggregate: maximum prefix length permitted will be 32
[ 1] 10.1.0.0/19
[ 2] - 10.1.12.0/26
[ 3] - 10.1.13.0/26
[ 4] - 10.1.20.0/26
[ 5] - 10.1.23.0/26
On peut donc implanter sur le routeur ISP une route statique de synthèse ou static summary route désignant les deux passerelles de l'aire OSPF.
# ip route add 10.1.0.0/19 nexthop via 10.1.30.1 nexthop via 10.1.30.9
Une fois cette commande exécutée, la table de routage du routeur ISP est la suivante.
# ip route ls
default via 192.0.2.1 dev eth0
10.1.0.0/19
nexthop via 10.1.30.1 dev eth1.101 weight 1
nexthop via 10.1.30.9 dev eth1.103 weight 1
10.1.30.0/29 dev eth1.101 proto kernel scope link src 10.1.30.2
10.1.30.8/29 dev eth1.103 proto kernel scope link src 10.1.30.10
192.0.2.0/27 dev eth0 proto kernel scope link src 192.0.2.3
-
Le mot clé
nexthopsert à définir plusieurs passerelles pour un même réseau de destination. -
Les interfaces via lesquelles les paquets doivent être transmis sont ajoutées automatiquement en fonction de l'adresse IP de passerelle. Par exemple, la passerelle
10.1.30.1est joignable via l'interfaceeth1.101. -
Sans indication particulière, les passerelles ont la même pondération :
weight 1. Comme précisé dans la Section 2, « Présentation de la topologie réseau étudiée », toutes les liaisons sont homogènes et offrent le même débit réseau.
Maintenant que la capacité à exploiter les deux liens est implantée à chaque extrémité, il ne reste qu'à valider le fonctionnement à partir du trafic émis et reçu l'hôte host transitant par ISP. C'est sur ce routeur que l'on procède à l'analyse du trafic avec l'outil tshark qui permet la capture de trafic en mode console. Le système du routeur ISP a en plus été configuré pour pouvoir effectuer les captures au niveau utilisateur normal en appliquant les instructions données dans l'article Capturer le trafic réseau au niveau utilisateur avec Wireshark.
Voici une séquence typique de capture sur le routeur ISP pendant le chargement d'une page Web sur host.
etu@isp:~$screen tshark -i eth1 ! port 22 -w /var/tmp/multipath-host.pcap [detached from 13986.pts-0.isp]etu@isp:~$ssh 10.1.20.2 Linux host 3.1.0-1-amd64 #1 SMP Mon Nov 14 08:02:25 UTC 2011 x86_64 <snipped/>etu@host:~$lynx www.iana.org Recherche 'www.iana.org' premieretu@host:~$logout Connection to 10.1.20.2 closed.etu@isp:~$screen -r [screen is terminating]etu@isp:~$ls -lh /var/tmp/multipath-host.pcap -rw------- 1 etu etu 12K déc. 11 23:25 /var/tmp/multipath-host.pcap
-
La commande screen fournie avec le paquet du même nom, sert à ouvrir un terminal dans lequel on lance la capture des paquets avec tshark.
-
L'interface utilisée pour la capture réseau est
eth1. Comme le «composant» contrôleur d'interface réseau sur une machine virtuelle ne dispose pas de fonctions évoluées, tous les types de trames transitant par l'interface sont capturés. On enregistre ainsi les trames avec les balises IEEE 802.1Q des VLANs101et103. -
L'option
! port 22élimine tous les segments utilisant le port SSH comme source ou comme destination. Comme le protocole SSH est utilisé pour ouvrir les sessions sur les routeurs et l'hôtehost, il est inutile de capturer ce trafic. -
Les paquets capturés sont enregistrés dans le fichier
/var/tmp/multipath-host.pcap. Comme le directory sticky bit est positionné sur le répertoire/var/tmp/, l'utilisateur normal dispose des droits d'écriture nécessaires à l'enregistrement des paquets capturés. -
Une fois la capture lancée, on ouvre un terminal sur
hostet on lance le navigateur web lynx. L'ouverture de la pagewww.iana.orgentraîne les échanges classiques de requêtes DNS puis HTTP. Ce sont ces échanges qui doivent valider l'utilisation des deux liens entre le routeurISPet l'aire OSPF. -
Après avoir consulté une ou deux pages web, on referme la session sur
hostet on arrête la capture réseau. Il ne reste alors qu'à analyser le contenu du fichier de capture.
En ouvrant le fichier de capture avec Wireshark, on retrouve les phases de la consultation de page web.
Cette copie d'écran montre les échanges au niveau réseau ainsi que les protocoles utilisés par les couches supérieures. On retrouve bien les adresses IP des différents protagonistes.
-
10.1.20.2: hôtehostà l'initiative du trafic réseau. -
192.0.2.1: système hôte hébergeant les instances de machines virtuelles sur lequel on trouve aussi un service de résolution des noms de domaines de type cache. -
192.0.32.8: serveur web hébergeant le sitewww.iana.org.
À première vue, la copie d'écran et l'identification des hôtes en communication ne montrent rien d'original. Il faut aller jusqu'à la visualisation des trames au niveau liaison pour caractériser la distribution du trafic sur les différents liens.
Prenons les trois étapes de l'établissement de connexion TCP entre le poste client et le serveur web.
-
La demande d'établissement de connexion ([SYN]) est émise par le poste client. Elle transite par le lien correspondant au VLAN 103.
No. Time Source Destination Protocol Info 19 21.215999 10.1.20.2 192.0.32.9 TCP 56075 > http [SYN] Seq=0 Frame 19: 78 bytes on wire (624 bits), 78 bytes captured (624 bits) Ethernet II, Src: RealtekU_12:34:06 (52:54:00:12:34:06), Dst: de:ad:be:ef:01:03 (de:ad:be:ef:01:03) 802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 103 000. .... .... .... = Priority: Best Effort (default) (0) ...0 .... .... .... = CFI: Canonical (0) .... 0000 0110 0111 = ID: 103 Type: IP (0x0800) Internet Protocol Version 4, Src: 10.1.20.2 (10.1.20.2), Dst: 192.0.32.9 (192.0.32.9) Transmission Control Protocol, Src Port: 56075 (56075), Dst Port: http (80), Seq: 0, Len: 0 -
L'acquittement de la demande d'établissement de connexion et du numéro initial de séquence ([SYN, ACK]) du poste client est émis par le serveur web. Il transite par le lien correspondant au VLAN 101.
No. Time Source Destination Protocol Info 20 21.216434 192.0.32.9 10.1.20.2 TCP http > 56075 [SYN, ACK] Seq=0 Ack=1 Frame 20: 78 bytes on wire (624 bits), 78 bytes captured (624 bits) Ethernet II, Src: de:ad:be:ef:01:01 (de:ad:be:ef:01:01), Dst: RealtekU_12:34:04 (52:54:00:12:34:04) 802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 101 000. .... .... .... = Priority: Best Effort (default) (0) ...0 .... .... .... = CFI: Canonical (0) .... 0000 0110 0101 = ID: 101 Type: IP (0x0800) Internet Protocol Version 4, Src: 192.0.32.9 (192.0.32.9), Dst: 10.1.20.2 (10.1.20.2) Transmission Control Protocol, Src Port: http (80), Dst Port: 56075 (56075), Seq: 0, Ack: 1, Len: 0 -
L'acquittement du numéro initial de séquence ([ACK]) du serveur web est émis par le poste client. Il transite par le lien correspondant au VLAN 103.
No. Time Source Destination Protocol Info 21 21.217229 10.1.20.2 192.0.32.9 TCP 56075 > http [ACK] Seq=1 Ack=1 Frame 21: 70 bytes on wire (560 bits), 70 bytes captured (560 bits) Ethernet II, Src: RealtekU_12:34:06 (52:54:00:12:34:06), Dst: de:ad:be:ef:01:03 (de:ad:be:ef:01:03) 802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 103 000. .... .... .... = Priority: Best Effort (default) (0) ...0 .... .... .... = CFI: Canonical (0) .... 0000 0110 0111 = ID: 103 Type: IP (0x0800) Internet Protocol Version 4, Src: 10.1.20.2 (10.1.20.2), Dst: 192.0.32.9 (192.0.32.9) Transmission Control Protocol, Src Port: 56075 (56075), Dst Port: http (80), Seq: 1, Ack: 1, Len: 0
![]() |
Note |
|---|---|
|
Le fichier de capture réseau comprenant l'ensemble des échanges est téléchargeable : multipath-host.pcap |
Avec ces trois étapes de l'établissement d'une connexion TCP on caractérise bien la répartition du trafic sur les deux liens de transit entre les passerelles de l'aire OSPF et le routeur de niveau supérieur ISP. Cette répartition n'est pas nécessairement équitable dans la mesure où l'alternance de l'utilisation des liens n'intervient que lors des permutations entre les adresses IP source et destination. Ainsi, avec un profil utilisateur de type «globe oculaire passif», le téléchargement de flux vidéo n'utilise qu'un seul lien ; ce qui provoque un déséquilibre en volume de trafic sachant que la requête HTTP n'occupe que quelques centaines d'octets tandis que le fichier vidéo demandé occupe quelques mégaoctets. Si on disposait d'un parc important de postes de travail en lieu et place du seul système host, on pourrait dire que la répartition de trafic est statistiquement équitable.
Si la balance de charge entre plusieurs liens, telle qu'elle est présentée ici est très intéressante, elle peut cependant engendrer de gros problèmes dans le cas où un lien viendrait à être indisponible. En effet, la solution de répartition utilise nécessairement toutes les passerelles introduites dans les tables de routage. Il serait donc souhaitable de compléter la solution en introduisant la notion de tolérance aux pannes. C'est justement l'objet de la section suivante.


![[Note]](/images/note.png)