Cisco 300-410: Redistribution de routes et routage basé sur des politiques — Guide d'étude

By Laurynas Brazys · 16 August 2026 · #cisco #300-410 #certification #exam-prep #study-guide

Fait partie du Cisco CCNP Enterprise 300-410 ENARSI — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Cisco, ou passez des tests chronométrés sur ExamRoll.io.

Aperçu général

La redistribution de routes et le routage basé sur des politiques (PBR) sont des outils puissants pour intégrer des domaines de routage hétérogènes et influencer les décisions de transfert au-delà du paradigme par défaut basé sur la destination. Correctement mis en œuvre, ils permettent une connectivité inter-domaine évolutive, une orientation sélective du trafic, une propagation contrôlée de la route par défaut et une prévention robuste des boucles. Incorrectement mis en œuvre, ils créent des boucles de routage, une réinjection de routes, des chemins sous-optimaux et des trous noirs difficiles à diagnostiquer. Cette section explique la logique de conception, les mécanismes opérationnels et les modes de défaillance, et fournit des directives précises sur le filtrage, la traduction des métriques et le PBR avec suivi et vérification.

Principes fondamentaux de la redistribution et du filtrage

Frontières des domaines de routage, métriques initiales et distance administrative

• Les frontières de domaine existent partout où différents protocoles se croisent (OSPF/EIGRP/BGP/statique/connecté). À ces frontières, la redistribution synthétise l’accessibilité entre les domaines.
• Les métriques initiales (seed metrics) sont obligatoires lorsque le protocole cible ne peut pas déduire une métrique (par exemple, la métrique externe OSPF, la métrique composite EIGRP). Sans métriques initiales explicites ou par défaut, les routes redistribuées peuvent être inutilisables ou fortement dé-préférencées.
• La distance administrative (AD) arbitre entre les protocoles. Valeurs par défaut typiques : eBGP 20, statique 1, OSPF 110, EIGRP interne 90, EIGRP externe 170, iBGP 200. Les environnements avec des AD mixtes peuvent préférer des sources non intentionnelles (par exemple, une route externe OSPF redistribuée pourrait l’emporter sur un chemin iBGP si l’AD n’est pas prise en compte), provoquant un routage asymétrique ou des boucles.

Risques de la redistribution et contrôles bidirectionnels

• La redistribution bidirectionnelle (A↔B) peut réinjecter des routes apprises dans le domaine d’origine, créant des boucles persistantes ou un « feedback » de routes. Contrôlez-la avec :
  • Le marquage de routes (tagging) pour marquer l’origine et bloquer la ré-entrée.
  • Le filtrage directionnel pour n’admettre que les préfixes nécessaires.
  • L’agrégation aux frontières pour réduire la granularité du feedback.
  • Les politiques de route par défaut passive : n’injecter qu’une route par défaut ou uniquement des agrégats résumés le cas échéant.
  • L’ajustement de l’AD pour s’assurer que le domaine principal préfère les routes natives aux routes redistribuées.

Tags de route et modèles de prévention des boucles

• Utilisez les tags pris en charge par le protocole pour transporter des métadonnées d’origine :
  • Tags des LSA externes OSPF (32 bits).
  • Tags de route EIGRP via des route maps.
  • Tags de communauté/communauté étendue BGP.
• Modèle courant :
  • Appliquer un tag lors de la redistribution dans un domaine cible (par exemple, définir le tag 65001 si la route est apprise depuis l’AS EIGRP 65001).
  • Lors de la redistribution inverse, faire correspondre ce tag et le refuser pour éviter une nouvelle origination.
• Collisions de tags : définissez un plan de tagging pour éviter les sémantiques qui se chevauchent entre les frontières.

Route maps, listes de préfixes, listes de distribution et granularité du filtrage

• Listes de préfixes (prefix lists) : idéales pour une granularité de correspondance sur les préfixes et les masques (supportent les opérateurs ge/le). À utiliser pour les frontières BGP et IGP.
• Listes de distribution (distribute lists) : filtrage hérité basé sur des listes d’accès/préfixes, lié directement à un processus de routage ; efficace pour les IGP mais avec un contexte limité.
• Route maps : politiques polyvalentes prenant en charge la correspondance sur les listes de préfixes, les tags, les prochains sauts, les métriques, les communautés, et permettant de définir des actions (métrique, tag, type, communauté, prepend du chemin AS).
• Utilisez les route maps lorsque vous devez à la fois filtrer et transformer les attributs ; utilisez les listes de préfixes pour une sélection efficace et évolutive des préfixes/masques.

Positionnement du filtrage de routes : entrant ou sortant

• Filtrage entrant (inbound) :
  • Réduit la croissance des tables RIB/FIB et l’utilisation du CPU en empêchant l’installation de routes non désirées.
  • Préféré pour protéger un domaine contre des mises à jour excessives ou toxiques (par exemple, à la frontière BGP).
• Filtrage sortant (outbound) :
  • Empêche les fuites de routes et l’annonce excessive.
  • Applique la politique d’exportation et la normalisation des attributs.
• Pour BGP, validez toujours les route maps sortantes pour éviter les modifications d’attributs non intentionnelles (par exemple, un prepend accidentel du chemin AS qui augmente le nombre de sauts vu par les voisins).

Gestion de la route par défaut

• Les stratégies incluent :
  • Injecter une route par défaut uniquement là où c’est nécessaire (par exemple, default-information originate OSPF avec une route map).
  • Redistribuer une route statique 0.0.0.0/0 avec précaution ; s’assurer que l’AD et le type de métrique évitent que la route par défaut ne supplante des routes plus spécifiques.
  • Pour les doubles frontières (Internet et MPLS), séparez les routes par défaut par VRF et appliquez des politiques d’exportation/importation pour éviter les fuites croisées.

Traduction des métriques et gestion de la route par défaut

Traduction des métriques entre les routes OSPF, EIGRP, BGP et statiques

• OSPF :
  • Les routes externes transportent un coût et un type. Le type E1 accumule le coût interne vers l’ASBR ; E2 est constant par défaut. Choisissez E1 lorsque le coût du chemin interne doit influencer la sélection de la sortie.
  • Définissez explicitement les métriques externes pour influencer la sélection du chemin à travers plusieurs ASBR.
• EIGRP :
  • La métrique composite utilise la bande passante, le délai, la fiabilité, la charge et le MTU. Lors de la redistribution, définissez au moins la bande passante et le délai ; sinon, les routes peuvent se voir attribuer de mauvaises métriques et être dé-préférencées.
  • N’utilisez les coefficients de métrique K1–K5 que si c’est indispensable ; conservez les valeurs par défaut pour l’interopérabilité.
• BGP :
  • Ne traduit pas directement les métriques IGP. Contrôlez la préférence de chemin avec la local preference (intra-AS), le MED (indication inter-AS), le prepend du chemin AS et le weight (local à un routeur).
  • Lors de la redistribution d’un IGP dans BGP, utilisez des route maps pour définir les communautés, le MED et pour éviter une granularité excessive.
• Statique :
  • Injecter dans les IGP avec des métriques explicites. Méfiez-vous d’une route statique avec une AD de 1 qui supplante localement les routes dynamiques ; ajustez l’AD par préfixe si nécessaire (par exemple, ip route 0.0.0.0 0.0.0.0 x.y.z.w 5).

Exemples concis

• OSPF ← EIGRP avec tags et type E1 :

  route-map EIGRP-TO-OSPF permit 10
   match tag 0
   set tag 65010
   set metric-type type-1
   set metric 50
  router ospf 1
   redistribute eigrp 10 subnets route-map EIGRP-TO-OSPF

• EIGRP ← OSPF avec métrique composite :

  route-map OSPF-TO-EIGRP permit 10
   match tag 0
   set tag 65020
   set metric 100000 50 255 1 1500
  router eigrp 10
   redistribute ospf 1 route-map OSPF-TO-EIGRP

• Contrôle des attributs sortants BGP (éviter l’allongement accidentel du chemin des préfixes locaux) :

  route-map OUT permit 10
   match ip address prefix-list EXPORT
   set local-preference 150
  route-map OUT permit 20
  router bgp 200
   neighbor 1.1.1.1 remote-as 65001
   neighbor 1.1.1.1 route-map OUT out

Incluez toujours une séquence permit de terminaison ; sinon, vous pourriez ajouter involontairement des attributs (tels que des prepends de chemin AS) ou rejeter toutes les autres routes.

Route par défaut

• Route par défaut OSPF avec politique :

  route-map OSPF-DEF permit 10
   match interface GigabitEthernet0/0
  router ospf 1
   default-information originate route-map OSPF-DEF metric 10 metric-type 1

Conception et opérations du routage basé sur des politiques (PBR)

Comportement de base et correspondance

• Le PBR modifie la décision de transfert paquet par paquet sans modifier la table de routage. Il est appliqué en entrée (inbound) sur une interface ou au trafic généré localement.
• Critères de correspondance courants : préfixes source/destination, DSCP/precedence, protocole/port (via ACL étendue), accessibilité du prochain saut (next-hop).
• Actions set clés :
  • set ip next-hop x.x.x.x [y.y.y.y …]
  • set interface
  • set ip default next-hop x.x.x.x (utilisé uniquement lorsque la recherche de route échoue)
  • set dscp , set ip precedence

Repli et prise en compte de la disponibilité

• Utilisez des listes de prochains sauts (next-hop) pour un repli ordonné. Si le premier prochain saut n’est pas résolu, le routeur évalue les prochains sauts suivants.
• Utilisez set ip next-hop verify-availability avec le suivi d’objet (object tracking) pour ne préférer que les prochains sauts accessibles ; sinon, le PBR peut créer des trous noirs (black holes).

  ip sla 10
   icmp-echo 203.0.113.1 source-interface GigabitEthernet0/0
   frequency 5
  ip sla schedule 10 life forever start-time now
  track 10 rtr 10 reachability
  route-map PBR permit 10
   match ip address ACL_PBR
   set ip next-hop verify-availability 198.51.100.1 1 track 10
   set ip default next-hop 203.0.113.2
  interface GigabitEthernet0/1
   ip policy route-map PBR

• PBR local ou sur interface :
  • Le PBR sur interface (ip policy route-map) traite le trafic de transit entrant sur cette interface.
  • Le PBR local (ip local policy route-map) traite le trafic initié par le routeur lui-même (par exemple, les sessions de gestion, les pings). À utiliser avec précaution pour éviter d’interrompre les sessions du plan de contrôle.

Interactions avec le plan de contrôle et la sécurité

• Le PBR opère dans le chemin de données (data path) avant la recherche de routage normale ; il ne modifie pas la RIB. Vérifiez la résolution d’adjacence CEF pour set next-hop.
• Le Control-plane policing (CoPP) ne régule pas les données de transit affectées par le PBR, mais il peut réguler les mises à jour de routage utilisées par les domaines redistribués. Lors de la validation des débits CoPP pour éviter l’instabilité des routes (routing flaps), configurez initialement conform-action transmit et exceed-action transmit pendant le test de la classification ACL, puis resserrez les paramètres si nécessaire.
• Si l’uRPF est déployé sur les équipements récepteurs, les chemins asymétriques créés par le PBR peuvent provoquer des pertes de paquets (drops). Utilisez ip verify unicast source reachable-via any le cas échéant pour autoriser les chemins de retour asymétriques.

Stratégie de vérification, de restauration et de dépannage

Commandes de vérification

• État des routes et des politiques :
  • show ip route et show ip route vrf <name> pour vérifier l’accessibilité par VRF.
  • show ip cef exact-route <src> <dst> pour observer les décisions de transfert réelles.
  • show route-map et show access-lists pour valider l’ordre des séquences et les correspondances.
  • show policy-map control-plane pour vérifier les effets de CoPP en période d’instabilité.
• Spécifique au protocole :
  • OSPF : show ip ospf database external, show ip ospf border-routers, et vérifier les tags LSA ; pour l’activation de l’interface OSPFv3 pour IPv4, utiliser ospfv3 1 ipv4 area <id> sous l’interface.
  • EIGRP : show ip eigrp topology, show ip protocols pour les sources de redistribution.
  • BGP : show ip bgp neighbors x.x.x.x advertised-routes et received-routes ; confirmer les changements d’attributs (AS-path, MED, communities, local preference) et s’assurer que les politiques sortantes autorisent les routes non correspondantes lorsque cela est prévu.

Flux de travail de dépannage

• Identifier la catégorie du symptôme :
  • Route manquante : vérifier les filtres entrants et la politique de redistribution à la frontière d’entrée.
  • Chemin incorrect : inspecter l’AD, la traduction des métriques et les modifications des attributs sortants.
  • Trou noir (black hole) : vérifier la disponibilité du prochain saut (next-hop) PBR, l’état de l’IP SLA/track, et s’assurer que « set ip default next-hop » est utilisé uniquement pour les destinations qui ne sont pas dans la table de routage.
  • Instabilité/flaps : vérifier d’abord les tags de prévention des boucles, les fuites de filtres et les compteurs CoPP.
• Inspecter l’ordre des politiques :
  • L’ordre des séquences de la route-map est important. Une séquence deny en sortie BGP peut supprimer l’exportation, tandis qu’un « permit with no set » laisse passer les routes sans modification. Toujours inclure un permit 20 final (ou similaire) pour autoriser les routes non correspondantes lorsque c’est approprié.
• Valider la prévention des boucles :
  • Confirmer que les tags sont définis à l’exportation et filtrés à la réimportation. S’assurer que la sumarisation et le filtrage sont symétriques aux deux extrémités.
• Restauration (rollback) et sécurité des changements :
  • Utiliser des fenêtres de maintenance et un déploiement par étapes (appliquer d’abord en entrée pour protéger votre domaine, puis en sortie).
  • Conserver des archives de configuration et utiliser configuration replace pour revenir en arrière rapidement.
  • Lorsque c’est possible, appliquer les politiques dans un laboratoire VRF ou sur un sous-ensemble limité de voisins avant le déploiement global.

Exemples courts et ciblés

• Filtrage de sous-réseaux BGP en entrée pour bloquer les routes plus spécifiques :

  ip prefix-list PL-IN deny 172.16.0.0/16 le 23
  ip prefix-list PL-IN permit 0.0.0.0/0 le 32
  router bgp 100
   neighbor 192.0.2.2 remote-as 200
   neighbor 192.0.2.2 prefix-list PL-IN in

• Utilisation correcte des valeurs par défaut de la route-map pour éviter des contraintes excessives :

  route-map SETLP permit 10
   match ip address prefix-list P1
   set local-preference 99
  route-map SETLP permit 20

Mises en garde opérationnelles et modes de défaillance

• Des métriques mal initialisées entraînent soit la préférence de tout le trafic pour un seul ASBR, soit aucune préférence pour un chemin par ailleurs valide.
• Des AS-path prepends non intentionnels ou l’absence d’un permit final font que les voisins perçoivent les préfixes locaux comme étant plus éloignés, par exemple, un préfixe 192.168.130.0/24 d’origine locale étant vu à deux sauts d’AS au lieu d’un seul.
• Le PBR sans track/verify-availability peut créer des trous noirs (black holes) silencieux dans le plan de données lors d’une défaillance du prochain saut.
• La redistribution par défaut sans politique peut supplanter des routes spécifiques en raison des différences d’AD, provoquant un routage sous-optimal ou une perte d’accessibilité.

Scénario de problème pratique

NorthPeak Media fusionne un WAN basé sur OSPF avec un data center basé sur EIGRP et a besoin d’une sortie Internet sélective via deux FAI. Exigences : prévenir les boucles de redistribution, préférer le FAI-A pour le trafic de production avec basculement automatique vers le FAI-B, et éviter d’impacter la stabilité du plan de contrôle.

Approche

1. Définir les frontières de redistribution et les tags

• Rationale : Une redistribution bidirectionnelle est requise entre OSPF (WAN) et EIGRP (DC). Les tags identifient l’origine de la route et empêchent sa réinjection.
• Actions :
  • Sur l’ASBR EIGRP-vers-OSPF, redistribuer eigrp avec set tag 65010, metric-type E1, et un coût de 50.
  • Sur l’ASBR OSPF-vers-EIGRP, redistribuer ospf avec set tag 65020 et une métrique composite EIGRP ; refuser toute route avec le tag 65010 revenant d’OSPF, et vice versa.

2. Normaliser les métriques et l’AD

• Rationale : S’assurer que les routes internes OSPF priment sur les routes externes OSPF et que les routes internes EIGRP priment sur les routes externes EIGRP ; éviter que l’iBGP ne masque involontairement les IGP.
• Actions :
  • Utiliser E1 pour les routes externes OSPF afin que le coût interne vers l’ASBR influence la sélection de la sortie.
  • Si nécessaire, augmenter l’AD des routes statiques redistribuées pour éviter qu’elles ne priment sur des routes IGP spécifiques.

3. Contrôler la propagation de la route par défaut

• Rationale : Seul le routeur en périphérie du WAN doit injecter la route 0.0.0.0/0 dans OSPF ; le DC ne doit pas propager une route par défaut dans OSPF ou EIGRP involontairement.
• Actions :
  • Sur l’ABR du WAN, utiliser default-information originate avec une route-map qui correspond à une interface FAI active (up/up) ; metric-type E1 et un coût modéré.
  • Ne pas redistribuer les routes par défaut statiques depuis le DC ; refuser explicitement 0.0.0.0/0 dans les clauses de la route-map pour la redistribution.

4. Appliquer le PBR pour une sortie sélective avec suivi IP SLA

• Rationale : Diriger le trafic de production vers le FAI-A avec un basculement rapide et automatique vers le FAI-B ; ne pas modifier la table de routage.
• Actions :
  • Créer une ACL correspondant aux sous-réseaux de production.
  • Configurer des tests ICMP ip sla vers le prochain saut du FAI-A et des objets track.
  • Sur les interfaces d’entrée du campus, appliquer ip policy route-map PBR-PROD :
    • set ip next-hop verify-availability <ISP-A-NH> 1 track <obj>
    • set ip default next-hop <ISP-B-NH> pour les destinations non présentes dans la table de routage.
  • Laisser le trafic non lié à la production suivre les chemins IGP/BGP normaux.

5. Protéger le plan de contrôle et le trafic de gestion

• Rationale : S’assurer que les sessions initiées par le routeur et les adjacences de routage ne sont pas perturbées par le PBR ou le CoPP.
• Actions :
  • Utiliser ip local policy route-map uniquement pour des adresses sources de gestion spécifiques si nécessaire ; sinon, éviter d’appliquer le PBR local globalement.
  • Lors de l’activation de la politique CoPP, définir initialement conform-action transmit et exceed-action transmit pour les classes BGP/OSPF afin de valider la correspondance des ACL et les débits sans provoquer de flaps ; ensuite, appliquer le contrôle (policing) souhaité.

6. Placement et validation des filtres

• Rationale : Protéger le domaine contre un nombre excessif de préfixes et éviter les fuites.
• Actions :
  • Appliquer des prefix-lists en entrée sur les voisins BGP pour bloquer les routes plus spécifiques non désirées et les bogons.
  • Utiliser des route-maps en sortie pour définir la local preference pour les préfixes sélectionnés et assurer un permit final.
  • Valider avec show ip route vrf <name> (par VRF), show ip bgp neighbors advertised-routes, et les compteurs de correspondance (hit counts) de show route-map.

7. Tester, surveiller et restaurer

• Rationale : Un déploiement contrôlé réduit les risques.
• Actions :
  • Déployer sur un sous-ensemble d’interfaces/voisins, surveiller l’état de l’IP SLA, et vérifier les compteurs PBR et les adjacences CEF.
  • Archiver la configuration de base et utiliser configuration replace pour une restauration rapide si des anomalies apparaissent.
  • Confirmer l’absence de boucles en vérifiant les tags de route de bout en bout et en s’assurant de l’absence de ré-origination avec show ip ospf database external et show ip eigrp topology.

← Politiques · Tous les domaines · MPLS →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →