Table of Contents
La fonction d'un routeur est de faire transiter les paquets entrant vers l'interface de sortie la plus appropriée pour les acheminer à leur destination, a priori en diminuant la distance restant à parourir (si possible).
Internet propose un routage hierarchisé à 2 niveaux :
La frontière entre les 2 parties est définie :
| Classe | netmask | prefix | intervalle |
| A | 255.0.0.0 | /8 | 0.0.0.0 - 127.255.255.255 |
| B | 255.255.0.0 | /16 | 128.0.0.0 - 191.255.255.255 |
| C | 255.255.255.0 | /24 | 192.0.0.0 - 223.255.255.255 |
Nous ne parlerons pas des adresses de classe D (224.0.0.0 - 239.255.255.255) réservées aux réseaux multicast qui ne sont pas abordés dans ce chapitre,ni les adresses de classe E (240.0.0.0 - 255.255.255.255) réservées aux réseaux expérimentaux.
Cette technique, bien que devenue obsolète, à laisser des traces dans le protocole de routage RIPv1 que nous verrons plus loin (même si l'usage de RIP tend à disparaître lui-aussi pour d'autres raisons)
L'adressage par classe a été jusqu'au année 1990 le principe du routage entre les réseaux.
Même dans le contexte précédent, un administrateur d'un réseau important devait souvent redécouper son espace d'adressage pour s'adapter aux contraintes topologiques de son réseaux.
Cette première technique, parfois dénommée "VLSM" pour "Variable Length Subnetting Mask" permet à un administrateur d'étendre le netmask d'un certain nombre de bits pour réaliser un plan d'adressage compatible avec ces contraintes.
Même un protocole ancien comme RIPv1 prend en compte (avec certaines réserves) cette technique.
Ceci ne résolvait pas les problèmes qui ont commencé à apparaitre sur les routeurs ïnter-network" au cours des années 1980 avec l'ouverture d'Internet aux entreprises et au grand public. L'explosion du nombre de réseaux a très vite saturé les tables de routages et une évolution pour le passage à l'échelle était nécessaire.
Dès 1993 (RFC1519- revue en 2006 RFC4632), CIDR ( Classless Internet Domain Routing ) a été formalisé et généralisé.
Pourquoi ?
- réduire la taille des tables de routage avec l'aggrégation de routes
- permettre un découpage plus pertinent de l'espace d'adressage pour économiser les adresses
Cette technique permet l'aggrégation de route qui consiste à regrouper en une seule entrée des adresses réseaux ayant un préfixe commun et un même prochain saut (il faut aussi que les métriques soient compatibles).
La longueur minimale de masque est 0 (1 pour pouvoir faire un peu de routage) et la longueur maximale est 30.
Dans chaque classe d'adresse est définie un plage d'adresse privée utilisable localement.
| Classe | plage d'adresses | notation |
| A | 10.0.0.0 - 10.255.255.255 | 10.0.0.0/8 |
| B | 172.16.0.0 - 172.31.255.255 | 172.16.0.0/12 |
| C | 192.168.0.0 - 192.168.255.255 | 192.168.0.0/16 |
Travail personnel : déterminer les RFC ayant trait aux adresses réservées et précisées leurs valeurs.
Une entrée de table de routage peut etre résumée sous la forme :
network address netmask next hop interface admin.metric origine La notion de métrique administrative est utile lorsque les routes proviennent de plusieurs sources (processus de routage dynamique, route statique) et permet d'arbitrer les choix lorsqu'une meme destination est annoncée par plusieurs sources. L'origine mémorise comment la route a été apprise.
Lors de l'arrivée d'un paquet, l'adresse de destination est extraite.
Pour tester une entrée de la table de routage, le netmask est appliquée à l'adresse de destination pour en extraire la partie network. Si elle est égale à la network address, la route correspond ( match ), sinon cette dernière est rejetée.
L'entrée la plus précise ( netmask correspondant au préfixe le plus long) est toujours choisie en priorité, si plusieurs entrées sont sélectionnables.
La route par défaut ( 0.0.0.0/0 ), si elle est définie, est donc choisie seulement si toutes les autres routes ont été rejetées.
Les implémentations sont souvent plus performantes que la méthode exposée ici.
D'autres paramètres peuvent etre pris en compte dans le processus de décision, que ce soit avant (PRE) ou après (POST) la consulatation de la table de routage (routage politique, QOS, choix de la table de routage ou VRF, NAT, PAT, ...).
Les techniques de NAT et PAT seront vues ultérieurement (en TP et en cours).
La construction de la table de routage est basé sur différentes sources :
- connected : en IPv4, une interface est liée à une adresse (et un netmask); le réseau correspondant est donc directement inséré dans la table et ce, tant que l'interface demeure active.
- static : saisie par l'opérateur - elle n'est jamais enlevée.
- dynamic : injectée dans la table par un processus de routage (RIP, OSPF, IS-IS, EIGRP, BGP, ...), elle peut etre enlevée automatiquement si la route est perdue; les routes dynamiques peuvent etre calculée où provenir d'une "redistribution" ( routes issues d'autres processus de routages, connectées ou statiques ).
/sbin/ifconfig <interface> <adresse IPv4>/<prefix length>
(config)#interface <type> <number> (config-int)#ip address <adresse IPv4> <netmask> (config-int)#no shutdown
D'autres paramètres peuvent etre ajoutés selon le type d'interface. À noter que sur un routeur, une interface doit etre explicitement activée (administrativly up).
Ajouter par l'opérateur à l'aide d'une commande :
(config)#ip route <network> <netmask> [ <nextHop | interface> ] <metric>
# traditionnel route add -net <network/prefix> gw <nextHop> metric <metric>
#iproute2 (au plus simple) ip route add <network/prefix> [ metric <metric> ] nexthop via <ip address> [ dev <interface> ] ...
Suffisante dans les situations simples, cette méthode nécessite systématiquement des modifications par l'opérateur pour s'adapter aux modifications de la topologie (évolutions du réseaux, pannes) et devient rapidement fastidieuse.
3 familles d'algorithmes :
- vecteur de distance (RIP, EIGRP, RIPnG)
- état des liens (OSPFv2, IS-IS, OSPFv3)
- politique, vecteur de chemin (BGP)