Aller au contenu principal

Réseaux & Web · L2 · Section 2/7

Routage

Progression

Points d’expérience : XPSérie de jours consécutifs : · —Progression du module : — / —compris

#Routage

Acheminer des paquets vers leur destination via des tables de routage; intra-domaine (OSPF) et inter-domaine (BGP) en bref.

Objectifs d'apprentissage

  • Expliquer la table de routage, le LPM et la route par défaut.
  • Différencier routage statique/dynamique; citer OSPF (intra) et BGP (inter).
  • Comprendre CIDR, agrégation de routes, et métriques simples (coût OSPF).

#Concepts

  • Table de routage: préfixe --> next-hop/iface.
  • Longest Prefix Match (LPM): choisir l'entrée la plus spécifique.
  • Routage statique vs dynamique (protocoles d'échanges).

#Résolution du next-hop

Après avoir choisi un next-hop logique, la machine résout son adresse MAC via ARP (IPv4) ou ND (IPv6) sur le lien de sortie, puis émet la trame. Sans entrée ARP/ND, un ARP request/NS est diffusé; l'absence de réponse mène à un drop.

#TTL/Hop Limit et traceroute

Chaque routeur décrémente TTL (IPv4) ou Hop Limit (IPv6). À 0, le paquet est détruit et un ICMP Time Exceeded est renvoyé; traceroute exploite ce mécanisme pour lister les sauts.

#Animation: décision de forwarding (LPM)

Préfixes
0.0.0.0/0, 10.0.0.0/8, 10.1.0.0/16…
Destination
10.1.2.3 matche /8 et /16
LPM
Choisir 10.1.0.0/16 (plus spécifique)
Next-hop
Transmettre via l’interface; décrémenter TTL

#Retries réseau (exponentiel + jitter)

Exponential backoff avec jitter

#Agrégation et annonces

  • CIDR permet d'agréger des préfixes contigus pour réduire la taille des tables (ex.: 10.0.0.0/16 pour 10.0.0.0/17 et 10.0.128.0/17).
  • En BGP, les attributs (AS_PATH, LOCAL_PREF, MED) influencent le chemin choisi; la « meilleure » route suit une politique, pas nécessairement la plus courte.

#Lab: lire la table de routage de sa machine

Objectif: observer une vraie table, appliquer le LPM à la main, puis vérifier la prédiction.

Sur Linux, la table du noyau (une entrée par ligne, préfixe puis next-hop et interface):

texttext

1$ ip route show2default via 192.168.1.1 dev eth0310.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.24192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.23

Questions, avec la table ci-dessus:

  1. Quel next-hop sert 192.168.1.200? Réponse: aucun routeur, la destination est sur le lien local (eth0 direct, résolution ARP vers la machine elle-même).
  2. Quel next-hop sert 10.8.0.9? Réponse: tun0, liaison directe, le préfixe /24 couvre l'adresse.
  3. Quel next-hop sert 93.184.216.34? Réponse: la route par défaut via 192.168.1.1, aucune entrée plus spécifique ne correspond.

Vérification par traçage: ip route get 93.184.216.34 doit renvoyer la même décision (via 192.168.1.1 dev eth0), et traceroute -n 93.184.216.34 doit montrer 192.168.1.1 comme premier saut. Observation attendue: le premier TTL expiré correspond toujours au next-hop sortant de votre table.

#Lab: décomposition LPM et agrégation

Calculez à la main puis vérifiez avec Python (ipaddress):

  1. Les deux préfixes 10.0.0.0/17 et 10.0.128.0/17 couvrent 10.0.0.0 à 10.0.255.255: leur agrégat exact est 10.0.0.0/16 (17e bit de l'adresse: 0 pour le premier bloc, 1 pour le second, donc l'agrégat relâche ce bit en passant à /16).
  2. Avec les entrées 0.0.0.0/0, 10.0.0.0/8, 10.0.4.0/24, la destination 10.0.4.7 emprunte le /24 (le plus spécifique), tandis que 10.0.5.1 retombe sur le /8.
  3. Une annonce 172.16.0.0/12 agrège 172.16.0.0/16 jusqu'à 172.31.0.0/16: les seize blocs /16 partagent les douze premiers bits.

Vérification (une console Python suffit):

pythonpython

1import ipaddress2net = ipaddress.ip_network('10.0.4.0/24')3print('10.0.4.7' in net, '10.0.5.1' in net)   # True False4sup = ipaddress.collapse_addresses([ipaddress.ip_network('10.0.0.0/17'),5                                    ipaddress.ip_network('10.0.128.0/17')])6print(list(sup))   # [IPv4Network('10.0.0.0/16')]

#Diagnostic: trois pannes typiques et leur signature

  • Next-hop injoignable (ip route montre une voie mais le ping vers le next-hop ne répond pas): la table est correcte, le lien ou le routeur est en panne; ping <next-hop> isole la cause en une commande.
  • Route manquante (pas d'entrée ni de route par défaut): le paquet est abandonné en local, message Network is unreachable; à distinguer d'un ping sans réponse, qui suppose une route mais une destination morte.
  • Asymétrie ou route plus spécifique erronée: la requête part, la réponse revient par un autre chemin (ou est envoyée vers la mauvaise interface); traceroute dans les deux sens révèle la divergence, ip route get confirme le choix côté émission.

#Mini-quiz

Pour 10.0.5.1, laquelle matche ?
Pour 10.0.5.1, laquelle matche ?

#Quiz

Quelle entrée sera choisie pour 192.168.1.42 ?
Quelle entrée sera choisie pour 192.168.1.42 ?

Exercice écrit (corrigé): un hôte possède default via 203.0.113.1, 203.0.113.0/24 dev eth0 et 198.51.100.0/24 via 203.0.113.9. Donnez l'interface et le next-hop pour 198.51.100.7 et pour 192.0.2.5. Correction: 198.51.100.7 correspond au préfixe via 203.0.113.9 (route spécifique, next-hop résolu par ARP sur eth0); 192.0.2.5 ne correspond à aucun préfixe spécifique, donc route par défaut via 203.0.113.1.