Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Distribution de routes VPN

Cette rubrique décrit la configuration d’un routeur pour gérer les informations de routage dans BGP, les signaux MPLS et les stratégies.

Activation de l’échange d’informations de routage pour les VPN

Pour que les VPN de couche 2, les VPN de couche 3, les instances de routage de routeur virtuel, les VPLS, les EVPN et les circuits de couche 2 fonctionnent correctement, les routeurs PE et P du fournisseur de services doivent pouvoir échanger des informations de routage. Pour que cela se produise, vous devez configurer un IGP (tel qu’OSPF ou IS-IS) ou des routes statiques sur ces routeurs. Vous configurez l’IGP sur l’instance principale du processus de protocole de routage au niveau de la [edit protocols] hiérarchie, et non au sein de l’instance de routage utilisée pour le VPN, c’est-à-dire pas au niveau de la [edit routing-instances] hiérarchie.

Lorsque vous configurez le routeur PE, ne configurez aucune synthèse des adresses de bouclage du routeur PE au niveau de la limite de la zone. L’adresse de bouclage de chaque routeur PE doit apparaître sous la forme d’une route distincte.

Configuration des sessions IBGP entre les routeurs PE dans les VPN

Vous devez configurer une session IBGP entre les routeurs PE pour permettre aux routeurs PE d’échanger des informations sur les routes d’origine et de destination du VPN. Les routeurs PE s’appuient sur ces informations pour déterminer les étiquettes à utiliser pour le trafic destiné aux sites distants.

Configurez une session IBGP pour le VPN comme suit :

L’adresse IP indiquée dans l’instruction local-address est l’adresse de l’interface de bouclage sur le routeur PE local. La session IBGP du VPN passe par l’adresse de bouclage. (Vous devez également configurer l’interface de bouclage au niveau de la [edit interfaces] hiérarchie.)

L’adresse IP indiquée dans l’instruction neighbor est l’adresse de bouclage du routeur PE voisin. Si vous utilisez la signalisation RSVP, cette adresse IP est la même que celle que vous spécifiez dans l’instruction to au niveau de la [edit mpls label-switched-path lsp-path-name] hiérarchie lorsque vous configurez le LSP MPLS.

L’instruction family vous permet de configurer la session IBGP pour les VPN de couche 2, VPLS, EVPN ou pour les VPN de couche 3.

  • Pour configurer une session IBGP pour les VPN et VPLS de couche 2, incluez l’instruction suivante signaling au niveau de la [edit protocols bgp group group-name family l2vpn] hiérarchie :

  • Pour configurer une session IBGP pour les EVPN, incluez l’instruction suivante signaling au niveau de la [edit protocols bgp group group-name family evpn] hiérarchie :

  • Pour configurer une session IBGP IPv4 pour les VPN de couche 3, configurez l’instruction unicast au niveau de la [edit protocols bgp group group-name family inet-vpn] hiérarchie :

  • Pour configurer une session IBGP IPv6 pour les VPN de couche 3, configurez l’instruction unicast au niveau de la [edit protocols bgp group group-name family inet6-vpn] hiérarchie :

Note:

Vous pouvez configurer les deux family inet et ou family inet-vpn les deux family inet6 et family inet6-vpn au sein du même groupe homologue. Cela vous permet d’activer la prise en charge des routes VPN IPv4 et IPv4 ou des routes VPN IPv6 et IPv6 au sein d’un même groupe de pairs.

Configuration des étiquettes d’agrégation pour les VPN

Les étiquettes agrégées pour VPN permettent à une plate-forme de routage Juniper Networks d’agréger un ensemble d’étiquettes entrantes (étiquettes reçues d’un routeur pair) en une seule étiquette de transfert sélectionnée dans l’ensemble des étiquettes entrantes. L’étiquette de transfert unique correspond à un seul saut suivant pour ce jeu d’étiquettes. L’agrégation d’étiquettes réduit le nombre d’étiquettes VPN que le routeur doit examiner.

Pour qu’un ensemble d’étiquettes partage une étiquette de transfert agrégée, elles doivent appartenir à la même classe d’équivalence de transfert (FEC). Les paquets étiquetés doivent avoir la même interface de sortie de destination.

L’inclusion de l’instruction community community-name avec l’instruction aggregate-label vous permet de spécifier des préfixes avec une communauté d’origine commune. Définis par stratégie sur le PE homologue, ces préfixes représentent une FEC sur le routeur PE pair.

PRUDENCE:

Si la communauté cible est définie par erreur au lieu de la communauté d’origine, des problèmes de transfert au niveau de l’EP de sortie peuvent en résulter. Tous les préfixes du PE homologue apparaîtront dans la même FEC, ce qui se traduira par une étiquette interne unique pour tous les routeurs CE derrière un PE donné dans le même VPN.

Pour utiliser les réflecteurs de route dans les réseaux VPN de couche 3, le routeur M10i de Juniper Networks agrège un ensemble d’étiquettes entrantes uniquement lorsque les routes :

  • Proviennent du même routeur homologue

  • Avoir le même site d’origine communauté

  • Avoir le même saut suivant

L’exigence de saut suivant est importante, car les réflecteurs de route transfèrent les routes provenant de différents homologues BGP vers un autre pair BGP sans modifier le saut suivant de ces routes.

Pour configurer les étiquettes d’agrégation pour les VPN, incluez l’instruction aggregate-label :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous au résumé de cette instruction.

Pour plus d’informations sur la configuration d’une communauté, reportez-vous à la section Présentation des communautés BGP, des communautés étendues et des grandes communautés en tant que conditions de correspondance de la stratégie de routage.

Configuration d’un protocole de signalisation et de LSP pour les VPN

Pour que les VPN fonctionnent, vous devez activer un protocole de signalisation, soit le LDP ou le RSVP sur les routeurs PE (Provider Edge) et sur les routeurs du fournisseur (P). Vous devez également configurer des chemins de commutation d’étiquettes (LSP) entre les routeurs d’entrée et de sortie. Dans une configuration VPN classique, vous devez configurer les LSP de chaque routeur PE vers tous les autres routeurs PE participant au VPN dans un maillage complet.

Note:

Comme pour toute configuration impliquant MPLS, vous ne pouvez pas configurer les interfaces orientées cœur sur les routeurs PE sur des PIC Fast Ethernet denses.

Pour activer un protocole de signalisation, effectuez les étapes décrites dans l’une des sections suivantes :

Utilisation de LDP pour la signalisation VPN

Pour utiliser LDP pour la signalisation VPN, effectuez les opérations suivantes sur les routeurs PE et fournisseur (P) :

  1. Configurez LDP sur les interfaces du cœur du réseau du fournisseur de services en incluant l’instruction ldp au niveau de la [edit protocols] hiérarchie.

    Vous devez configurer LDP uniquement sur les interfaces entre les routeurs PE ou entre les routeurs PE et P. Vous pouvez les considérer comme des interfaces « orientées vers le cœur ». Vous n’avez pas besoin de configurer LDP sur l’interface entre les routeurs PE et CE (Customer Edge).

  2. Configurez la famille d’adresses MPLS sur les interfaces sur lesquelles vous avez activé LDP (les interfaces que vous avez configurées à l’étape 1) en incluant l’instruction family mpls au niveau de la [edit interfaces type-fpc/pic/port unit logical-unit-number] hiérarchie.

  3. Configurez OSPF ou IS-IS sur chaque routeur PE et P.

    Vous configurez ces protocoles au niveau de l’instance principale du protocole de routage, et non à l’intérieur de l’instance de routage utilisée pour le VPN.

    • Pour configurer OSPF, incluez l’instruction ospf au niveau de la [edit protocols] hiérarchie. Au minimum, vous devez configurer une zone dorsale sur au moins une des interfaces du routeur.

    • Pour configurer IS-IS, incluez l’instruction isis au niveau hiérarchique [edit protocols] et configurez l’interface de bouclage et la famille ISO de l’Organisation internationale de normalisation (ISO) au niveau hiérarchique [edit interfaces] . Au minimum, vous devez activer IS-IS sur le routeur, configurer un titre d’entité réseau (NET) sur l’une des interfaces du routeur (de préférence l’interface de bouclage, lo0) et configurer la famille ISO sur toutes les interfaces sur lesquelles vous souhaitez qu’IS-IS s’exécute. Lorsque vous activez IS-IS, les niveaux 1 et 2 sont activés par défaut. Voici la configuration minimale d’IS-IS. Dans l’instruction address , address se trouve le NET.

Utilisation de RSVP pour la signalisation VPN

Pour utiliser RSVP pour la signalisation VPN, effectuez les opérations suivantes :

  1. Sur chaque routeur PE, configurez l’ingénierie de trafic.

    Pour ce faire, vous devez configurer un protocole IGP (Interior Gateway Protocol) qui prend en charge l’ingénierie de trafic (IS-IS ou OSPF) et activer la prise en charge de l’ingénierie de trafic pour ce protocole.

    Pour activer la prise en charge de l’ingénierie de trafic OSPF, incluez l’instruction suivante traffic-engineering au niveau de la [edit protocols ospf] hiérarchie :

    Pour les réseaux IS-IS, la prise en charge de l’ingénierie de trafic est activée par défaut.

  2. Sur chaque routeur PE et P, activez RSVP sur les interfaces qui font partie du chemin de commutation d’étiquettes (LSP).

    Sur le routeur PE, ces interfaces sont les points d’entrée et de sortie du LSP. Sur le routeur P, ces interfaces connectent le LSP entre les routeurs PE. N’activez pas RSVP sur l’interface entre les routeurs PE et CE, car cette interface ne fait pas partie du LSP.

    Pour configurer RSVP sur les routeurs PE et P, incluez l’instruction interface au niveau de la [edit protocols rsvp] hiérarchie. Incluez une interface instruction pour chaque interface sur laquelle vous activez RSVP.

  3. Sur chaque routeur PE, configurez un LSP MPLS sur le routeur PE qui est le point de sortie du LSP.

    Pour ce faire, incluez les interface instructions et label-switched-path au niveau de la [edit protocols mpls] hiérarchie :

    Dans l’instruction to , spécifiez l’adresse du point de sortie du LSP, qui est une adresse sur le routeur PE distant.

    Dans l’instruction interface , spécifiez le nom de l’interface (les parties physique et logique). Incluez une instruction pour l’interface interface associée au LSP.

    Lorsque vous configurez la partie logique de la même interface au niveau de la [edit interfaces] hiérarchie, vous devez également configurer les family inet instructions et family mpls :

  4. Sur tous les routeurs P qui participent au LSP, activez MPLS en incluant l’instruction interface au niveau de la [edit mpls] hiérarchie.

    Incluez une interface instruction pour chaque connexion au LSP.

  5. Activez MPLS sur l’interface entre les routeurs PE et CE en incluant l’instruction interface au niveau de la [edit mpls] hiérarchie.

    Cela permet au routeur PE d’attribuer une étiquette MPLS au trafic entrant dans le LSP ou de supprimer l’étiquette du trafic sortant du LSP.

    Pour plus d’informations sur la configuration de MPLS, reportez-vous à la section Configuration du routeur entrant pour les LSP à signalisation MPLS.

Voir aussi

Configuration des stratégies pour la table VRF sur les routeurs PE dans les VPN

Sur chaque routeur PE, vous devez définir des stratégies qui définissent la manière dont les routes sont importées et exportées à partir de la table VRF du routeur. Dans ces stratégies, vous devez définir la cible de routage et, si vous le souhaitez, définir l’origine de l’itinéraire.

Pour configurer la stratégie pour les tables VRF, procédez comme suit dans les sections suivantes :

Configuration de la cible de routage

Dans le cadre de la configuration de stratégie de la table de routage VPN, vous devez définir une cible de routage, qui définit le VPN dont la route fait partie. Lorsque vous configurez différents types de services VPN (VPN de couche 2, VPN de couche 3, EVPN ou VPLS) sur le même routeur PE, veillez à attribuer des valeurs de route cible uniques afin d’éviter d’ajouter des informations de route et de signalisation à la mauvaise table de routage VPN.

Pour configurer la cible de route, incluez l’option target dans l’instruction community :

Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :

  • [edit policy-options]

  • [edit logical-systems logical-system-name policy-options]

name est le nom de la communauté.

community-id est l’identifiant de la communauté. Spécifiez-le dans l’un des formats suivants :

  • as-number:number, où as-number est un nombre AS (une valeur de 2 octets) et number est une valeur de communauté de 4 octets. Le nombre AS peut être compris entre 1 et 65 535. Nous vous recommandons d’utiliser un numéro AS non privé attribué par l’IANA, de préférence le numéro AS du FAI ou du client. La valeur de la communauté peut être un nombre compris entre 0 et 4 294 967 295 (232 – 1).

  • ip-address:number, où ip-address est une adresse IPv4 (une valeur de 4 octets) et number est une valeur de communauté de 2 octets. L’adresse IP peut être n’importe quelle adresse unicast unique au monde. Nous vous recommandons d’utiliser l’adresse que vous configurez dans l’instruction, qui est une adresse non privée dans la router-id plage de préfixes qui vous a été attribuée. La valeur de la communauté peut être un nombre compris entre 1 et 65 535.

Configuration de l’origine de l’itinéraire

Dans les stratégies d’importation et d’exportation de la table VRF du routeur PE, vous pouvez éventuellement affecter l’origine de route (également appelée site d’origine) aux routes VRF d’un routeur PE à l’aide d’une stratégie d’exportation VRF appliquée aux mises à jour de route IPv4 du VPN BGP BGP EXTERNE MULTIPROTOCOLE (MP-EBGP) envoyées à d’autres routeurs PE.

La mise en correspondance sur l’attribut d’origine de route affecté dans la stratégie d’importation VRF d’un PE récepteur permet de s’assurer que les routes VPN-IPv4 apprises via les mises à jour MP-EBGP d’un PE ne sont pas réimportées vers le même site VPN à partir d’un autre PE connecté au même site.

Pour configurer l’origine d’un itinéraire, procédez comme suit :

  1. Incluez l’énoncé community avec l’option origin :

    Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :

    • [edit policy-options]

    • [edit logical-systems logical-system-name policy-options]

    name est le nom de la communauté.

    community-id est l’identifiant de la communauté. Spécifiez-le dans l’un des formats suivants :

    • as-number:number, où as-number est un nombre AS (une valeur de 2 octets) et number est une valeur de communauté de 4 octets. Le nombre AS peut être compris entre 1 et 65 535. Nous vous recommandons d’utiliser un numéro AS non privé attribué par l’IANA, de préférence le numéro AS du FAI ou du client. La valeur de la communauté peut être un nombre compris entre 0 et 4 294 967 295 (232 – 1).

    • ip-address:number, où ip-address est une adresse IPv4 (une valeur de 4 octets) et number est une valeur de communauté de 2 octets. L’adresse IP peut être n’importe quelle adresse unicast unique au monde. Nous vous recommandons d’utiliser l’adresse que vous configurez dans l’instruction, qui est une adresse non privée dans la router-id plage de préfixes qui vous a été attribuée. La valeur de la communauté peut être un nombre compris entre 1 et 65 535.

  2. Incluez la communauté dans la stratégie d’importation de la table VRF du routeur PE en configurant l’instruction community avec l’identificateur community-id défini à l’étape 1 au niveau de la [edit policy-options policy-statement import-policy-name term import-term-name from] hiérarchie. Reportez-vous à la section Configuration d’une stratégie d’importation pour la table VRF du routeur PE.

    Si la clause de from la stratégie ne spécifie pas de condition de communauté, l’instruction vrf-import dans laquelle la stratégie est appliquée ne peut pas être validée. L’opération de validation Junos OS ne passe pas le contrôle de validation.

  3. Incluez la communauté dans la stratégie d’exportation de la table VRF du routeur PE en configurant l’instruction community avec l’identificateur community-id défini à l’étape 1 au niveau de la [edit policy-options policy-statement export-policy-name term export-term-name then] hiérarchie. Reportez-vous à la section Configuration d’une stratégie d’exportation pour la table VRF du routeur PE.

Reportez-vous à la section Configuration de l’origine de route pour les VPN pour obtenir un exemple de configuration.

Configuration d’une stratégie d’importation pour la table VRF du routeur PE

Chaque VPN peut disposer d’une stratégie qui définit la manière dont les routes sont importées dans la table VRF du routeur PE. Une stratégie d’importation est appliquée aux routes reçues d’autres routeurs PE dans le VPN. Une stratégie doit évaluer toutes les routes reçues sur la session IBGP avec le routeur PE pair. Si les routes correspondent aux conditions, la route est installée dans la table VRF du routing-instance-name.inet.0 routeur PE. Une stratégie d’importation doit contenir une deuxième clause qui rejette toutes les autres routes.

À moins qu’une stratégie d’importation ne contienne qu’une then reject déclaration, elle doit inclure une référence à une communauté. Dans le cas contraire, lorsque vous tentez de valider la configuration, celle-ci échoue. Vous pouvez configurer plusieurs stratégies d’importation.

Une stratégie d’importation détermine ce qu’il faut importer dans une table VRF spécifiée en fonction des routes VPN apprises des routeurs PE distants via IBGP. La session IBGP est configurée au niveau de la [edit protocols bgp] hiérarchie. Si vous configurez également une stratégie d’importation au niveau hiérarchique [edit protocols bgp] , les stratégies d’importation au [edit policy-options] niveau hiérarchique et au niveau hiérarchique [edit protocols bgp] sont combinées par le biais d’une opération AND logique. Cela vous permet de filtrer le trafic en tant que groupe.

Pour configurer une stratégie d’importation pour la table VRF du routeur PE, procédez comme suit :

  1. Pour définir une stratégie d’importation, incluez l’instruction policy-statement . Pour tous les routeurs PE, une stratégie d’importation doit toujours inclure l’instruction policy-statement , au minimum :

    Vous pouvez inclure l’instruction policy-statement aux niveaux hiérarchiques suivants :

    • [edit policy-options]

    • [edit logical-systems logical-system-name policy-options]

    La import-policy-name stratégie évalue toutes les routes reçues via la session IBGP avec l’autre routeur PE. Si les routes correspondent aux conditions de l’instruction from , la route est installée dans la table VRF .inet.0 du routing-instance-namerouteur PE. Le deuxième terme de la politique rejette toutes les autres voies.

    Pour plus d’informations sur la création de stratégies, reportez-vous au Guide de l’utilisateur des stratégies de routage, des filtres de pare-feu et des mécanismes de contrôle du trafic.

  2. Vous pouvez éventuellement utiliser une expression régulière pour définir un ensemble de communautés à utiliser pour la stratégie d’importation VRF.

    Par exemple, vous pouvez configurer les éléments suivants à l’aide de l’instruction community au niveau de la [edit policy-options policy-statement policy-statement-name] hiérarchie :

    Notez que vous ne pouvez pas configurer une expression régulière dans le cadre d’une communauté étendue de cible de routage. Pour plus d’informations sur la configuration des expressions régulières pour les communautés, consultez Comment les communautés BGP et les communautés étendues sont évaluées dans les conditions de correspondance de la stratégie de routage.

  3. Pour configurer une stratégie d’importation, incluez l’instruction vrf-import suivante :

    Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :

    • [edit routing-instances routing-instance-name]

    • [edit logical-systems logical-system-name routing-instances routing-instance-name]

Configuration d’une stratégie d’exportation pour la table VRF du routeur PE

Chaque VPN peut disposer d’une stratégie qui définit la manière dont les routes sont exportées à partir de la table VRF du routeur PE. Une stratégie d’exportation est appliquée aux routes envoyées à d’autres routeurs PE dans le VPN. Une stratégie d’exportation doit évaluer toutes les routes reçues via la session de protocole de routage avec le routeur CE. (Cette session peut utiliser les protocoles de routage BGP, OSPF ou RIP (Routing Information Protocol), ou des routes statiques.) Si les routes correspondent aux conditions, la cible de communauté spécifiée (qui est la cible de route) leur est ajoutée et elles sont exportées vers les routeurs PE distants. Une politique d’exportation doit contenir une deuxième clause qui rejette toutes les autres voies.

Les stratégies d’exportation définies dans l’instance de routage VPN sont les seules stratégies d’exportation qui s’appliquent à la table VRF. Toute stratégie d’exportation que vous définissez sur la session IBGP entre les routeurs PE n’a aucun effet sur la table VRF. Vous pouvez configurer plusieurs stratégies d’exportation.

Pour configurer une stratégie d’exportation pour la table VRF du routeur PE, procédez comme suit :

  1. Pour tous les routeurs PE, une stratégie d’exportation doit distribuer les routes VPN vers et depuis les routeurs CE connectés en fonction du type de protocole de routage que vous configurez entre les routeurs CE et PE au sein de l’instance de routage.

    Pour définir une stratégie d’exportation, incluez l’instruction policy-statement . Une politique d’exportation doit toujours inclure l’énoncé policy-statement suivant :

    Note:

    La configuration de l’instruction community add est requise pour les stratégies d’exportation VRF VPN de couche 2. Si vous remplacez l’instruction community add par l’instruction community set , le routeur à la sortie de la liaison VPN de couche 2 peut abandonner la connexion.
    Note:

    Lors de la configuration de VPN multicast draft-rosen fonctionnant en mode spécifique à la source et de l’utilisation de l’instruction vrf-export pour spécifier la stratégie d’exportation, la stratégie doit avoir un terme qui accepte les routes de la table de routage vrf-name.mdt.0. Ce terme garantit une découverte automatique PE correcte à l’aide de la famille d’adresses inet-mdt .

    Lors de la configuration de VPN multicast draft-rosen fonctionnant en mode spécifique à la source et à l’aide de l’instruction vrf-target , la stratégie d’exportation VRF est générée automatiquement et accepte automatiquement les routes de la table de routage vrf-name.mdt.0.

    Vous pouvez inclure l’instruction policy-statement aux niveaux hiérarchiques suivants :

    • [edit policy-options]

    • [edit logical-systems logical-system-name policy-options]

    La export-policy-name stratégie évalue toutes les routes reçues via la session de protocole de routage avec le routeur CE. (Cette session peut utiliser les protocoles de routage BGP, OSPF ou RIP, ou des routes statiques.) Si les routes correspondent aux conditions de l’instruction from , la cible de communauté spécifiée dans l’instruction then community add leur est ajoutée et elles sont exportées vers les routeurs PE distants. Le deuxième terme de la politique rejette toutes les autres voies.

    Pour plus d’informations sur la création de stratégies, reportez-vous au Guide de l’utilisateur des stratégies de routage, des filtres de pare-feu et des mécanismes de contrôle du trafic.

  2. Pour appliquer la stratégie, incluez l’énoncé vrf-export suivant :

    Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :

    • [edit routing-instances routing-instance-name]

    • [edit logical-systems logical-system-name routing-instances routing-instance-name]

Application des stratégies d’exportation VRF et BGP

Lorsque vous appliquez une stratégie d’exportation VRF comme décrit dans Configuration d’une stratégie d’exportation pour la table VRF du routeur PE, les routes des instances de routage VPN sont annoncées aux autres routeurs PE en fonction de cette stratégie, tandis que la stratégie d’exportation BGP est ignorée.

Si vous incluez l’instruction vpn-apply-export dans la configuration BGP, les stratégies d’exportation VRF et d’exportation de groupe BGP ou de voisinage sont appliquées (VRF d’abord, puis BGP) avant que les routes ne soient annoncées dans les tables de routage VPN vers d’autres routeurs PE.

Note:

Lorsqu’un équipement PE agit également en tant que réflecteur de route (RR) ou routeur de limite de système autonome (ASBR) dans un VPN Carrier-over-Carrier ou inter-AS, la manipulation du saut suivant dans la stratégie vrf-export est ignorée.

Lorsque vous incluez l’instruction vpn-apply-export , tenez compte des points suivants :

  • Les routes importées dans la table de routage bgp.l3vpn.0 conservent les attributs des routes d’origine (par exemple, une route OSPF reste une route OSPF même lorsqu’elle est stockée dans la table de routage bgp.l3vpn.0). Vous devez en tenir compte lorsque vous configurez une stratégie d’exportation pour les connexions entre un routeur IBGP PE et un routeur PE, un réflecteur de route et un routeur PE, ou des routeurs homologues ASBR (AS boundary router).

  • Par défaut, toutes les routes de la table de routage bgp.l3vpn.0 sont exportées vers les homologues IBGP. Si la dernière instruction de la stratégie d’exportation est « Tout refuser » et si la stratégie d’exportation ne correspond pas spécifiquement aux routes de la table de routage bgp.l3vpn.0, aucune route n’est exportée.

Pour appliquer les stratégies d’exportation VRF et BGP aux routes VPN, incluez l’instruction vpn-apply-export suivante :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de cette instruction.

Configuration d’une cible VRF

L’inclusion de l’instruction vrf-target dans la configuration d’une communauté cible VRF entraîne la génération par défaut de stratégies d’importation et d’exportation VRF qui acceptent et balisent les routes avec la communauté cible spécifiée. Vous pouvez toujours créer des stratégies plus complexes en configurant explicitement des stratégies d’importation et d’exportation VRF. Ces stratégies remplacent les stratégies par défaut générées lorsque vous configurez l’instruction vrf-target .

Si vous ne configurez pas les import options et export de l’instruction vrf-target , la chaîne de communauté spécifiée est appliquée dans les deux sens. Les import mots-clés et export vous donnent plus de flexibilité, vous permettant de spécifier une communauté différente pour chaque direction.

La syntaxe de la communauté cible VRF n’est pas un nom. Vous devez le spécifier au format target:x:y. Il n’est pas possible de spécifier un nom de communauté, car cela vous obligerait également à configurer les membres de cette communauté à l’aide de l’instruction policy-options . Si vous définissez les instructions, vous pouvez simplement configurer les policy-options stratégies d’importation et d’exportation VRF comme d’habitude. Le but de l’instruction vrf-target est de simplifier la configuration en vous permettant de configurer la plupart des instructions au niveau de la [edit routing-instances] hiérarchie.

Pour configurer une cible VRF, incluez l’instruction vrf-target suivante :

Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :

  • [edit routing-instances routing-instance-name]

  • [edit logical-systems logical-system-name routing-instances routing-instance-name]

Voici un exemple de la façon dont vous pouvez configurer l’instruction vrf-target :

Pour configurer l’instruction vrf-target avec les export options et import , incluez les instructions suivantes :

Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :

  • [edit routing-instances routing-instance-name]

  • [edit logical-systems logical-system-name routing-instances routing-instance-name]

Configuration de l’origine de route pour les VPN

Vous pouvez utiliser route origin pour empêcher les routes apprises à partir d’un routeur CE marqué avec origin community d’être annoncées à partir d’un autre routeur CE dans le même AS.

Dans l’exemple, l’origine de route est utilisée pour empêcher les routes apprises à partir du routeur CE A qui sont marquées avec la communauté d’origine d’être annoncées vers le routeur CE E par AS 200. L’exemple de topologie illustré à la Figure 1.

Figure 1 : exemple de topologie de réseau du site d’origine Network Topology of Site of Origin Example

Dans cette topologie, le routeur CE A et le routeur CE E se trouvent dans le même AS (AS200). Ils utilisent EBGP pour échanger des routes avec leurs routeurs PE respectifs, le routeur PE B et le routeur PE D. Les deux routeurs CE disposent d’une connexion arrière.

Les sections suivantes décrivent comment configurer l’origine de route d’un groupe de VPN :

Configuration de la communauté du site d’origine sur le routeur CE A

La section suivante décrit comment configurer le routeur CE A pour annoncer des routes avec une communauté de site d’origine au routeur PE B pour cet exemple.

Note:

Dans cet exemple, les itinéraires directs sont configurés pour être annoncés, mais n’importe quel itinéraire peut être configuré.

Configurez une stratégie pour annoncer les routes avec my-soo la communauté sur le routeur CE A comme suit :

Configuration de la communauté sur le routeur CE A

Configurez la communauté sur le my-soo routeur CE A comme suit :

Application de la déclaration de stratégie sur le routeur CE A

Appliquez l’énoncé de stratégie d’exportation vers mon FAI en tant que stratégie d’exportation à l’appairage EBGP sur le routeur CE A comme suit :

Lorsque vous émettez la show route receive-protocol bgp detail commande, vous devez voir les routes suivantes provenant du routeur PE B avec my-soo la communauté :

Configuration de la stratégie sur le routeur PE D

Configurez une stratégie sur le routeur PE D qui empêche les routes avec my-soo balisage communautaire par le routeur CE A d’être annoncées sur le routeur CE E comme suit :

Configuration de la communauté sur le routeur PE D

Configurez la communauté sur le routeur PE D comme suit :

Application de la stratégie sur le routeur PE D

Pour éviter que les routes apprises à partir du routeur CE A ne soient annoncées au routeur CE E (les deux routeurs peuvent communiquer ces routes directement), appliquez l’instruction de soo-ce1-policy stratégie en tant que stratégie d’exportation à la session vpn_blueEBGP du routeur PE D et du routeur CE E .

Affichez la session EBGP sur le routeur PE D à l’aide de la show routing-instances commande.

Appliquez l’énoncé soo-ce1-policy de stratégie en tant que stratégie d’exportation à la session vpn_blue EBGP du routeur PE D et du routeur CE E comme suit :

Documentation connexe