J'ai donc cette tâche où je dois configurer un réseau virtuel avec un protocole de routage OSPF. J'ai tout d'abord ignoré cette interface de bouclage que je devais configurer sur les routeurs car cela ne faisait aucune différence dans ce logiciel de virtualisation appelé Cisco Packet Tracer (je pensais). Ensuite, j'ai construit le réseau dans la vraie vie avec certains routeurs Cisco et cela n'a rien fait non plus. Avec ou sans cette boucle, le réseau a fonctionné (ping d'un hôte à l'autre). Maintenant ma question est: Pourquoi cette interface de bouclage est-elle nécessaire ou quelle fonction fait-elle? Dans l'image ci-dessous est le réseau que j'ai dû construire (si c'est une aide).
9
Tout d'abord, les interfaces de bouclage sont principalement utilisées lorsque nous voulons établir des contiguïtés entre 2 équipements (c'est-à-dire des routeurs) et pour être sûr que lorsqu'une liaison échoue, la contiguïté ne descendra pas car, les interfaces de bouclage sont des interfaces logiques, et vous pouvez les atteindre par différentes façons.
Une autre utilisation pour cela est d'annoncer certains réseaux. Les réseaux ne peuvent être annoncés que s'ils existaient dans la table de routage. Je suppose que, dans l'exemple ci-dessus, lorsque vous commentez toutes les interfaces de bouclage, une utilisation qui peut être faite pour cela, est d'annoncer certains réseaux et de voir comment OSPF peut fonctionner, mais, même si vous utilisez ou non des interfaces de bouclage, votre configuration doit bien fonctionner.
la source
En ajoutant à @Ron Maupin une excellente réponse, je dirais en outre que le choix (judicieux) de l'ID du routeur pour être l'interface de boucle sera plus "puissant" dans les scénarios de défaillance de la liaison. Comme d'autres l'ont mentionné, chaque routeur OSPF choisit un ID de routeur. Cet ID est choisi parmi TOUTES les interfaces disponibles sur un routeur donné SAUF configuration explicite contraire. Donc, en cas d'échec de liaison pour un routeur spécifique - si la logique de sélection de l'ID du routeur est toujours définie sur "l'adresse IP la plus élevée" et qu'aucune adresse de bouclage n'est également configurée dans le processus OSPF (ou qu'il n'y a pas d'adresse de bouclage dans du routeur) - alors cet échec de liaison déclenchera une nouvelle procédure de sélection d'ID de routeur "dans" le routeur et, peut-être plus important encore, obligera ce routeur à faire de la publicité son ID de routeur "nouvellement élu", ce qui signifie envoyer à nouveau des messages OSPF sur le réseau.
D'un autre côté , si l'ID du routeur a été défini "de manière déterministe" en le configurant comme l'adresse de bouclage (ou s'il y a une adresse de bouclage dans le processus OSPF), cela ne descendra jamais (sauf bien sûr, l'ensemble du routeur / Le processus OSPF descendra), puis si l'une des interfaces du routeur tombe en panne, l'ID du routeur ne sera pas affecté , par conséquent , aucun message OSPF multicast "nouveau routeur ID" ne sera envoyé sur le réseau.
Compte tenu de la topologie ci-dessus, dans le cas où le routeur E (ou plus précisément sa seule interface) tombe en panne, de toute façon, quand il remontera, il annoncera toujours son ID de routeur "encore une fois". Mais (!!) si un autre routeur ( A, B, C ou D ) aura une (ou plusieurs) de ses interfaces en panne, alors si l'ID du routeur n'a pas été "défini de manière déterministe" - la nouvelle publicité devra être envoyé sur le réseau, ce qui affectera sa bande passante globale. Et c'est le cas où l'adresse de bouclage pour l'ID de routeur dans OSPF est bénéfique.
la source