Redistribution entre protocoles par classe et sans classe : EIGRP ou OSPF dans RIP ou IGRP

Options de téléchargement

  • PDF     (130.9 KB)
    Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
  • ePub     (99.5 KB)
    Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
  • Mobi (Kindle)     (155.5 KB)
    Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils
Mis à jour:11 septembre 2018
ID du document:13721

Langage exempt de préjugés

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.

À propos de cette traduction

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.

Introduction

Ce document décrit deux problèmes courants liés à redistribution de routes entre RIP et OSPF ou IGRP et EIGRP. RIP et IGRP n'annonceront pas de routes hors de l'interface si celles-ci ne sont pas sur le même réseau principal, mais sont dotées d'un masque différent de celui de cette interface en particulier. Pour plus d'informations sur les mises à jour RIP et IGRP, référez-vous au document « Behavior of RIP and IGRP When Sending and Receiving Updates ».

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Components Used

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Les informations présentées dans ce document ont été créées à partir de périphériques dans un environnement de laboratoire spécifique. All of the devices used in this document started with a cleared (default) configuration. Si vous travaillez dans un réseau opérationnel, assurez-vous de bien comprendre l'impact potentiel de toute commande avant de l'utiliser.

Conventions

Pour plus d'informations sur les conventions des documents, référez-vous aux Conventions utilisées pour les conseils techniques de Cisco.

OSPF possède un masque plus long que RIP

Dans le diagramme de réseau pour ce problème, le routeur GW-2 se redistribue entre RIP et OSPF. Le domaine OSPF a un masque différent (plus long dans ce cas) que le domaine RIP, et il se trouve sur le même réseau principal. Par conséquent, le protocole RIP n’annonce pas les routes apprises du protocole OSPF et redistribuées dans le protocole RIP.

52a.gif

Solution

Le masque de sous-réseau du domaine OSPF est difficile à modifier. Ajoutez donc une route statique dans le routeur GW-2 qui pointe vers le domaine OSPF avec un masque de 255.255.255.0, mais avec un saut suivant null0. Ensuite, redistribuez les routes statiques dans RIP. Voici la configuration pour accomplir cette tâche :

ip route 128.103.35.0 255.255.255.0 null0
 router rip 
 redistribute static
 default metric 1

Cela permet d’annoncer 128.103.35.0 via RIP via l’interface E2/0 du routeur GW-2. Cependant, le routeur GW-2 a encore des routes plus spécifiques apprises à partir du protocole OSPF dans sa table de routage, de sorte que les meilleures décisions de routage sont prises.

Le protocole RIP possède un masque plus long que le protocole OSPF

Dans le diagramme de réseau pour ce problème, le domaine RIP a un masque de 255.255.255.248 et le domaine OSPF a un masque de 255.255.255.240. Le protocole RIP n’annonce pas les routes apprises du protocole OSPF et redistribuées dans le protocole RIP.

52b.gif

Solution

Nous pouvons ajouter une route statique dans le routeur GW-2 qui pointe vers le domaine OSPF avec le masque 255.255.255.248. Cependant, comme il s’agit d’un masque plus spécifique que le masque OSPF d’origine, le prochain saut doit être un saut ou une interface(s) suivante(s) réel(s). En outre, nous avons besoin de plusieurs routes statiques afin de couvrir toutes les adresses du domaine OSPF. Ainsi, les routes statiques sont redistribuées dans RIP.

Dans le code ci-dessous, les deux premières routes statiques couvrent la plage 128.103.35.32 255.255.255.240 dans le domaine OSPF. Les deux deuxième routes statiques couvrent la plage 128.103.35.16 255.255.255.240 dans le domaine OSPF. Et les quatre dernières routes statiques couvrent la plage 128.130.35.64 255.255.255.240, connue via deux interfaces dans le domaine OSPF. 

ip route 128.103.35.32 255.255.255.248 E0/0 
ip route 128.103.35.40 255.255.255.248 E0/0

ip route 128.103.35.16 255.255.255.248 E1/0
ip route 128.103.35.24 255.255.255.248 E1/0

ip route 128.103.35.64 255.255.255.248 128.103.35.34
ip route 128.103.35.64 255.255.255.248 128.103.35.18
ip route 128.103.35.72 255.255.255.248 128.103.35.34
ip route 128.103.35.72 255.255.255.248 128.103.35.18
router rip
redistribute static
default metric 1

Conclusion

Les solutions présentées dans ce document fonctionnent également lorsque vous utilisez le protocole EIGRP au lieu du protocole OSPF et le protocole IGRP au lieu du protocole RIP. Ce problème ne doit pas se produire si les masques des deux protocoles sont identiques ou si tous les protocoles que vous utilisez prennent en charge le masque de sous-réseau de longueur variable (VLSM). Ce correctif est considéré uniquement comme un correctif destiné à couvrir les limites RIP et IGRP (VLSM). Pour plus d'informations sur les limitations de VLSM RIP et IGRP, référez-vous à Pourquoi RIP et IGRP ne prennent pas en charge VLSM?.

Informations connexes

Ce document vous est-il utile?

FeedbackCommentaires

Contacter Cisco