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

Aperçu

En général, il est important d’éviter (ou de récupérer) que plusieurs routeurs PE envoient du trafic dupliqué dans le réseau central, car cela peut entraîner l’envoi de trafic dupliqué au client. Le cas d’utilisation du RPF basé sur l’expéditeur est limité aux MVPN BGP. Le champ d’application du cas d’utilisation est limité pour les raisons suivantes :

• Une vérification RPF traditionnelle pour le PIM natif est basée sur l’interface entrante. Cette vérification RPF empêche les boucles mais n’empêche pas plusieurs redirecteurs sur un réseau local. Le RPF traditionnel a été utilisé parce que les protocoles multicast actuels évitent les doublons sur un réseau local 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 fonctionnement normal de protocole. Le protocole dispose d’un mécanisme basé sur les données (messages d’assertion PIM) pour détecter les doublons lorsqu’ils se produisent et les résoudre.

• En mode PIM bidirectionnel, un choix de redirecteur désigné (DF) est effectué sur tous les réseaux locaux afin d’é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 réseau local.

Le RPF basé sur l’expéditeur est une solution à utiliser en conjonction avec les MVPN BGP, car les MVPN BGP utilisent une alternative aux solutions d’événements pilotées par les données et à l’élection DF en mode bidirectionnel. En effet, d’une part, le réseau central n’est pas exactement un réseau local. 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 routeur PE approprié. 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 à partir du bon routeur PE en amont.

Plus précisément, les données doivent arriver avec l’étiquette MPLS correcte dans l’en-tête externe utilisé pour encapsuler les données à travers le noyau. L’étiquette identifie le tunnel et, s’il s’agit d’un tunnel point à multipoint, le routeur PE en amont.

Le RPF basé sur l’expéditeur ne remplace pas le choix d’un redirecteur unique, mais constitue une fonctionnalité complémentaire. La configuration d’une adresse de bouclage primaire (ou ID de routeur) plus élevée sur un périphérique PE (PE1) que sur un autre (PE2) garantit que PE1 est le gagnant de l’élection du redirecteur unique. L’instruction unicast-umh-election entraîne la préférence de route unicast pour déterminer le choix du redirecteur unique. Si le choix d’un redirecteur unique n’est pas utilisé ou s’il n’est pas suffisant pour empêcher les doublons dans le noyau, il est recommandé d’utiliser un RPF basé sur l’expéditeur.

Pour les tunnels fournisseur point à multipoint RSVP, l’étiquette de transport identifie le routeur PE émetteur, car il est nécessaire que l’avant-dernier saut popping (PHP) soit désactivé lors de l’utilisation de tunnels 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 (car le tunnel RSVP-TE est point à multipoint) le routeur PE émetteur.

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

Note:

La technique de secours racine à chaud décrite dans Internet draft draft-morin-l3vpn-mvpn-fast-failover-05 Le basculement rapide en amont 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 routeur PE en amont de secours. Plusieurs copies du trafic peuvent ainsi transiter par le noyau fournisseur jusqu’au routeur PE sortant. Le RPF basé sur l’expéditeur et le serveur de secours racine à chaud peuvent être utilisés ensemble pour prendre en charge le trafic MVPN BGP en direct . Il s’agit d’un système multicast sur MPLS destiné à acheminer le trafic TV et IPTV professionnel critique. Un grand nombre de ces déploiements doivent être entièrement redondants, y compris les routeurs PE d’entrée et de sortie. 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 temps réel sont reçus au niveau du routeur PE de sortie, et le routeur PE de sortie transfère un seul flux 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 hot-root standby, consultez hot-root-standby.

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 à chaud ou si le choix d’un redirecteur unique n’est pas suffisant pour éviter les doublons. Le choix d’un redirecteur unique 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 réseau central. Dans certains cas, le choix d’un redirecteur unique ne peut pas empêcher le trafic dupliqué d’arriver au routeur PE sortant. Un exemple de ceci (décrit dans la section 9.3.1 de la RFC 6513) est lorsque le mode clairsemé PIM 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 routeur PE entrant correct est sélectionné. Comme décrit dans la RFC 6513, section 9.1.1, 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 n’est pas 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 de sortie 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 cible de route transportée par la route C-multicast. Cette cible de route entraîne l’envoi de la route C-multicast au routeur PE en amont et son importation dans le VRF approprié sur le routeur PE en amont. Le routeur PE de sortie programme l’entrée de transfert pour qu’elle n’accepte que le trafic provenant de ce routeur PE, et uniquement sur un tunnel particulier enraciné à 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 dans la route VPN-IP vers le point de rendez-vous (RP) pour construire la cible de route transportée par la route C-multicast.

Cette cible de route entraîne l’envoi de la route C-multicast au routeur PE en amont et son importation 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é à ce routeur PE. Cependant, si d’autres routeurs PE sont passés en mode SPT pour (C-S, C-G) et ont envoyé des routes de découverte automatique (A-D) de source active (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 A-D SA (C-S, C-G). Le trafic pour (C-S, C-G) peut être transporté 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 sortant a uniquement l’état (C-*, C-G) et n’a pas l’état (C-S, C-G), le routeur PE sortant peut recevoir (C-S, C-G) des routes SA de type 5 de plusieurs routeurs PE et choisir la meilleure, comme suit : Pour chaque route SA reçue (C-S, C-G), le routeur PE sortant trouve dans son jeu de routes UMH (upstream multicast hop) défini pour C-S une route avec le même séparateur de route (RD). Parmi toutes les routes trouvées, le routeur PE sélectionne la route UMH (en fonction de la sélection UMH). Le meilleur itinéraire (C-S, C-G) SA est celui dont le RD est le même que celui de l’itinéraire UMH sélectionné.

Lorsqu’un routeur PE sortant a uniquement l’état (C-*, C-G) et n’a pas l’état (C-S, C-G), et que si ultérieurement le routeur PE sortant 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 routeur PE en amont pour cela (C-S, C-G) ne sera pas nécessairement le même routeur PE qui est à l’origine de la meilleure route A-D SA déjà sélectionnée pour (C-S, C-G). Il est possible d’avoir une situation dans laquelle le routeur PE à l’origine de la meilleure route A-D SA (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 rejoindra pas le S-PMSI, mais continuera à 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. Il s’agit d’un comportement attendu.

Le routeur PE de sortie détermine l’émetteur d’une route A-D SA (C-S, C-G) de type 5 en recherchant dans son ensemble UMH route-candidate 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 A-D SA.