Services Multlink en ligne

Les interfaces WAN PPP multiliaisons en ligne (MLPPP), FRF.16 (Multilink Frame Relay) et FRF.15 (Multilink Frame Relay end-to-end) pour multiplexage temporel (TDM) fournissent des services de regroupement via le moteur de transfert de paquets sans nécessiter de PIC ou de concentracteur de port dense (DPC).

Traditionnellement, les services de regroupement 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 de liaisons (LFI) sur le paquet, réduisant ainsi le délai de transmission de paquets de haute priorité.

Cette prise en charge inclut plusieurs liens 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 les emplacements pour d’autres MIC.

Note:

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

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

La configuration de MLPPP en ligne pour les interfaces WAN bénéficie des 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 RTC est utilisé pour les réseaux MPLS.

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

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

• Fournisseurs de services disposant de réseaux centraux basés sur SONET.

La figure suivante illustre l’étendue 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 bande passante et une redondance de liaison plus élevées.

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

MLPPP est un protocole permettant d’agréger plusieurs liens constitutifs en un ensemble PPP plus grand. MLFR vous permet d’agréger plusieurs liaisons Frame Relay par multiplexage inverse. MLPPP et MLFR offrent des options de service entre les services T1 et E1 à faible vitesse. En plus de fournir une bande passante supplémentaire, le regroupement de plusieurs liaisons peut augmenter le niveau de tolérance de panne de votre service d’accès dédié. Comme vous pouvez implémenter 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, reportez-vous à :

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

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

La surcharge de la couche de liaison peut entraîner des pertes de paquets sur les liaisons constitutives en raison du bourrage de bits sur les liaisons série. Le bourrage de bits est utilisé pour empêcher les données d’être interprétées comme des informations de contrôle.

Par défaut, 4 % de la bande passante totale du bundle est réservée à la surcharge de la couche de liaison. Dans la plupart des environnements réseau, la surcharge moyenne de la couche de liaison est de 1,6 %. Par conséquent, nous recommandons une mesure de protection de 4 %. Pour plus d’informations, reportez-vous à la RFC 4814, Hash and Stuffing : Overlooked Factors in Network Device Benchmarking.

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

Vous pouvez inclure cette instruction 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 contiguïté de routage. Pour agréger des liens T1 dans un ensemble MLPPP, incluez l’instruction suivante bundle au niveau de la [edit interfaces t1-fpc/pic/port unit logical-unit-number family mlppp] hiérarchie :

Note:

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 :

Note:

Les routeurs ACX Series ne prennent pas en charge les propriétés drop-timeout et link-layer-overhead.

L’interface IQ des services de liaison logique représente le bundle MLPPP. Pour le bundle 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 les paquets des files d’attente en fonction d’une stratégie de planification. En règle générale, vous désignez une file d’attente comme ayant une priorité stricte, et les files d’attente restantes sont traitées proportionnellement aux pondérations que vous configurez.

Pour MLPPP, affectez 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 une bande passante de 95, 0, 0 et 5 % au débit de transmission et à la taille de la 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 lien constitutif, comme illustré dans Exemple : configuration d’une interface LSQ en tant que bundle NxT1 à l’aide de MLPPP.

Note:

Pour les routeurs M320 et T Series, le taux de transmission du planificateur par défaut et les pourcentages de taille de tampon pour les files d’attente 0 à 7 sont de 95, 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 permuté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 le bundle comporte plusieurs liens, 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 des services de liaison, une file d’attente de priorité stricte-haute peut priver les trois autres files d’attente, car le trafic dans une file d’attente de priorité stricte-haute est transmis avant que toute autre file d’attente ne soit traitée. Cette implémentation est différente de l’implémentation CoS standard de Junos dans laquelle une file d’attente stricte-haute priorité effectue un tourniquet avec des files d’attente de 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 effectuée. 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 encapsulée multiliaison ou non encapsulée, 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 sur une file d’attente, incluez l’instruction suivante 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 sur plusieurs liaisons 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 liaisons. Pour ce faire, incluez l’instruction fragment-threshold dans la configuration. Si vous choisissez de définir le trafic d’une file d’attente pour qu’il soit non encapsulé plutôt que multilink, 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 cartes 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 sur plusieurs liaisons, 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 prochain numéro de séquence disponible à partir d’un compteur. Le logiciel place ensuite le paquet sur l’une des N différentes liaisons T1. La liaison est choisie paquet par paquet afin d’équilibrer la charge sur les différentes liaisons T1.

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

Si vous n’incluez pas l’instruction fragment-threshold dans la carte 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 la valeur par défaut pour toutes les classes de transfert. Si vous ne définissez pas de taille maximale de fragment dans la configuration, les paquets sont fragmentés s’ils dépassent la plus petite MTU de toutes les liaisons du bundle.

Même si vous ne définissez pas de taille maximale de fragment dans la configuration, vous pouvez configurer l’unité reconstruite maximale reçue (MRRU) en incluant l’instruction mrru au niveau de la [edit interfaces lsq-fpc/pic/port unit logical-unit-number] hiérarchie. Le MRRU est similaire au MTU, mais il est spécifique aux interfaces de services de liaison. Par défaut, la taille 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 des services multiliaisons et liaisons.

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 la réorganisation des paquets. Pour éviter toute 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 IP, le logiciel calcule le hachage en fonction de l’adresse source, de l’adresse de destination et du protocole IP. Pour 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, cela ne garantit pas que la charge sur les différentes liaisons T1 soit équilibrée. S’il y a beaucoup de flux, la charge est généralement équilibrée.

Les N différentes interfaces T1 sont reliées à un autre routeur, qui peut provenir de Juniper Networks ou d’un autre fournisseur. Le routeur situé à l’extrémité rassemble les paquets de toutes les liaisons T1. Si un paquet a un en-tête MLPPP, le champ de 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 un bundle xT1 à l’aide de NFRF.16, vous agrégez N différents liens T1 dans un bundle. Le Nbundle xT1 contient un nombre potentiellement important de circuits virtuels permanents de relais de trames, identifiés par leurs DLCI. Chaque DLCI est appelé une interface logique, car il peut représenter, par exemple, une contiguïté de routage.

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

Note:

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 des services de liaison représente le bundle FRF.16. Quatre files d’attente sont associées à chaque DLCI. Un planificateur supprime les paquets des files d’attente en fonction d’une stratégie de planification. Sur l’interface IQ des services de liaison, vous désignez généralement une file d’attente pour qu’elle ait une priorité stricte. Les files d’attente restantes sont traitées proportionnellement aux pondérations que vous configurez.

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

Si le bundle comporte plusieurs liens, 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 une seule carte de planificateur à l’interface IQ des services de liaison (lsq) et à chaque DLCI IQ des services de liaison, ou vous pouvez affecter des cartes de planificateur différentes aux différentes DLCI du bundle, comme illustré 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 multiclass ne sont pas pris en charge pour FRF.16, le trafic de chaque lien constitutif est transmis à partir de la file d’attente 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 des planificateurs par défaut et les pourcentages de taille de tampon pour les files d’attente 0 à 3 sont de 95, 0, 0 et 5 %. Ces planificateurs par défaut envoient tout le trafic utilisateur vers la file d’attente 0 et tout le trafic de contrôle réseau vers 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 à 95, 0, 0 et 5 %, et l’appliquer aux liens constitutifs.

Note:

Pour les routeurs M320 et T Series, le taux de transmission du planificateur par défaut et les pourcentages de taille de tampon pour les files d’attente 0 à 7 sont de 95, 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 permuté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 sur une file d’attente, incluez l’instruction suivante fragmentation-maps au niveau de la [edit class-of-service] hiérarchie :

Pour le trafic FRF.16, seules les files d’attente encapsulées multiliaisons (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 au niveau de la hiérarchie pour le no-fragmentation [edit class-of-service fragmentation-maps map-name forwarding-class class-name] trafic FRF.16. Pour FRF.16, si vous souhaitez acheminer de la voix ou tout autre trafic sensible à la latence, vous ne devez pas utiliser de liaisons lentes. À des vitesses T1 et supérieures, le délai de sérialisation est suffisamment petit pour que vous n’ayez pas besoin d’utiliser de LFI explicite.

Lorsqu’un paquet est retiré d’une file d’attente encapsulée sur plusieurs liaisons, 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 prochain numéro de séquence disponible d’un compteur. Le logiciel place ensuite le paquet sur l’une des N différentes liaisons T1. La liaison est choisie paquet par paquet afin d’équilibrer la charge sur les différentes liaisons T1.

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

Si vous n’incluez pas l’instruction fragment-threshold dans la carte 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 la valeur par défaut pour toutes les classes de transfert. Si vous ne définissez pas de taille maximale de fragment dans la configuration, les paquets sont fragmentés s’ils dépassent la plus petite MTU de toutes les liaisons du bundle.

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] Le MRRU est similaire au MTU, mais il est spécifique aux interfaces de services de liaison. Par défaut, la taille 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 des services multiliaisons et liaisons.

Les N différentes interfaces T1 sont reliées à un autre routeur, qui peut provenir de Juniper Networks ou d’un autre fournisseur. Le routeur situé à l’extrémité rassemble les paquets de toutes les liaisons T1. Étant donné que 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 des numéros de séquence.

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

Note:

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 contiguïté de routage.

L’interface IQ des services de liaison logique représente le bundle MLPPP. Quatre files d’attente sont associées à l’interface logique. Un planificateur supprime les paquets des files d’attente en fonction d’une stratégie de planification. En règle générale, vous désignez une file d’attente comme ayant 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 fractionnaire à l’aide de MLPPP et LFI, vous associez une interface DS0 (T1 fractionnaire) à une interface IQ de services de liaison. Pour associer une interface T1 fractionnaire à une interface IQ des services de liaison, incluez l’instruction suivante bundle au niveau de la [edit interfaces ds-fpc/pic/port:channel unit logical-unit-number family mlppp] hiérarchie :

Note:

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, affectez une seule carte de planificateur à l’interface IQ (lsq) des services de liaison et à chaque liaison constituante. Les planificateurs par défaut des routeurs M Series et T Series, qui attribuent une bande passante de 95, 0, 0 et 5 % au débit de transmission et à la taille de la 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 en pourcentage 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 lien constitutif, comme illustré dans Exemple : configuration d’une interface LSQ pour une interface T1 fractionnaire à l’aide de MLPPP et LFI.

Note:

Pour les routeurs M320 et T Series, le taux de transmission du planificateur par défaut et les pourcentages de taille de tampon pour les files d’attente 0 à 7 sont de 95, 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 des services de liaison, une file d’attente à priorité stricte peut priver toutes les autres files d’attente, car le trafic dans une file d’attente à priorité stricte est transmis avant que toute autre file d’attente ne soit traitée. Cette implémentation est différente de l’implémentation CoS Junos standard dans laquelle une file d’attente de priorité stricte et haute priorité reçoit un nombre infini de crédits et effectue un tourniquet avec des files d’attente de 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 effectuée. 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 encapsulée multiliaison ou non encapsulée, 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 sur une file d’attente, incluez l’instruction suivante 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 soit non encapsulée. Pour plus d’informations sur les cartes 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 sur plusieurs liaisons, il est fragmenté. Si le paquet dépasse la MTU minimale de la liaison ou si un seuil de fragment est configuré dans une file d’attente au niveau de la [edit class-of-service fragmentation-maps map-name forwarding-class class-name] hiérarchie, le logiciel divise le paquet en deux fragments ou plus, auxquels sont attribués des numéros de séquence multiliaison consécutifs.

Si vous n’incluez pas l’instruction fragment-threshold dans la carte 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 la valeur par défaut pour toutes les classes de transfert. Si vous ne définissez pas de taille maximale de fragment dans la configuration, les paquets sont fragmentés s’ils dépassent la plus petite MTU de toutes les liaisons du bundle.

Même si vous ne définissez pas de taille maximale de fragment dans la configuration, vous pouvez configurer l’unité reconstruite maximale reçue (MRRU) en incluant l’instruction mrru au niveau de la [edit interfaces lsq-fpc/pic/port unit logical-unit-number] hiérarchie. Le MRRU est similaire au MTU, mais il est spécifique aux interfaces de services de liaison. Par défaut, la taille 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 des services multiliaisons et liaisons.

Lorsqu’un paquet est retiré d’une file d’attente encapsulée sur plusieurs liaisons, 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 prochain numéro de séquence disponible à partir d’un compteur. Le logiciel place ensuite le paquet sur la liaison fractionnaire T1. Le trafic provenant 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 fractionnaire T1 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 reliée à un autre routeur, qui peut provenir de Juniper Networks ou d’un autre fournisseur. Le routeur situé à l’extrémité rassemble les paquets de la liaison fractionnaire T1. Si un paquet a un en-tête MLPPP, le logiciel suppose que le paquet est un fragment d’un paquet plus volumineux, et le champ du numéro de fragment est utilisé pour réassembler le paquet plus volumineux. 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 fait aucune tentative pour réassembler ou réorganiser le paquet.

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

Note:

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 le bundle FRF.12. Quatre files d’attente sont associées à chaque interface logique. Un planificateur supprime les paquets des files d’attente en fonction d’une stratégie de planification. En règle générale, vous désignez une file d’attente comme ayant une priorité stricte, et les files d’attente restantes sont traitées proportionnellement aux pondérations que vous configurez.

Pour FRF.12, affectez une seule carte 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 une bande passante de 95, 0, 0 et 5 % au débit de transmission et à la taille de la 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 taux de transmission en pourcentage 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 fractionnaire à l’aide de FRF.12.

Note:

Pour les routeurs M320 et T Series, le taux de transmission du planificateur par défaut et les pourcentages de taille de tampon pour les files d’attente 0 à 7 sont de 95, 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 des services de liaison, une file d’attente de priorité stricte-haute peut priver les trois autres files d’attente, car le trafic dans une file d’attente de priorité stricte-haute est transmis avant que toute autre file d’attente ne soit traitée. Cette implémentation est différente de l’implémentation CoS standard de Junos dans laquelle une file d’attente stricte-haute priorité effectue un tourniquet avec des files d’attente de 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 effectuée. 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 encapsulée multiliaison ou non encapsulée, 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 sur une file d’attente, incluez l’instruction suivante 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 soit non encapsulée. Pour plus d’informations sur les cartes 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 sur plusieurs liaisons, il est fragmenté. Si le paquet dépasse la MTU minimale de la liaison ou si un seuil de fragment est configuré dans une file d’attente au niveau de la [edit class-of-service fragmentation-maps map-name forwarding-class class-name] hiérarchie, le logiciel divise le paquet en deux fragments ou plus, auxquels sont attribués des numéros de séquence multiliaison consécutifs.

Si vous n’incluez pas l’instruction fragment-threshold dans la carte 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 la valeur par défaut pour toutes les classes de transfert. Si vous ne définissez pas de taille maximale de fragment dans la configuration, les paquets sont fragmentés s’ils dépassent la plus petite MTU de toutes les liaisons du bundle.

Même si vous ne définissez pas de taille maximale de fragment dans la configuration, vous pouvez configurer l’unité reconstruite maximale reçue (MRRU) en incluant l’instruction mrru au niveau de la [edit interfaces lsq-fpc/pic/port unit logical-unit-number] hiérarchie. Le MRRU est similaire au MTU, mais il est spécifique aux interfaces de services de liaison. Par défaut, la taille 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 des services multiliaisons et liaisons.

Lorsqu’un paquet est retiré d’une file d’attente encapsulée sur plusieurs liaisons, le logiciel attribue au paquet 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 prochain numéro de séquence disponible d’un compteur. Le logiciel place ensuite le paquet sur la liaison fractionnaire T1. Le trafic provenant 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 fractionnaire T1 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 reliée à un autre routeur, qui peut provenir de Juniper Networks ou d’un autre fournisseur. Le routeur situé à l’extrémité rassemble les paquets de la liaison fractionnaire T1. 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 numéro de fragment est utilisé pour réassembler le paquet plus volumineux. 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 fait aucune tentative pour réassembler ou réorganiser le paquet.

Un paquet entier d’une file d’attente non encapsulée peut être placé entre des fragments d’une file d’attente encapsulée sur plusieurs liaisons. Toutefois, les fragments d’une file d’attente encapsulée sur plusieurs liaisons ne peuvent pas être entrelacés avec les fragments d’une autre file d’attente encapsulée sur plusieurs liaisons. C’est l’objet 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 ont été entrelacés, il se peut que les champs d’en-tête ne contiennent pas suffisamment d’informations pour séparer les fragments.

Cet exemple regroupe une seule interface T3 sur une interface IQ de services de liaison avec une 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. Junos OS ne prend actuellement pas en charge CRTP sur Frame Relay. Pour plus d’informations, reportez-vous à la section Configuration des interfaces de services pour les services vocaux.

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

Cette configuration utilise une carte 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 multiliens, 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 illustré 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 mis en forme au niveau du PIC de sortie à une vitesse particulière (NxDS0). Cela vous permet de configurer LFI à l’aide du protocole FRF.12 de bout en bout sur les DLCI de relais de trames.

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

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

Pour éviter les pertes de fragments au niveau du PIC de sortie, vous devez affecter un taux de mise en forme aux interfaces logiques IQ des services de liaison 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 des services de liaison doit correspondre au taux de mise en forme attribué à la DLCI associée au bundle.

Une carte du planificateur doit également être associée aux interfaces de sortie. La file d’attente qui transporte la voix doit être de priorité stricte-haute, tandis que toutes les autres files d’attente doivent être de faible priorité. C’est ce qui 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 masse. Vous pouvez également utiliser MLPPP multiclasse pour transporter plusieurs classes de trafic dans différentes classes multiliaisons.

Pour plus d’informations sur le fonctionnement de FRF.12 avec les interfaces IQ des services de liaison, reportez-vous à la section Configuration des interfaces LSQ pour les interfaces fractionnaires uniques T1 ou E1 à l’aide de FRF.12.

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

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

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

• 2 ports OC-3/STM1 ATM2 IQ

• DS3 ATM2 IQ à 4 ports

Le PPP multiplexé de circuit virtuel sur AAL5 n’est pas pris en charge. Le relais de trame n’est pas pris en charge. Le regroupement de plusieurs guichets virtuels ATM dans 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 planification 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 Junos OS pour les périphériques de routage.

Note:

Ne configurez pas les profils RED sur les interfaces logiques ATM qui sont groupées. Il n’y a pas de chute à l’interface du guichet automatique.

Dans cet exemple, deux circuits virtuels ATM sont configurés et regroupés dans deux ensembles IQ de services de liaison. Une carte de fragmentation permet d’entrelacer le trafic vocal avec d’autres types de trafic multiliaison. Grâce à l’utilisation de MLPPP, chaque bundle IQ de services de liaison peut être configuré pour CRTP.