Comprendre la redondance pseudowire Scénarios de backhaul mobile
Face à la demande croissante de services mobiles haut débit, les fournisseurs de télécommunications constatent une forte augmentation des besoins en bande passante. Pour répondre à la demande, les opérateurs déploient des réseaux de backhaul basés sur les paquets qui offrent une capacité accrue à moindre coût, tout en offrant la fiabilité de service et la qualité d’expérience requises par les utilisateurs.
La majeure partie de l’infrastructure de backhaul héritée est traditionnellement construite sur des liaisons PDH micro-ondes, TDM T1/E1 ou ATM sur DSL. Les fournisseurs de services ont traditionnellement ajouté des liaisons TDM ultérieures à leurs stations de base lorsque cela était nécessaire pour faire face à des scénarios de contraintes de bande passante. Ce modèle d’expansion s’est avéré inefficace face aux demandes de trafic sans précédent requises par la 3G et les services LTE (Long Term Evolution). En conséquence directe, les opérateurs migrent progressivement vers une infrastructure Ethernet de plus grande capacité dans la partie backhaul des topologies 3G et LTE. Les stations de base modernes offrent désormais une connectivité Ethernet backhaul, permettant aux technologies pseudowire de transporter le contenu de l’utilisateur final vers la destination souhaitée. Dans le cadre de cette transition vers Ethernet, les fournisseurs de services exigent de plus en plus de mécanismes de résilience afin de combler l’écart d’existence avec les fonctionnalités fournies par les anciennes technologies existantes. Dans cette optique, Junos OS fournit des capacités de redondance pseudowire efficaces aux topologies où les segments de couche 2 et de couche 3 sont interconnectés.
Exemple de topologie
La figure 1 montre un exemple de topologie.
Avantages de la redondance pseudowire Backhaul mobile
Les fonctionnalités de redondance pseudowire de Junos OS sont les suivantes :
-
Chemins redondants et sans boucle pour interconnecter les domaines de couche 2 et de couche 3.
-
Les domaines de couche 2 et de couche 3 sont synchronisés en fonction du chemin de données choisi.
-
Les perturbations du trafic sont minimes dans les cas suivants :
-
Défaillances de liaison d’accès
-
Défaillances de nœuds
-
Défaillances du plan de contrôle
-
-
Une fois la restauration de la panne terminée, l’interruption du trafic est minime.
Extension TLV d’état du circuit virtuel de couche 2
Le protocole d’état pseudowire TLV est utilisé pour communiquer l’état d’un pseudowire entre des routeurs PE (Provider Edge). Pour éviter les écarts potentiels entre le chemin principal, il doit exister un mécanisme permettant de synchroniser tous les éléments du réseau par rapport au chemin principal sur lequel le trafic doit être envoyé. Dans cette optique, le statut de la TLV est étendu pour répondre à cette exigence.
Le statut pseudowire TLV n’est pas pris en charge par la gamme de routeurs ACX5000.
En définissant les états actif et veille par les routeurs d’accès, Junos OS atténue les collisions potentielles sur le chemin principal, car un élément réseau unique détermine le chemin de transfert à choisir. En outre, cela permet aux opérateurs réseau de changer de chemin de transfert à la demande, ce qui est très utile pour le dépannage et la maintenance du réseau.
Les états actif et veille sont communiqués aux routeurs d’agrégation à l’aide d’un indicateur d’état pseudowire supplémentaire.
Le tableau 1 comprend une liste des drapeaux d’état pseudowire.
| Drapeau |
Code |
|---|---|
| L2CKT_PW_STATUS_PW_FWD |
0x00000000 |
| L2CKT_PW_STATUS_PW_NOT_FWD |
0x00000001 |
| L2CKT_PW_STATUS_AC_RX_FAULT |
0x00000002 |
| L2CKT_PW_STATUS_AC_TX_FAULT |
0x00000004 |
| L2CKT_PW_STATUS_PSN_RX_FAULT |
0x00000008 |
| L2CKT_PW_STATUS_PSN_TX_FAULT |
0x00000010 |
| L2CKT_PW_STATUS_PW_FWD_STDBY |
0x00000020 Indique l’état de veille. |
| L2CKT_PW_STATUS_SWITCH_OVER |
0x00000040 |
Dans les scénarios basés sur Multichassis LAG (MC-LAG), ce même indicateur PW_FWD_STDBY est utilisé pour annoncer aux périphériques PE distants quel circuit de connexion (AC) est utilisé comme actif. À l’arrivée de ce drapeau, le périphérique PE récepteur abandonne tout pseudowire construit vers le routeur à l’origine de cet état. Comme nous pouvons le voir, ce comportement indique une sémantique légèrement différente pour le drapeau PW_FWD_STDBY. Par conséquent, vous pouvez configurer l’instruction hot-standby-vc-on pour contrôler si le pseudowire doit être construit à l’arrivée de l’indicateur PW_FWD_STDBY (dans le scénario pseudowire en réserve chaude) ou simplement le détruire (dans le scénario MC-LAG).
Comment ça marche
La solution utilise des interfaces appariées de tunnel logique (lt-) pour assembler les domaines de couche 2 et de couche 3.
La figure 2 montre un diagramme illustrant le fonctionnement de la redondance pseudowire dans un scénario de backhaul mobile.
Un pseudowire de couche 2 se termine sur l’une des interfaces de tunnel logique (x), définies avec la famille d’adresses circuit cross-connect (CCC) configurée. Un VPN de couche 3 (RFC 2547) termine la deuxième interface de tunnel logique (y), définie avec la famille d’adresses IPv4 (inet). Les interfaces de tunnel logique (x) et (y) sont appariées. Les pseudowires de couche 2 établis entre chaque routeur d’accès et ses équipements PE d’agrégation correspondants se terminent sur l’interface de tunnel logique définie dans chaque équipement PE. Cette interface de tunnel logique permet d’établir un circuit virtuel (VC) de couche 2 vers l’extrémité distante. Par conséquent, la famille d’adresses CCC doit y être configurée. Il en va de même pour l’extrémité distante, où une interface équivalente doit être définie avec des capacités CCC.
Cette interface de tunnel logique CCC créée dans les équipements PE d’agrégation est couplée à une deuxième interface de tunnel logique sur laquelle la famille d’adresses INET est activée. Cette deuxième interface de tunnel logique est configurée dans le contexte d’un VPN de couche 3 RFC 2547.
Dans le cadre du présent document, nous appelons respectivement les interfaces de tunnel logique CCC et INET LT(x) et LT(y).
Le processus rpd (Routing Protocol Process) de Junos OS permet l’assemblage nécessaire pour interconnecter le VC de couche 2 se terminant par LT(x) et le LT(y) associé.
Dans les routeurs PE d’agrégation, le processus de routage construit un pseudowire vers les routeurs d’accès, et cela se produit quel que soit l’état actif ou en veille du pseudowire. La même chose se produit dans les routeurs d’accès, où l’état de contrôle et de transfert est préétabli à la fois dans le moteur de routage et dans le moteur de transfert de paquets pour atténuer les interruptions de trafic pendant les périodes de convergence.
Un circuit de connexion (CA) est un circuit physique ou virtuel (VC) qui relie un équipement CE à un équipement PE. La préférence locale est utilisée pour fournir de meilleures informations que la valeur MED (Multiple Exit Discriminator) ne fournit pour la sélection du chemin d'un paquet. Vous pouvez configurer l’attribut de préférence locale afin qu’il ait une valeur plus élevée pour les préfixes reçus d’un routeur qui fournit un chemin souhaité que les préfixes reçus d’un routeur qui fournit un chemin moins souhaitable. Plus la valeur est élevée, plus l’itinéraire est préféré. L’attribut de préférence locale est la métrique la plus souvent utilisée en pratique pour exprimer des préférences pour un ensemble de chemins par rapport à un autre.
Si le circuit de couche 2 est primaire, le périphérique PE correspondant annonce le sous-réseau du CA avec la préférence locale la plus élevée. Tous les équipements PE d’agrégation annoncent initialement le sous-réseau du CA avec la même préférence locale. Vous pouvez configurer une politique de routage pour autoriser la publication d’une valeur de préférence locale plus élevée si le VC de couche 2 est actif.
Si un pseudowire est en panne, LT(x) est marqué avec le drapeau CCC_Down. Lorsque cela se produit, l’équipement PE correspondant retire le sous-réseau CA initialement annoncé. L’adresse LT(y) est partagée entre les équipements PE d’agrégation en tant que port d’instance virtuelle (VIP). Aucun message VRRP hello n’est échangé. Les deux dispositifs PE assument le rôle principal.
Les VC de couche 2 principaux et de secours restent ouverts afin de réduire les perturbations du trafic lors des transitions de secours vers les réseaux primaires. L’instruction hot-standby-vc-on de configuration permet l’activation manuelle.
La résilience dans le domaine de couche 2 est assurée par une simple redondance pseudowire pour les connexions dos à dos. Pour les autres topologies, la vérification de la connectivité du circuit virtuel pseudowire (VCCV) est utilisée.
Résilience dans le domaine de couche 3 est fournie par MPLS reroutage rapide et la restauration des services de bout en bout. Un minuteur de restauration empêche la présence de VC dans le chemin secondaire d’être replacées sur le chemin principal immédiatement après la restauration du périphérique PE principal.
Les routeurs d’accès peuvent indiquer aux routeurs d’agrégation quel VC de couche 2 est considéré comme actif. À l'arrivée au niveau LT(x) d'un message TLV d'état communiquant un état de veille, le processus de routage diminue la valeur de préférence locale du BGP du sous-réseau direct représenté par l'adresse IPv4 LT(y). À ce stade, BGP annonce ce changement de préférence locale au reste des membres du domaine de couche 3, qui sélectionneront ensuite à nouveau le périphérique PE de redirecteur désigné en s'appuyant sur les mécanismes de sélection de chemin de BGP.
Un comportement similaire se produit à l’arrivée d’un message TLV d’état indiquant un état actif VC de couche 2. Dans ce cas, le périphérique PE récepteur modifie la préférence locale correspondant au sous-réseau du LT(y). La valeur à utiliser pour diminuer ou augmenter la valeur de préférence locale du sous-réseau est configurée manuellement à l'aide d'une stratégie.