Configuration des interfaces de services de liaison
Les équipements Juniper Networks prennent en charge les services de liens sur l’interface lsq-0/0/0 de file d’attente des services de liaison, qui inclut des services multiliens tels que MLPP, MLFR et CRTP. Les rubriques ci-dessous décrivent la présentation des services de liaison, les détails de configuration et la vérification des services de liaison.
Présentation des interfaces de services de liaison
Les services de liaison comprennent les services multiliens MLPPP (Multilink Point-to-Point Protocol), MLFR (Multilink Frame Relay) et CRTP (Compressed Real-Time Transport Protocol). Les équipements Juniper Networks prennent en charge les services de liens sur l’interface de file d’attente lsq-0/0/0 des services de liaison.
Vous configurez l’interface de file d’attente des services de liaison (lsq-0/0/0) sur un périphérique Juniper Networks pour prendre en charge les services multiliens et CRTP.
L’interface de file d’attente de services de liaison se compose de services fournis par les interfaces suivantes : interface de services de liaison (ml-fpc/pic/port ), interface de services de liaison (ls-fpc/pic/port ) et interface de file d’attente intelligente de services de liaison (lsq-fpc/pic/port ). Bien que les interfaces de files d’attente intelligentes (IQ) de services de liaison soient installées sur des cartes d’interface physique (PIC), l’interface de file d’attente de services de liaison est une interface interne uniquement et n’est pas associée à un support physique ou à un module d’interface physique (PIM).
(ls-fpc/pic/port ) n’est pas pris en charge.
Cette section contient les rubriques suivantes.
- Services disponibles sur une interface de services de liaison
- Exceptions aux services de liens
- Configuration de MLPPP multiclasse
- File d’attente avec LFI
- Présentation du protocole de transport en temps réel compressé
- Configuration de la fragmentation par classe de transfert
- Configuration de la surcharge de couche de liaison
Services disponibles sur une interface de services de liaison
L’interface des services de liens est une interface logique disponible par défaut. Le Tableau 1 récapitule les services disponibles sur l’interface.
| Services |
But |
Plus d’informations |
|---|---|---|
| Paquets multiliens au moyen de l’encapsulation MLPPP et MLFR |
Regroupe plusieurs liaisons constitutives en un ensemble logique plus large pour fournir plus de bande passante, de équilibrage de charge et de redondance.
Note:
Les configurations DCAC (Dynamic Call Admission Control) ne sont pas prises en charge sur les interfaces de services de liaison. |
|
| fragmentation de liaison et entrelacement (LFI) |
Réduit le retard et la gigue sur les liaisons en fractionnant les paquets de données volumineux et en entrelaçant les paquets vocaux sensibles au retard avec les paquets plus petits qui en résultent. |
Comprendre la fragmentation des liens et la configuration entrelacée |
| Protocole de transport en temps réel (CRTP) compressé |
Réduit la surcharge causée par le protocole RTP (Real-Time Transport Protocol) sur les paquets voix et vidéo. |
Présentation du protocole de transport en temps réel compressé |
| Classificateurs de classes de service (CoS), classes de transfert, planificateurs et mappages de planificateurs, et taux de mise en forme |
Donne une priorité plus élevée aux paquets sensibles à la latence, en configurant le protocole CoS, par exemple :
|
Exceptions aux services de liens
L’implémentation des services de liaison et multiliaison est similaire à celle des autres plates-formes de routage, à quelques exceptions près :
-
La prise en charge des services de liaison et de liaison multiple se trouve sur l’interface à la
lsq-0/0/0place desml-fpc/pic/portinterfaces ,lsq-fpc/pic/portet .ls-fpc/pic/port -
Lorsque LFI est activé, les paquets fragmentés sont mis en file d’attente de manière circulaire sur les liaisons constitutives pour permettre l’équilibrage de charge par paquet et par fragment. Voir File d’attente avec LFI.
-
La prise en charge de la planification par unité concerne tous les types de liaisons constitutives (sur tous les types d’interfaces).
-
La prise en charge du protocole CRTP (Compressed Real-Time Transport Protocol) s’applique à la fois au MLPPP et au PPP.
Configuration de MLPPP multiclasse
Sur lsq-0/0/0 les équipements Juniper Networks, l’encapsulation MLPPP permet de configurer des MLPPP multiclasses. Si vous ne configurez pas MLPPP multiclasse, les fragments de différentes classes ne peuvent pas être entrelacés. Tous les fragments d’un seul paquet doivent être envoyés avant que les fragments d’un autre paquet ne soient envoyés. Les paquets non fragmentés peuvent être entrelacés entre les fragments d’un autre paquet pour réduire la latence observée par les paquets non fragmentés. En effet, le trafic sensible à la latence est encapsulé en tant que trafic PPP normal, et le trafic en masse est encapsulé en tant que trafic multi-liaison. Ce modèle fonctionne tant qu’il existe une seule classe de trafic sensible à la latence et qu’il n’y a pas de trafic hautement prioritaire qui prime sur le trafic sensible à la latence. Cette approche de LFI, utilisée sur le PIC de services de liaison, ne prend en charge que deux niveaux de priorité du trafic, ce qui n’est pas suffisant pour transporter les quatre à huit classes de transfert.
Le MLPPP multiclasse permet d’acheminer plusieurs classes de trafic sensible à la latence sur un seul bundle multilink avec du trafic en masse. En effet, le MLPPP multiclasse permet à différentes classes de trafic d’avoir des garanties de latence différentes. Avec MLPPP multiclasse, vous pouvez mapper chaque classe de transfert dans une classe multilink distincte, préservant ainsi les garanties de priorité et de latence.
La configuration de LFI et de MLPPP multiclasse sur le même bundle n’est pas nécessaire, ni prise en charge, car MLPPP multiclasse représente un surensemble de fonctionnalités. Lorsque vous configurez MLPPP multiclasse, LFI est automatiquement activé.
L’implémentation PPP de Junos OS ne prend pas en charge la négociation des options NCP de compression de champ d’adresse et de compression de champ de protocole PPP, ce qui signifie que le logiciel envoie toujours un en-tête PPP complet de 4 octets.
L’implémentation Junos OS de MLPPP multiclasse ne prend pas en charge la compression des octets d’en-tête communs.
Le MLPPP multiclasse simplifie considérablement les problèmes d’ordre des paquets qui se produisent lorsque plusieurs liaisons sont utilisées. Sans MLPPP multiclasse, tout le trafic vocal appartenant à un flux unique est haché sur un seul lien pour éviter les problèmes d’ordre des paquets. Avec le MLPPP multiclasse, vous pouvez affecter le trafic vocal à une classe de priorité élevée et vous pouvez utiliser plusieurs liens.
Pour configurer MLPPP multiclasse sur une interface IQ de services de liaison, vous devez spécifier le nombre de classes de liaisons multiples à négocier lorsqu’un lien rejoint le bundle, et vous devez spécifier le mappage d’une classe de transfert dans une classe MLPPP multiclasse.
Pour spécifier le nombre de classes de liaisons multiples à négocier lorsqu’un lien rejoint l’offre groupée, incluez l’instruction multilink-max-classes :
multilink-max-classes number;
Vous pouvez inclure cette déclaration aux niveaux hiérarchiques suivants :
-
[edit interfaces interface-name unit logical-unit-number] -
[edit logical-routers logical-router-name interfaces interface-name unit logical-unit-number]
Le nombre de classes multilink peut être compris entre 1 et 8. Le nombre de classes multilink pour chaque classe de transfert ne doit pas dépasser le nombre de classes multilink à négocier.
Pour spécifier le mappage d’une classe de transfert dans une classe MLPPP multiclasse, incluez l’instruction multilink-class au niveau de la [edit class-of-service fragmentation-maps forwarding-class class-name] hiérarchie :
edit class-of-service fragmentation-maps forwarding-classclass-namemultilink-class number
Le numéro d’index de classe à maillons multiples peut être compris entre 0 et 7. L’instruction multilink-class et l’instruction s’excluent no-fragmentation mutuellement.
Pour afficher le nombre de classes multilink négociées, exécutez la show interfaces lsq-0/0/0.logical-unit-number detail commande.
File d’attente avec LFI
Les paquets LFI ou non-LFI sont placés dans des files d’attente sur les liens constitutifs en fonction des files d’attente dans lesquelles ils arrivent. Aucun changement dans le nombre de files d’attente ne se produit lorsque les paquets fragmentés, non fragmentés ou LFI sont mis en file d’attente.
Par exemple, supposons que Q0 de la file d’attente est configurée avec un seuil de fragmentation 128, Q1 est configuré sans fragmentation et Q2 est configuré avec un seuil de fragmentation 512. Q0 reçoit un flux de trafic avec une taille de paquet de 512. Q1 reçoit un trafic vocal de 64 octets et Q2 reçoit un flux de trafic avec des paquets de 128 octets. Ensuite, le flux sur Q0 est fragmenté et mis en file d’attente dans Q0 d’un lien constitutif. De plus, tous les paquets du Q2 sont mis en file d’attente du Q0 sur la liaison constitutive. Le flux de Q1 est considéré comme LFI car aucune fragmentation n’est configurée. Tous les paquets de Q0 et Q2 sont mis en file d’attente sur Q0 de la liaison constitutive. Tous les paquets de Q1 sont mis en file d’attente sur Q2 de la liaison constitutive.
En utilisant lsq-0/0/0, CRTP peut être appliqué sur les paquets LFI et non-LFI. Il n’y aura aucun changement dans leur nombre de files d’attente à cause du CRTP.
File d’attente aux 2e trimestres de liens vers les citoyens
Lorsque vous utilisez la classe de service sur un bundle multilien, tout le trafic Q2 du bundle multilink est mis en file d’attente vers Q2 des liaisons constitutives en fonction d’un hachage calculé à partir de l’adresse source, de l’adresse de destination et du protocole IP du paquet. Si la charge utile IP est du trafic TCP ou UDP, le hachage inclut également le port source et le port de destination. En raison de cet algorithme de hachage, tout le trafic appartenant à un flux de trafic est mis en file d’attente vers Q2 d’un lien constitutif. Cette méthode de livraison du trafic vers le lien constitutif est appliquée à tout moment, y compris lorsque le forfait n’a pas été configuré avec LFI.
Présentation du protocole de transport en temps réel compressé
Le protocole de transport en temps réel (RTP) peut aider à assurer l’interopérabilité entre différentes implémentations d’applications audio et vidéo en réseau. Cependant, dans certains cas, l’en-tête, qui inclut les en-têtes IP, UDP et RTP, peut être trop grand (environ 40 octets) sur les réseaux utilisant des lignes à faible débit telles que les modems commutés. Le protocole CRTP (Compressed Real-Time Transport Protocol) peut être configuré pour réduire la surcharge réseau sur les liaisons à faible débit. Le CRTP remplace les en-têtes IP, UDP et RTP par un ID de contexte (CID) de 2 octets, ce qui réduit considérablement la surcharge d’en-tête.
La figure 1 montre comment CRTP compresse l’en-tête RTP dans un paquet vocal en réduisant un en-tête de 40 octets à un en-tête de 2 octets.
Vous pouvez configurer CRTP avec l’encapsulation d’interface logique MLPPP ou PPP sur les interfaces de services de liaison. Voir Exemple : Configuration d’un bundle MLPPP.
Les trames de données en temps réel et en temps différé sont transportées ensemble sur des liaisons à faible débit sans causer de retards excessifs au trafic en temps réel. Voir Comprendre la fragmentation des liens et la configuration d’entrelacement.
Configuration de la fragmentation par classe de transfert
Pour lsq-0/0/0 , vous pouvez spécifier des propriétés de fragmentation pour des classes de transfert spécifiques. Le trafic sur chaque classe de transfert peut être encapsulé multilink (fragmenté et séquencé) ou non encapsulé (haché sans fragmentation). Par défaut, le trafic de toutes les classes de transfert est encapsulé sur plusieurs liaisons.
Lorsque vous ne configurez pas de propriétés de fragmentation pour les files d’attente sur les interfaces MLPPP, le seuil de fragmentation que vous définissez au niveau de la [edit interfaces interface-name unit logical-unit-number fragment-threshold] hiérarchie est le seuil de fragmentation pour toutes les classes de transfert au sein de l’interface MLPPP. Pour les interfaces MLFR FRF.16, le seuil de fragmentation que vous définissez au niveau de la [edit interfaces interface-name mlfr-uni-nni-bundle-options fragment-threshold] hiérarchie est le seuil de fragmentation pour toutes les classes de transfert au sein de l’interface MLFR FRF.16.
Si vous ne définissez aucune taille maximale de fragment dans la configuration, les paquets sont toujours fragmentés s’ils dépassent la plus petite unité de transmission maximale (MTU) ou l’unité reconstruite reçue maximale (MRRU) de toutes les liaisons du lot. Un flux non encapsulé n’utilise qu’un seul lien. Si le flux dépasse une seule liaison, la classe de transfert doit être encapsulée multi-liaison, sauf si la taille du paquet dépasse la MTU/MRRU.
Même si vous ne définissez pas de taille de fragment maximale dans la configuration, vous pouvez configurer la MRRU en incluant l’instruction mrru au niveau de la [edit interfaces lsq-0/0/0 unit logical-unit-number] hiérarchie ou [edit interfaces interface-name mlfr-uni-nni-bundle-options] . La MRRU est similaire à la MTU, mais spécifique aux interfaces de services de liaison. Par défaut, la taille de MRRU est de 1504 octets et vous pouvez la configurer pour qu’elle soit de 1500 à 4500 octets.
Pour configurer les propriétés de fragmentation sur une file d’attente, incluez l’instruction fragmentation-maps au niveau de la [edit class-of-service] hiérarchie :
[edit class-of-service]
fragmentation-maps {
map-name {
forwarding-class class-name {
fragment-threshold bytes;
multilink-class number;
no-fragmentation;
}
}
}
Pour définir un seuil de fragmentation par classe de transfert, incluez l’instruction fragment-threshold dans le mappage de fragmentation. Cette instruction définit la taille maximale de chaque fragment de liaison multiple.
Pour définir le trafic d’une file d’attente pour qu’il soit non encapsulé plutôt qu’encapsulé sur plusieurs liaisons, incluez l’instruction no-fragmentation dans la carte de fragmentation. Cette instruction spécifie qu’aucun en-tête de fragmentation supplémentaire n’est ajouté aux paquets reçus dans cette file d’attente et qu’un équilibrage de charge de liaison statique est utilisé pour assurer la livraison des paquets dans l’ordre.
Pour une classe de transfert donnée, vous pouvez inclure l’instruction ou no-fragmentation ; elles s’excluent fragment-threshold mutuellement.
Vous utilisez l’instruction multilink-class pour mapper une classe de transfert dans un MLPPP multiclasse. Pour une classe de transfert donnée, vous pouvez inclure l’instruction ou no-fragmentation ; elles s’excluent multilink-class mutuellement.
Pour associer une carte de fragmentation à une interface PPP multiliaison ou à un DLCI MLFR FRF.16, incluez l’affirmation fragmentation-map au niveau de la [edit class-of-service interfaces interface-name unit logical-unit-number] hiérarchie :
[edit class-of-service interfaces]
lsq-0/0/0 {
unit logical-unit-number { # Multilink PPP
fragmentation-map map-name;
}
}
lsq-0/0/0:channel { # MLFR FRF.16
unit logical-unit-number
fragmentation-map map-name;
}
}
Configuration de la surcharge de couche de liaison
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 lsq-0/0/0 les appareils Juniper Networks, vous pouvez configurer le pourcentage de bande passante à réserver pour la surcharge de la couche de liaison. Pour ce faire, incluez l’instruction link-layer-overhead :
link-layer-overhead percent;
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-routers logical-router-name interfaces interface-name unit logical-unit-number]
Vous pouvez configurer la valeur pour qu’elle soit comprise entre 0 % et 50 %.
Présentation de la configuration des services de liaison
Avant de commencer :
Installez le matériel de l’appareil.
Établissez une connectivité de base. Consultez le guide de démarrage de votre appareil.
Avoir une compréhension de base des interfaces physiques et logiques et des conventions d’interface de Juniper Networks. Voir Présentation des interfaces
Planifiez la façon dont vous allez utiliser l’interface des services de liaison sur votre réseau. Voir Vue d’ensemble des interfaces de services de liaison.
Pour configurer les services de liens sur une interface, effectuez les tâches suivantes :
- Configurer la fragmentation et l’entrelacement des liens (LFI). Voir Exemple : Configuration de la fragmentation et de l’entrelacement des liaisons.
- Configurez les classificateurs et les classes de transfert. Voir Exemple : Définition de classificateurs et de classes de transfert.
- Configurez les cartes du planificateur. Voir Présentation de la définition et de l’application de mappages de planificateur.
- Configurez les taux de mise en forme des interfaces. Voir Exemple : Configuration des taux de mise en forme d’interface
- Configurez un bundle MLPPP. Voir Exemple : Configuration d’un bundle MLPPP.
- Pour configurer CRTP, reportez-vous à Exemple : Configuration du protocole de transport en temps réel compressé
Vérification de l’interface des services de liaison
Vérifiez que la configuration fonctionne correctement.
- Vérification des statistiques de l’interface des services de liaison
- Vérification de la configuration des services de liaison CoS
Vérification des statistiques de l’interface des services de liaison
But
Vérifiez les statistiques de l’interface des services de liaison.
Action
L’exemple de sortie fourni dans cette section est basé sur les configurations fournies dans Exemple : configuration d’un bundle MLPPP. Pour vérifier que les liens constitutifs sont correctement ajoutés à l’offre groupée et que les paquets sont fragmentés et transmis correctement, effectuez les actions suivantes :
Sur l’appareil R0 et l’appareil R1, les deux appareils utilisés dans cet exemple, configurez MLPPP et LFI comme décrit dans Exemple : Configuration d’un bundle MLPPP.
À partir de la CLI, entrez la commande permettant de vérifier qu’une
pingconnexion est établie entre R0 et R1.Transmettre 10 paquets de données de 200 octets chacun, de R0 à R1.
Sur R0, depuis la CLI, entrez la
show interfaces interface-name statisticscommande.
user@R0> show interfaces lsq-0/0/0 statistics detail
Physical interface: lsq-0/0/0, Enabled, Physical link is Up
Interface index: 134, SNMP ifIndex: 29, Generation: 135
Link-level type: LinkService, MTU: 1504
Device flags : Present Running
Interface flags: Point-To-Point SNMP-Traps
Last flapped : 2006-06-23 11:36:23 PDT (03:38:43 ago)
Statistics last cleared: 2006-06-23 15:13:12 PDT (00:01:54 ago)
Traffic statistics:
Input bytes : 0 0 bps
Output bytes : 1820 0 bps
Input packets: 0 0 pps
Output packets: 10 0 pps
...
Egress queues: 8 supported, 8 in use
Queue counters: Queued packets Transmitted packets Dropped packets
0 DATA 10 10 0
1 expedited-fo 0 0 0
2 VOICE 0 0 0
3 NC 0 0 0
Logical interface lsq-0/0/0.0 (Index 67) (SNMP ifIndex 41) (Generation 133)
Flags: Point-To-Point SNMP-Traps 0x4000 Encapsulation: Multilink-PPP
Bandwidth: 16mbps
Bundle options:
...
Drop timer period 0
Sequence number format long (24 bits)
Fragmentation threshold 128
Links needed to sustain bundle 1
Interleave fragments Enabled
Bundle errors:
Packet drops 0 (0 bytes)
Fragment drops 0 (0 bytes)
...
Statistics Frames fps Bytes bps
Bundle:
Fragments:
Input : 0 0 0 0
Output: 20 0 1920 0
Packets:
Input : 0 0 0 0
Output: 10 0 1820 0
Link:
se-1/0/0.0
Input : 0 0 0 0
Output: 10 0 1320 0
se-1/0/1.0
Input : 0 0 0 0
Output: 10 0 600 0
...
Destination: 10.0.0.9/24, Local: 10.0.0.10, Broadcast: Unspecified, Generation:144
Cette sortie affiche un résumé des informations de l’interface. Vérifiez les informations suivantes :
Physical interface: l’interface physique estEnabled. Si l’interface est affichée sous la formeDisabled, effectuez l’une des opérations suivantes :Dans l’éditeur de configuration de la CLI, supprimez l’instruction
disableau niveau de la[edit interfaces interface-name]hiérarchie de configuration.Dans l’éditeur de configuration J-Web, décochez la
Disablecase sur laInterfaces>interface-namepage.
Physical link—La liaison physique estUp. L’état de liaison indiqueDownun problème avec le module d’interface, le port d’interface ou la connexion physique (erreurs de couche de lien).Last flapped: leLast Flappedtemps est une valeur attendue. L’heureLast Flappedindique la dernière fois que l’interface physique est devenue indisponible, puis à nouveau disponible. Un instabilité inattendue indique des erreurs probables au niveau de la couche de liaison.Traffic statistics: nombre et débit d’octets et de paquets reçus et transmis sur l’interface. Vérifiez que le nombre d’octets et de paquets entrants et sortants correspond au débit attendu pour l’interface physique. Pour effacer les statistiques et ne voir que les nouvelles modifications, utilisez laclear interfaces statistics interface-namecommande.Queue counters: le nom et le nombre de files d’attente sont configurés. Cet exemple de sortie montre que 10 paquets de données ont été transmis et qu’aucun paquet n’a été perdu.Logical interface—Nom du bundle multilink que vous avez configuré—lsq-0/0/0.0.Bundle options: le seuil de fragmentation est correctement configuré et l’entrelacement des fragments est activé.Bundle errors: tous les paquets et fragments perdus par le paquet.Statistics: les fragments et les paquets sont reçus et transmis correctement par l’appareil. Toutes les références au sens du trafic (entrée ou sortie) sont définies par rapport à l’appareil. Les fragments d’entrée reçus par l’appareil sont assemblés en paquets d’entrée. Les paquets de sortie sont segmentés en fragments de sortie pour être transmis hors de l’appareil.Dans cet exemple, 10 paquets de données de 200 octets ont été transmis. Le seuil de fragmentation étant défini sur 128 octets, tous les paquets de données ont été fragmentés en deux fragments. L’exemple de sortie montre que 10 paquets et 20 fragments ont été transmis correctement.
Link—Les liens constitutifs sont ajoutés à ce bundle et reçoivent et transmettent correctement les fragments et les paquets. Le nombre combiné de fragments transmis sur les liaisons constitutives doit être égal au nombre de fragments transmis à partir du paquet. Cet exemple de sortie montre que le bundle a transmis 20 fragments et les deux liensse-1/0/0.0constitutifs etse-1/0/1.0.0correctement transmis10+10=20les fragments.DestinationetLocal: adresse IP du côté distant du faisceau de liaisons multiples et du côté local du faisceau de liaisons multiples. Cet exemple de sortie montre que l’adresse de destination est l’adresse sur R1 et l’adresse locale est l’adresse sur R0.
Vérification de la configuration des services de liaison CoS
But
Vérifiez les configurations CoS sur l’interface des services de liaison.
Action
Dans la CLI, entrez les commandes suivantes :
show class-of-service interface interface-nameshow class-of-service classifier name classifier-nameshow class-of-service scheduler-map scheduler-map-name
L’exemple de sortie fourni dans cette section est basé sur les configurations fournies dansExemple : configuration d’un bundle MLPPP.
user@R0> show class-of-service interface lsq-0/0/0
Physical interface: lsq-0/0/0, Index: 136
Queues supported: 8, Queues in use: 4
Scheduler map: [default], Index: 2
Input scheduler map: [default], Index: 3
Chassis scheduler map: [default-chassis], Index: 4
Logical interface: lsq-0/0/0.0, Index: 69
Object Name Type Index
Scheduler-map s_map Output 16206
Classifier ipprec-compatibility ip 12
user@R0> show class-of-service interface ge-0/0/1
Physical interface: ge-0/0/1, Index: 140
Queues supported: 8, Queues in use: 4
Scheduler map: [default], Index: 2
Input scheduler map: [default], Index: 3
Logical interface: ge-0/0/1.0, Index: 68
Object Name Type Index
Classifier classfy_input ip 4330
user@R0> show class-of-service classifier name classify_input
Classifier: classfy_input, Code point type: inet-precedence, Index: 4330
Code point Forwarding class Loss priority
000 DATA low
010 VOICE low
user@R0> show class-of-service scheduler-map s_map
Scheduler map: s_map, Index: 16206
Scheduler: DATA, Forwarding class: DATA, Index: 3810
Transmit rate: 49 percent, Rate Limit: none, Buffer size: 49 percent, Priority:low
Drop profiles:
Loss priority Protocol Index Name
Low any 1 [default-drop-profile]
Medium low any 1 [default-drop-profile]
Medium high any 1 [default-drop-profile]
High any 1 [default-drop-profile]
Scheduler: VOICE, Forwarding class: VOICE, Index: 43363
Transmit rate: 50 percent, Rate Limit: none, Buffer size: 5 percent, Priority:high
Drop profiles:
Loss priority Protocol Index Name
Low any 1 [default-drop-profile]
Medium low any 1 [default-drop-profile]
Medium high any 1 [default-drop-profile]
High any 1 [default-drop-profile]
Scheduler: NC, Forwarding class: NC, Index: 2435
Transmit rate: 1 percent, Rate Limit: none, Buffer size: 1 percent, Priority:high
Drop profiles:
Loss priority Protocol Index Name
Low any 1 [default-drop-profile]
Medium low any 1 [default-drop-profile]
Medium high any 1 [default-drop-profile]
High any 1 [default-drop-profile]
Ces exemples de sortie montrent un résumé des composants CoS configurés. Vérifiez les informations suivantes :
Logical Interface: nom du faisceau multilink et des composants CoS appliqués au bundle. L’exemple de sortie montre que le bundle multilink estlsq-0/0/0.0, et que le mappages_mapdu planificateur CoS lui est appliqué.Classifier: points de code, classes de transfert et priorités de perte affectées au classificateur. L’exemple de sortie montre qu’un classificateur par défaut,ipprec-compatibility, a été appliqué à l’interfacelsq-0/0/0et que le classificateurclassify_inputa été appliqué à l’interfacege-0/0/1.Scheduler: vitesse de transmission, taille de la mémoire tampon, priorité et priorité des pertes attribuées à chaque planificateur. L’exemple de sortie affiche les planificateurs de données, de voix et de contrôle du réseau avec toutes les valeurs configurées.
Comprendre la configuration de l’interface interne LSQ-0/0/0
L’interface des services de liaison est une interface interne uniquement. Il n’est pas associé à un support physique ou à un PIM. Les paquets sont acheminés vers cette interface pour être regroupés ou compressés.
Il peut être nécessaire de mettre à niveau votre configuration pour utiliser l’interface interne lsq-0/0/0 comme interface de file d’attente des services de liaison au lieu de ls-0/0/0, qui est obsolète. Vous pouvez également annuler votre configuration modifiée pour utiliser ls-0/0/0.
Exemple : Mise à niveau de ls-0/0/0 vers lsq-0/0/0 pour les services multiliens
Cet exemple montre comment passer de ls-0/0/0 à lsq-0/0/0 (ou pour inverser la modification) pour les services multiliens.
Exigences
Cette procédure n’est nécessaire que si vous utilisez toujours ls-0/0/0 au lieu de lsq-/0/0/0 ou si vous devez revenir à l’ancienne interface.
Aperçu
Dans cet exemple, vous renommez l’interface interne des services de liens de ls-0/0/0 en lsq-0/0/0 ou vice versa. Vous renommez toutes les occurrences de ls-0/0/0 dans la configuration en lsq-0/0/0 et configurez la carte de fragmentation en n’ajoutant aucune fragmentation. Vous ne spécifiez aucune fragmentation après le nom de la file d’attente 2, si la file d’attente 2 est configurée ou après le transfert assuré. Vous attachez ensuite la carte de fragmentation configurée à l’étape précédente à lsq-0/0/0 et spécifiez le numéro d’unité 6 du bundle multilink pour lequel les fragments d’entrelacement sont configurés.
Ensuite, vous restaurez la configuration de lsq-0/0/0 à ls-0/0/0. Vous renommez toutes les occurrences de la configuration de lsq-0/0/0 en ls-0/0/0. Vous supprimez le mappage de fragmentation s’il est configuré dans la hiérarchie [class-of-service] et supprimez le mappage de fragmentation s’il est affecté à lsq-0/0/0. Vous pouvez supprimer multilink-max-classes s’il est configuré pour lsq-0/0/0 dans la hiérarchie [interfaces]. Vous supprimez ensuite link-layer-overhead s’il est configuré pour lsq-0/0/0 dans la hiérarchie [interfaces].
Si aucune fragmentation n’est configurée sur une classe de transfert et que le mappage de fragmentation est affecté à lsq-0/0/0, vous configurez les fragments d’entrelacement pour l’interface ls-0/0/0. Enfin, vous configurez le classificateur des paquets LFI pour qu’il fasse référence à la file d’attente 2. (L’interface ls-0/0/0 traite la file d’attente 2 comme la file d’attente LFI.)
Configuration
Procédure
Configuration rapide de la CLI
Pour effectuer rapidement une mise à niveau de ls-0/0/0 vers lsq-0/0/0 (ou annuler la modification), copiez les commandes suivantes et collez-les dans la CLI :
For interfaces ls-0/0/0 to lsq-0/0/0 [edit] rename interfaces ls-0/0/0 to lsq-0/0/0 set class-of-service fragmentation-maps map6 forwarding-class assured-forwarding no-fragmentation set class-of-service interfaces lsq-0/0/0 unit 6 fragmentation-map map6
For interfaces lsq-0/0/0 to ls-0/0/0 [edit] rename interfaces lsq-0/0/0 to ls-0/0/0 delete class-of-service fragmentation-maps map6 delete class-of-service interfaces lsq-0/0/0 unit 6 fragmentation-map map6 delete interfaces lsq-0/0/0 unit 6 link-layer-overhead delete interfaces lsq-0/0/0:0 mlfr-uni-nni-bundle-options link-layer-overhead set interfaces ls-0/0/0 unit 6 interleave-fragments
Procédure étape par étape
L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur la procédure à suivre, consultez Utilisation de l’éditeur CLI en mode configuration.
Pour effectuer une mise à niveau de ls-0/0/0 vers lsq-0/0/0 ou pour annuler cette modification :
Renommez toutes les occurrences de ls-0/0/0 dans la configuration.
[edit] user@host# rename interfaces ls-0/0/0 to lsq-0/0/0
Configurez la carte de fragmentation.
[edit class-of-service fragmentation-maps] user@host# set map6 forwarding-class assured-forwarding no-fragmentation
Spécifiez le numéro d’unité du faisceau multilien.
[edit class-of-service ] user@host# set interfaces lsq-0/0/0 unit 6 fragmentation-map map6
Annulez la configuration pour toutes les occurrences de la configuration.
[edit] user@host# rename interfaces lsq-0/0/0 to ls-0/0/0
Supprimer la carte de fragmentation sous Classe de service.
[edit] user@host# delete class-of-service fragmentation-maps map6
Supprimez le mappage de fragmentation s’il est affecté à l’interface lsq-0/0/0.
[edit class-of-service interfaces] user@host# delete lsq-0/0/0 unit 6 fragmentation-map map6
Supprimez les classes multilink max si elles sont configurées pour lsq-0/0/0.
Note:Multilink-max-classes n’est pas pris en charge et n’est probablement pas configuré.
Supprimez link-layer-overhead s’il est configuré pour lsq-0/0/0.
[edit interfaces] user@host# delete lsq-0/0/0 unit 6 link-layer-overhead
Supprimez link-layer-overhead s’il est configuré pour lsq-0/0/0:0.
[edit interfaces] user@host# delete lsq-0/0/0:0 mlfr-uni-nni-bundle-options link-layer-overhead
Configurez les fragments d’entrelacement pour l’interface ls-0/0/0.
[edit interfaces] user@host# set ls-0/0/0 unit 6 interleave-fragments
Résultats
À partir du mode configuration, confirmez votre configuration en entrant la show class-of-service commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration de cet exemple pour la corriger.
[edit]
user@host# show class-of-service
interfaces {
lsq-0/0/0 {
unit 6 {
fragmentation-map map6;
}
}
}
fragmentation-maps {
map6 {
forwarding-class {
assured-forwarding {
no-fragmentation;
}
}
}
}
Si vous avez terminé de configurer l’appareil, entrez en commit mode configuration.
Vérification
Vérifiez que la configuration fonctionne correctement.
Dépannage de l’interface des services de liaison
Pour résoudre les problèmes de configuration d’une interface de services de liaison :
- Déterminer quels composants CoS sont appliqués aux liens constitutifs
- Déterminez les causes de la gigue et de la latence sur le bundle multilink
- Déterminez si LFI et l’équilibrage de charge fonctionnent correctement
- Déterminer la raison pour laquelle des paquets sont perdus sur un circuit PVC entre un appareil Juniper Networks et un appareil tiers
Déterminer quels composants CoS sont appliqués aux liens constitutifs
Problème
Description
Vous configurez un bundle de liaisons multiples, mais vous avez également du trafic sans encapsulation MLPPP passant par des liens constitutifs du bundle de liaisons multiples. Appliquez-vous tous les composants CoS aux liaisons constitutives, ou les appliquer au bundle multilink est-il suffisant ?
Solution
Vous pouvez appliquer un mappage de planificateur au bundle de liaisons multiples et à ses liaisons constitutives. Bien que vous puissiez appliquer plusieurs composants CoS avec le mappage du planificateur, configurez uniquement ceux qui sont nécessaires. Nous vous recommandons de garder la configuration sur les liaisons constitutives simple pour éviter tout retard inutile dans la transmission.
Le Tableau 2 présente les composants CoS à appliquer à un faisceau multiliaison et aux liaisons qui le composent.
Composant Cos |
Offre groupée Multilink |
Liens constitutifs |
Explication |
|---|---|---|---|
Classificateur |
Oui |
Non |
La classification CoS a lieu du côté entrant de l’interface, et non du côté émetteur, de sorte qu’aucun classificateur n’est nécessaire sur les liens constitutifs. |
Classe de transfert |
Oui |
Non |
La classe de transfert est associée à une file d’attente, et la file d’attente est appliquée à l’interface par un mappage de planificateur. L’affectation de la file d’attente est prédéterminée sur les liens constitutifs. Tous les paquets de Q2 du bundle multilink sont affectés au Q2 du lien constitutif, et les paquets de toutes les autres files d’attente sont mis en file d’attente au Q0 du lien constitutif. |
Carte du planificateur |
Oui |
Oui |
Appliquez des mappages de planificateur sur le bundle de liaisons multiples et le lien constituant comme suit :
|
Fréquence de mise en forme d’un planificateur unitaire ou d’un planificateur au niveau de l’interface |
Non |
Oui |
Étant donné que la planification par unité n’est appliquée qu’au point final, appliquez cette vitesse de mise en forme aux liens constitutifs uniquement. Toute configuration appliquée précédemment est remplacée par la configuration de la liaison constitutive. |
Vitesse de transmission exacte ou mise en forme au niveau de la file d’attente |
Oui |
Non |
La mise en forme au niveau de l’interface appliquée aux liens constitutifs remplace toute mise en forme sur la file d’attente. Appliquez donc la mise en forme exacte du débit de transmission sur le faisceau multiliaison uniquement. |
Règles de réécriture |
Oui |
Non |
Les bits de réécriture sont copiés du paquet dans les fragments automatiquement lors de la fragmentation. Ainsi, ce que vous configurez sur le bundle multilink est transporté sur les fragments vers les liens constitutifs. |
Groupe de distribution virtuel |
Oui |
Non |
Les groupes de canaux virtuels sont identifiés par des règles de filtre de pare-feu qui sont appliquées aux paquets uniquement avant le bundle de liaisons multiples. Ainsi, vous n’avez pas besoin d’appliquer la configuration du groupe de canaux virtuels aux liens constitutifs. |
Voir aussi
Déterminez les causes de la gigue et de la latence sur le bundle multilink
Problème
Description
Pour tester la gigue et la latence, vous envoyez trois flux de paquets IP. Tous les paquets ont les mêmes paramètres de priorité IP. Après avoir configuré LFI et CRTP, la latence augmentait même sur une liaison non encombrée. Comment réduire la gigue et la latence ?
Solution
Pour réduire la gigue et la latence, procédez comme suit :
Assurez-vous d’avoir configuré une vitesse de mise en forme sur chaque lien constitutif.
Assurez-vous de ne pas avoir configuré de taux de mise en forme sur l’interface des services de liaison.
Assurez-vous que la valeur de la vitesse de mise en forme configurée est égale à la bande passante de l’interface physique.
Si les vitesses de mise en forme sont configurées correctement et que la gigue persiste, contactez le Centre d’assistance technique de Juniper Networks (JTAC).
Déterminez si LFI et l’équilibrage de charge fonctionnent correctement
Problème
Description
Dans ce cas, vous disposez d’un réseau unique qui prend en charge plusieurs services. Le réseau transmet des données et du trafic vocal sensible à la latence. Après avoir configuré MLPPP et LFI, assurez-vous que les paquets vocaux sont transmis sur le réseau avec un délai et une gigue minimes. Comment savoir si les paquets vocaux sont traités comme des paquets LFI et si l’équilibrage de charge est effectué correctement ?
Solution
Lorsque LFI est activé, les paquets de données (non-LFI) sont encapsulés avec un en-tête MLPPP et fragmentés en paquets d’une taille spécifiée. Les paquets vocaux sensibles au retard (LFI) sont encapsulés dans PPP et entrelacés entre les fragments de paquets de données. La mise en file d’attente et l’équilibrage de charge sont effectués différemment pour les paquets LFI et non-LFI.
Pour vérifier que LFI fonctionne correctement, déterminez que les paquets sont fragmentés et encapsulés comme configuré. Une fois que vous savez si un paquet est traité comme un paquet LFI ou non, vous pouvez confirmer si l’équilibrage de charge est correctement effectué.
Solution Scenario—Supposons que deux équipements Juniper Networks, R0 et R1, soient connectés par un bundle lsq-0/0/0.0 multilink qui agrège deux liaisons série, se-1/0/0 et se-1/0/1. Sur R0 et R1, MLPPP et LFI sont activés sur l’interface des services de liaison et le seuil de fragmentation est défini sur 128 octets.
Dans cet exemple, nous avons utilisé un générateur de paquets pour générer des flux de voix et de données. Vous pouvez utiliser la fonctionnalité de capture de paquets pour capturer et analyser les paquets sur l’interface entrante.
Les deux flux de données suivants ont été envoyés sur le lot multilink :
100 paquets de données de 200 octets (supérieurs au seuil de fragmentation)
500 paquets de données de 60 octets (inférieurs au seuil de fragmentation)
Les deux flux vocaux suivants ont été envoyés sur le forfait multiliaison :
100 paquets vocaux de 200 octets à partir du port source 100
300 paquets vocaux de 200 octets à partir du port source 200
Pour confirmer que la LFI et l’équilibrage de charge sont correctement exécutés :
Seules les parties significatives de la sortie de commande sont affichées et décrites dans cet exemple.
Vérifiez la fragmentation des paquets. Depuis le mode opérationnel, entrez la commande pour vérifier que les
show interfaces lsq-0/0/0gros paquets sont correctement fragmentés.user@R0#> show interfaces lsq-0/0/0 Physical interface: lsq-0/0/0, Enabled, Physical link is Up Interface index: 136, SNMP ifIndex: 29 Link-level type: LinkService, MTU: 1504 Device flags : Present Running Interface flags: Point-To-Point SNMP-Traps Last flapped : 2006-08-01 10:45:13 PDT (2w0d 06:06 ago) Input rate : 0 bps (0 pps) Output rate : 0 bps (0 pps) Logical interface lsq-0/0/0.0 (Index 69) (SNMP ifIndex 42) Flags: Point-To-Point SNMP-Traps 0x4000 Encapsulation: Multilink-PPP Bandwidth: 16mbps Statistics Frames fps Bytes bps Bundle: Fragments: Input : 0 0 0 0 Output: 1100 0 118800 0 Packets: Input : 0 0 0 0 Output: 1000 0 112000 0 ... Protocol inet, MTU: 1500 Flags: None Addresses, Flags: Is-Preferred Is-Primary Destination: 9.9.9/24, Local: 9.9.9.10Meaning: la sortie affiche un résumé des paquets transitant par l’appareil sur le bundle multilink. Vérifiez les informations suivantes sur le bundle multilink :Nombre total de paquets en transit = 1000
Le nombre total de fragments en transit = 1100
Nombre de paquets de données fragmentés = 100
Le nombre total de paquets envoyés (600 + 400) sur le bundle multilink correspond au nombre de paquets en transit (1000), ce qui indique qu’aucun paquet n’a été perdu.
Le nombre de fragments en transit dépasse de 100 le nombre de paquets en transit, ce qui indique que 100 gros paquets de données ont été correctement fragmentés.
Corrective Action: si les paquets ne sont pas fragmentés correctement, vérifiez votre configuration du seuil de fragmentation. Les paquets inférieurs au seuil de fragmentation spécifié ne sont pas fragmentés.Vérifiez l’encapsulation des paquets. Pour savoir si un paquet est traité comme un paquet LFI ou non-LFI, déterminez son type d’encapsulation. Les paquets LFI sont encapsulés PPP et les paquets non-LFI sont encapsulés avec PPP et MLPPP. Les encapsulations PPP et MLPPP ont des surcharges différentes, ce qui donne des paquets de tailles différentes. Vous pouvez comparer la taille des paquets pour déterminer le type d’encapsulation.
Un petit paquet de données non fragmenté contient un en-tête PPP et un en-tête MLPPP unique. Dans un paquet de données fragmenté volumineux, le premier fragment contient un en-tête PPP et un en-tête MLPPP, mais les fragments consécutifs ne contiennent qu’un en-tête MLPPP.
Les encapsulations PPP et MLPPP ajoutent le nombre d’octets suivant à un paquet :
L’encapsulation PPP ajoute 7 octets :
4 octets d’en-tête + 2 octets de séquence de vérification de trame (FCS) + 1 octet inactif ou contenant un indicateur
L’encapsulation MLPPP ajoute entre 6 et 8 octets :
4 octets d’en-tête PPP + 2 à 4 octets d’en-tête multilink
La figure 2 montre la surcharge ajoutée aux en-têtes PPP et MLPPP.
Figure 2 : En-têtes
PPP et MLPPP
Pour les paquets CRTP, la surcharge d’encapsulation et la taille des paquets sont encore plus petites que pour un paquet LFI. Pour plus d’informations, consultez Exemple : configuration du protocole de transport en temps réel compressé.
Le Tableau 3 indique la surcharge d’encapsulation pour un paquet de données et un paquet vocal de 70 octets chacun. Après encapsulation, la taille du paquet de données est supérieure à la taille du paquet vocal.
Tableau 3 : surcharge d’encapsulation PPP et MLPPP Type de paquet
Encapsulation
Taille initiale du paquet
Overhead d’encapsulation
Taille du paquet après encapsulation
Paquet vocal (LFI)
PPP
70 octets
4 + 2 + 1 = 7 octets
77 octets
Fragment de données (non-LFI) avec séquence courte
MLPPP
70 octets
4 + 2 + 1 + 4 + 2 = 13 octets
83 octets
Fragment de données (non-LFI) avec une longue séquence
MLPPP
70 octets
4 + 2 + 1 + 4 + 4 = 15 octets
85 octets
En mode opérationnel, entrez la
show interfaces queuecommande pour afficher la taille du paquet transmis sur chaque file d’attente. Divisez le nombre d’octets transmis par le nombre de paquets pour obtenir la taille des paquets et déterminer le type d’encapsulation.Vérifiez l’équilibrage de charge. À partir du mode opérationnel, entrez la
show interfaces queuecommande sur le faisceau multiliaison et ses liaisons constitutives pour confirmer si l’équilibrage de charge est effectué en conséquence sur les paquets.user@R0> show interfaces queue lsq-0/0/0 Physical interface: lsq-0/0/0, Enabled, Physical link is Up Interface index: 136, SNMP ifIndex: 29 Forwarding classes: 8 supported, 8 in use Egress queues: 8 supported, 8 in use Queue: 0, Forwarding classes: DATA Queued: Packets : 600 0 pps Bytes : 44800 0 bps Transmitted: Packets : 600 0 pps Bytes : 44800 0 bps Tail-dropped packets : 0 0 pps RED-dropped packets : 0 0 pps … Queue: 1, Forwarding classes: expedited-forwarding Queued: Packets : 0 0 pps Bytes : 0 0 bps … Queue: 2, Forwarding classes: VOICE Queued: Packets : 400 0 pps Bytes : 61344 0 bps Transmitted: Packets : 400 0 pps Bytes : 61344 0 bps … Queue: 3, Forwarding classes: NC Queued: Packets : 0 0 pps Bytes : 0 0 bps …user@R0> show interfaces queue se-1/0/0 Physical interface: se-1/0/0, Enabled, Physical link is Up Interface index: 141, SNMP ifIndex: 35 Forwarding classes: 8 supported, 8 in use Egress queues: 8 supported, 8 in use Queue: 0, Forwarding classes: DATA Queued: Packets : 350 0 pps Bytes : 24350 0 bps Transmitted: Packets : 350 0 pps Bytes : 24350 0 bps ... Queue: 1, Forwarding classes: expedited-forwarding Queued: Packets : 0 0 pps Bytes : 0 0 bps … Queue: 2, Forwarding classes: VOICE Queued: Packets : 100 0 pps Bytes : 15272 0 bps Transmitted: Packets : 100 0 pps Bytes : 15272 0 bps … Queue: 3, Forwarding classes: NC Queued: Packets : 19 0 pps Bytes : 247 0 bps Transmitted: Packets : 19 0 pps Bytes : 247 0 bps …user@R0> show interfaces queue se-1/0/1 Physical interface: se-1/0/1, Enabled, Physical link is Up Interface index: 142, SNMP ifIndex: 38 Forwarding classes: 8 supported, 8 in use Egress queues: 8 supported, 8 in use Queue: 0, Forwarding classes: DATA Queued: Packets : 350 0 pps Bytes : 24350 0 bps Transmitted: Packets : 350 0 pps Bytes : 24350 0 bps … Queue: 1, Forwarding classes: expedited-forwarding Queued: Packets : 0 0 pps Bytes : 0 0 bps … Queue: 2, Forwarding classes: VOICE Queued: Packets : 300 0 pps Bytes : 45672 0 bps Transmitted: Packets : 300 0 pps Bytes : 45672 0 bps … Queue: 3, Forwarding classes: NC Queued: Packets : 18 0 pps Bytes : 234 0 bps Transmitted: Packets : 18 0 pps Bytes : 234 0 bpsMeaning: le résultat de ces commandes affiche les paquets transmis et mis en file d’attente sur chaque file d’attente de l’interface des services de liaison et des liaisons qui la composent. Le Tableau 4 présente un résumé de ces valeurs. (Le nombre de paquets transmis étant égal au nombre de paquets en file d’attente sur toutes les liaisons, ce tableau affiche uniquement les paquets en file d’attente.)Tableau 4 : nombre de paquets transmis sur une file d’attente Paquets en file d’attente
Bundle lsq-0/0/0.0
Lien constituant se-1/0/0
Lien constituant se-1/0/1
Explication
Paquets au T0
600
350
350
Le nombre total de paquets transitant par les liaisons constitutives (350+350 = 700) dépassait le nombre de paquets mis en file d’attente (600) sur le faisceau multilien.
Paquets au T2
400
100
300
Le nombre total de paquets transitant par les liaisons constitutives était égal au nombre de paquets sur le paquet.
Paquets au T3
0
19
18
Les paquets transitant par Q3 des liens constitutifs sont destinés aux messages keepalive échangés entre les liens constitutifs. Ainsi, aucun paquet n’a été compté au 3e trimestre du lot.
Sur le bundle multilink, vérifiez les points suivants :
Le nombre de paquets mis en file d’attente correspond au nombre de paquets transmis. Si les chiffres correspondent, aucun paquet n’a été perdu. Si le nombre de paquets mis en file d’attente était supérieur à celui transmis, les paquets étaient perdus en raison d’une trop petite taille de la mémoire tampon. La taille de la mémoire tampon sur les liens constitutifs contrôle la congestion à l’étape de sortie. Pour corriger ce problème, augmentez la taille de la mémoire tampon sur les liens constitutifs.
Le nombre de paquets transitant par Q0 (600) correspond au nombre de paquets de données de grande et de petite taille reçus (100+500) sur le bundle multilink. Si les nombres correspondent, tous les paquets de données ont correctement transité par Q0.
Le nombre de paquets transitant par Q2 sur le bundle multilink (400) correspond au nombre de paquets vocaux reçus sur le bundle multilink. Si les chiffres correspondent, tous les paquets LFI vocaux ont correctement transité par Q2.
Sur les liens des constituants, vérifiez les points suivants :
Le nombre total de paquets transitant par Q0 (350+350) correspond au nombre de paquets et de fragments de données (500+200). Si les nombres correspondent, tous les paquets de données après fragmentation ont correctement transité Q0 des liens constitutifs.
Les paquets ont transité par les deux liaisons constitutives, ce qui indique que l’équilibrage de charge a été correctement effectué sur les paquets non-LFI.
Le nombre total de paquets transitant au T2 (300+100) sur les liaisons constitutives correspond au nombre de paquets vocaux reçus (400) sur le faisceau multilien. Si les chiffres correspondent, tous les paquets LFI vocaux ont correctement transité par Q2.
Les paquets LFI du port
100source ontse-1/0/0transité et les paquets LFI du port200source ont transitése-1/0/1. Ainsi, tous les paquets LFI (Q2) ont été hachés en fonction du port source et ont correctement transité par les deux liens constitutifs.
Corrective Action: si les paquets n’ont transité que par une seule liaison, procédez comme suit pour résoudre le problème :Déterminez si la liaison physique est
up(opérationnelle) oudown(indisponible). Un lien indisponible indique un problème avec le PIM, le port d’interface ou la connexion physique (erreurs de couche de lien). Si la liaison est opérationnelle, passez à l’étape suivante.Vérifiez que les classificateurs sont correctement définis pour les paquets non-LFI. Assurez-vous que les paquets non-LFI ne sont pas configurés pour être mis en file d’attente au 2e trimestre. Tous les paquets mis en file d’attente jusqu’à Q2 sont traités comme des paquets LFI.
Vérifiez qu’au moins une des valeurs suivantes est différente dans les paquets LFI : adresse source, adresse de destination, protocole IP, port source ou port de destination. Si les mêmes valeurs sont configurées pour tous les paquets LFI, les paquets sont tous hachés dans le même flux et transitent par le même lien.
Utilisez les résultats pour vérifier l’équilibrage de charge.
Déterminer la raison pour laquelle des paquets sont perdus sur un circuit PVC entre un appareil Juniper Networks et un appareil tiers
Problème
Description
Vous configurez un circuit virtuel permanent (PVC) entre des interfaces T1, E1, T3 ou E3 sur un équipement Juniper Networks et un équipement tiers, et des paquets sont abandonnés et le ping échoue.
Solution
Si l’appareil tiers ne prend pas en charge FRF.12 de la même manière que l’appareil Juniper Networks ou s’il prend en charge FRF.12 d’une manière différente, l’interface de l’équipement Juniper Networks sur la carte PVC peut ignorer un paquet fragmenté contenant des en-têtes FRF.12 et le compter comme une « exclusion contrôlée ».
Pour contourner ce problème, configurez les bundles multilink sur les deux homologues et configurez les seuils de fragmentation sur les bundles multilink.