Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Création de routes VPN uniques à l’aide des tables VRF

Comprendre les tables de routage et de routage virtuels

Pour séparer les routes d’un VPN des routes de l’Internet public ou de celles des autres VPN, le routeur PE crée une table de routage distincte pour chaque VPN, appelée table de routage et de routage de VPN (VRF). Le routeur PE crée une table VRF pour chaque VPN qui dispose d’une connexion à CE routeur virtuel. Tout client ou site qui appartient au VPN n’a accès qu’aux routes des tables VRF pour ce VPN.

La Figure 1 illustre les tables VRF créées sur les routeurs PE. Les trois routeurs PE sont connectant à des routeurs CE dans deux VPN différents. Ainsi, chaque routeur PE crée deux tables VRF, une pour chaque VPN.

Figure 1: Tables VRF VRF Tables

Chaque tableau de la réalité virtuelle (VRF) est rempli à partir des routes reçues de sites CE directement connectés, associés à cette instance de routage VRF, et des routes reçues d’autres routeurs PE qui ont passé le filtrage communautaire BGP et se trouve dans le même VPN.

Chaque routeur PE conserve également une table de routage globale(inet.0)pour atteindre d’autres routeurs à l’intérieur et à l’extérieur du réseau central du fournisseur.

Chaque connexion client (c’est-à-dire chaque interface logique)est associée à une table VRF. Seule la table VRF associée à un site client est consultée pour obtenir les paquets provenant de ce site.

Vous pouvez configurer le routeur de manière à ce que si le prochain saut vers une destination ne se trouve pas dans la table VRF, le routeur effectue une recherche dans la table de routage globale, utilisée pour l’accès à Internet.

Le Junos OS utilise les tables de routage suivantes pour les VPN:

  • bgp.l3vpn.0—Stocke les routes apprises à partir des autres routeurs PE. Les routes de la table de routage bgp.l3vpn.0 sont copiées dans une VRF de couche 3 lorsqu’une stratégie d’importation VRF correspondante est mise en place dans le routeur PE. Ce tableau n’est présent que sur les routeurs PE et ne stocke pas les routes reçues CE routeurs connectés directement.

    Lorsqu’un routeur PE reçoit un routeur provenant d’un autre routeur PE, il place la route dans sa table de routage bgp.l3vpn.0. Le routage est résolu à l’aide des informations de la table de routage inet.3. La route résultante est convertie en format IPv4 et redistribuée à toutes les tables de routage routing-instance-name .inet.0 du routeur PE si elle est en correspondance avec la stratégie d’importation VRF.

    Le tableau bgp.l3vpn.0 est également utilisé pour résoudre les routes sur les tunnels MPLS qui connectent les routeurs PE. Ces routes sont stockées dans la table de routage inet.3. Pour que les routes VPN soient correctement résolues, la connectivité des routeurs PE-to-PE doit être inet.3 (et non inet.0).

    Lorsqu’un routeur affiche des routes unicast VPN-IPv4 non locales et qu’il est un réflecteur de route ou effectue un peering externe, les routes unicast VPN-IPv4 sont automatiquement exportées vers la table de routage VPN (bgp.l3vpn.0). Le routeur peut alors effectuer une sélection de chemins et faire la publicité à partir de la table de routage bgp.l3vpn.0.

    Pour déterminer s’il est important d’ajouter une route à la table de routage bgp.l3vpn.0, l’Junos OS contrôle cette route par rapport aux stratégies d’importation d’instance VRF pour tous les VPN configurés sur le routeur PE. Si le routage VPN-IPv4 correspond à l’une des stratégies, il est ajouté à la table de routage bgp.l3vpn.0. Pour afficher les routes dans la table de routage bgp.l3vpn.0, utilisez la table de routage d’affichage commande bgp.l3vpn.0.

  • routing-instance-name .inet.0:stocke toutes les routes IPv4 unicast reçues des routeurs CE connectés directement dans une instance de routage (c’est-à-dire dans un SEUL VPN) et toutes les routes statiques explicitement configurées dans l’instance de routage. Il s’agit de la table VRF et n’est présente que sur les routeurs PE. Par exemple, pour une instance de routage nommée VPN-A,la table de routage de cette instance est nommée VPN-A.inet.0.

    Lorsqu’un routeur CE fait la publicité sur un routeur PE, le routeur PE place la route dans la table de routage routing-instance-name .inet.0 correspondante et met en avant la route vers d’autres routeurs PE s’il passe une stratégie d’exportation VRF. Cette politique balise le routeur avec l’distinguisher (cible de route) correspondant au site VPN auquel le réseau CE fournisseur. Un label est également alloué et distribué avec le routeur. La table de routage bgp.l3vpn.0 n’est pas impliquée dans ce processus.

    Le tableau routing-instance-name .inet.0 stocke également les routes annoncées par un routeur PE distant en correspondance avec la politique d’importation VRF pour ce VPN. Le routeur PE a redistribué ces routes à partir de sa table bgp.l3vpn.0.

    Les routes ne sont pas redistribuées depuis la table routing-instance-name .inet.0 vers la table bgp.l3vpn.0 ; elles sont directement annoncées à d’autres routeurs PE.

    Pour chaque table routing-instance-name de routage .inet.0, une table de routage est maintenue dans la moteur de transfert de paquets du routeur. Cette table est conservée en complément des tables de routage correspondant aux tables de routage inet.0 et mpls.0 du routeur. Comme pour les tables de routage inet.0 et mpls.0, les meilleures routes de la table de routage routing-instance-name .inet.0 sont placées dans la table de routage.

    Pour afficher les routes dans le tableau routing-instance-name .inet.0, utilisez la table de routes d’affichage routing-instance-name .inet.0.

  • inet.3— Stocke toutes les MPLS apprendre à partir des signaux LDP et RSVP effectués pour le trafic VPN. La table de routage stocke MPLS routages uniquement si l’option bgp-igp d’ingénierie du trafic n’est pas activée.

    Pour que les routes VPN soient correctement résolues, la table inet.3 doit contenir des routes vers tous les routeurs PE du VPN.

    Pour afficher les routes dans le tableau inet.3, utilisez la commande show route table inet.3.

  • inet.0— Stockeles routes apprises par les sessions IBGP entre les routeurs PE. Pour fournir un accès Internet aux sites VPN, configurez la table de routage routing-instance-name .inet.0 afin de contenir une route par défaut vers la table de routage inet.0.

    Pour afficher les routes dans le tableau inet.0, utilisez la commande show route table inet.0.

Les stratégies de routage suivantes, qui sont définies dans les déclarations d’importation et d’exportation de vrF, sont spécifiques aux tables VRF.

  • Stratégie d’importation: appliquée aux routes VPN-IPv4 apprises à partir d’un autre routeur PE pour déterminer si le routeur doit être ajouté à la table de routage bgp.l3vpn.0 du routeur PE. Chaque instance de routage d’un routeur PE a une stratégie d’importation VRF.

  • Politique d’exportation— Appliquée aux routes VPN-IPv4 annoncées pour les autres routeurs PE. Les routes VPN-IPv4 sont des routes IPv4 annoncées par les routeurs connectés CE localement.

Le traitement des routeurs VPN diffère d’BGP un traitement de route normal. En BGP, les routes sont acceptées si elles ne sont pas explicitement rejetées par la stratégie d’importation. Cependant, étant donné qu’un grand nombre de routes VPN sont prévues, le Junos OS n’accepte pas les routes VPN, et donc les stocke, sauf si le routeur est en correspondance avec au moins une stratégie d’importation VRF. Si aucune stratégie d’importation VRF n’accepte expressément le routeur, elle est écartée et non stockée dans la table bgp.l3vpn.0. Ainsi, en cas de modification d’un VPN sur un routeur PE( par exemple l’ajout d’une nouvelle table VRF ou la modification d’une stratégie d’importation de VRF), le routeur PE envoie un message de remise à niveau de route BGP aux autres routeurs PE (ou au réflecteur si cela fait partie de la topologie VPN) afin de récupérer toutes les routes VPN afin de pouvoir les réévaluer afin de déterminer s’ils doivent être maintenus ou éliminés.

Voir également

Comprendre la localisation VRF dans les VPN de couche 3

Dans un VPN de couche 3, pour séparer les routes d’un VPN des routes de l’Internet public ou de celles des autres VPN, le routeur PE crée une table de routage distincte pour chaque VPN, appelée table de routage et de routage virtuel (VRF). Chaque VRF utilise un routeur et une cible de route pour différencier les autres VPN afin d’obtenir un VPN dans un réseau public. Le routeur PE crée une table VRF pour chaque VPN qui dispose d’une connexion à CE routeur virtuel. Tout client ou site qui appartient au VPN n’a accès qu’aux routes des tables VRF pour ce VPN.

Les routeurs PE d’un déploiement VPN de couche 3 sont deux types de cartes d’interfaces hébergeant les interfaces suivantes:

  • CE d’interfaces

  • Interfaces core-facing

Note:

Un FPC peut être orienté cœur ou CE de cœur.

Les VRF sont présentes sur ces cartes de ligne et, actuellement, en Junos OS, toutes les routes de toutes les VRF sont présentes sur toutes les cartes d’allumant les sauts suivants en composite chaînés sur tous les FPPC. Cette technologie utilise la mémoire de chaque carte de ligne. Étant donné que le trafic provenant d’interfaces CE ne passe par les CARTES FPC correspondantes que par les CE, toutes les routes et les sauts suivants n’ont pas besoin d’être présents sur toutes les cartes d’interfaces. La localisation VRF fournit un mécanisme permettant de localiser les routes de VRF vers des cartes d’ligne spécifiques afin d’optimiser le nombre de routes qu’un routeur peut gérer. CE interfaces de ligne localisent tous les routes du type d’instance VRF à une carte de ligne spécifique. Si CE interfaces sont des interfaces logiques comme AE, RLSQ ou IRB, alors un numéro de carte d’interface doit être configuré pour localiser les routes. Les cartes de ligne central stockent toutes les routes VRF. Ces cartes doivent être configurées uniquement en tant que carte VPN par défaut ou en tant que réseau central VPN. Les cartes de ligne principales stockent les routes de toutes les VRF et sont des types suivants:

  • vpn-core-facing-default: le FPC central installe toutes les routes et les sauts suivants des routes VRF.

  • vpn-core-facing uniquement: le FPC central installe toutes les routes et ne stocke pas les sauts suivants des routes VRF.

Note:

Les FPC à cœur de cœur peuvent être configurés en tant que système core-facing-default ou core-facing uniquement.

Optimisation des routes VPN à l’aide de la localisation VRF pour les VPN de couche 3

La localisation de routage et de routage virtuels (VRF) fournit un mécanisme permettant de localiser les routes de VRF vers des cartes d’ligne spécifiques afin d’optimiser le nombre de routes qu’un routeur peut gérer. CE interfaces de ligne localisent tous les routes du type d’instance VRF à une carte de ligne spécifique. Si les interfaces CE sont des interfaces logiques comme AE/RLSQ/IRB, alors la carte d’interface doit être configurée pour localiser les routes. Les cartes de ligne central stockent toutes les routes VRF. Ces cartes doivent être configurées uniquement en tant que réseau central VPN ou comme réseau central par défaut. Pour configurer la localisation VRF, configurez l’énoncé au niveau de la hiérarchie et localized-fib [edit routing-instances instance-name routing-options] configurez vpn-localization l’énoncé au niveau de la [edit chassis fpc fpc-slot] hiérarchie. La show route vpn-localization commande affiche les informations de localisation de toutes les VRF du système.

Avant de commencer à localiser la table VRF:

  • Configurez les interfaces.

  • Configurez les protocoles de routage et de signalisation.

Pour configurer la localisation VRF:

  1. Configurez le châssis du routeur.

    1. Configurez l’emplacement FPC en tant qu’emplacement VPN central uniquement ou avec l’emplacement VPN central par défaut pour stocker les routes VRF.

  2. Configurez un service réseau IP amélioré sur le châssis.
  3. Créez un type d’instance, configurez l’éminent routeur et configurez la communauté cible VRF et le label de cible VRF.
  4. Configurez l’option de routage multi-chemin pour équilibrer la charge indépendamment du protocole.
  5. Configurez le FPC spécifique des interfaces physiques en contact avec CE ou spécifiez le numéro d’emplacement FPC si les interfaces CE sont des interfaces logiques comme AE ou RSQL ou IRB pour localiser les routes des instances de routage VRF.

    • Configurez le FPC spécifique de CE interfaces physiques orientées réseau pour localiser les routes des instances de routage VRF.

    • Configurez le numéro d’emplacement FPC des interfaces logiques orientées CE interfaces logiques telles qu’AE ou RSQL ou IRB afin de localiser les routes d’instance de routage VRF.

  6. Configurez le groupe de pairs du BGP pour l’instance de routage.
  7. Configurez le protocole MVPN pour l’instance de routage.

Exemple: Amélioration de l’évolutivité à l’aide de la localisation VRF pour les VPN de couche 3

Cet exemple montre comment configurer la localisation VRF sur les routeurs MX Series, ce qui vous permet d’améliorer l’évolutivité du VPN sur MX Series routeurs.

Exigences

Cet exemple utilise les composants matériels et logiciels suivants:

  • 5 MX Series 5G Plates-formes de routage universelles

  • Junos OS version 14.2 ou ultérieure s’exécutant sur tous les équipements

Avant de commencer:

  1. Configurez les interfaces de l’équipement.

  2. Configurez le BGP protocole de sécurité.

Aperçu

À partir de Junos OS version 14.2, la localisation VRF fournit un mécanisme permettant de localiser les routes de VRF vers des cartes d’ligne spécifiques, ce qui permet d’optimiser le nombre de routes qu’un routeur peut gérer. CE interfaces ouvertes localisent l’ensemble des routes du type d’instance VRF à une carte de ligne spécifique. Si les interfaces CE sont des interfaces logiques comme AE ou RLSQ ou IRB, alors la carte d’interface doit être configurée pour localiser les routes. Les cartes de ligne central stockent toutes les routes VRF. Ces cartes doivent être configurées uniquement en tant que réseau central VPN ou comme réseau central par défaut. Pour configurer la localisation VRF, configurez l’énoncé de configuration au niveau de la hiérarchie et localized-fib [edit routing-instances instance-name routing-options] configurez-le vpn-localization au niveau de la [edit chassis fpc fpc-slot] hiérarchie. La show route vpn-localization commande affiche les informations de localisation de toutes les VRF du système.

Topologie

Sur la topologie de la figure 2,la localisation VRF est configurée sur l’équipement PE1.

Figure 2: Localisation de vrf par exemple Example VRF Localization

Configuration

CLI configuration rapide

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les interruptions de ligne, modifiez les détails nécessaires pour correspondre à votre configuration réseau, copiez et collez les commandes dans le CLI au niveau de la hiérarchie, puis entrez dans le mode de [edit] commit configuration.

CE1

Pe1 (En france)

P

Pe2

CE2

Configuration de l’équipement PE1

Procédure étape par étape

L’exemple suivant vous oblige à naviguer dans différents niveaux de la hiérarchie de configuration. Pour plus d’informations sur la navigation du CLI, consultez l’outil deCLI en mode de configuration .

Pour configurer l’équipement PE1:

  1. Indiquez le nombre d’interfaces Ethernet agrégées à créer, configurez les SPC en tant qu’interfaces vpn-core uniquement et activez des services réseau IP améliorés.

  2. Configurez les interfaces.

  3. Configurez les options de stratégie pour équilibrer la charge des paquets.

  4. Configurez le protocole RSVP sur l’interface.

  5. Configurez le protocole MPLS de sécurité.

  6. Configurez le protocole BGP pour le groupe mpbg.

  7. Configurez le OSPF protocole de sécurité.

  8. Configurez le protocole LDP sur l’interface.

  9. Créez un type d’instance et configurez les instances de routage sur l’interface.

  10. Configurez l’éminent routeur et configurez le LSP statique pour le tunnel du fournisseur RSVP-TE.

  11. Configurez la cible VRF et le label de cible VRF pour l’instance de routage.

  12. Configurez l’option de routage multi-chemin pour une instance de routage et configurez l’option de routage fib localisée pour l’instance de routage.

  13. Configurez le groupe de protocoles BGP pour une instance de routage.

  14. Configurez les protocoles MVPN.

  15. Configurez le routage actif en continu et le numéro de système autonome pour une option de routage.

  16. Configurez la stratégie d’équilibrage de charge pour la table de forwarding et l’espace étendu pour le saut suivant en composite chaîné pour la L3VPN de la table de forwarding.

Résultats

À partir du mode de configuration, confirmez votre configuration en entrant les show chassis commandes , , et show interfaces show policy-options show protocols show routing-instances les show routing-options Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Si vous avez terminé la configuration de l’équipement, commit saisissez-le en mode de configuration.

Vérification

Vérifier que la configuration fonctionne correctement.

Vérification de la localisation VRF

But

Vérifiez la localisation de VRF dans un VPN de couche 3.

Action

À partir du mode opérationnel, exécutez show route vpn-localization la commande pour l’équipement PE1.

Sens

Le résultat affiche les informations de localisation de toutes les VRF.

Vérification de la localisation VRF pour un VPN

But

Vérifier la localisation VRF pour un VPN.

Action

À partir du mode opérationnel, exécutez show route vpn-localization vpn-name vpn-name la commande.

Sens

Le résultat indique la localisation VPN d’un VPN.

Filtrage des paquets dans les VPN de couche 3 basé sur les en-têtes IP

En incluant l’instruction dans la configuration d’une instance de routage, il est possible d’associer le label interne à une table de routage VRF spécifique. Cette mise en correspondance permet l’examen de l’en-tête IP encapsulé au niveau d’un routeur VPN de vrf-table-label sortie. Vous pouvez activer cette fonctionnalité afin d’obtenir l’une des fonctionnalités suivantes:

  • Transfert du trafic sur une interface PE-routeur vers équipement CE, dans un support partagé, où l’équipement CE est un commutateur de couche 2 sans fonctionnalité IP (par exemple, un commutateur Metro Ethernet).

    Le premier examen est effectué sur le label VPN afin de déterminer le tableau VRF auquel se référer, et le second se fait sur l’en-tête IP pour déterminer comment faire avancer les paquets vers les hôtes finaux corrects sur le support partagé.

  • Effectuez un filtrage de sortie au niveau du routeur PE de sortie.

    La première recherche sur le label VPN est effectuée pour déterminer la table de routage VRF à désigner, et une autre sur l’en-tête IP pour déterminer comment filtrer et forwarder les paquets. Vous pouvez activer cette fonctionnalité en configurant des filtres de sortie sur les interfaces VRF.

    Lorsque vous ajoutez l’instruction dans la configuration d’une table de routage VRF, un label d’interface logique de commutation d’étiquettes (LSI) est créé et mapé sur la table de vrf-table-label routage VRF. Toutes les routes d’une telle table de routage VRF sont annoncées avec le label d’interface logique LSI alloué à la table de routage VRF. Lorsque les paquets de ce VPN arrivent sur une interface core-facing, ils sont traités comme si le paquet IP fermé arrivait sur l’interface LSI, puis était puis transmis et filtrer en fonction du tableau correct.

Pour filtrer le trafic en fonction de l’en-tête IP, indiquez vrf-table-label l’instruction:

Vous pouvez inclure l’énoncé aux niveaux hiérarchiques suivants:

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

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

Vous pouvez inclure l’instruction pour les VPN de couche vrf-table-label 3 IPv4 et IPv6. Si vous ajoutez l’instruction d’une table de routage VRF double pile (où les routes IPv4 et IPv6 sont prise en charge), cette instruction s’applique aux routes IPv4 et IPv6 et le même label est annoncé pour les deux ensembles de routes.

Vous pouvez également configurer la comptabilisation SCU pour les VPN de couche 3 configurée avec l’énoncé en incluant vrf-table-label source-class-usage l’option. Inclure source-class-usage l’instruction au niveau [edit routing-instances routing-instance-name vrf-table-label] de la hiérarchie. L’instruction de ce niveau hiérarchique est prise en charge uniquement pour le type d’instance (VPN de couche source-class-usage vrf 3). La DCU n’est pas prise en charge pour vrf-table-label l’énoncé. Pour plus d’informations, consultez la catégorie source et l’utilisation des classes de destination.

Les sections suivantes fournissent plus d’informations sur le filtrage du trafic basé sur l’en-tête IP:

Options de filtrage du sortie

Vous pouvez activer le filtrage de sortie (qui permet aux routeurs VPN de couche 3 d’effectuer en même temps des recherches sur l’étiquette VPN et l’en-tête IP) en incluant l’instruction au niveau de la vrf-table-label [edit routing-instances instance-name] hiérarchie. Il n’y a aucune restriction quant à l’utilisation de cet énoncé pour les interfaces CE-routeur vers PE-routeur. Toutefois, il existe plusieurs limitations sur d’autres types d’interfaces, telles que décrites dans les sections suivantes à ce sujet.

Vous pouvez également activer le filtrage des sorties en configurant une interface de tunnel VPN (VT) sur des plates-formes de routage équipées d’une carte PIC (Tunnel Services Physical Interface Card). Lorsque vous activez le filtrage de sortie de cette manière, il n’y a aucune restriction sur le type d’interface de cœur utilisée. Il n’y a pas non plus de restriction sur le type CE’interface de routeur à PE utilisée.

Prise en charge des interfaces VLAN et agrégées pour le filtrage basé sur IP

La prise en charge de l’énoncé sur les interfaces VLAN agrégées est disponible sur les vrf-table-label routeurs résumés dans le tableau 1.

Tableau 1: Prise en charge des interfaces VLAN et agrégées

Interfaces

M Series routeur sans FPC amélioré

M Series routeur avec FPC amélioré

M320 routeur de nouvelle M320

T Series routeur de nouvelle T Series

Agrégées

Non

Oui

Oui

Oui

VLAN

Non

Oui

Oui

Oui
Note:

L’instruction n’est pas prise en charge pour les interfaces physiques vrf-table-label Gigabit Ethernet agrégées, 10 Gigabit Ethernet et VLAN sur M120 routeurs.

Prise en charge d’ATM et d’interfaces de relais de trames pour le filtrage ip

La prise en charge de l’énoncé en mode de transfert vrf-table-label asynchrone (ATM) et des interfaces de relais de trames est disponible sur les routeurs résumés dans le tableau 2.

Tableau 2: Prise en charge des interfaces ATM et relais de trames

Interfaces

M Series routeur sans FPC amélioré

M Series routeur avec FPC amélioré

M320 routeur de nouvelle M320

T Series routeur de nouvelle T Series

ATM1

Non

Non

Non

Non

IQ (Intelligent Fileing) ATM2

Non

Oui

Oui

Oui

Relais de trames

Non

Oui

Oui

Oui

Canalisé

Non

Non

Non

Non

Lorsque vous inclut l’énoncé, vous devez connaître les limites suivantes avec ATM ou les interfaces de relais vrf-table-label de trames:

  • vrf-table-labelL’énoncé est pris en charge sur les interfaces ATM, mais avec les limites suivantes:

    • Les interfaces ATM peuvent être configurées sur le routeur M320, les routeurs T Series et sur M Series routeurs avec un FPC amélioré.

    • L’interface peut uniquement être une interface de routeur PE qui reçoit du trafic à partir d’un routeur P.

    • Le routeur doit avoir un PIC IQ ATM2.

  • L’énoncé est également pris en charge sur les interfaces encapsulées par relais de vrf-table-label trames, mais avec les limites suivantes:

    • Les interfaces de relais de trames peuvent être configurées sur le routeur M320, sur les routeurs T Series, et sur M Series routeurs avec un FPC amélioré.

    • L’interface peut uniquement être une interface de routeur PE qui reçoit du trafic à partir d’un routeur P.

Prise en charge des interfaces Ethernet, SONET/SDH et T1/T3/E3 pour le filtrage basé sur IP

La prise en charge de l’énoncé sur vrf-table-label Les interfaces Ethernet, SONET/SDH et T1/T3/E3 est disponible sur les routeurs résumés dans le tableau 3.

Tableau 3: Prise en charge
des interfaces Ethernet, SONET/SDH et T1/T3/E3

Interfaces

M Series routeur sans FPC amélioré

M Series routeur avec FPC amélioré

M320 routeur de nouvelle M320

T Series routeur de nouvelle T Series

Ethernet

Oui

Oui

Oui

Oui

SONET/SDH

Oui

Oui

Oui

Oui

T1/T3/E3

Oui

Oui

Oui

Oui

Seules les SPC Ethernet suivantes soutiennent l’énoncé sur M Series routeurs sans vrf-table-label FPC amélioré:

  • Gigabit Ethernet 1 port

  • Gigabit Ethernet 2 ports

  • Fast Ethernet 4 ports

Prise en charge de SONET/SDH et DS3/E3: interfaces de file d’utilisateur intelligentes améliorées canalisées pour un filtrage basé sur IP

La prise en charge de l’énoncé des interfaces IQE canalisées spécifiées n’est disponible que sur les routeurs M120 et M320 avec FPC Enhanced III, comme résumé dans le vrf-table-label tableau 4.

canalisées sur M320 routeurs avec FPC III améliorée
Tableau 4: Prise en charge des interfaces IQE

Interfaces

M120 routeurs de nouvelle catégorie avec FPC III améliorés

M320 routeurs de nouvelle catégorie avec FPC III améliorés

OC12

Oui

Oui

STM4

Oui

Oui

OC3

Oui

Oui

STM1

Oui

Oui

DS3

Oui

Oui

L’E3

Oui

Oui

Les PIC IQE de type 1 suivantes sont prise en charge:

  • IQE OC12/STM4 1 port avec SFP

  • IQE OC3/STM1 4 ports avec SFP

  • IQE DS3/E3 4 ports avec BNC

  • IQE OC3/STM1 canalisé 2 ports avec SFP, sans partitions SONET

  • IQE OC12/STM4 canalisé 1 port avec SFP, sans partitions SONET

Les contraintes suivantes s’appliquent à une configuration de routeur utilisant des systèmes logiques:

  • Contraintes d’interfaces PIC IQE multi-ports: si l’interface de port 1 est configurée en tant que système logique unique avec sa propre instance de routage et l’interface port 2, elle est configurée en tant que système logique unique sur les ports 1 et 2, vous ne pouvez pas configurer vrf-table-label l’instruction sur l’instance de routage dans les deux systèmes logiques. Un seul ensemble de labels LSI est pris en charge. la dernière instance de routage avec vrf-table-label l’instruction configurée est engagée.

  • Encapsulation de relais de trames et interfaces logiques à travers des contraintes de systèmes logiques. À l’image du PIC multiport avec les systèmes logiques, si vous tentez de configurer une interface logique d’un PIC IQE avec l’encapsulation de relais de trames dans un système logique et configurez une autre interface logique sur le même PIC IQE dans le deuxième système logique, la configuration ne sera pas efficace pour toutes les instances configurées par vrf-table-label l’énoncé. Elle fonctionne uniquement pour les instances configurées dans l’un des systèmes logiques.

Les deux contraintes ci-dessus se produisent parce que la configuration du routeur maintient un arbre LSI dans l’moteur de transfert de paquets par système logique, qui est commun à tous les flux. La recherche de la table du canal du flux est ensuite modifiée pour pointer vers l’arborescence LSI. Dans le cas des PIC IQE de type multiport 1, toutes les interfaces physiques partagent le même flux. C’est pourquoi les interfaces logiques (multiports ou non) partagent évidemment le même flux. Par conséquent, la liaison LSI est au niveau du flux. Par conséquent, il n’est pas pris en charge le provisionment d’interfaces logiques sous un même flux, avec une interface core-facing et la prise en charge d’un ensemble différent d’instances de vrf-table-label routage avec l’énoncé.

Prise en charge des interfaces PPP multilink et relais de trames multitexte pour le filtrage IP

Les routeurs résumés dans le tableau 5 peuvent prendre en charge l’énoncé relatif aux vrf-table-label interfaces MLPPP (Multilink Point-to-Point Protocol) et MLFR (Multilink Frame Relay).

Tableau 5: Prise en charge des interfaces PPP multilink et relais de trames multitexte

Interfaces

M Series routeur sans FPC amélioré

M Series routeur avec FPC amélioré

M320

T Series routeur de nouvelle T Series

MX Series routeur de nouvelle MX Series

MLPPP

Non

Oui

Non

Non

Non

MLFR de bout en bout (FRF.15)

Non

Oui

Non

Non

Non

UNI/NNI MLFR (FRF.16)

Non

Non

Non

Non

Non

M Series routeurs MLPPP et MLFR doivent être AS un PIC vrf-table-label d’interfaces MLPPP et MLFR. vrf-table-label L’instruction sur les interfaces MLPPP n’est pas prise en charge M120 routeurs.

Prise en charge du filtrage ip des paquets avec des étiquettes de dessus null

Vous pouvez inclure l’énoncé dans la configuration pour les interfaces de cœur de réseau qui reçoivent des paquets MPLS contenant un label null top, qui peuvent être transmis par les équipements de certains vrf-table-label fournisseurs. Ces paquets peuvent être reçus uniquement sur le routeur M320, le routeur M10i et les routeurs T Series à l’aide de l’un des PIC suivants:

  • Gigabit Ethernet 1 port avec SFP

  • Gigabit Ethernet 2 ports avec SFP

  • Gigabit Ethernet 4 ports avec SFP

  • Gigabit Ethernet 10 ports avec SFP

  • SONET STM4 1 port

  • SONET STM4 4 ports

  • SONET 1 port STM16

  • SONET STM16 1 port (non SFP)

  • SONET 4 ports STM16

  • SONET 1 port STM64

Les PIC suivantes peuvent recevoir des paquets contenant des labels « null top » mais uniquement lorsqu’elles sont installées dans un routeur M120 ou un routeur M320 avec un FPC Enhanced III:

  • Ethernet 10 Gigabit 1 port

  • IQ2 1 port 10 Gigabit Ethernet

Limites générales du filtrage IP

Les limites suivantes s’appliquent lorsque vous ajoutez vrf-table-label l’instruction:

  • Les filtres de pare-feu ne peuvent pas être appliqués aux interfaces incluses dans une instance de routage sur laquelle vous avez configuré vrf-table-label l’énoncé.

  • La valeur TTL (time-to-live) de l’en-tête MPLS n’est pas copiée sur l’en-tête IP des paquets envoyés depuis le routeur PE vers le routeur CE.

  • Vous ne pouvez pas inclure l’instruction dans une configuration d’instance de routage comprenant également une interface de tunnel de bouctage virtuel ; l’opération de validation échoue vrf-table-label dans ce cas.

  • Lorsque vous ajoutez l’énoncé, les paquets MPLS avec étiquettes LSI (label-switched interface) qui arrivent sur les interfaces de cœur de réseau ne sont pas comptabilisés au niveau de l’interface logique si l’interface de cœur est l’une des suivantes:

    • ATM

    • Relais de trames

    • Ethernet configuré avec des VLANs

    • Ethernet agrégé configuré avec des VLANs

  • Pour les moteurs de routage de paquets LMNR, Stoli et I-Chip, vous ne pouvez pas inclure l’instruction dans la configuration d’une instance de routage VRF si l’interface PE-routeur vers P-routeur est l’une des interfaces suivantes:

    Note:

    L’énoncé est pris en charge lorsque l’interface PE-routeur vers P-routeur est une interface de tunnel sur une moteur de transfert de paquets Junos Trio, aucune limitation ne vrf-table-label s’applique.

    • Interface SONET/SDH agrégée

    • Interface canalisée

    • Interface de tunnel (par exemple, encapsulation de routage générique [GRE] ou IP Security [IPsec])

    • Interface encapsulée « circuit cross-connect » (CCC) ou « translational cross-connect » (TCC)

    • Interface de tunnel logique

    • Interface encapsulée de service de réseau lan privé virtuel (VPLS)

      Note:

      Toutes CE interfaces de routeur à PE et PE-routeur à CE-routeur sont prise en charge.

  • Vous ne pouvez pas inclure l’énoncé dans la configuration d’une instance de routage VRF si le vrf-table-label PIC PE-routeur vers P-routeur fait partie des PIC suivants:

    • 10 ports E1

    • Fast Ethernet 8 ports

    • Fast Ethernet 12 ports

    • Fast Ethernet 48 ports

    • PIC ATM autre que LE IQ ATM2

  • Les statistiques de trafic de l’interface de commutation d’étiquettes (LSI) ne sont pas prise en charge pour les valeurs IQ2 (Intelligent Fileing 2), IQE (Enhanced IQE) et IQ2E (Enhanced IQ2E) sur les routeurs d’M Series.

Voir également

Configuration d’une politique d’allocation et de substitution d’étiquettes pour les VPN

Vous pouvez contrôler les annonces d’étiquettes MPLS sorties et AS routeurs de bordure (ASBR). Vous pouvez attribuer des étiquettes au niveau du saut suivant (par défaut) ou par table (en configurant l’énoncé de l’étiquette vrf-table). Ce choix affecte toutes les routes d’une instance de routage donnée. Vous pouvez également configurer une stratégie pour générer des labels selon chaque route en spécifiant une stratégie d’allocation d’étiquettes.

Pour spécifier une stratégie d’allocation d’étiquettes pour l’instance de routage, configurez l’énoncé et spécifiez une stratégie d’allocation d’étiquettes en utilisant label l’option d’allocation:

Vous pouvez configurer cet énoncé aux niveaux hiérarchiques suivants:

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

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

Note:

Le [edit logical-systems] niveau de hiérarchie n’est pas applicable ACX Series routeurs.

Pour configurer la stratégie d’allocation d’étiquettes, inclure label-allocation l’instruction au niveau de la [edit policy-options policy-statement policy-statement-name term term-name then] hiérarchie. Vous pouvez configurer le mode d’allocation d’étiquettes en tant que per-nexthop ou per-table.

Pour une option VPN B ASBR, les étiquettes des routes de transit sont remplacées par un label local de tunnel virtuel ou vrf-table. Lorsqu’un tableau VRF est configuré sur l’ASBR (ce type de configuration est rare pour le modèle d’option B), l’ASBR ne génère pas de MPLS de swap ou de swap et d’état push pour les routes de transit. L’ASBR fait place à un label local virtual-tunnel ou vrf-table-label pour le transfert du trafic en fonction des tables de transfert IP. La substitution d’étiquettes permet de conserver les labels sur Juniper Networks routeurs.

Toutefois, ce type de substitution d’étiquette casse efficacement le chemin MPLS de transfert, qui devient visible lors de l’utilisation d’MPLS commande OAM comme le ping LSP. Vous pouvez configurer la manière dont les étiquettes sont remplacées par un routeur en spécifiant une politique de substitution d’étiquette.

Pour spécifier une stratégie de substitution d’étiquette pour l’instance de routage, configurez l’énoncé et spécifiez une politique de substitution d’étiquette en utilisant label l’option de substitution:

Vous pouvez configurer cet énoncé aux niveaux hiérarchiques suivants:

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

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

Note:

Le [edit logical-systems] niveau de hiérarchie n’est pas applicable ACX Series routeurs.

La politique de substitution d’étiquettes est utilisée pour déterminer si un label doit être remplacé ou non sur un routeur ASBR. Les résultats du fonctionnement de la stratégie sont soit accepter (la substitution d’étiquette est exécutée) soit rejeter (la substitution d’étiquette n’est pas effectuée). Le comportement par défaut est accepté. L’exemple de commande de jeu suivant illustre comment vous pouvez configurer une politique de substitution d’étiquette de rejet: set policy-options policy-statement no-label-substitution term default then reject .