Services de liaison multiple en ligne

Pour le multiplexage temporel (TDM), les interfaces MLPPP (Multilink Frame Relay), Multilink Frame Relay (FRF.16) et Multilink Frame Relay End-to-End (FRF.15) pour le multiplexage temporel (WAN), fournissent des services de groupage via le moteur de transfert de paquets sans nécessiter de PIC ou de concentracteur de port dense (DPC).

Traditionnellement, les services groupés sont utilisés pour regrouper plusieurs liaisons à faible débit afin de créer un canal à bande passante plus élevée. Cette bande passante combinée est disponible pour le trafic de toutes les liaisons et prend en charge la fragmentation et l’entrelacement des liaisons (LFI) sur le paquet, réduisant ainsi le délai de transmission des paquets prioritaires.

Cette prise en charge inclut plusieurs liaisons sur le même bundle ainsi qu’une extension multiclasse pour MLPPP. Grâce à ce service, vous pouvez activer le regroupement de services sans emplacements DPC supplémentaires pour prendre en charge Service DPC et libérer des emplacements pour d’autres MIC.

Remarque :

MLPPP n’est pas pris en charge sur Virtual Chassis MX Series.

À partir de Junos OS version 15.1, vous pouvez configurer des interfaces MLPPP en ligne sur les routeurs MX80, MX104, MX240, MX480 et MX960 à l’aide de MIC d’émulation de circuit E1/T1 multiplexées. Un maximum de huit bundles d’interfaces MLPPP en ligne sont pris en charge sur les MIC d’émulation de circuit E1/T1 canalisées, de la même manière que les bundles MLPPP en ligne sur d’autres MIC avec lesquelles ils sont compatibles.

La configuration du MLPPP en ligne pour les interfaces WAN offre les services suivants :

• Liaison CE-PE pour les services VPN et DIA de couche 3 avec des réseaux d’accès basés sur les réseaux téléphoniques publics commutés (RTPC).

• Liaison PE-P lorsque le RTPC est utilisé pour les réseaux MPLS.

Cette fonctionnalité est utilisée par les fournisseurs de services suivants :

• Les fournisseurs de services qui utilisent le RTPC pour offrir des services VPN et DIA de couche 3 avec des réseaux d’accès basés sur le RTC aux moyennes ou grandes entreprises.

• Les fournisseurs de services avec des réseaux centraux basés sur SONET.

La figure suivante illustre la portée de cette fonctionnalité :

Pour connecter de nombreux sites plus petits dans des VPN, le regroupement des circuits TDM avec la technologie MLPPP/MLFR est le seul moyen d’offrir une meilleure bande passante et une meilleure redondance des liens.

Le MLPPP vous permet de regrouper plusieurs liaisons PPP en un seul bundle multilink, et le MLFR vous permet de regrouper plusieurs identifiants de connexion de liaison de données (DLCI) Frame Relay en un seul bundle multilink. Les offres groupées Multilink fournissent une bande passante, un équilibrage de charge et une redondance supplémentaires en agrégeant des liaisons à faible débit, telles que les liaisons T1, E1 et série.

Le MLPPP est un protocole permettant d’agréger plusieurs liaisons constitutives en un ensemble PPP plus important. Le MLFR permet d’agréger plusieurs liaisons Frame Relay par multiplexage inverse. Le MLPPP et le MLFR offrent des options de service entre les services T1 et E1 à faible débit. En plus de fournir une bande passante supplémentaire, le regroupement de plusieurs liens peut ajouter un niveau de tolérance de panne à votre service d’accès dédié. Comme vous pouvez mettre en œuvre le regroupement sur plusieurs interfaces, vous pouvez protéger les utilisateurs contre la perte d’accès en cas de défaillance d’une seule interface.

Pour configurer MLPPP en ligne pour les interfaces WAN, consultez :

• Exemple : configuration du MLPPP en ligne et du relais de trame multiliaison de bout en bout (FRF.15) pour les interfaces WAN

• Exemple : Configuration du relais de trame multiliaison en ligne (FRF.16) pour les interfaces WAN

Une surcharge de couche de liaison peut entraîner la perte de paquets sur les liaisons constitutives en raison du bit-stuffing sur les liaisons série. Le bit stuffing est utilisé pour empêcher que les données ne soient interprétées comme des informations de contrôle.

Par défaut, 4 % de la bande passante totale des offres groupées est réservée à la surcharge de couche de liaison. Dans la plupart des environnements réseau, le surcoût moyen de couche de liaison est de 1,6 %. Par conséquent, nous recommandons 4 % comme mesure de protection. Pour plus d’informations, consultez RFC 4814, Hachage et bourrage : facteurs négligés dans l’analyse comparative des périphériques réseau.

Pour les interfaces IQ (lsq-) de services de liaison, vous pouvez configurer le pourcentage de bande passante des offres groupées à réserver pour la surcharge de la couche de liaison. Pour ce faire, incluez l’affirmation link-layer-overhead :

Vous pouvez inclure cette déclaration aux niveaux hiérarchiques suivants :

• [edit interfaces interface-name mlfr-uni-nni-bundle-options]

• [edit interfaces interface-name unit logical-unit-number]

• [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number]

Vous pouvez configurer la valeur pour qu’elle soit comprise entre 0 % et 50 %.

Pour configurer un Nbundle xT1 à l’aide de MLPPP, vous agrégez N différentes liaisons T1 dans un bundle. Le Nbundle xT1 est appelé interface logique, car il peut représenter, par exemple, une adjacence de routage. Pour agréger des liens T1 dans un bundle MLPPP, incluez l’instruction bundle au niveau de la [edit interfaces t1-fpc/pic/port unit logical-unit-number family mlppp] hiérarchie :

Remarque :

Services de liaison Les interfaces IQ prennent en charge les interfaces physiques T1 et E1. Ces instructions s’appliquent aux interfaces T1, mais la configuration des interfaces E1 est similaire.

Pour configurer les propriétés de l’interface IQ des services de liaison, incluez les instructions suivantes au niveau de la [edit interfaces lsq-fpc/pic/port unit logical-unit-number] hiérarchie :

Remarque :

Les routeurs ACX Series ne prennent pas en charge les propriétés de délai d’abandon et de surcharge de couche de lien.

L’interface IQ des services de liaison logique représente l’offre groupée MLPPP. Pour l’offre groupée MLPPP, il existe quatre files d’attente associées sur les routeurs M Series et huit files d’attente associées sur les routeurs M320 et T Series. Un planificateur supprime des paquets des files d’attente conformément à une stratégie de planification. En règle générale, vous désignez une file d’attente avec une priorité stricte, et les files d’attente restantes sont traitées proportionnellement aux pondérations que vous configurez.

Pour MLPPP, attribuez un mappage de planificateur unique à l’interface IQ des services de liaison (lsq) et à chaque lien constitutif. Les planificateurs par défaut des routeurs M Series et T Series, qui attribuent 95, 0, 0 et 5 % de bande passante au débit de transmission et à la taille de mémoire tampon des files d’attente 0, 1, 2 et 3, ne sont pas adéquats lorsque vous configurez le trafic LFI ou multiclasse. Par conséquent, pour MLPPP, vous devez configurer un planificateur unique avec des taux de transmission et des tailles de mémoire tampon non nuls pour les files d’attente 0 à 3, et affecter ce planificateur à l’interface IQ des services de liaison (lsq) et à chaque liaison constitutive, comme indiqué dans Exemple : configuration d’une interface LSQ en tant qu’offre groupée NxT1 à l’aide de MLPPP.

Remarque :

Pour les routeurs M320 et T Series, le taux de transmission du planificateur par défaut et les pourcentages de taille de mémoire tampon pour les files d’attente 0 à 7 sont de 95, 0, 0, 0, 5, 0, 0, 0 et 0 %.

Si le lien membre appartenant à une interface de bundle MLPP, MLFR ou MFR est déplacé vers une autre interface de bundle, ou si les liens sont échangés entre deux interfaces de bundle, une validation est nécessaire entre les opérations de suppression et d’ajout pour s’assurer que la configuration est appliquée correctement.

Si l’offre groupée comporte plusieurs liaisons, vous devez inclure l’instruction per-unit-scheduler au niveau de la [edit interfaces lsq-fpc/pic/port] hiérarchie :

Pour configurer et appliquer la stratégie de planification, incluez les instructions suivantes au niveau de la [edit class-of-service] hiérarchie :

Pour les interfaces IQ de services de liaison, une file d’attente de haute priorité stricte peut affamer les trois autres files d’attente, car le trafic d’une file d’attente de haute priorité stricte est transmis avant toute autre file d’attente. Cette implémentation diffère de l’implémentation Junos CoS standard dans laquelle une file d’attente stricte à haute priorité effectue un tourniquet avec des files d’attente à haute priorité, comme décrit dans le Guide de l’utilisateur de la classe de service (routeurs et commutateurs EX9200).

Une fois que le planificateur a supprimé un paquet d’une file d’attente, une certaine action est entreprise. L’action varie selon que le paquet provient d’une file d’attente encapsulée multiliaison (fragmentée et séquencée) ou d’une file d’attente non encapsulée (hachée sans fragmentation). Chaque file d’attente peut être désignée comme étant encapsulée ou non encapsulée pour plusieurs liaisons, indépendamment de l’autre. Par défaut, le trafic de toutes les classes de transfert est encapsulé sur plusieurs liaisons. Pour configurer la gestion de la fragmentation des paquets dans une file d’attente, incluez l’instruction fragmentation-maps au niveau de la [edit class-of-service] hiérarchie :

Pour Nles bundles xT1 utilisant MLPPP, l’équilibrage de charge octet utilisé dans les files d’attente encapsulées multi-liens est supérieur à l’équilibrage de charge par flux utilisé dans les files d’attente non encapsulées. Toutes les autres considérations sont égales. Par conséquent, nous vous recommandons de configurer toutes les files d’attente pour qu’elles soient encapsulées sur plusieurs liens. Pour ce faire, vous devez inclure l’instruction fragment-threshold dans la configuration. Si vous choisissez de définir le trafic sur une file d’attente pour qu’il soit non encapsulé plutôt que encapsulé par liaison multiple, incluez l’instruction no-fragmentation dans la carte de fragmentation. Vous utilisez l’instruction multilink-class pour mapper une classe de transfert dans un MLPPP multiclasse (MCML). . Pour plus d’informations sur les mappages de fragmentation, consultez Configuration de la fragmentation CoS par classe de transfert sur les interfaces LSQ.

Lorsqu’un paquet est retiré d’une file d’attente encapsulée en plusieurs liens, le logiciel lui attribue un en-tête MLPPP. L’en-tête MLPPP contient un champ de numéro de séquence, qui est rempli avec le numéro de séquence disponible suivant d’un compteur. Le logiciel place ensuite le paquet sur l’une N des différentes liaisons T1. La liaison est choisie paquet par paquet pour équilibrer la charge entre les différentes liaisons T1.

Si le paquet dépasse le MTU de liaison minimal ou si un seuil de fragments est configuré au niveau hiérarchique [edit class-of-service fragmentation-maps map-name forwarding-class class-name] d’une file d’attente, le logiciel divise le paquet en deux fragments ou plus, auxquels sont attribués des numéros de séquence multiliens consécutifs. Le lien sortant pour chaque fragment est sélectionné indépendamment de tous les autres fragments.

Si vous n’incluez pas l’instruction fragment-threshold dans le mappage de fragmentation, le seuil de fragmentation que vous définissez au niveau de la [edit interfaces interface-name unit logical-unit-number] hiérarchie est le seuil par défaut pour toutes les classes de transfert. Si vous ne définissez aucune taille maximale de fragment dans la configuration, les paquets sont fragmentés s’ils dépassent la plus petite MTU de tous les liens du lot.

Même si vous ne définissez pas de taille de fragment maximale dans la configuration, vous pouvez configurer l’unité reconstruite reçue maximale (MRRU) en incluant l’instruction mrru au niveau de la [edit interfaces lsq-fpc/pic/port unit logical-unit-number] hiérarchie. La MRRU est similaire à la MTU, mais spécifique aux interfaces de services de liaison. Par défaut, la taille de la MRRU est de 1500 octets et vous pouvez la configurer pour qu’elle soit de 1500 à 4500 octets. Pour plus d’informations, reportez-vous à la section Configuration de MRRU sur les interfaces logiques multiliaison et de services de liaison.

Lorsqu’un paquet est retiré d’une file d’attente non encapsulée, il est transmis avec un en-tête PPP simple. Comme il n’y a pas d’en-tête MLPPP, il n’y a pas d’informations de numéro de séquence. Par conséquent, le logiciel doit prendre des mesures spéciales pour éviter de réordonnancer les paquets. Pour éviter la réorganisation des paquets, le logiciel place le paquet sur l’une N des différentes liaisons T1. Le lien est déterminé en hachant les valeurs de l’en-tête. Pour l’IP, le logiciel calcule le hachage en fonction de l’adresse source, de l’adresse de destination et du protocole IP. Pour le MPLS, le logiciel calcule le hachage en fonction d’un maximum de cinq étiquettes MPLS, ou de quatre étiquettes MPLS et de l’en-tête IP.

Pour UDP et TCP, le logiciel calcule le hachage en fonction des ports source et de destination, ainsi que des adresses IP source et de destination. Cela garantit que tous les paquets appartenant au même flux TCP/UDP passent toujours par la même liaison T1 et ne peuvent donc pas être réorganisés. Cependant, elle ne garantit pas que la charge sur les différentes liaisons T1 est équilibrée. S’il y a beaucoup de flux, la charge est généralement équilibrée.

Les N différentes interfaces T1 sont liées à un autre routeur, qui peut provenir de Juniper Networks ou d’un autre fournisseur. Le routeur à l’extrémité distant rassemble les paquets de toutes les liaisons T1. Si un paquet a un en-tête MLPPP, le champ Numéro de séquence est utilisé pour remettre le paquet dans l’ordre des numéros de séquence. Si le paquet a un en-tête PPP simple, le logiciel accepte le paquet dans l’ordre dans lequel il arrive et ne tente pas de le réassembler ou de le réorganiser.

Pour configurer une Noffre groupée xT1 à l’aide de FRF.16, vous agrégez N différentes liaisons T1 dans une offre groupée. L’offre NxT1 contient un nombre potentiellement important de circuits intégrés virtuels (PVC) Frame Relay, identifiés par leurs DLCI. Chaque DLCI est appelé interface logique, car il peut représenter, par exemple, une adjacence de routage.

Pour agréger des liens T1 dans un bundle FRF.16, incluez l’instruction mlfr-uni-nni-bundles au niveau de la [edit chassis fpc slot-number pic slot-number] hiérarchie et incluez l’instruction bundle au niveau de la [edit interfaces t1-fpc/pic/port unit logical-unit-number family mlfr-uni-nni] hiérarchie :

Remarque :

Services de liaison Les interfaces IQ prennent en charge les interfaces physiques T1 et E1. Ces instructions s’appliquent aux interfaces T1, mais la configuration des interfaces E1 est similaire.

Pour configurer les propriétés de l’interface IQ des services de liaison, incluez les instructions suivantes au niveau de la [edit interfaces lsq- fpc/pic/port:channel] hiérarchie :

Le canal IQ de services de liaison représente le bundle FRF.16. Quatre files d’attente sont associées à chaque DLCI. Un planificateur supprime des paquets des files d’attente conformément à une stratégie de planification. Sur l’interface de Link Services IQ, vous désignez généralement une file d’attente à priorité stricte. Les files d’attente restantes sont gérées proportionnellement aux pondérations que vous configurez.

Pour les interfaces IQ de services de liaison, une file d’attente de haute priorité stricte peut affamer les trois autres files d’attente, car le trafic d’une file d’attente de haute priorité stricte est transmis avant toute autre file d’attente. Cette implémentation diffère de l’implémentation Junos CoS standard dans laquelle une file d’attente stricte à haute priorité effectue un tourniquet avec des files d’attente à haute priorité, comme décrit dans le Guide de l’utilisateur de la classe de service (routeurs et commutateurs EX9200).

Si l’offre groupée comporte plusieurs liaisons, vous devez inclure l’instruction per-unit-scheduler au niveau de la [edit interfaces lsq-fpc/pic/port:channel] hiérarchie :

Pour FRF.16, vous pouvez affecter un seul mappage de planificateur à l’interface IQ des services de liaison (lsq) et à chaque DLCI IQ des services de liaison, ou vous pouvez affecter différents mappages de planificateur aux différents DLCI du bundle, comme indiqué dans Exemple : configuration d’une interface LSQ en tant que bundle NxT1 à l’aide de FRF.16.

Pour les liens constitutifs d’un bundle FRF.16, vous n’avez pas besoin de configurer un planificateur personnalisé. Étant donné que LFI et multiclasse ne sont pas pris en charge pour FRF.16, le trafic de chaque liaison constitutive est transmis à partir de la file 0. Cela signifie que vous devez autoriser la majeure partie de la bande passante à être utilisée par la file d’attente 0. Pour les routeurs M Series et T Series, le taux de transmission et les pourcentages de taille de mémoire tampon des planificateurs par défaut pour les files d’attente 0 à 3 sont de 95, 0, 0 et 5 %. Ces planificateurs par défaut envoient tout le trafic utilisateur à la file 0 et tout le trafic de contrôle réseau à la file d’attente 3, et sont donc bien adaptés au comportement de FRF.16. Si vous le souhaitez, vous pouvez configurer un planificateur personnalisé qui reproduit explicitement le comportement de file d’attente de 95, 0, 0 et 5 % et l’appliquer aux liens constitutifs.

Remarque :

Pour les routeurs M320 et T Series, le taux de transmission du planificateur par défaut et les pourcentages de taille de mémoire tampon pour les files d’attente 0 à 7 sont de 95, 0, 0, 0, 5, 0, 0, 0 et 0 %.

Si le lien membre appartenant à une interface de bundle MLPP, MLFR ou MFR est déplacé vers une autre interface de bundle, ou si les liens sont échangés entre deux interfaces de bundle, une validation est nécessaire entre les opérations de suppression et d’ajout pour s’assurer que la configuration est appliquée correctement.

Pour configurer et appliquer la stratégie de planification, incluez les instructions suivantes au niveau de la [edit class-of-service] hiérarchie :

Pour configurer la gestion de la fragmentation des paquets dans une file d’attente, incluez l’instruction fragmentation-maps au niveau de la [edit class-of-service] hiérarchie :

Pour le trafic FRF.16, seules les files d’attente encapsulées à liaisons multiples (fragmentées et séquencées) sont prises en charge. Il s’agit du comportement de file d’attente par défaut pour toutes les classes de transfert. FRF.16 n’autorise pas le trafic non encapsulé, car le protocole exige que tous les paquets portent l’en-tête de fragmentation. Si un paquet volumineux est divisé en plusieurs fragments, les fragments doivent avoir des numéros séquentiels consécutifs. Par conséquent, vous ne pouvez pas inclure l’instruction no-fragmentation au niveau de la hiérarchie pour le [edit class-of-service fragmentation-maps map-name forwarding-class class-name] trafic FRF.16. Pour FRF.16, si vous souhaitez transporter de la voix ou tout autre trafic sensible à la latence, vous ne devez pas utiliser de liens lents. À des vitesses T1 et supérieures, le délai de sérialisation est suffisamment petit pour que vous n’ayez pas besoin d’utiliser LFI explicite.

Lorsqu’un paquet est retiré d’une file d’attente encapsulée en plusieurs liens, le logiciel lui attribue un en-tête FRF.16. L’en-tête FRF.16 contient un champ de numéro de séquence, qui est rempli avec le numéro de séquence disponible suivant d’un compteur. Le logiciel place ensuite le paquet sur l’une N des différentes liaisons T1. La liaison est choisie paquet par paquet pour équilibrer la charge entre les différentes liaisons T1.

Si le paquet dépasse le MTU de liaison minimal ou si un seuil de fragments est configuré au niveau hiérarchique [edit class-of-service fragmentation-maps map-name forwarding-class class-name] d’une file d’attente, le logiciel divise le paquet en deux fragments ou plus, auxquels sont attribués des numéros de séquence multiliens consécutifs. Le lien sortant pour chaque fragment est sélectionné indépendamment de tous les autres fragments.

Si vous n’incluez pas l’instruction fragment-threshold dans le mappage de fragmentation, le seuil de fragmentation que vous définissez au niveau de la [edit interfaces interface-name unit logical-unit-number] hiérarchie ou [edit interfaces interface-name mlfr-uni-nni-bundle-options] est le seuil par défaut pour toutes les classes de transfert. Si vous ne définissez aucune taille maximale de fragment dans la configuration, les paquets sont fragmentés s’ils dépassent la plus petite MTU de tous les liens du lot.

Même si vous ne définissez pas de taille de fragment maximale dans la configuration, vous pouvez configurer l’unité reconstruite reçue maximale (MRRU) en incluant l’instruction mrru au niveau de la [edit interfaces lsq-fpc/pic/port unit logical-unit-number] hiérarchie ou [edit interfaces interface-name mlfr-uni-nni-bundle-options] . La MRRU est similaire à la MTU, mais elle est spécifique aux interfaces de services de liaison. Par défaut, la taille de la MRRU est de 1500 octets et vous pouvez la configurer pour qu’elle soit comprise entre 1500 et 4500 octets. Pour plus d’informations, reportez-vous à la section Configuration de MRRU sur les interfaces logiques multiliaison et de services de liaison.

Les N différentes interfaces T1 sont liées à un autre routeur, qui peut provenir de Juniper Networks ou d’un autre fournisseur. Le routeur à l’extrémité distant rassemble les paquets de toutes les liaisons T1. Comme chaque paquet a un en-tête FRF.16, le champ de numéro de séquence est utilisé pour remettre le paquet dans l’ordre du numéro de séquence.

Cet exemple configure une Noffre groupée xT1 à l’aide de FRF.15 sur une interface IQ de services de liaison. FRF.15 est similaire à FRF.12, comme décrit dans Configuration des interfaces LSQ pour des interfaces T1 ou E1 fractionnelles uniques à l’aide de FRF.12. La différence est que FRF.15 prend en charge plusieurs liens physiques dans un bundle, alors que FRF.12 ne prend en charge qu’un seul lien physique par bundle. Pour l’implémentation Junos OS de FRF.15, vous pouvez configurer un DLCI par liaison physique.

Remarque :

Services de liaison Les interfaces IQ prennent en charge les interfaces physiques T1 et E1. Cet exemple fait référence aux interfaces T1, mais la configuration des interfaces E1 est similaire.

Lorsque vous configurez une seule interface T1 fractionnaire, elle est appelée interface logique, car elle peut représenter, par exemple, une adjacence de routage.

L’interface IQ des services de liaison logique représente l’offre groupée MLPPP. Quatre files d’attente sont associées à l’interface logique. Un planificateur supprime des paquets des files d’attente conformément à une stratégie de planification. En règle générale, vous désignez une file d’attente avec une priorité stricte, et les files d’attente restantes sont traitées proportionnellement aux pondérations que vous configurez.

Pour configurer une seule interface T1 fractionnée à l’aide de MLPPP et LFI, vous devez associer une interface DS0 (T1 fractionnaire) à une interface IQ de services de liaison. Pour associer une interface T1 fractionnée à une interface IQ de services de liaison, incluez l’affirmation bundle au niveau de la [edit interfaces ds-fpc/pic/port:channel unit logical-unit-number family mlppp] hiérarchie :

Remarque :

Services de liaison Les interfaces IQ prennent en charge les interfaces physiques T1 et E1. Ces instructions s’appliquent aux interfaces T1, mais la configuration des interfaces E1 est similaire.

Pour configurer les propriétés de l’interface IQ des services de liaison, incluez les instructions suivantes au niveau de la [edit interfaces lsq-fpc/pic/port unit logical-unit-number] hiérarchie :

Pour MLPPP, attribuez un mappage de planificateur unique à l’interface Link Services IQ (lsq) et à chaque lien constitutif. Les planificateurs par défaut des routeurs M Series et T Series, qui attribuent 95, 0, 0 et 5 % de bande passante au débit de transmission et à la taille de mémoire tampon des files d’attente 0, 1, 2 et 3, ne sont pas adéquats lorsque vous configurez le trafic LFI ou multiclasse. Par conséquent, pour MLPPP, vous devez configurer un planificateur unique avec des débits de transmission et des tailles de mémoire tampon non nuls pour les files d’attente 0 à 3, et affecter ce planificateur à l’interface IQ (lsq) des services de liaison et à chaque liaison constitutive, comme indiqué dans Exemple : configuration d’une interface LSQ pour une interface T1 fractionnée à l’aide de MLPPP et LFI.

Remarque :

Pour les routeurs M320 et T Series, le taux de transmission du planificateur par défaut et les pourcentages de taille de mémoire tampon pour les files d’attente 0 à 7 sont de 95, 0, 0, 0, 5, 0, 0, 0 et 0 %.

Pour configurer et appliquer la stratégie de planification, incluez les instructions suivantes au niveau de la [edit class-of-service] hiérarchie :

Pour les interfaces IQ de services de liaison, une file d’attente de haute priorité stricte peut affamer toutes les autres files d’attente, car le trafic d’une file d’attente de haute priorité stricte est transmis avant toute autre file d’attente. Cette implémentation diffère de l’implémentation CoS standard de Junos, dans laquelle une file d’attente stricte à haute priorité reçoit des crédits infinis et effectue un tourniquet avec des files d’attente à haute priorité, comme décrit dans le Guide de l’utilisateur sur la classe de service (routeurs et commutateurs EX9200).

Une fois que le planificateur a supprimé un paquet d’une file d’attente, une certaine action est entreprise. L’action varie selon que le paquet provient d’une file d’attente encapsulée multiliaison (fragmentée et séquencée) ou d’une file d’attente non encapsulée (hachée sans fragmentation). Chaque file d’attente peut être désignée comme étant encapsulée ou non encapsulée pour plusieurs liaisons, indépendamment de l’autre. Par défaut, le trafic de toutes les classes de transfert est encapsulé sur plusieurs liaisons. Pour configurer la gestion de la fragmentation des paquets dans une file d’attente, incluez l’instruction fragmentation-maps au niveau de la [edit class-of-service] hiérarchie :

Si vous avez besoin que la file d’attente transmette de petits paquets avec une faible latence, configurez la file d’attente pour qu’elle soit non encapsulée en incluant l’instruction no-fragmentation . Si vous avez besoin que la file d’attente transmette des paquets volumineux avec une latence normale, configurez la file d’attente pour qu’elle soit encapsulée sur plusieurs liaisons en incluant l’instruction fragment-threshold . Si vous avez besoin que la file d’attente transmette des paquets volumineux avec une faible latence, nous vous recommandons d’utiliser une liaison plus rapide et de configurer la file d’attente pour qu’elle ne soit pas encapsulée. Pour plus d’informations sur les mappages de fragmentation, consultez Configuration de la fragmentation CoS par classe de transfert sur les interfaces LSQ.

Lorsqu’un paquet est retiré d’une file d’attente encapsulée en plusieurs liens, il est fragmenté. Si le paquet dépasse le MTU de liaison minimal ou si un seuil de fragments est configuré au niveau hiérarchique [edit class-of-service fragmentation-maps map-name forwarding-class class-name] d’une file d’attente, le logiciel divise le paquet en deux fragments ou plus, auxquels sont attribués des numéros de séquence multiliens consécutifs.

Si vous n’incluez pas l’instruction fragment-threshold dans le mappage de fragmentation, le seuil de fragmentation que vous définissez au niveau de la [edit interfaces interface-name unit logical-unit-number] hiérarchie est le seuil par défaut pour toutes les classes de transfert. Si vous ne définissez aucune taille maximale de fragment dans la configuration, les paquets sont fragmentés s’ils dépassent la plus petite MTU de tous les liens du lot.

Même si vous ne définissez pas de taille de fragment maximale dans la configuration, vous pouvez configurer l’unité reconstruite reçue maximale (MRRU) en incluant l’instruction mrru au niveau de la [edit interfaces lsq-fpc/pic/port unit logical-unit-number] hiérarchie. La MRRU est similaire à la MTU, mais spécifique aux interfaces de services de liaison. Par défaut, la taille de la MRRU est de 1500 octets et vous pouvez la configurer pour qu’elle soit de 1500 à 4500 octets. Pour plus d’informations, reportez-vous à la section Configuration de MRRU sur les interfaces logiques multiliaison et de services de liaison.

Lorsqu’un paquet est retiré d’une file d’attente encapsulée en plusieurs liens, le logiciel lui attribue un en-tête MLPPP. L’en-tête MLPPP contient un champ de numéro de séquence, qui est rempli avec le numéro de séquence disponible suivant d’un compteur. Le logiciel place ensuite le paquet sur la liaison T1 fractionnaire. Le trafic d’une autre file d’attente peut être entrelacé entre deux fragments du paquet.

Lorsqu’un paquet est retiré d’une file d’attente non encapsulée, il est transmis avec un en-tête PPP simple. Le paquet est ensuite placé sur la liaison T1 fractionnaire dès que possible. Si nécessaire, le paquet est placé entre les fragments d’un paquet d’une autre file d’attente.

L’interface T1 fractionnée est liée à un autre routeur, qui peut provenir de Juniper Networks ou d’un autre fournisseur. Le routeur à l’extrémité distant collecte les paquets de la liaison T1 fractionnée. Si un paquet a un en-tête MLPPP, le logiciel suppose que le paquet est un fragment d’un paquet plus grand, et le champ du numéro de fragment est utilisé pour réassembler le paquet plus grand. Si le paquet a un en-tête PPP simple, le logiciel accepte le paquet dans l’ordre dans lequel il arrive et le logiciel ne tente pas de le réassembler ou de le réorganiser.

Pour configurer une seule interface T1 fractionnée à l’aide de FRF.16, vous associez une interface DS0 à une interface IQ (lsq) de services de lien. Lorsque vous configurez un seul T1 fractionné, il transporte un nombre potentiellement important de circuits virtuels permanents Frame Relay identifiés par leurs DLCI. Chaque DLCI est appelé interface logique, car il peut représenter, par exemple, une adjacence de routage. Pour associer l’interface DS0 à une interface IQ de services de liaison, incluez l’instruction bundle au niveau de la [edit interfaces ds-fpc/pic/port:channel unit logical-unit-number family mlfr-end-to-end] hiérarchie :

Remarque :

Services de liaison Les interfaces IQ prennent en charge les interfaces physiques T1 et E1. Ces instructions s’appliquent aux interfaces T1, mais la configuration des interfaces E1 est similaire.

Pour configurer les propriétés de l’interface IQ des services de liaison, incluez les instructions suivantes au niveau de la [edit interfaces lsq-fpc/pic/port unit logical-unit-number] hiérarchie :

L’interface IQ des services de liaison logique représente l’offre groupée FRF.12. Quatre files d’attente sont associées à chaque interface logique. Un planificateur supprime des paquets des files d’attente conformément à une stratégie de planification. En règle générale, vous désignez une file d’attente avec une priorité stricte, et les files d’attente restantes sont traitées proportionnellement aux pondérations que vous configurez.

Pour FRF.12, affectez un seul mappage de planificateur à l’interface IQ des services de liaison (lsq) et à chaque liaison constitutive. Pour les routeurs M Series et T Series, les planificateurs par défaut, qui attribuent 95, 0, 0 et 5 % de bande passante au débit de transmission et à la taille de mémoire tampon des files d’attente 0, 1, 2 et 3, ne sont pas adéquats lorsque vous configurez le trafic LFI ou multiclasse. Par conséquent, pour FRF.12, vous devez configurer des planificateurs avec des débits de transmission et des tailles de mémoire tampon non nuls pour les files d’attente 0 à 3, et les affecter à l’interface IQ des services de liaison (lsq) et à chaque liaison constitutive, comme indiqué dans Exemples : Configuration d’une interface LSQ pour une interface T1 fractionnée à l’aide de FRF.12.

Remarque :

Pour les routeurs M320 et T Series, le taux de transmission du planificateur par défaut et les pourcentages de taille de mémoire tampon pour les files d’attente 0 à 7 sont de 95, 0, 0, 0, 5, 0, 0, 0 et 0 %.

Pour configurer et appliquer la stratégie de planification, incluez les instructions suivantes au niveau de la [edit class-of-service] hiérarchie :

Pour les interfaces IQ de services de liaison, une file d’attente de haute priorité stricte peut affamer les trois autres files d’attente, car le trafic d’une file d’attente de haute priorité stricte est transmis avant toute autre file d’attente. Cette implémentation diffère de l’implémentation Junos CoS standard dans laquelle une file d’attente stricte à haute priorité effectue un tourniquet avec des files d’attente à haute priorité, comme décrit dans le Guide de l’utilisateur de la classe de service (routeurs et commutateurs EX9200).

Une fois que le planificateur a supprimé un paquet d’une file d’attente, une certaine action est entreprise. L’action varie selon que le paquet provient d’une file d’attente encapsulée multiliaison (fragmentée et séquencée) ou d’une file d’attente non encapsulée (hachée sans fragmentation). Chaque file d’attente peut être désignée comme étant encapsulée ou non encapsulée pour plusieurs liaisons, indépendamment de l’autre. Par défaut, le trafic de toutes les classes de transfert est encapsulé sur plusieurs liaisons. Pour configurer la gestion de la fragmentation des paquets dans une file d’attente, incluez l’instruction fragmentation-maps au niveau de la [edit class-of-service] hiérarchie :

Si vous avez besoin que la file d’attente transmette de petits paquets avec une faible latence, configurez la file d’attente pour qu’elle soit non encapsulée en incluant l’instruction no-fragmentation . Si vous avez besoin que la file d’attente transmette des paquets volumineux avec une latence normale, configurez la file d’attente pour qu’elle soit encapsulée sur plusieurs liaisons en incluant l’instruction fragment-threshold . Si vous avez besoin que la file d’attente transmette des paquets volumineux avec une faible latence, nous vous recommandons d’utiliser une liaison plus rapide et de configurer la file d’attente pour qu’elle ne soit pas encapsulée. Pour plus d’informations sur les mappages de fragmentation, consultez Configuration de la fragmentation CoS par classe de transfert sur les interfaces LSQ.

Lorsqu’un paquet est retiré d’une file d’attente encapsulée en plusieurs liens, il est fragmenté. Si le paquet dépasse le MTU de liaison minimal ou si un seuil de fragments est configuré au niveau hiérarchique [edit class-of-service fragmentation-maps map-name forwarding-class class-name] d’une file d’attente, le logiciel divise le paquet en deux fragments ou plus, auxquels sont attribués des numéros de séquence multiliens consécutifs.

Si vous n’incluez pas l’instruction fragment-threshold dans le mappage de fragmentation, le seuil de fragmentation que vous définissez au niveau de la [edit interfaces interface-name unit logical-unit-number] hiérarchie est le seuil par défaut pour toutes les classes de transfert. Si vous ne définissez aucune taille maximale de fragment dans la configuration, les paquets sont fragmentés s’ils dépassent la plus petite MTU de tous les liens du lot.

Même si vous ne définissez pas de taille de fragment maximale dans la configuration, vous pouvez configurer l’unité reconstruite reçue maximale (MRRU) en incluant l’instruction mrru au niveau de la [edit interfaces lsq-fpc/pic/port unit logical-unit-number] hiérarchie. La MRRU est similaire à la MTU, mais elle est spécifique aux interfaces de services de liaison. Par défaut, la taille de la MRRU est de 1500 octets et vous pouvez la configurer pour qu’elle soit comprise entre 1500 et 4500 octets. Pour plus d’informations, reportez-vous à la section Configuration de MRRU sur les interfaces logiques multiliaison et de services de liaison.

Lorsqu’un paquet est retiré d’une file d’attente encapsulée en plusieurs liens, le logiciel lui attribue un en-tête FRF.12. L’en-tête FRF.12 contient un champ de numéro de séquence, qui est rempli avec le numéro de séquence disponible suivant d’un compteur. Le logiciel place ensuite le paquet sur la liaison T1 fractionnaire. Le trafic d’une autre file d’attente peut être entrelacé entre deux fragments du paquet.

Lorsqu’un paquet est retiré d’une file d’attente non encapsulée, il est transmis avec un en-tête Frame Relay simple. Le paquet est ensuite placé sur la liaison T1 fractionnaire dès que possible. Si nécessaire, le paquet est placé entre les fragments d’un paquet d’une autre file d’attente.

L’interface T1 fractionnée est liée à un autre routeur, qui peut provenir de Juniper Networks ou d’un autre fournisseur. Le routeur à l’extrémité distant collecte les paquets de la liaison T1 fractionnée. Si un paquet a un en-tête FRF.12, le logiciel suppose que le paquet est un fragment d’un paquet plus grand, et le champ de numéro de fragment est utilisé pour réassembler le paquet plus grand. Si le paquet a un en-tête Frame Relay simple, le logiciel accepte le paquet dans l’ordre dans lequel il arrive et le logiciel ne tente pas de le réassembler ou de le réorganiser.

Un paquet entier d’une file d’attente non encapsulée peut être placé entre des fragments d’une file d’attente encapsulée à liaisons multiples. Toutefois, les fragments d’une file d’attente encapsulée à liaisons multiples ne peuvent pas être entrelacés avec des fragments d’une autre file d’attente encapsulée à liaisons multiples. C’est l’intention de la spécification FRF.12, Accord de mise en œuvre de la fragmentation des relais de trames. Si des fragments de deux files d’attente différentes étaient entrelacés, les champs d’en-tête peuvent ne pas contenir suffisamment d’informations pour séparer les fragments.

Cet exemple regroupe une seule interface T3 sur une interface IQ de services de liaison avec encapsulation MLPPP. La liaison d’une seule interface T3 à un bundle multilink vous permet de configurer le RTP compressé (CRTP) sur l’interface T3.

Ce scénario s’applique uniquement aux offres groupées MLPPP. Actuellement, Junos OS ne prend pas en charge CRTP sur Frame Relay. Pour plus d’informations, consultez Configuration des interfaces de services pour les services vocaux.

Il n’est pas nécessaire de configurer LFI aux vitesses DS3, car le délai de sérialisation des paquets est négligeable.

Cette configuration utilise un mappage de fragmentation par défaut, ce qui entraîne l’envoi de toutes les classes de transfert (files d’attente) avec un en-tête multilien.

Pour éliminer les en-têtes à liaisons multiples, vous pouvez configurer une carte de fragmentation dans laquelle toutes les files d’attente ont l’instruction no-fragmentation au niveau de la [edit class-of-service fragmentation-maps map-name forwarding-class class-name] hiérarchie et attacher la carte de fragmentation à l’interface lsq-1/3/0.1 , comme indiqué ici :

Cet exemple configure une interface T3 ou OC3 à canal clair avec plusieurs interfaces logiques (DLCI) sur la liaison. Dans ce scénario, chaque DLCI représente un client. Les DLCI sont formés au niveau du PIC de sortie à une vitesse donnée (NxDS0). Cela vous permet de configurer LFI à l’aide du protocole de bout en bout FRF.12 sur les DLCI Frame Relay.

Pour ce faire, configurez d’abord les interfaces logiques (DLCI) sur l’interface physique. Ensuite, regroupez les DLCI, de sorte qu’il n’y ait qu’un seul DLCI par paquet.

L’interface physique doit être capable d’une planification par DLCI, ce qui vous permet d’attacher des taux de mise en forme à chaque DLCI. Pour plus d’informations, reportez-vous à la bibliothèque d’interfaces réseau de Junos OS pour les équipements de routage.

Pour éviter la perte de fragments au niveau du PIC de sortie, vous devez affecter un taux de mise en forme aux interfaces logiques des services de liaison IQ et aux DLCI de sortie. Les taux de mise en forme sur les DLCI spécifient la quantité de bande passante disponible pour chaque DLCI. Le taux de mise en forme sur les interfaces IQ de services de liaison doit correspondre à la vitesse de mise en forme attribuée au DLCI associé à l’offre groupée.

Une carte de planification doit également être associée aux interfaces de sortie. La file d’attente qui transporte la voix doit avoir une priorité stricte élevée, tandis que toutes les autres files d’attente doivent être de faible priorité. Cela rend LFI possible.

Cet exemple montre le trafic vocal dans la file d’attente ef . Le trafic vocal est entrelacé avec des données en vrac. Vous pouvez également utiliser MLPPP multiclasse pour transporter plusieurs classes de trafic dans différentes classes de liaisons multiples.

Pour plus d’informations sur le fonctionnement de FRF.12 avec les interfaces IQ de services de liaisons, consultez Configuration des interfaces LSQ pour des interfaces T1 ou E1 fractionnées uniques à l’aide de FRF.12.

Cet exemple configure une interface ATM2 IQ avec MLPPP groupé avec des interfaces IQ de services de liaison. Cela permet de configurer LFI sur les circuits virtuels ATM.

Pour ce type de configuration, l’interface ATM2 IQ doit avoir une encapsulation LLC.

Les PIC ATM suivants sont pris en charge dans ce scénario :

• 2 ports OC-3/STM1 ATM2 IQ

• 4 ports DS3 ATM2 IQ

Le PPP multiplexé de circuit virtuel sur AAL5 n’est pas pris en charge. Frame Relay n’est pas pris en charge. Le regroupement de plusieurs VC ATM en une seule interface logique n’est pas pris en charge.

Contrairement aux interfaces DS3 et OC3, il n’est pas nécessaire de créer une carte de planificateur distincte pour le PIC ATM. Pour ATM, vous définissez les composants CoS au niveau de la [edit interfaces at-fpc/pic/port atm-options] hiérarchie, comme décrit dans la bibliothèque d’interfaces réseau de Junos OS pour les périphériques de routage.

Remarque :

Ne configurez pas de profils RED sur les interfaces logiques ATM fournies. Les pertes ne se produisent pas à l’interface ATM.

Dans cet exemple, deux VC ATM sont configurés et regroupés en deux bundles IQ de services de liaison. Une carte de fragmentation est utilisée pour entrelacer le trafic vocal avec d’autres trafics multi-liaisons. Du fait de l’utilisation du MLPPP, chaque bundle IQ de services de liaison peut être configuré pour le CRTP.