Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document décrit comment les routeurs fonctionnent, sont configurés et comment sélectionner une route pour eux.
Aucune condition préalable spécifique n'est requise pour ce document.
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Pour plus d'informations sur les conventions utilisées dans ce document, consultez Conventions relatives aux conseils techniques Cisco.
Un aspect des routeurs Cisco est la manière dont le routeur choisit la meilleure route parmi celles présentées par les protocoles, la configuration manuelle et divers autres moyens. La sélection d’une route nécessite des connaissances sur le fonctionnement des routeurs Cisco.
Trois processus sont impliqués dans la création et la gestion de la table de routage dans un routeur Cisco :
Divers processus de routage, qui en réalité exécutent un protocole réseau (ou de routage), comme l'Enhanced interior gateway routing protocol (EIGRP), le Border Gateway Protocol (BGP), l'IS-IS (Intermediate System-to-Intermediate System), et l'Open Shortest Path First (OSPF).
La table de routage elle-même, qui accepte les informations des processus de routage et répond également aux demandes de renseignements du processus de transfert.
Le processus de transfert, qui demande des informations de la table de routage pour prendre une décision de transfert de paquets.
Vous devez examiner l’interaction entre les protocoles de routage et la table de routage pour comprendre comment la table de routage est construite.
Les principaux éléments à prendre en compte lors de la création de la table de routage sont les suivants :
Distance administrative - Il s'agit de la mesure de fidélité de source de la route. Si un routeur apprend l’existence d’une destination à partir de plusieurs protocoles de routage, la distance administrative est comparée et la préférence est accordée aux routes ayant la distance administrative la plus faible.
Métrique - Il s'agit d'une mesure utilisée par le protocole de routage pour calculer le meilleur chemin vers une destination donnée, s'il apprend plusieurs chemins vers la même destination. Chaque protocole de routage utilise une métrique différente.
Longueur du préfixe
Comme chaque protocole de routage reçoit des mises à jour et d'autres informations, il choisit le meilleur chemin vers n'importe quelle destination donnée et essaye d'installer ce chemin dans la table de routage. Par exemple, si EIGRP apprend d'un chemin vers 10.1.1.0/24, et décide que ce chemin particulier est le meilleur chemin EIGRP vers cette destination, il essaye d'installer le chemin qu'il a appris dans la table de routage.
Le routeur décide s'il doit installer ou non les routes présentées par les processus de routage en se basant sur la distance administrative de la route en question. Si ce chemin présente la distance administrative la plus faible vers cette destination (par rapport aux autres routes de la table), il est installé dans la table de routage. Si cette route n’est pas la route avec la meilleure distance administrative, alors la route est rejetée.
Par exemple, supposons qu’un routeur exécute quatre processus de routage : EIGRP, OSPF, RIP et IGRP. Maintenant, chacun des quatre processus a appris de diverses routes vers le réseau 192.168.24.0/24, et chacun a choisi son meilleur chemin à ce réseau à l'aide de ses métriques et de ses processus internes.
Chacun de ces processus essaie d'installer sa route vers 192.168.24.0/24 dans la table de routage. Les processus de routage ont chacun une distance administrative qui leur a été assignée, qui est utilisée pour décider quelle route doit être installée.
Distances administratives par défaut | |
---|---|
connected | 0 |
static | 1 |
eBGP | 20 |
EIGRP (interne) | 90 |
IGRP | 100 |
OSPF | 110 |
IS-IS | 115 |
DÉCHIRURE | 120 |
EIGRP (externe) | 170 |
iBGP | 200 |
Route récapitulative EIGRP | 5 |
Comme la route EIGRP interne présente la meilleure distance administrative (plus la distance administrative est petite, plus la préférence est élevée), elle est installée dans la table de routage.
Que font les autres protocoles, RIP, IGRP et OSPF, avec les routes qui n’ont pas été installées ? Que se passe-t-il si la route préférée, apprise d'EIGRP, échoue ? Le logiciel Cisco IOS® emploie deux approches pour résoudre ce problème . La première est de faire en sorte que chaque processus de routage essaie d'installer périodiquement ses meilleures routes. Si la route préférée échoue, la meilleure route suivante (déterminée par la distance administrative) réussit à la tentative suivante. L’autre solution consiste à demander au protocole de routage qui n’a pas réussi à installer sa route dans la table de se raccrocher à la route et de demander au processus de la table de routage de signaler si le meilleur chemin échoue.
Pour les protocoles qui ne possèdent pas leurs propres tables d’informations de routage, comme IGRP, la première méthode est utilisée. Chaque fois qu'IGRP reçoit une mise à jour d'une route, il essaye d'installer les informations mises à jour dans la table de routage. S’il existe déjà une route vers cette même destination dans la table de routage, la tentative d’installation échoue.
Pour les protocoles qui ont leur propre base de données d'informations de routage, tels qu'EIGRP, IS-IS, OSPF, BGP, et RIP, une route de secours est enregistrée quand la tentative initiale d'installation de la route échoue. Si route installée dans la table de routage échoue pour quelque raison, le processus de maintenance de la table de routage appelle chaque processus de protocole de routage qui a enregistré une route de secours, et leur demande de réinstaller la route dans la table de routage. S’il existe plusieurs protocoles avec des routes de secours enregistrées, la route préférée est choisie en fonction de la distance administrative.
La distance administrative par défaut n’est pas toujours adaptée à votre réseau ; vous pouvez l’ajuster de sorte que les routes RIP soient préférées aux routes IGRP. Mais, d'abord, regardez les implications si vous modifiez la distance administrative.
Il est très dangereux de modifier la distance administrative sur les protocoles de routage. Il peut entraîner des boucles de routage et d'autres bizarreries dans votre réseau. Par conséquent, modifiez toujours la distance administrative avec prudence. Assurez-vous de planifier le changement et d'en connaître les conséquences avant de procéder à cette opération.
Pour des protocoles entiers, il est facile de modifier la distance. Il vous suffit d’utiliser la commande distance dans le mode de sous-configuration du processus de routage. Vous pouvez également modifier la distance pour des routes apprises à partir d'une source uniquement dans certains protocoles, et vous pouvez modifier la distance uniquement pour quelques routes. Pour plus d'informations, référez-vous à Exemple de configuration de l'ajustement de la distance administrative pour la sélection de route dans les routeurs Cisco IOS.
Pour les routes statiques, pour modifier la distance de chaque route, entrez une distance après la commande ip route :
ip route network subnet mask next hop distance
Vous ne pouvez pas modifier la distance administrative pour toutes les routes statiques en même temps.
Les routes sont choisies et intégrées dans la table de routage en fonction de la distance administrative du protocole de routage. Les routes apprise du protocole de routage avec la plus faible distance administrative sont installées dans la table de routage. S'il y a plusieurs chemins vers la même destination à partir d'un seul protocole de routage, alors les différents chemins auraient la même distance administrative et le meilleur chemin est sélectionné selon les métriques. Les métriques sont des valeurs associées à des routes spécifiques qui les classent de la plus préférée à la moins préférée. Les paramètres utilisés pour déterminer les métriques sont différents pour différents protocoles de routage. Le chemin avec la métrique la moins élevée est sélectionné comme chemin optimal et installé dans la table de routage. S'il y a plusieurs chemins vers la même destination avec des métriques égales, l'équilibrage de charge est réalisé sur ces deux voies d'accès à coût égal. Pour plus d'informations sur l'équilibrage de charge consultez Comment fonctionne l'équilibrage de charge ?
Examinez un autre scénario pour voir comment le routeur gère une autre situation courante : la variation de la longueur des préfixes. Supposez, à nouveau, qu’un routeur exécute quatre processus de routage et que chaque processus a reçu ces routes :
EIGRP (interne) : 192.168.32.0/26
RIP : 192.168.32.0/24
OSPF : 192.168.32.0/19
Lesquelles de ces routes peuvent être installées dans la table de routage ? Puisque les routes internes EIGRP ont la meilleure distance administrative, vous pouvez supposer que la première peut être installée. Cependant, puisque chacune de ces routes a une longueur de préfixe différente (masque de sous-réseau), elles sont considérées comme des destinations différentes et elles peuvent toutes être installées dans la table de routage.
La section suivante fournit les informations de la table de routage pour prendre des décisions de transmission.
Examinez les trois routes qui ont été installées dans la table de routage et voyez à quoi elles ressemblent sur le routeur.
router# show ip route .... D 192.168.32.0/26 [90/25789217] via 10.1.1.1 R 192.168.32.0/24 [120/4] via 10.1.1.2 O 192.168.32.0/19 [110/229840] via 10.1.1.3 ....
Si un paquet arrive sur une interface du routeur destinée pour 192.168.32.1, quelle route le routeur choisirait-il ? Cela dépend de la longueur du préfixe, ou du nombre de bits dans le masque de sous-réseau. De plus longs préfixes sont toujours privilégiés par rapport à des plus courts lors de l'expédition d'un paquet.
Dans ce cas, un paquet destiné à 192.168.32.1 est orienté vers 10.1.1.1, car 192.168.32.1 fait partie du réseau 192.168.32.0/26 (192.168.32.0 à 192.168.32.63). Il fait partie également des deux autres routes disponibles, mais le 192.168.32.0/26 a le préfixe le plus long dans la table de routage (26 bits contre 24 ou 19 bits).
De même, si un paquet destiné à 192.168.32.100 arrive sur l'une des interfaces de routeur, il est transféré vers 10.1.1.2, car 192.168.32.100 ne se trouve pas dans 192.168.32.0/26 (192.168.32.0 à 192.168.32.63), mais se trouve dans la destination 192.168.32.0/24 (192.163) 8.32.0 à 192.168.32.255). De nouveau, il tombe également dans la fourchette couverte par 192.168.32.0/19, mais 192.168.32.0/24 a un préfixe plus long.
Où la commande ip classless configuration intervient dans les processus de routage et de transfert est souvent déroutant. En réalité, IP classless affecte uniquement le fonctionnement des processus de transfert dans Cisco IOS ; il n'affecte pas la façon dont la table de routage est construite. Si IP classless n'est pas configuré (avec la commande no ip classless), le routeur ne peut pas transférer les paquets vers les super-réseaux. Par exemple, placez à nouveau trois routes dans la table de routage et acheminez les paquets via le routeur.
Remarque : si la route de super-réseau ou par défaut est apprise via IS-IS ou OSPF, la commande de configuration no ip classless est ignorée. Dans ce cas, le comportement de commutation de paquets fonctionne comme si ip classless étaient configurés
router# show ip route .... 172.30.0.0/16 is variably subnetted, 2 subnets, 2 masks D 172.30.32.0/20 [90/4879540] via 10.1.1.2 D 172.30.32.0/24 [90/25789217] via 10.1.1.1 S* 0.0.0.0/0 [1/0] via 10.1.1.3
Le réseau 172.30.32.0/24 inclut les adresses 172.30.32.0 à 172.30.32.255, et le réseau 172.30.32.0/20 inclut les adresses 172.30.32.0 à 172.30.47.255. Vous pouvez donc essayer de commuter trois paquets via cette table de routage et voir quels sont les résultats.
Un paquet destiné à 172.30.32.1 est transféré à 10.1.1.1, puisque c'est la correspondance de préfixe la plus longue.
Un paquet destiné à 172.30.33.1 est transféré à 10.1.1.2, puisque c'est la correspondance de préfixe la plus longue.
Un paquet destiné à 192.168.10.1 est transmis à 10.1.1.3 ; comme ce réseau n’existe pas dans la table de routage, ce paquet est transmis à la route par défaut.
Un paquet destiné à 172.30.254.1 est abandonné.
La réponse à ces quatre questions est le dernier paquet, qui est abandonné. Il est abandonné car sa destination, 172.30.254.1, se trouve dans un réseau principal connu, 172.30.0.0/16, mais le routeur ne connaît pas ce sous-réseau particulier dans ce réseau principal.
C'est l'essence du routage par classe : si une partie d'un réseau principal est connue, mais que le sous-réseau vers lequel le paquet est destiné au sein de ce réseau principal est inconnu, le paquet est abandonné.
L’aspect le plus déroutant de cette règle est que le routeur n’utilise la route par défaut que si le réseau principal de destination n’existe pas du tout dans la table de routage.
Cela peut entraîner des problèmes dans un réseau où un site distant, avec une seule connexion au reste du réseau, n'exécute aucun protocole de routage, comme illustré.
N'exécute aucun protocole de routage
Le routeur du site distant est configuré comme ceci :
interface Serial 0 ip address 10.1.2.2 255.255.255.0 ! interface Ethernet 0 ip address 10.1.1.1 255.255.255.0 ! ip route 0.0.0.0 0.0.0.0 10.1.2.1 ! no ip classless
Avec cette configuration, les hôtes du site distant peuvent atteindre des destinations sur Internet (via l'entité 10.x.x.x), mais pas les destinations dans l'entité 10.x.x.x, qui est le réseau de l'entreprise. Comme le routeur distant connaît une partie du réseau 10.0.0.0/8, les deux sous-réseaux connectés directement et aucun autre sous-réseau 10.x.x.x, il suppose que ces autres sous-réseaux n’existent pas et abandonne les paquets qui leur sont destinés. Toutefois, le trafic destiné à Internet n’a jamais de destination dans la plage d’adresses 10.x.x.x et est donc correctement routé via la route par défaut.
Si vous configurez ip classless sur le routeur distant, ce problème est résolu parce qu'il permet au routeur d'ignorer les limites par classe des réseaux dans sa table de routage et simplement de router vers la correspondance de préfixe la plus longue qu'il peut trouver.
En résumé, pour prendre une décision de transfert se compose de trois ensembles de processus : les protocoles de routage, la table de routage et le processus réel qui prend une décision de transfert et commute les paquets. Ces trois ensembles de processus sont illustrés, avec leur relation, dans l'image suivante :
Trois ensembles de processus de routage
La correspondance de préfixe la plus longue est toujours la meilleure parmi les routes installées dans la table de routage, tandis que le protocole de routage avec la distance administrative la plus faible l’est toujours lorsque les routes sont installées dans la table de routage.
Révision | Date de publication | Commentaires |
---|---|---|
2.0 |
14-Nov-2022 |
Format et recertification mis à jour. |
1.0 |
14-Nov-2001 |
Première publication |