configuration des interfaces des services de liaison
Les équipements Juniper Networks prennent en charge les services de liaison sur l’interface de file d’attente lsq-0/0/0 des services de liaison qui inclut des services multiliaisons tels que MLPP, MLFR et CRTP. Les rubriques ci-dessous présentent les services de liaison, les détails de configuration et la vérification des services de liaison sur les pare-feu SRX Series.
Vue d’ensemble des interfaces de services de liaison
Les services de liaison comprennent les services multiliaisons 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 liaison sur l’interface de file d’attente des services de lsq-0/0/0 liaison.
Vous configurez l’interface de file d’attente des services de liaison (lsq-0/0/0) sur un équipement Juniper Networks afin qu’il prenne en charge les services multiliaisons et CRTP.
L’interface de file d’attente des services de liaison sur les pare-feu SRX Series comprend les services fournis par les interfaces suivantes sur les plates-formes de routage Juniper Networks M Series et T Series : l’interface de services multiliaison (ml-fpc/pic/port), l’interface de services de liaison (ls-fpc/pic/port) et l’interface de file d’attente intelligente des services de liaison (lsq-fpc/pic/port). Bien que les services multiliaison, les services de liaison et les interfaces de file d’attente intelligente (IQ) des plates-formes de routage M Series et T Series soient installés sur des cartes d’interface physique (PIC), l’interface de file d’attente des services de liaison sur les pare-feu SRX Series 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 sur les pare-feu SRX Series.
Cette section contient les rubriques suivantes.
- Services disponibles sur une interface de services de liaison
- Exceptions relatives aux services de liaison
- 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 liaison est une interface logique disponible par défaut. Le Tableau 1 récapitule les services disponibles sur l’interface.
Services |
But |
Plus d’informations |
|---|---|---|
Faisceaux multiliaisons grâce à l’encapsulation MLPPP et MLFR |
Agrège plusieurs liens constitutifs en un seul ensemble logique plus grand pour fournir une bande passante, un équilibrage de charge et une redondance supplémentaires.
Note:
Les configurations du contrôle d’admission d’appel dynamique (DCAC) ne sont pas prises en charge sur les interfaces de services de liaison. |
|
Fragmentation et entrelacement de liens (LFI) |
Réduit le délai et la gigue sur les liaisons en fractionnant les gros paquets de données et en entrelaçant les paquets vocaux sensibles au délai avec les paquets plus petits qui en résultent. |
Comprendre la fragmentation de liaison et la configuration d’entrelacement |
Protocole de transport en temps réel compressé (CRTP) |
Réduit la surcharge causée par le protocole de transport en temps réel (RTP) sur les paquets voix et vidéo. |
Présentation du protocole de transport en temps réel compressé |
Classificateurs de classe de service (CoS), classes de transfert, planificateurs, cartes d’ordonnanceur et taux de mise en forme |
Accorde une priorité plus élevée aux paquets sensibles à la latence en configurant la classe de service (CoS, par exemple) :
|
Exceptions relatives aux services de liaison
L’implémentation des services de liaison et multiliaison sur les pare-feu SRX Series est similaire à celle des plates-formes de routage M Series et T Series, avec les exceptions suivantes :
La prise en charge des services de liaison et multiliaison se trouve sur l’interface
lsq-0/0/0au lieu desml-fpc/pic/portinterfaces ,lsq-fpc/pic/portet .ls-fpc/pic/portLorsque LFI est activé, les paquets fragmentés sont mis en file d’attente de manière circulaire sur les liens constitutifs 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é se fait sur tous les types de liaisons constitutives (sur tous les types d’interfaces).
La prise en charge du protocole CRTP (Compressed Real-Time Transport Protocol) concerne à la fois MLPPP et PPP.
Configuration de MLPPP multiclasse
Sur lsq-0/0/0 les équipements Juniper Networks, avec l’encapsulation MLPPP, vous pouvez configurer MLPPP multiclasse. Si vous ne configurez pas MLPPP multiclasse, les fragments de différentes classes ne peuvent pas être entrelacés. Tous les fragments d’un 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 multiliaison. Ce modèle fonctionne tant qu’il existe une seule classe de trafic sensible à la latence et qu’aucun trafic prioritaire n’est prioritaire sur le trafic sensible à la latence. Cette approche de LFI, utilisée sur le PIC des 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 prises en charge par les plates-formes de routage des séries M et T.
Le MLPPP multiclasse permet d’avoir plusieurs classes de trafic sensible à la latence qui sont acheminées 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 multiclass MLPPP, vous pouvez mapper chaque classe de transfert dans une classe multilink distincte, préservant ainsi les garanties de priorité et de latence.
Il n’est pas nécessaire et n’est pas non plus pris en charge de configurer LFI et MLPPP multiclasse sur le même bundle, car MLPPP multiclasse représente un sur-ensemble 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 PPP NCP de compression de champ d’adresse et de compression de champ de protocole, 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 de classement des paquets qui se produisent lorsque plusieurs liaisons sont utilisées. Sans MLPPP multiclasse, tout le trafic vocal appartenant à un seul flux est haché sur un lien unique afin d’éviter les problèmes d’ordre des paquets. Avec MLPPP multiclasse, vous pouvez affecter le trafic vocal à une classe de priorité élevée et utiliser plusieurs liaisons.
Pour configurer MLPPP multiclasse sur une interface IQ de services de liaison, vous devez spécifier le nombre de classes multiliaisons à négocier lorsqu’une liaison 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 multilink qui doivent être négociées lorsqu’un lien rejoint le bundle, incluez l’instruction multilink-max-classes suivante :
multilink-max-classes number;
Vous pouvez inclure cette instruction 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 multiliaisons peut être compris entre 1 et 8. Le nombre de classes multiliaisons pour chaque classe de transfert ne doit pas dépasser le nombre de classes multiliaisons à négocier.
Pour spécifier le mappage d’une classe de transfert dans une classe MLPPP multiclasse, incluez l’instruction au multilink-class 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 la classe multiliaison peut être compris entre 0 et 7. L’énoncé multilink-class et l’énoncé s’excluent no-fragmentation mutuellement.
Pour afficher le nombre de classes multiliaisons 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 liaisons constitutives en fonction des files d’attente dans lesquelles ils arrivent. Aucune modification du numéro de file 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 la file d’attente Q0 est configurée avec le seuil de fragmentation 128, Q1 est configurée sans fragmentation et Q2 est configurée avec le seuil de fragmentation 512. Q0 reçoit un flux de trafic avec une taille de paquet 512. Q1 reçoit un trafic vocal de 64 octets et Q2 un flux de trafic de 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 le Q0 sur le lien constituant. Le flux sur 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 constituante. Tous les paquets de Q1 sont mis en file d’attente au Q2 de la liaison constituante.
À l’aide lsq-0/0/0de , CRTP peut être appliqué sur des paquets LFI et non-LFI. Il n’y aura aucun changement dans le nombre de files d’attente à cause du CRTP.
File d’attente au Q2s des Constituants Links
Lors de l’utilisation de la classe de service sur un bundle multilink, tout le trafic Q2 du bundle multilink est mis en file d’attente vers Q2 des liens constitutifs 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. À la suite de cet algorithme de hachage, tout le trafic appartenant à un flux de trafic est mis en file d’attente au Q2 d’un lien constitutif. Cette méthode d’acheminement du trafic vers le lien constitutif est appliquée à tout moment, y compris lorsque le bundle 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 permettre 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 volumineux (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 du réseau sur les liaisons à faible débit. 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 des en-têtes.
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 MLPPP ou l’encapsulation d’interface logique PPP sur les interfaces de services de liaison. Reportez-vous à la section 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 vitesse sans causer de retards excessifs dans le trafic en temps réel. Reportez-vous à la section Présentation de la fragmentation des liens et de la configuration de l’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é multiliaison (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 de 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 de toutes les classes de transfert au sein de l’interface MLFR FRF.16.
Si vous ne définissez pas de 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é maximale reconstruite reçue (MRRU) de toutes les liaisons du paquet. Un flux non encapsulé n’utilise qu’une seule liaison. Si le flux dépasse une liaison unique, la classe de transfert doit être encapsulée sur plusieurs liaisons, sauf si la taille du paquet dépasse la MTU/MRRU.
Même si vous ne définissez pas de taille maximale de fragment 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] 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 1504 octets et vous pouvez la configurer pour qu’elle soit comprise entre 1500 et 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 la carte 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 à être non encapsulé plutôt qu’encapsulé sur plusieurs liaisons, incluez l’instruction no-fragmentation dans la carte de fragmentation. Cette instruction spécifie qu’un en-tête de fragmentation supplémentaire n’est pas 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 fragment-threshold ou no-fragmentation ; elles s’excluent 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 multilink-class ou no-fragmentation ; elles s’excluent mutuellement.
Pour associer une carte de fragmentation à une interface PPP multiliaison ou à un DLCI MLFR FRF.16, incluez l’instruction suivante 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
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 %.
Sur lsq-0/0/0 les équipements Juniper Networks, vous pouvez configurer le pourcentage de la bande passante du bundle à 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 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-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 %.
Vue d’ensemble 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. Reportez-vous à la section Présentation des interfaces
Planifiez la façon dont vous allez utiliser l’interface des services de liaison sur votre réseau. Reportez-vous à la section Présentation des interfaces des services de liaison.
Pour configurer les services de liaison sur une interface, effectuez les tâches suivantes :
- Configurez la fragmentation et l’entrelacement de liaisons (LFI). Reportez-vous à la section Exemple : Configuration de la fragmentation et de l’entrelacement des liens.
- Configurez les classificateurs et les classes de transfert. Voir Exemple : Définition de classificateurs et transfert de classes.
- Configurez les cartes du planificateur. Reportez-vous à la section Comprendre comment définir et appliquer des mappages de planificateur.
- Configurez les taux de mise en forme de l’interface. Voir Exemple : Configuration des taux de mise en forme de l’interface
- Configurez un bundle MLPPP. Reportez-vous à la section Exemple : Configuration d’un bundle MLPPP.
- Pour configurer MLFR, reportez-vous à la section Exemple : Configuration du relais de trames multiliaison FRF.15 ou Exemple : Configuration du relais de trames multiliaison FRF.16
- Pour configurer CRTP, reportez-vous à la section 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 CoS des services de liaison
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 au bundle et que les paquets sont fragmentés et transmis correctement, procédez comme suit :
Sur les appareils R0 et R1, les deux appareils utilisés dans cet exemple, configurent MLPPP et LFI comme décrit dans Exemple : Configuration d’un bundle MLPPP.
À partir de l’interface de ligne de commande, entrez la
pingcommande pour vérifier qu’une connexion est établie entre R0 et R1.Transmettre 10 paquets de données de 200 octets chacun de R0 à R1.
Sur R0, à partir de l’interface de ligne de commande, 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 sur l’interface. Vérifiez les informations suivantes :
Physical interface: l’interface physique estEnabled. Si l’interface s’affiche sous la formeDisabled, effectuez l’une des opérations suivantes :Dans l’éditeur de configuration 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: le lien physique estUp. L’état de liaison de indique un problème au niveau du module d’interface, du port d’interfaceDownou de la connexion physique (erreurs de couche de liaison).Last flapped: l’heureLast Flappedest une valeur attendue. L’heureLast Flappedindique la dernière fois que l’interface physique est devenue indisponible, puis à nouveau disponible. Des instabilités inattendues indiquent 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 n’afficher que les nouvelles modifications, utilisez laclear interfaces statistics interface-namecommande.Queue counters: le nom et le nombre de files d’attente sont tels que configurés. Cet exemple de sortie montre que 10 paquets de données ont été transmis et qu’aucun paquet n’a été abandonné.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 abandonnés 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. Étant donné que le seuil de fragmentation est fixé à 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 de la liasse. Cet exemple de sortie montre que le faisceau a transmis 20 fragments et que les deux liensse-1/0/0.0constitutifs ontse-1/0/1.0.0été transmis10+10=20correctement.DestinationetLocal: adresse IP du côté distant du bundle multilink et du côté local du bundle multilink. 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 CoS des services de liaison
But
Vérifiez les configurations CoS sur l’interface des services de liaison.
Action
À partir de l’interface de ligne de commande, 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 bundle 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 la cartes_mapdu planificateur CoS lui est appliquée.Classifier: points de code, classes de transfert et priorités de perte attribués 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: taux de transmission, taille de la mémoire tampon, priorité et priorité de perte attribués à chaque planificateur. L’exemple de sortie affiche les planificateurs de contrôle de données, de voix et de réseau avec toutes les valeurs configurées.
Comprendre la configuration LSQ-0/0/0 de l’interface interne
L’interface des services de liaison est une interface interne uniquement. Il n’est pas associé à un support physique ou à un PIM. Dans un pare-feu SRX Series, les paquets sont acheminés vers cette interface pour le regroupement ou la compression des liens.
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 restaurer 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 multiliaisons
Cet exemple montre comment passer de ls-0/0/0 à lsq-0/0/0 (ou pour annuler la modification) pour les services multiliaison.
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 liaison de ls-0/0/0 à 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 spécifiez qu’il n’y a pas de fragmentation après le nom de la file d’attente 2, si la file d’attente 2 est configurée ou après un 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 faisceau de liaisons multiples 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 à ls-0/0/0. Vous supprimez la carte de fragmentation si elle est configurée sous la hiérarchie [class-of-service] et vous supprimez la carte de fragmentation si elle est affectée à lsq-0/0/0. Vous pouvez supprimer multilink-max-classes s’il est configuré pour lsq-0/0/0 sous la hiérarchie [interfaces]. Vous supprimez ensuite link-layer-overhead s’il est configuré pour lsq-0/0/0 sous la hiérarchie [interfaces].
Si aucune fragmentation n’est configurée sur une classe de transfert et que la carte de fragmentation est affectée à 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 passer rapidement de ls-0/0/0 à lsq-0/0/0 (ou annuler la modification), copiez les commandes suivantes et collez-les dans l’interface de ligne de commande :
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, reportez-vous à la section 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 ce changement :
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 multiliaison.
[edit class-of-service ] user@host# set interfaces lsq-0/0/0 unit 6 fragmentation-map map6
Restaurez la configuration pour toutes les occurrences de la configuration.
[edit] user@host# rename interfaces lsq-0/0/0 to ls-0/0/0
Supprimez la carte de fragmentation sous classe de service.
[edit] user@host# delete class-of-service fragmentation-maps map6
Supprimez la carte de fragmentation si elle est affectée à 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 max multiliaisons s’il est configuré pour lsq-0/0/0.
Note:Multilink-max-classes n’est pas pris en charge et n’est probablement pas configuré.
Supprimez la surcharge de couche de liaison si elle est configurée pour lsq-0/0/0.
[edit interfaces] user@host# delete lsq-0/0/0 unit 6 link-layer-overhead
Supprimez la surcharge de couche de liaison si elle est configurée 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, passez commit en mode de 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 sur 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 multiliaisons
- Déterminez si le LFI et l’équilibrage de charge fonctionnent correctement
- Déterminez pourquoi des paquets sont abandonnés sur un circuit virtuel virtuel entre un équipement Juniper Networks et un équipement tiers
Déterminer quels composants CoS sont appliqués aux liens constitutifs
Problème
Description
Vous configurez un bundle multilink, mais vous avez également du trafic sans encapsulation MLPPP qui passe par les liens constitutifs du bundle multilink. Appliquez-vous tous les composants CoS aux liaisons constitutives ou leur application au bundle multilink est-elle suffisante ?
Solution
Vous pouvez appliquer un mappage de planificateur à l’ensemble de liaisons multiples et à ses liens constitutifs. Bien que vous puissiez appliquer plusieurs composants CoS avec la carte du planificateur, configurez uniquement ceux qui sont nécessaires. Nous vous recommandons de garder la configuration sur les liens constitutifs simple afin d’éviter tout retard inutile dans la transmission.
Le Tableau 2 présente les composants CoS à appliquer sur un faisceau de liaisons multiples et ses liaisons constitutives.
Composant Cos |
Offre groupée multiliaison |
Liens constitutifs |
Explication |
|---|---|---|---|
Classificateur |
Oui |
Non |
La classification CoS s’effectue du côté entrant de l’interface, et non du côté émetteur, de sorte qu’aucun classificateur n’est nécessaire sur les liaisons constitutives. |
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 une carte 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 à Q2 du lien constitutif, et les paquets de toutes les autres files d’attente sont mis en file d’attente à Q0 du lien constitutif. |
Carte du planificateur |
Oui |
Oui |
Appliquez les mappages du planificateur sur le faisceau de liaisons multiples et le lien constitutif comme suit :
|
Taux de mise en forme d’un planificateur unitaire ou d’un planificateur au niveau de l’interface |
Non |
Oui |
Étant donné que l’ordonnancement par unité n’est appliqué qu’au point d’extrémité, appliquez ce taux de mise en forme aux liens constitutifs uniquement. Toute configuration appliquée antérieurement est écrasée par la configuration du lien constitutif. |
Modélisation exacte du débit de transmission ou 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 de la file d’attente. Appliquez donc la mise en forme exacte du débit de transmission uniquement sur le faisceau multiliaison. |
Règles de réécriture |
Oui |
Non |
Les bits de réécriture sont automatiquement copiés du paquet dans les fragments lors de la fragmentation. Ainsi, ce que vous configurez sur le bundle multilink est transporté sur les fragments vers les liens constitutifs. |
Groupe de canaux virtuels |
Oui |
Non |
Les groupes de canaux virtuels sont identifiés à l’aide de règles de filtre de pare-feu qui sont appliquées aux paquets uniquement avant le bundle multiliaison. Par conséquent, 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 multiliaisons
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 configuration de 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é un taux de mise en forme sur chaque lien constitutif.
Assurez-vous que vous n’avez pas configuré de taux de mise en forme sur l’interface des services de liaison.
Assurez-vous que la valeur du taux de mise en forme configurée est égale à la bande passante de l’interface physique.
Si les taux de mise en forme sont correctement configurés et que la gigue persiste, contactez le Centre d’assistance technique de Juniper Networks (JTAC).
Déterminez si le 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 le trafic de données et de voix sensible au retard. Après avoir configuré MLPPP et LFI, assurez-vous que les paquets vocaux sont transmis sur le réseau avec très peu de retard et de gigue. Comment savoir si les paquets vocaux sont traités comme des paquets LFI et si l’équilibrage de charge est correctement effectué ?
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 délai (LFI) sont encapsulés en 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 est correctement exécuté, vérifiez 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 vérifier si l’équilibrage de charge est correctement effectué.
Solution Scenario—Supposons que deux équipements Juniper Networks, R0 et R1, soient connectés par un faisceau lsq-0/0/0.0 multiliaison 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 vocaux 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 bundle multilink :
100 paquets de données de 200 octets (supérieurs au seuil de fragmentation)
500 paquets de données de 60 octets (inférieur au seuil de fragmentation)
Les deux flux vocaux suivants ont été envoyés sur le bundle multilink :
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 LFI et l’équilibrage de charge sont correctement effectués :
Seules les parties significatives de la sortie de la commande sont affichées et décrites dans cet exemple.
Vérifiez la fragmentation des paquets. À partir du mode opérationnel, entrez la
show interfaces lsq-0/0/0commande pour vérifier que les paquets volumineux 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écapitulatif des paquets transitant par l’équipement sur le faisceau de liaisons multiples. Vérifiez les informations suivantes sur le bundle multilink :Le nombre total de paquets en transit = 1000
Le nombre total de fragments en transit = 1100
Le 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é abandonné.
Le nombre de fragments en transit dépasse de 100 le nombre de paquets en transit, ce qui indique que 100 paquets de données volumineux ont été correctement fragmentés.
Corrective Action: si les paquets ne sont pas fragmentés correctement, vérifiez la configuration de votre 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 en PPP, et les paquets non-LFI sont encapsulés à la fois avec PPP et MLPPP. Les encapsulations PPP et MLPPP ont des surcharges différentes, ce qui entraîne des paquets de tailles différentes. Vous pouvez comparer les tailles de paquets pour déterminer le type d’encapsulation.
Un petit paquet de données non fragmenté contient un en-tête PPP et un seul en-tête MLPPP. 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 suivants 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 illustre 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 montre 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 : overhead 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
Le MLPPP (en anglais seulement)
70 octets
4 + 2 + 1 + 4 + 2 = 13 octets
83 octets
Fragment de données (non-LFI) avec séquence longue
Le MLPPP (en anglais seulement)
70 octets
4 + 2 + 1 + 4 + 4 = 15 octets
85 octets
Depuis le 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 bundle multilink et ses liens constitutifs pour vérifier si l’équilibrage de charge est correctement effectué 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: la sortie 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 les liens qui la constituent. Le tableau 4 présente un résumé de ces valeurs. (Étant donné que le nombre de paquets transmis est é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 mis en file d’attente
Bundle lsq-0/0/0.0
Lien constitutif se-1/0/0
Lien constitutif 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 en file d’attente (600) sur le faisceau de liaisons multiples.
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 Q3 des liens constitutifs sont destinés aux messages keepalive échangés entre les liens constitutifs. Ainsi, aucun paquet n’a été compté au Q3 du paquet.
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 numéros correspondent, aucun paquet n’a été abandonné. Si le nombre de paquets transmis était supérieur à celui détecté, des paquets étaient abandonnés car la mémoire tampon était trop petite. La taille de la mémoire tampon sur les liens constitutifs contrôle l’encombrement à 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 Q0 (600) correspond au nombre de paquets de données de grande et de petite taille reçus (100+500) sur le bundle multiliaison. Si les chiffres correspondent, tous les paquets de données ont correctement transité Q0.
Le nombre de paquets transitant Q2 sur le paquet multiliaison (400) correspond au nombre de paquets vocaux reçus sur le paquet multiliaison. Si les chiffres correspondent, tous les paquets LFI vocaux ont correctement transité au T2.
Sur les liens constitutifs, vérifiez les points suivants :
Le nombre total de paquets transitant par Q0 (350+350) correspond au nombre de paquets de données 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 liaisons constitutives.
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 Q2 (300+100) sur les liaisons constitutives correspond au nombre de paquets vocaux reçus (400) sur le faisceau multiliaison. Si les chiffres correspondent, tous les paquets LFI vocaux ont correctement transité au T2.
Les paquets LFI du port
100source ontse-1/0/0transité , et les paquets LFI du port200source ontse-1/0/1transité . Ainsi, tous les paquets LFI (Q2) ont été hachés en fonction du port source et ont correctement transité par les deux liaisons constitutives.
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). Une liaison indisponible indique un problème au niveau du PIM, du port d’interface ou de la connexion physique (erreurs de couche de liaison). 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 jusqu’au Q2. Tous les paquets mis en file d’attente 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 la même liaison.
Utilisez les résultats pour vérifier l’équilibrage de charge.
Déterminez pourquoi des paquets sont abandonnés sur un circuit virtuel virtuel entre un équipement Juniper Networks et un équipement tiers
Problème
Description
Vous configurez un circuit virtuel permanent (PVC) entre les interfaces T1, E1, T3 ou E3 sur un équipement Juniper Networks et un équipement tiers, et des paquets sont abandonnés et la commande ping échoue.
Solution
Si l’équipement tiers ne prend pas en charge FRF.12 de la même manière que l’équipement Juniper Networks ou s’il prend en charge FRF.12 d’une manière différente, l’interface de l’équipement Juniper Networks sur le circuit virtuel peut ignorer un paquet fragmenté contenant des en-têtes FRF.12 et le considérer comme un « rejet contrôlé ».
Pour contourner ce problème, configurez les bundles multiliaisons sur les deux homologues et configurez les seuils de fragmentation sur les bundles multiliaisons.