Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Comprendre le RPF basé sur l’expéditeur dans un MVPN BGP avec RSVP-TE Tunnels de fournisseur point à multipoint

Dans un BGP multicast VPN (MVPN) (également appelé VPN multiprotocole BGP multicast nouvelle génération), le RPF (Reverse-Path Forwarding) basé sur l’expéditeur permet d’empêcher plusieurs routeurs PE (Provider Edge) d’envoyer du trafic vers le cœur, empêchant ainsi le trafic dupliqué d’être envoyé à un client. Dans le diagramme suivant, le RPF basé sur l’expéditeur configuré sur les appareils PE3 et PE4 de sortie empêche l’envoi de trafic dupliqué aux clients.

Figure 1 : RPF basé sur l’expéditeur Network topology diagram showing multicast setup with Sender, Customer Edge, Provider Edge routers PE0-PE4, Rendezvous Point, and Receivers R3 and R4.

Les fichiers RPF basés sur l’expéditeur (et les serveurs de secours à chaud) ne sont pris en charge que pour les MPLS BGP MVPN avec des tunnels de fournisseur point à multipoint RSVP. Les modes SPT uniquement et SPT-RPT MVPN sont pris en charge.

Le RPF basé sur l’expéditeur ne fonctionne pas lorsque des tunnels de fournisseur point à multipoint sont utilisés avec des interfaces à commutation d’étiquettes (LSI). Junos OS n’attribue qu’une seule étiquette LSI pour chaque VRF et l’utilise pour tous les tunnels point à multipoint. Par conséquent, l’étiquette que reçoit la sortie n’indique pas le routeur PE émetteur. Les étiquettes LSI ne peuvent actuellement pas être mises à l’échelle pour créer une étiquette unique pour chaque tunnel point à multipoint. Par conséquent, des interfaces de tunnel virtuel (vt) doivent être utilisées pour la fonctionnalité RPF basée sur l’expéditeur avec des tunnels fournisseur point à multipoint.

Si vous le souhaitez, les interfaces LSI peuvent continuer à être utilisées à des fins d’unicast, et les interfaces de tunnel virtuel peuvent être configurées pour être utilisées uniquement pour le multicast.

Vue d’ensemble

En général, il est important d’éviter (ou de récupérer) que plusieurs routeurs PE envoient du trafic en double dans le cœur, car cela peut entraîner l’envoi de trafic en double au client. Le RPF basé sur l’expéditeur a un cas d’utilisation limité aux MVPN BGP. La portée du cas d’utilisation est limitée pour les raisons suivantes :

  • Un contrôle RPF traditionnel pour le PIM natif est basé sur l’interface entrante. Cette vérification RPF empêche les boucles mais n’empêche pas plusieurs redirecteurs sur un LAN. Le RPF traditionnel a été utilisé parce que les protocoles de multicast actuels évitent les doublons sur un LAN ou ont des événements basés sur les données pour résoudre les doublons une fois qu’ils sont détectés.

  • En mode clairsemé PIM, des doublons peuvent se produire sur un LAN en mode de protocole normal. Le protocole dispose d’un mécanisme piloté par les données (messages d’assertion PIM) pour détecter les doublons lorsqu’ils se produisent et les résoudre.

  • En mode bidirectionnel PIM, une sélection de redirecteur désigné (DF) est effectuée sur tous les réseaux locaux pour éviter les doublons.

  • Les MVPN Draft Rosen utilisent le mécanisme d’assertion PIM car avec les MVPN Draft Rosen, le réseau central est analogue à un LAN.

Le RPF basé sur l’expéditeur est une solution à utiliser conjointement avec les MVPN BGP, car les MVPN BGP utilisent une alternative aux solutions basées sur les événements basés sur les données et à l’élection DF en mode bidirectionnel. Il en est ainsi parce que, d’une part, le réseau central n’est pas exactement un LAN. Dans un scénario MVPN, il est possible de déterminer quel routeur PE a envoyé le trafic. Junos OS utilise ces informations pour transférer le trafic uniquement s’il provient du bon routeur PE. Avec le RPF basé sur l’expéditeur, la vérification RPF est améliorée pour vérifier si les données sont arrivées sur la bonne interface de tunnel virtuel entrant (vt-) et si les données ont été envoyées depuis le bon routeur PE en amont.

Plus précisément, les données doivent recevoir l’étiquette MPLS correcte dans l’en-tête externe utilisé pour encapsuler les données via le cœur. L’étiquette identifie le tunnel et, si le tunnel est point à multipoint, le routeur PE en amont.

Le RPF basé sur l’expéditeur ne remplace pas l’élection du transfert unique, mais est une fonctionnalité complémentaire. La configuration d’une adresse de bouclage principale (ou ID de routeur) plus élevée sur un équipement PE (PE1) que sur un autre (PE2) garantit que PE1 est le gagnant de l’élection du transfert unique. L’instruction unicast-umh-election entraîne la préférence de route unicast pour déterminer le choix du transfert unique. Si l’option de transfert unique n’est pas utilisée ou si elle n’est pas suffisante pour éviter les doublons dans le cœur, il est recommandé d’utiliser le RPF basé sur l’expéditeur.

Pour les tunnels de fournisseur point à multipoint RSVP, l’étiquette de transport identifie le routeur PE d’envoi, car il est nécessaire que l’avant-dernier saut (PHP) soit désactivé lors de l’utilisation de tunnels de fournisseur point à multipoint avec MVPNs. PHP est désactivé par défaut lorsque vous configurez le protocole MVPN dans une instance de routage. L’étiquette identifie le tunnel et (le tunnel RSVP-TE étant point à multipoint) le routeur PE émetteur.

Le mécanisme RPF basé sur l’expéditeur est décrit dans la section 9.1.1 de la section 9.1.1 de la RFC 6513, Multicast in MPLS/BGP IP VPNs .

Remarque :

La technique de secours à chaud décrite dans le brouillon Internet draft-morin-l3vpn-mvpn-fast-failover-05 Le basculement rapide en amont de VPN multicast est une fonctionnalité de routeur PE de sortie dans laquelle le routeur PE de sortie envoie un message de jointure c-multicast de l’arborescence source à un routeur PE principal et à un PE en amont de secours. Cela permet à plusieurs copies du trafic de circuler via le cœur du fournisseur vers le routeur PE de sortie. Le RPF basé sur l’expéditeur et le hot-root standby peuvent être utilisés conjointement pour prendre en charge le trafic MVPN BGP en direct . Il s’agit d’un système de multicast sur MPLS destiné à acheminer le trafic de diffusion TV et IPTV professionnel critique. Pour bon nombre de ces déploiements, la redondance complète de l’équipement réseau, y compris les routeurs PE entrants et sortants. Dans certains cas, une approche live-live est nécessaire, ce qui signifie que deux flux de trafic dupliqués sont envoyés sur le réseau en suivant des chemins différents. Lorsque cette technique est combinée avec le transfert basé sur l’expéditeur, les deux flux de trafic en direct sont reçus au niveau du routeur PE de sortie, et le routeur PE de sortie transfère un flux unique au réseau client. Toute défaillance du réseau peut être réparée localement au niveau du routeur PE de sortie. Pour plus d’informations sur la mise en veille de racine à chaud, consultez la rubrique veille de racine à chaud.

Le RPF basé sur l’expéditeur empêche l’envoi de doublons au client, même s’il y a des doublons dans le réseau du fournisseur. Des doublons peuvent exister dans le fournisseur en raison d’une configuration de secours à racine chaude ou si le choix du transfert unique n’est pas suffisant pour éviter les doublons. Le choix d’un seul transfert est utilisé pour empêcher les doublons sur le réseau central, tandis que le RPF basé sur l’expéditeur empêche les doublons vers le client, même s’il y a des doublons dans le cœur. Dans certains cas, l’option de transfert unique ne peut pas empêcher le trafic dupliqué d’arriver au routeur PE de sortie. Un exemple de ceci (décrit dans la section 9.3.1 de la RFC 6513) est lorsque le mode PIM sparse est configuré dans le réseau client et que le MVPN est en mode RPT-SPT avec un I-PMSI.

Détermination du routeur PE en amont

Une fois que Junos OS a choisi le routeur PE entrant, la décision RPF basée sur l’expéditeur détermine si le bon routeur PE entrant est sélectionné. Comme décrit dans la section 9.1.1 de la RFC 6513, un routeur PE de sortie, PE1, choisit un routeur PE en amont spécifique, pour donné (C-S, C-G). Lorsque PE1 reçoit un paquet (C-S, C-G) d’un PMSI, il peut être en mesure d’identifier le routeur PE qui a transmis le paquet au PMSI. Si cet émetteur est autre que le routeur PE sélectionné par PE1 comme routeur PE en amont, PE1 peut abandonner le paquet. Cela signifie que le routeur PE détecte un doublon, mais que le doublon n’est pas transféré.

Lorsqu’un routeur PE sortant génère une route C-multicast de type 7, il utilise la communauté étendue d’importation de route VRF transportée dans la route VPN-IP vers la source pour construire la route cible portée par la route C-multicast. Avec cette cible de route, la route C-multicast est envoyée au routeur PE en amont, puis importée dans le VRF approprié du routeur PE en amont. Le routeur PE de sortie programme l’entrée de transfert pour accepter uniquement le trafic provenant de ce routeur PE, et uniquement sur un tunnel particulier enraciné dans ce routeur PE.

Lorsqu’un routeur PE de sortie génère une route C-multicast de type 6, il utilise la communauté étendue d’importation de route VRF transportée sur la route VPN-IP vers le point de rendez-vous (RP) pour construire la route cible portée par la route C-multicast.

Avec cette cible de route, la route C-multicast est envoyée au routeur PE en amont et importée dans le VRF approprié sur le routeur PE en amont. Le routeur PE de sortie programme l’entrée de transfert pour qu’elle accepte le trafic de ce routeur PE uniquement, et uniquement sur un tunnel particulier enraciné dans ce routeur PE. Toutefois, si d’autres routeurs PE sont passés en mode SPT pour (C-S, C-G) et ont envoyé des routes d’autodécouverte (A-D) actives de la source (SA) (routes de type 5), et si le routeur PE de sortie n’a que l’état (C-*, C-G), le routeur PE en amont pour (C-S, C-G) n’est pas le routeur PE vers le RP auquel il a envoyé une route de type 6, mais le routeur PE à l’origine d’une route SA A-D pour (C-S, C-G). Le trafic pour (C-S, C-G) peut être acheminé sur un I-PMSI ou un S-PMSI, selon la façon dont il a été annoncé par le routeur PE en amont.

En outre, lorsqu’un routeur PE de sortie n’a que l’état (C-*, C-G) et n’a pas l’état (C-S, C-G), le routeur PE de sortie peut recevoir (C-S, C-G) des routes SA de type 5 provenant de plusieurs routeurs PE et choisit la meilleure, comme suit : Pour chaque route SA reçue (C-S, C-G), le routeur PE de sortie trouve dans son ensemble de routes candidates UMH (Upstream Multicast Hop) pour C-S une route avec le même RD (Route Distinguisher) de même route. Parmi toutes ces routes trouvées, le routeur PE sélectionne la route UMH (en fonction de la sélection UMH). La meilleure route (C-S, C-G) SA est celle dont le RD est le même que celui de la route UMH sélectionnée.

Lorsqu’une routeur PE de sortie n’a que l’état (C-*, C-G) et n’a pas l’état (C-S, C-G), et si par la suite le routeur PE de sortie crée l’état (C-S, C-G) (par exemple, à la suite de la réception d’un message de jointure PIM (C-S, C-G) de l’un de ses voisins de périphérie client [CE], le PE en amont routeur pour cela (C-S, C-G) ne sera pas nécessairement le même routeur PE que celui à l’origine de la meilleure route SA A-D déjà sélectionnée (C-S, C-G). Il est possible d’avoir une situation dans laquelle le routeur PE qui a créé la meilleure route SA A-D pour (C-S, C-G) transporte le (C-S, C-G) sur un I-PMSI, tandis qu’un autre routeur PE, qui est également connecté au site qui contient C-S, transporte (C-S, C-G) sur un S-PMSI. Dans ce cas, le routeur PE en aval ne rejoindrait pas le S-PMSI, mais continuerait à recevoir (C-S, C-G) sur l’I-PMSI, car la route UMH pour C-S est celle qui a été annoncée par le routeur PE qui transporte (C-S, C-G) sur l’I-PMSI. C’est un comportement normal.

Le routeur PE de sortie détermine l’expéditeur d’une route SA A-D (C-S, C-G) de type 5 en trouvant dans son ensemble de route candidat UMH pour C-S une route dont le RD est le même que dans la route SA A-D. La communauté étendue d’importation de route VRF de la route trouvée contient l’adresse IP de l’expéditeur de la route SA A-D.

Comportement RPF basé sur l’expéditeur spécifique à la plate-forme

Utilisez l’explorateur de fonctionnalités pour confirmer la prise en charge de la plate-forme et de la version pour des fonctionnalités spécifiques.

Utilisez le tableau suivant pour examiner le comportement spécifique à votre plateforme.

Tableau 1 : Comportement RPF basé sur l’expéditeur spécifique à la plate-forme

Plate-forme

Différence

MX Series

  • Le RPF basé sur l’expéditeur est pris en charge sur les plates-formes MX Series avec des cartes de ligne MPC. Comme condition préalable, le routeur doit être réglé sur network-services enhanced-ip mode.

Plusieurs chemins actifs et de sauvegarde dans la liste RPF

Lors d’un événement « Make Before Break » (MBB), Junos OS attribue plusieurs étiquettes de même pondération à un chemin de commutation d’étiquettes (LSP) dans un tunnel de fournisseur MVPN. Le périphérique de sortie accepte uniquement le trafic provenant du saut suivant actif, c’est-à-dire le saut suivant installé en premier. Le saut suivant installé par la suite est traité comme le saut suivant de rejet. Tant que le trafic passe par l’étiquette installée en premier, il n’y a pas de perte de trafic. Lorsque le trafic du PE d’entrée passe par l’étiquette installée suivante (traitée comme rejetée au niveau du PE de sortie), il y a une perte temporaire de trafic jusqu’à ce que l’événement MBB soit terminé.

À partir de Junos OS Evolved 23.4R1, a Session Id est créé, en fonction du nom du tunnel fournisseur. Les sessions sont regroupées sous cette liaison Session Id pour un saut suivant unicast. Avec cela, différentes étiquettes dans le même LSP se verront attribuer le même Session Id. Junos OS l’utilise Session Id pour accepter et transférer le trafic à partir de n’importe quelle étiquette avec un Session IDfichier .

Dans la figure ci-dessous, PE3 est configuré avec MVPN Hot Root Standby (HRS), récupérant ainsi le trafic multicast à partir du périphérique entrant principal PE1 et du périphérique entrant secondaire PE2. Un tunnel RSVP P2MP est établi entre PE1 et PE3, avec l’étiquette entrante L1. Un deuxième tunnel RSVP P2MP existe entre PE2 et PE3, avec l’étiquette entrante L2. Si PE1 est inaccessible pour une raison quelconque, l’équipement de sortie PE3 commence à récupérer le trafic de PE2. Dans le cas où un événement MBB est déclenché, PE2 signale un nouveau chemin LSP et PE3 alloue une nouvelle étiquette LSP L3 entrante. Pendant ce temps, la liste RPF dans PE3 est programmée avec deux étiquettes entrantes. Le PE entrant décide quand transférer le trafic de l’ancienne étiquette vers la nouvelle. Lorsque le trafic passe à la nouvelle étiquette, l’ancienne étiquette est arrachée. PE3 modifie son RPF NH pour l’étiqueter L3, après quoi le flux de trafic est rétabli.

Avec le regroupement des deux étiquettes, L2 et L3 sous une seule Session Id, la commutation entre les deux étiquettes LSP devient transparente et provoque un délai de transition minimal de moins de 50 ms.

Figure 2 : Événement MBB déclenché pendant HRS Network diagram showing multicast traffic in an MPLS network. A break between PE1 and PE3 is bypassed by labels L2 and L3 from PE2 to PE3.

De même, pour les tunnels de fournisseur MVPN avec un seuil de débit de trafic I-PMSI, le trafic transite par le tunnel I-PMSI jusqu’à ce que le seuil soit dépassé, auquel cas le trafic bascule vers le tunnel S-PMSI. Lors de ce basculement de l’I-PMSI vers le S-PMSI tunnel, vous pouvez subir une perte de trafic en raison d’une modification du saut suivant à partir duquel le PE de sortie recevait et transférait le trafic.

Figure 3 : Passage de l’I-PMSI au S-PMSI Multicast network architecture using MPLS and RSVP showing traffic flow from Multicast Source to Receiver via PE routers with labels L1, L2 IPMSI, and L3 SPMSI.

Junos utilise le Session Id pour regrouper les prochains sauts I-PMSI et S-PMSI, minimisant ainsi le délai de transition à moins de 50 ms.

L’exécution de la commande show multicast route extensive instance instance inclura le Session Id et Session Status si présent.

Voir aussi

Documentation connexe