4. Répartition de trafic - load balancing

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.

4.1. Route de synthèse multichemins sur le routeur ISP - multipath static summary route

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é nexthop sert à 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.1 est joignable via l'interface eth1.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.

4.2. Analyse réseau sur le routeur ISP avec répartition de trafic

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' premier
etu@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 VLANs 101 et 103.

  • 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ôte host, 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 host et on lance le navigateur web lynx. L'ouverture de la page www.iana.org entraîne les échanges classiques de requêtes DNS puis HTTP. Ce sont ces échanges qui doivent valider l'utilisation des deux liens entre le routeur ISP et l'aire OSPF.

  • Après avoir consulté une ou deux pages web, on referme la session sur host et 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.

Phases de la consultation de la page www.iana.org.

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ôte host à 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 site www.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.

  1. 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
  2. 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
  3. 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] 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.