Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Distribution des routes VPN

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

Favoriser 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 être en mesure d’échanger des informations de routage. Pour cela, vous devez configurer des routes IGP (comme 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 à la limite de la zone. L’adresse de bouclage de chaque routeur PE doit apparaître sous la forme d’un routage distinct.

Configuration des sessions IBGP entre 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 à l’origine et à la fin du VPN. Les routeurs PE s’appuient sur ces informations pour déterminer les étiquettes à utiliser pour le trafic à destination des sites distants.

Configurez une session IBGP pour le VPN comme suit :

L’adresse IP de l’instruction local-address est l’adresse de l’interface de bouclage du routeur PE local. La session IBGP pour le VPN s’exécute via l’adresse de bouclage. (Vous devez également configurer l’interface de bouclage au niveau de la [edit interfaces] hiérarchie.)

L’adresse IP de l’instruction neighbor est l’adresse de bouclage du routeur PE voisin. Si vous utilisez la signalisation RSVP, cette adresse IP est 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, les VPLS, les EVPN ou les VPN de couche 3.

  • Pour configurer une session IBGP pour les VPN de couche 2 et VPLS, incluez l’instruction 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 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 , family inet-vpn ou les deux family inet6 , au family inet6-vpn sein du même groupe d’pairs. Cela vous permet d’activer la prise en charge des routes VPN IPv4 et IPv4 ou des routes VPN IPv6 et IPv6 au sein du même groupe d’homologues.

Configuration des étiquettes agrégées pour LES VPN

L’agrégation d’étiquettes pour VPN permet à une plate-forme de routage Juniper Networks d’agréger un ensemble d’étiquettes entrantes (étiquettes reçues d’un routeur pair) en un seul label de transfert sélectionné parmi l’ensemble d’étiquettes entrantes. Le label de transfert unique correspond à un saut suivant pour cet ensemble de labels. L’agrégation d’étiquettes réduit le nombre d’étiquettes VPN que le routeur doit examiner.

Pour qu’une série d’étiquettes partage un label de transfert agrégé, elles doivent appartenir à la même classe d’agrégation 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 dans 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 pair, ces préfixes représentent un FEC sur le routeur PE pair.

ATTENTION:

Si la communauté cible est définie par erreur au lieu de la communauté d’origine, des problèmes de transfert au PE sortant peuvent en résulter. Tous les préfixes de l’appairage PE apparaissent dans le même FEC, ce qui donne une seule étiquette interne pour tous les routeurs CE derrière un PE donné dans le même VPN.

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

  • sont reçues par le même routeur

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

  • Avoir le même saut suivant

L’exigence du saut suivant est importante, car les réflecteurs de route des routes avant proviennent de différents pairs BGP vers un autre pair BGP sans modifier le saut suivant de ces routes.

Pour configurer des étiquettes agrégées pour les VPN, incluez l’instruction aggregate-label :

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

Pour plus d’informations sur la configuration d’une communauté, consultez Understanding BGP Communities, Extended Communities and Large Communities as Routing Policy Match Conditions( Comprendre les communautés BGP, les communautés étendues et les grandes communautés) en tant que conditions de correspondance des stratégies 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, 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 typique, vous devez configurer des 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 configurer aucune des interfaces centrales des routeurs PE sur des PIC Fast Ethernet denses.

Pour activer un protocole de signalisation, procédez comme suit dans l’une des sections suivantes :

Utilisation de LDP pour la signalisation VPN

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

  1. Configurez LDP sur les interfaces au 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. On peut les considérer comme des interfaces « orientées cœur ». Il n’est pas nécessaire de configurer le LDP sur l’interface entre le pe et les routeurs de périphérie client (CE).

  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 à l’instance principale du protocole de routage, et non dans 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 de la [edit protocols] hiérarchie et configurez l’interface de bouclage et la famille ISO (International Organization for Standardisation) au niveau de la [edit interfaces] hiérarchie. 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 IS-IS doit être exécuté. Lorsque vous activez IS-IS, les niveaux 1 et 2 sont activés par défaut. Voici la configuration IS-IS minimale. Dans l’énoncé address , address il s’agit du NET.

Utilisation de RSVP pour la signalisation VPN

Pour utiliser RSVP pour la signalisation VPN, procédez comme suit :

  1. Sur chaque routeur PE, configurez les aspects techniques du trafic.

    Pour ce faire, vous devez configurer un protocole IGP (Interior Gateway Protocol) qui prend en charge les aspects techniques du trafic (IS-IS ou OSPF) et qui prend en charge les aspects techniques du trafic pour ce protocole.

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

    Pour IS-IS, la prise en charge des aspects techniques du trafic est activée par défaut.

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

    Sur le routeur PE, ces interfaces représentent les points d’entrée et de sortie vers le LSP. Sur le routeur P, ces interfaces connectent le LSP entre les routeurs PE. N’activez pas le protocole RSVP sur l’interface entre le pe et les routeurs 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, ajoutez les interface instructions et label-switched-path instructions au niveau de la [edit protocols mpls] hiérarchie :

    Dans l’instruction to , indiquez 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 physiques et logiques). Incluez une interface instruction pour l’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 instructions et les family inet instructions 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 un label MPLS au trafic entrant dans le LSP ou de supprimer le label du trafic sortant du LSP.

    Pour plus d’informations sur la configuration de MPLS, consultez la rubrique Configuring the Ingress Router for MPLS-Signaled LSP.

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 façon 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 route et définir éventuellement l’origine du routage.

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 des stratégies pour la table de routage VPN, vous devez définir une cible de routage, qui définit le VPN auquel le routage 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 cibles de routage uniques afin d’éviter la possibilité d’ajouter des informations de routage et de signalisation à la mauvaise table de routage VPN.

Pour configurer la cible de routage, 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é. Indiquez-le dans l’un des formats suivants :

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

  • ip-address:number, où ip-address se trouve une adresse IPv4 (valeur de 4 octets) et number une valeur de la communauté à 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 router-id , qui est une adresse non privée dans votre plage de préfixes assignés. La valeur de la communauté peut être comprise entre 1 et 65 535.

Configuration de l’origine du routage

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

La correspondance sur l’attribut d’origine de route assigné dans la stratégie d’importation VRF d’une PE destinataire 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 sur le même site VPN à partir d’un pe différent connecté au même site.

Pour configurer l’origine du routage, 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é. Indiquez-le dans l’un des formats suivants :

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

    • ip-address:number, où ip-address se trouve une adresse IPv4 (valeur de 4 octets) et number une valeur de la communauté à 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 router-id , qui est une adresse non privée dans votre plage de préfixes assignés. La valeur de la communauté peut être comprise 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. Voir Configuration d’une stratégie d’importation pour la table VRF du routeur PE.

    Si la clause de from la politique ne spécifie pas de condition de communauté, l’énoncé vrf-import dans lequel la politique 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. Voir Configuration d’une stratégie d’exportation pour la table VRF du routeur PE.

Reportez-vous à La configuration de l’origine du routage pour les VPN pour un exemple de configuration.

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

Chaque VPN peut avoir une stratégie qui définit la façon 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 des autres routeurs PE du 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, le routage est installé dans la table VRF du routing-instance-name.inet.0 routeur PE. Une stratégie d’importation doit contenir un deuxième terme qui rejette toutes les autres routes.

À moins qu’une stratégie d’importation ne contienne qu’une then reject seule déclaration, elle doit inclure une référence à une communauté. Sinon, lorsque vous tentez de valider la configuration, la validation é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 à partir 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 de la [edit protocols bgp] hiérarchie, les stratégies d’importation au niveau de la [edit policy-options] hiérarchie et du [edit protocols bgp] niveau de hiérarchie sont combinées via une opération ET logique. Vous pouvez ainsi 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 sur la session IBGP avec l’autre routeur PE. Si les routes correspondent aux conditions de l’instruction from , le routage est installé dans la table VRF .inet.0 du routing-instance-namerouteur PE. Le deuxième terme de la politique rejette toutes les autres routes.

    Pour plus d’informations sur la création de stratégies, consultez le 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 l’instruction suivante à 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 comme faisant partie d’une communauté étendue cible de routage. Pour plus d’informations sur la configuration des expressions régulières pour les communautés, consultez Understanding How to Define BGP Communities and Extended Communities .

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

    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 avoir une stratégie qui définit la façon 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 aux autres routeurs PE du VPN. Une stratégie d’exportation doit évaluer toutes les routes reçues sur la session du protocole de routage avec le routeur CE. (Cette session peut utiliser les protocoles de routage BGP, OSPF ou Routing Information Protocol [RIP] ou des routes statiques.) Si les routes correspondent aux conditions, la cible de la communauté spécifiée (qui est la cible de routage) y est ajoutée et ils sont exportés vers les routeurs PE distants. Une stratégie d’exportation doit contenir un deuxième terme qui rejette toutes les autres routes.

Les stratégies d’exportation définies au sein de l’instance de routage VPN sont les seules à s’appliquer à la table VRF. Toute stratégie d’exportation définie 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 conformément au 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’instruction policy-statement , au minimum :

    Note:

    La configuration de l’instruction community add est une exigence 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 bloquer la connexion.

    Note:

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

    Lors de la configuration des VPN multicast draft-rosen fonctionnant en mode spécifique à la source et utilisant l’instruction vrf-target , la stratégie d’exportation VRF est automatiquement générée 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 sur la session du 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 la communauté spécifiée dans l’instruction then community add leur est ajoutée et ils sont exportés vers les routeurs PE distants. Le deuxième terme de la politique rejette toutes les autres routes.

    Pour plus d’informations sur la création de stratégies, consultez le 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 politique, incluez l’énoncé vrf-export :

    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 la section Configuration d’une stratégie d’exportation pour la table VRF du routeur PE, les routes des instances de routage VPN sont annoncées sur d’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 BGP group ou neighbor export 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 comme un réflecteur de route (RR) ou un routeur autonome aux limites du système (ASBR) dans un VPN Carrier-over-Carrier ou inter-AS, la manipulation du saut suivant dans la stratégie d’exportation vrf est ignorée.

Lorsque vous incluez la vpn-apply-export déclaration, sachez que :

  • Les routes importées dans la table de routage bgp.l3vpn.0 conservent les attributs des routes d’origine (par exemple, un routage OSPF reste un routage OSPF, même lorsqu’il est stocké dans la table de routage bgp.l3vpn.0). Vous devez en être conscient 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 ASBR (as boundary router).

  • Par défaut, toutes les routes de la table de routage bgp.l3vpn.0 sont exportées vers les pairs IBGP. Si la dernière déclaration de la stratégie d’exportation est refuser tout 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 d’exportation BGP aux routes VPN, incluez l’instruction vpn-apply-export :

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

Configuration d’une cible VRF

L’inclusion de l’instruction vrf-target dans la configuration d’une communauté cible VRF génère des stratégies d’importation et d’exportation VRF par défaut 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 les 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 l’instruction et export ses import vrf-target options, la chaîne de communauté spécifiée est appliquée dans les deux directions. Les import mots-clés export vous donnent plus de flexibilité, vous permettant de spécifier une communauté différente pour chaque orientation.

La syntaxe de la communauté cible VRF n’est pas un nom. Vous devez le spécifier dans le format target:x:y. Un nom de communauté ne peut pas être spécifié, car cela vous obligerait également à configurer les membres de la communauté à l’aide de l’instruction policy-options . Si vous définissez les policy-options instructions, vous pouvez simplement configurer les stratégies d’importation et d’exportation VRF comme d’habitude. L’objectif 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 :

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 configuration de l’instruction vrf-target :

Pour configurer l’instruction vrf-target avec les export options 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 du routage pour les VPN

Vous pouvez utiliser l’origine de route pour empêcher les routes apprises à partir d’un routeur de périphérie client (CE) marqué de la communauté d’origine d’être annoncé à nouveau à partir d’un autre routeur CE dans le même AS.

Dans l’exemple, l’origine du routage est utilisée pour empêcher les routes apprises à partir du routeur CE A qui sont marqués de la communauté d’origine d’être renvoyés au routeur E CE par AS 200. L’exemple de topologie est illustré sur la figure 1.

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

Dans cette topologie, les routeurs CE A et CE E sont dans le même AS (AS200). Ils utilisent EBGP pour échanger des routes avec leurs routeurs PE (Provider Edge) respectifs, les routeurs PE B et D. Les deux routeurs CE ont une connexion arrière.

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

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

La section suivante décrit comment configurer le routeur CE A afin de promouvoir les routes via un site de la communauté d’origine sur le routeur PE B pour cet exemple.

Note:

Dans cet exemple, les routes directes sont configurées pour être annoncées, mais n’importe quelle route peut être configurée.

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 A CE comme suit :

Appliquer l’énoncé de politique sur le routeur CE A

Appliquez l’énoncé de stratégie export-to-my-isp en tant que stratégie d’exportation à l’appairage EBGP sur le routeur A CE comme suit :

Lorsque vous désactivez 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 la communauté balisées par le routeur CE A d’être annoncée sur le routeur E CE 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 E CE (les deux routeurs peuvent communiquer ces routes directement), appliquez l’instruction soo-ce1-policy de stratégie en tant que stratégie d’exportation à la session vpn_blueE EBGP des routeurs PE D et CE .

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

Appliquez la déclaration de soo-ce1-policy 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 :