Présentation des services de liaison et multiliens
Présentation des services Link et Multilink
Les protocoles multiliens vous permettent de diviser, recombiner et séquencer des datagrammes sur plusieurs liaisons de données logiques. L’objectif d’une opération multiliaison est de coordonner plusieurs liaisons indépendantes entre une paire fixe de systèmes, fournissant une liaison virtuelle avec une bande passante supérieure à celle de n’importe lequel des membres. En plus de fournir une bande passante incrémentielle, le regroupement de plusieurs liaisons peut ajouter un niveau de tolérance aux pannes à votre service d’accès dédié, car vous pouvez implémenter le regroupement sur plusieurs PIC, protégeant ainsi contre la défaillance d’un seul PIC.
Junos OS prend en charge plusieurs protocoles basés sur des liaisons multiples, notamment le protocole MLPPP (Multilink Point-to-Point Protocol) et le relais de trames multiliens (MLFR). MLPPP vous permet de regrouper plusieurs liens PPP en un seul lien logique. MLFR vous permet de regrouper plusieurs identificateurs de connexion de liaison de données (DLCI) du relais de trame en une seule liaison logique. Le MLPPP et le MLFR offrent une granularité d’options de service entre les services T1 et E1 à faible vitesse et les services T3 et E3 à plus grande vitesse. Vous utilisez MLPPP et MLFR pour augmenter la bande passante par incréments plus petits et plus rentables.
L’extension multiclasse de l’extension MLPPP permet plusieurs classes de service à l’aide de MLPPP. Pour plus d’informations, consultez RFC 2686, The Multi-Class Extension to Multi-Link PPP. L’implémentation PPP de Junos OS ne prend pas en charge la négociation des options NCP PPP de compression de champs d’adresses et de compression de champ de protocole. Le logiciel envoie toujours un en-tête PPP complet de 4 octets.
Normes
Les normes MLPPP, MLFR FRF.15 et MLFR FRF.16 sont définies dans les spécifications suivantes :
RFC 1990, Le protocole PPP Multilink Protocol (MP)
FRF.15, Accord de mise en œuvre du relais multilien de bout en bout
FRF.16.1, Accord de mise en œuvre UNI/NNI de relais de trames multiliens
Note:La vérification de la compatibilité de la classe de discrimination de point de terminaison est activée sur les interfaces MLPPP. Avant Junos OS version 8.0, lorsqu’un routeur Juniper Networks recevait un message Endpoint Discriminator Class non pris en charge de la part d’un pair de session MLPPP, il renvoyait une réponse ACK.
Présentation des PIC des services multiliens et de liaison
Chaque Multilink Services ou Link Services PIC peut prendre en charge un certain nombre d’offres. Un bundle peut contenir jusqu’à huit liens individuels.
Pour les PIC Multilink Services, les liens peuvent être des interfaces physiques T1, E1 ou DS0, et chaque lien est associé à un numéro d’unité logique que vous configurez. Pour les PIC Link Services, les liaisons peuvent être E1, T1, DS3 canalisées vers DS1, DS3 canalisées vers DS0, E1 canalisées, STM1 canalisées ou interfaces IQ canalisées. Pour les bundles MLFR FRF.16, chaque lien est associé à un numéro de canal que vous configurez.
Vous devez configurer un lien avant de pouvoir rejoindre un bundle. Chaque paquet devrait se composer d’un seul type de lien; Le mélange d’interfaces physiques de vitesses différentes au sein d’un bundle n’est pas pris en charge.
Trois versions de Multilink Services et trois versions des PIC Link Services sont disponibles, comme indiqué dans le tableau 1. Le matériel PIC est identique, à l’exception de différentes façades qui vous permettent d’identifier la version que vous installez. Le logiciel limite le nombre d’unités et le nombre maximal d’interfaces physiques que vous attribuez au PIC.
Capacité PIC |
Numéros d’unité |
Nombre maximal d’interfaces T1/DS0 |
Nombre maximal d’interfaces E1 |
|---|---|---|---|
PIC à 4 paquets |
0 à 3 |
32 liens |
32 liens |
PIC à 32 paquets |
0 à 31 |
256 liens |
219 liens |
PIC à 128 paquets |
0 à 127 |
292 liens |
219 liens |
Un seul PIC peut prendre en charge une bande passante agrégée de 450 mégabits par seconde (Mbit/s).
Vous pouvez configurer un plus grand nombre de liaisons, mais les ICI Multilink Services et Link Services ne peuvent traiter de manière fiable que 450 Mbit/s de trafic. Un débit de trafic plus élevé peut dégrader les performances.
Dans Junos OS versions 9.0 et ultérieures, vous n’êtes pas autorisé à configurer un numéro d’unité supérieur au numéro d’unité maximal disponible sur votre PIC de services de liaison. Si vous tentiez de le faire, un message d’erreur s’entraînerait.
Assistance sur les PIC de service
Junos OS prend en charge les protocoles basés sur des liaisons multiples sur les PIC de services tels que le PIC Multilink Services et le PIC Link Services, ainsi que sur les services de file d’attente intelligente (IQ) et les services vocaux configurés sur les PIC Adaptive Services (AS) et MultiServices. Pour plus d’informations sur l’IQ des services de liaison, consultez Layer 2 Service Package Capabilities and Interfaces. Pour plus d’informations sur les services vocaux, consultez Configuration des interfaces de services pour les services vocaux.
À partir de Junos OS version 12.1, les MIC canalisés suivants sur les routeurs MX240, MX480 et MX960 prennent en charge les services basés sur le protocole MLPPP (Multilink Point-to-Point Protocol) :
MIC SONET/SDH OC3/STM1 (multidébit) canalisé à 4 ports avec SFP (MIC-3D-4CHOC3-2CHOC12)
MIC SONET/SDH OC3/STM1 (multidébit) canalisé à 8 ports avec SFP (MIC-3D-8CHOC3-4CHOC12)
MIC DS3/E3 canalisé à 8 ports (MIC-3D-8CHDS3-E3-B)
Pour plus d’informations sur les MIC de services basés sur MLPPP, consultez Vue d’ensemble des interfaces multiliens sur les MICs canalisées.
Les PIC Link Services et Multilink Services prennent en charge les types d’encapsulation suivants :
Le
Le
À partir de Junos OS version 12.1, la prise en charge des types et protocoles d’encapsulation suivants a été étendue aux routeurs MX240, MX480 et MX960 avec des contrôleurs DPC multiservices :
Le
MLPPP multiclasse
MLFR de bout en bout (FRF.15)
MLFR UNI NNI (FRF.16) (également appelé MFR)
Protocole de transport en temps réel compressé (CRTP)
Seul MLPPP est pris en charge sur les routeurs ACX Series. MLFR n’est pas pris en charge sur les routeurs ACX Series.
Au niveau de l’unité logique, les CIO Multilink Services et Link Services prennent en charge les types d’encapsulation MLPPP et MLFR Frame Relay Forum (FRF) 15. Au niveau de l’interface physique , le PIC Link Services prend également en charge le type d’encapsulation MLFR FRF.16.
Sur les routeurs de périphérie multiservices de la série M, une seule liaison DS3 est autorisée dans un lot MLFR. Les bundles MLPPP peuvent inclure deux liens DS3.
Sur les routeurs ACX Series, même si le PIC peut prendre en charge jusqu’à 4xDS3 de débit total, chaque agrégat ne peut exécuter qu’un volume de trafic égal à un DS3 en bande passante. L’agrégation de liens DS3 n’est pas prise en charge.
Prise en charge des types d’interfaces
MLPPP et MLFR FRF.15 sont pris en charge sur les types ml-fpc/pic/portd’interface , ls-fpc/pic/portet lsq-fpc/pic/port. Pour MLFR FRF.15, plusieurs circuits virtuels permanents (PVC) sont combinés en un circuit virtuel agrégé (AVC). Cela permet de fragmenter plusieurs PVC à une extrémité et de réassembler l’AVC à l’autre extrémité.
MLFR FRF.16 est pris en charge sur une interface canalisée, ls-fpc/pic/port:channelce qui désigne un seul bundle MLFR FRF.16. Pour MLFR FRF.16, plusieurs liens sont combinés pour former un seul lien logique. La fragmentation et le réassemblage des paquets se produisent sur une base par VC. Chaque offre groupée peut prendre en charge plusieurs VC. Services de liaison Les PIC peuvent prendre en charge jusqu’à 256 DLCI par offre groupée MLFR FRF.16. Les connexions physiques doivent être E1, T1, DS3-to-DS1 canalisées, DS3-to-DS0 canalisées, E1 canalisées, STM1 canalisées ou interfaces IQ canalisées. Lorsque vous regroupez des interfaces canalisées à l’aide de l’interface de services de liaison, les interfaces canalisées nécessitent des concentrateurs PIC flexibles (FPC) améliorés de la série M.
Le ml- type d’interface est utilisé pour configurer les interfaces sur le PIC Multilink Services et ne prend pas en charge les fonctionnalités de classe de service (CoS). Le ls- type d’interface est utilisé pour les configurations CoS limitées sur le PIC Link Services, et le type d’interface est utilisé pour les lsq- configurations CoS complètes sur les PIC Adaptive Services et MultiServices. Les interfaces de bundle sont configurées sur le DPC Multiservices en tant qu’interfaces Link Services IQ (lsq) et Virtual LSQ Redundancy (rlsq).
Pour les interfaces IQ (lsq), les composants CoS de Junos OS sont entièrement pris en charge et gérés normalement sur les routeurs M Series et T Series, comme décrit dans le Guide de l’utilisateur de la classe de service Junos OS pour les périphériques de routage. Pour plus d’informations sur la configuration IQ des services de liaison, consultez Layer 2 Service Package Capabilities and Interfaces.
Lorsque vous exécutez MLPPP ou MLFR sur une interface non-QPP, vous ne pouvez pas mélanger des unités logiques membres d’un agrégat avec des unités logiques configurées à l’aide d’autres familles, telles que inet. Par exemple, la configuration suivante n’est pas valide :
interface e3-0/0/0 {
encapsulation frame-relay;
unit 99 {
dlci 99;
family mlfr-end-to-end {
bundle ls-0/0/0.1;
}
}
unit 100 { ## mixes mlfr with family inet
dlci 100;
family inet {
address 192.168.164.53/30;
}
}
}
Voir aussi
Présentation des interfaces multiliens sur les MICs canalisés
Les cartes d’interface modulaires (MIC) multiservices vous permettent d’exécuter plusieurs services sur le même MIC en configurant un ensemble de services et d’applications tels que les services vocaux et les services L2TP (Layer 2 Tunneling Protocol). Sur les plates-formes de routage universelles 5G MX Series de Juniper Networks, le DPC multiservices offre essentiellement les mêmes fonctionnalités que le PIC multiservices. Les interfaces des deux plates-formes sont configurées de la même manière. Les interfaces Multilink sont hébergées sur un MIC canalisé. Les interfaces groupées sont configurées sur Multiservices DPC en tant qu’interfaces de redondance LSQ virtuelle (rlsq).
À partir de Junos OS version 12.1, les MIC canalisés suivants sur les routeurs MX240, MX480 et MX960 prennent en charge les services basés sur le protocole MLPPP (Multilink Point-to-Point Protocol) :
MIC SONET/SDH OC3/STM1 (multidébit) canalisé à 4 ports avec SFP (MIC-3D-4CHOC3-2CHOC12)
MIC SONET/SDH OC3/STM1 (multidébit) canalisé à 8 ports avec SFP (MIC-3D-8CHOC3-4CHOC12)
MIC DS3/E3 canalisé à 8 ports (MIC-3D-8CHDS3-E3-B)
Les encapsulations, interfaces, protocoles et types de paquets suivants sont pris en charge sur les MIC susmentionnés :
Multilink Point-to-Point Protocol (MLPPP) : prend en charge le contrôle de flux basé sur les priorités (PFC) pour les paquets de données et le protocole LCP (Link Control Protocol) pour les paquets de contrôle. Le protocole CRTP (Compressed Real-Time Transport Protocol) et le MLPPP multiclasse sont pris en charge pour les paquets de données et de contrôle.
Multilink Frame Relay (MLFR) end-to-end (FRF.15) : prend en charge l’interface de gestion locale Ethernet (LMI), le Consortium LMI (C-LMI) et le protocole LIP (Link Integrity Protocol) pour les paquets de données et de contrôle.
Multilink Frame Relay (MFR) UNI NNI (FRF.16) : prend en charge l’interface de gestion locale Ethernet (LMI), le Consortium LMI (C-LMI) et le protocole LIP (Link Integrity Protocol) pour les paquets de données et de contrôle.
Paquets MLPPP et MLFR non multiliens LFI (Link fragmentation and interlacing).
Les services de couche 2 et les fonctionnalités de services vocaux sont implémentés sur les concentrateurs de ports denses multiservices, qui prennent en charge les deux types de trafic suivants qui sont routés par le moteur de transfert de paquets :
Customer-end to provider-end (également appelé trafic client) : ici, les fragments Multilink du client arrivent aux interfaces multiservices configurées sur le MIC canalisé. Ces fragments sont ensuite transmis au DPC Multiservices pour un traitement de couche 2 tel que CoS et sont réassemblés par le logiciel Multiservices fonctionnant sur le DPC Multiservices. Ces paquets réassemblés sont envoyés au moteur de transfert de paquets où ils passent par le processus de recherche de routeur normal et sont finalement envoyés via Internet au fournisseur. Les paquets vocaux passent également par le même processus.
Provider-end to customer-end (également appelé trafic Internet) : ici, les paquets de données envoyés par le fournisseur Internet sont reçus via n’importe quelle interface d’entrée générique dans le moteur de transfert de paquets. Ces paquets sont ensuite envoyés au DPC Multiservices pour traitement de couche 2. Le logiciel Multiservices exécuté sur Multiservices DPC fragmente ces paquets de données et les envoie au moteur de transfert de paquets. Ces fragments Multilink sont envoyés au client via les interfaces MIC canalisées. Les paquets vocaux passent également par le même processus.
Toutes les fonctionnalités prises en charge sur les PIC Multilink et Link Services le sont également sur les MIC Multilink Services ou Link Services. Pour plus d’informations sur les PIC Multilink et Link Services, consultez Vue d’ensemble des PIC Multilink and Link Services.
La prise en charge des encapsulations, interfaces, protocoles et types de paquets suivants est désormais étendue aux MIC susmentionnés :
Multilink Point-to-Point Protocol (MLPPP) : prend en charge le contrôle de flux basé sur les priorités (PFC) pour les paquets de données et le protocole de contrôle de liaison (LCP) pour les paquets de contrôle. Le protocole CRTP (Compressed Real-Time Transport Protocol) et le MLPPP multiclasse sont pris en charge pour les paquets de données et de contrôle.
Multilink Frame Relay (MLFR) end-to-end (FRF.15) : prend en charge l’interface de gestion locale Ethernet (LMI) et le Consortium LMI (C-LMI) pour les paquets de données et de contrôle.
Multilink Frame Relay (MLFR) UNI NNI (FRF.16) : prend en charge l’interface de gestion locale Ethernet (LMI), le Consortium LMI (C-LMI) et le protocole LIP (Link Integrity Protocol) pour les paquets de données et de contrôle.
Fragmentation et entrelacement des liens (LFI) sur les paquets MLPPP et MLFR multiliens : réduit les retards et la gigue sur les liaisons en divisant les gros paquets de données et en entrelaçant les paquets vocaux sensibles au délai avec les paquets plus petits qui en résultent.