Configuration de LFI (Link Fragmentation and Interleaving) avec les commutateurs de campus ATM

Introduction

Ce document fournit une présentation technique de la fragmentation et de l'entrelacement de liens (LFI) sur une connexion d'interfonctionnement Frame Relay vers ATM (IWF) (telle que définie par le Frame Relay Forum ou l'accord FRF.8), ainsi qu'un exemple de configuration pour l'utilisation du LS1010 ou du Catalyst 8500 comme périphérique IWF dans le nuage WAN. LFI utilise les fonctionnalités de fragmentation intégrées de l’encapsulation MLPPP (Multilink Point-to-Point Protocol) sur ATM et Frame Relay pour fournir une solution de fragmentation et d’entrelacement de bout en bout pour les liaisons à faible débit avec des bandes passantes allant jusqu’à 768 kbits/s.

Conditions préalables

Exigences

Ce document exige une compréhension des éléments suivants :

• Environnement FRF.8 standard et modes de traduction et transparents FRF.8 - Voir Présentation des modes de traduction et transparents avec FRF.8.

• Connaissance des commandes de configuration LS1010 et Catalyst 8500 et de la manière dont l’adaptateur de port Frame Relay E1 multicanal fractionné ou l’adaptateur de port Frame Relay DS3 multicanal fractionné effectue l’interfonctionnement entre un point d’extrémité Frame Relay et un point d’extrémité ATM.

• Délai de sérialisation et gigue. Voir VoIP sur liaisons PPP avec qualité de service (LLQ / IP RTP Priority, LFI, cRTP) et VoIP sur relais de trames avec qualité de service (Fragmentation, Traffic Shaping, IP RTP Priority).

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Pourquoi MLPPP sur ATM et Frame Relay ?

La fragmentation est une technique clé pour contrôler le délai de sérialisation et la variation du délai sur des liaisons à faible vitesse acheminant du trafic en temps réel et non en temps réel. Le délai de sérialisation est le délai fixe nécessaire pour synchroniser une trame vocale ou de données sur l’interface réseau. Il est directement lié à la fréquence d’horloge de la liaison. Un indicateur supplémentaire est nécessaire pour séparer les trames pour les faibles vitesses d'horloge et les petites tailles de trames.

LFI utilise les fonctionnalités de fragmentation intégrées de MLPPP pour empêcher le retard et la gigue (variations de retard) provoqués par la mise en file d'attente de gros paquets de taille variable entre des paquets vocaux relativement petits. Avec LFI, les paquets dont la taille est supérieure à la taille de fragment configurée sont encapsulés dans un en-tête MLPPP. La RFC 1990 définit l'en-tête MLPPP ainsi que les éléments suivants :

• (B)Le bit du fragment de départ est un champ d'un bit défini sur 1 sur le premier fragment dérivé d'un paquet PPP et défini sur 0 pour tous les autres fragments du même paquet PPP.

• (E)Le bit du fragment final est un champ d'un bit défini sur 1 sur le dernier fragment et défini sur 0 pour tous les autres fragments.

• Le champ de séquence est un nombre de 24 bits ou de 12 bits qui est incrémenté pour chaque fragment transmis. Par défaut, le champ de séquence a une longueur de 24 bits, mais peut être négocié pour n'avoir que 12 bits avec l'option de configuration LCP décrite ci-dessous.

En plus de la fragmentation, les paquets sensibles au délai doivent être planifiés avec une priorité adéquate entre les fragments d'un gros paquet. Avec la fragmentation, Weighted Fair Queueing (WFQ) prend « conscience » qu'un paquet fait partie d'un fragment ou n'est pas fragmenté. WFQ attribue un numéro de séquence à chaque paquet entrant, puis planifie les paquets en fonction de ce numéro.

La fragmentation de couche 2 offre une solution supérieure à toutes les autres approches pour résoudre le « problème des gros paquets ». Le tableau suivant répertorie les avantages et les inconvénients d'autres solutions potentielles.

Solution potentielle	Avantages	Inconvénients
Abandonner la transmission du gros paquet et le remettre en file d'attente derrière le trafic sensible au délai.	Ne reporte que la transmission des paquets. Lorsque le paquet est retransmis, le même problème peut se produire. Si les paquets sont continuellement remis en file d'attente et même abandonnés, la bande passante risque de manquer.	Certaines interfaces physiques ne prennent pas en charge la transmission abandonnée ou entraînent une baisse des performances (par exemple, la réinitialisation de la file d’attente de transmission entière).
Fragmentez le gros paquet à l’aide des techniques de fragmentation de la couche réseau.	Les protocoles IP et CLNP prennent en charge la fragmentation sur n’importe quel routeur, le réassemblage se produisant sur l’hôte de destination. Peut éviter de fragmenter le gros paquet avec la détection MTU. Utilise un mécanisme global pour résoudre ce qui est essentiellement un problème local (à un saut) : tous les sauts en aval doivent traiter un plus grand nombre de paquets à commuter, même si toutes les liaisons suivantes sont rapides. Annule l'option de compression d'en-tête TCP/IP.	De nombreuses applications n'acceptent pas la fragmentation et définissent le bit « Ne pas fragmenter » dans l'en-tête IP. Ces paquets seront abandonnés s'ils sont fragmentés. Les applications qui ne sont pas capables d'accepter des paquets fragmentés seront rendues inutilisables dans cet environnement.
Fragmentez le paquet à l’aide de techniques de couche liaison.	Pris en charge avec tout paquet de couche réseau ou paquet ponté.	Propose une fragmentation par liaison plutôt que d’exiger le transport de paquets fragmentés de bout en bout. Seuls les routeurs connectés à la liaison lente doivent prendre en charge la gestion et le réassemblage des paquets supplémentaires.

La taille de fragment idéale pour le protocole point-à-point multiliaison sur ATM (MLPPPoATM) doit permettre aux fragments de s’intégrer dans un multiple exact de cellules ATM. Reportez-vous à la section Fragmentation et entrelacement de liaison pour Frame Relay et circuit virtuel ATM pour obtenir des conseils sur la sélection des valeurs de fragmentation.

En-têtes MLPPPoA et MLPPPoFR

Une configuration type de FRF.8 se compose des éléments suivants :

• Point d’extrémité Frame Relay

• Un terminal ATM

• Périphérique d'interfonctionnement (IWF)

Chaque point d’extrémité encapsule les paquets de données et de voix dans un en-tête d’encapsulation de couche 2, qui communique le protocole encapsulé et transporté dans la trame ou la cellule. Frame Relay et ATM prennent en charge les en-têtes d’encapsulation NLPID (Network Layer Protocol ID). Le document ISO/IEC TR 9577 définit des valeurs NLPID bien connues pour un certain nombre de protocoles. Une valeur de 0xCF est attribuée au protocole PPP.

La RFC 1973 définit le protocole PPP dans Frame Relay et l'en-tête MLPPPoFR, tandis que la RFC 2364 définit le protocole PPP sur AAL5 et l'en-tête MLPPPoA. Les deux en-têtes utilisent une valeur NLPID de 0xCF pour identifier PPP comme protocole encapsulé.

Chacun de ces en-têtes est illustré à la Figure 1 ci-dessous.

Figure 1. En-tête PPP sur AAL5, en-tête MLPPPoA avec encapsulation NLPID et en-tête MLPPPoA avec multiplexage VC

Remarque : l'en-tête MLPPPoFR inclut également un champ d'indicateur d'un octet de 0x7e, qui n'est pas illustré à la Figure 1. Après les en-têtes, l’octet numéro 5 lance les champs de protocole PPP ou MLPPP.

Tableau 1 - FRF.8 Transparent vs. FRF.8 Translational

Figure 2. Comment le paquet MLPPPoATM est fragmenté à l'aide de NLPID.

Figure 3. Comment le paquet MLPPPoATM est fragmenté à l'aide du multiplexage VC.

La signification des valeurs d'octet est indiquée ci-dessous :

• 0xFEFE : identifie les points d'accès de service (SAP) source et de destination dans l'en-tête LLC (Logical Link Control). Une valeur de 0xFEFE indique que ce qui suit est un en-tête NLPID de forme courte, qui est utilisé avec des protocoles ayant une valeur NLPID définie.

• 0x03 : champ de contrôle utilisé avec de nombreuses encapsulations, y compris HDLC (High Level Data Link Control). Indique également que le contenu du paquet est constitué d’informations non numérotées.

• 0xCF - Valeur NLPID connue pour PPP.

FRF.8 Transparent et modes de traduction

L'accord FRF.8 définit deux modes de fonctionnement pour le périphérique IWF :

• Transparent : le périphérique IWF transfère les en-têtes d'encapsulation sans les modifier. Il n'effectue pas de mappage, de fragmentation ou de réassemblage d'en-tête de protocole.

• Traduction : le périphérique IWF effectue le mappage d'en-tête de protocole entre les deux en-têtes d'encapsulation pour tenir compte des petites différences entre les types d'encapsulation.

Le mode configuré sur le périphérique IWF, qui peut être un commutateur Cisco ATM Campus ou un routeur de la gamme 7200 avec une carte de ports ATM PA-A3, modifie le nombre d’octets d’en-tête de couche 2 sur les segments ATM et Frame Relay de la liaison d’interfonctionnement. Regardons les frais généraux plus en détail.

Les deux tableaux suivants présentent les octets de surcharge pour les paquets de données et les paquets de voix sur IP (VoIP).

Tableau 2 - Surcharge de liaison de données en octets pour un paquet de données sur une liaison FRF.8.

Mode FRF.8			Transparent					Traduction
Direction Du Trafic			Frame Relay vers ATM			ATM vers Frame Relay		Frame Relay vers ATM			ATM vers Frame Relay
Tronçon Frame Relay ou ATM du circuit virtuel permanent			Relais de trames		GAB	GAB	Relais de trames	Relais de trames	GAB		GAB		Relais de trames
Indicateur de trame (0x7e)			1		0	0	1	1	0		1		0
En-tête Frame Relay			2		0	0	2	2	0		0		2
LLC DSAP/SSAP (0xfefe)			0		0	2	2	0	2		2		0
Contrôle LLC (0x03)			1		1	1	1	1	1		1		1
NLPID (0xcf pour PPP)			1		1	1	1	1	1		1		1
ID de protocole MLP (0x003d)			2		2	2	2	2	2		2		2
MLP Numéro de séquence			4		4	4	4	4	4		4		4
ID de protocole PPP (1ère fraction uniquement)			2		2	2	2	2	2		2		2
Charge utile (couche 3+)			0		0	0	0	0	0		0		0
Couche d’adaptation ATM (AAL)5			0		8	8	0	0	8		8		0
Séquence de contrôle de trame (FCS)			2		0	0	2	2	0		0		2
Surcharge totale (octets)			15		18	20	17	15	20		20		15

Tableau 3 - Surcharge de liaison de données en octets pour un paquet VoIP sur une liaison FRF.8.

Mode FRF.8	Transparent				Traduction				Frame Relay vers Frame Relay
Direction Du Trafic	Frame Relay vers ATM		ATM vers Frame Relay		Frame Relay vers ATM		ATM vers Frame Relay
Tronçon Frame Relay ou ATM du circuit virtuel permanent	Relais de trames	GAB	GAB	Relais de trames	Relais de trames	GAB	GAB	Relais de trames
Indicateur de trame (0x7e)	1	0	0	1	1	0	0	1	1
En-tête Frame Relay	2	0	0	2	2	0	0	2	2
LLC DSAP/SSAP (0xfefe)	0	0	2	2	0	2	2	0	0
Contrôle LLC (0x03)	1	1	1	1	1	1	1	1	1
NLPID (0xcf pour PPP)	1	1	1	1	1	1	1	1	1
ID PPP	2	2	2	2	2	2	2	2	0
Charge utile (IP+User Datagram Protocol (UDP)+RTP+Voix)	0	0	0	0	0	0	0	0	0
AAL5	0	8	8	0	0	8	8	0	0
FCS	2	0	0	2	2	0	0	2	2
Surcharge totale (octets)	9	12	14	11	9	14	14	9	7

En examinant les tableaux ci-dessus, notez ce qui suit :

• Les paquets dont la taille est inférieure à la taille de fragmentation spécifiée sont encapsulés uniquement dans un en-tête PPP et non dans un en-tête MLPPP. De même, les paquets supérieurs à la taille de fragmentation spécifiée sont encapsulés à la fois dans un en-tête PPP et dans un en-tête MLPPP. Ainsi, les paquets VoIP ont jusqu'à huit octets de surcharge en moins.

• Seul le premier fragment PPP multiliaison (MLP) inclut un champ d’ID de protocole PPP. Ainsi, le premier fragment porte deux octets supplémentaires de surcharge.

• En mode transparent, les en-têtes d'encapsulation sont transmis sans modification via le périphérique IWF. Ainsi, la surcharge varie dans chaque sens et sur chaque segment. Plus précisément, un en-tête MLPPPoA commence par un en-tête NLPID court de 0xFEFE. En mode transparent, cet en-tête est transmis tel quel par le périphérique IWF du segment ATM au segment Frame Relay. Cependant, dans le sens Frame Relay-ATM, aucun en-tête de ce type n’existe en mode transparent sur l’un ou l’autre segment.

• En mode de traduction, le périphérique IWF modifie les en-têtes d'encapsulation. Ainsi, la surcharge est la même sur chaque segment dans l'une ou l'autre direction. Plus précisément, dans le sens ATM vers Frame Relay, le point d’extrémité ATM encapsule le paquet dans un en-tête MLPPPoA. Le périphérique IWF supprime l'en-tête NLPID avant de transmettre la trame restante au segment Frame Relay. Dans le sens Frame Relay-ATM, le périphérique IWF manipule à nouveau la trame et ajoute un en-tête NLPID avant de transmettre la trame segmentée au point d’extrémité ATM.

• Lors de la conception de liaisons FRF avec MLP, veillez à tenir compte du nombre correct d'octets de surcharge de liaison de données. Cette surcharge influence la quantité de bande passante consommée par chaque appel VoIP. Il joue également un rôle dans la détermination de la taille de fragment MLP optimale. L'optimisation de la taille des fragments pour qu'elle s'adapte à un nombre entier de cellules ATM est essentielle, en particulier sur les circuits virtuels permanents à faible débit, où une quantité importante de bande passante peut être gaspillée en remplissant la dernière cellule à un multiple pair de 48 octets.

Pour des raisons de clarté, passons en revue les étapes du processus d’encapsulation de paquet lorsqu’un paquet passe dans la direction Frame Relay vers ATM en mode transparent :

1. Le point d’extrémité Frame Relay encapsule le paquet dans un en-tête MLPPPoFR.

2. Le périphérique IWF supprime l'en-tête Frame Relay de deux octets avec l'identificateur de connexion de liaison de données (DLCI). Il transfère ensuite le paquet restant à l'interface ATM de l'IWF, qui le segmente en cellules et le transfère à travers le segment ATM.

3. Le terminal ATM examine l’en-tête du paquet reçu. Si les deux premiers octets du paquet reçu sont 0x03CF, le point d’extrémité ATM considère le paquet comme un paquet MLPPPoA valide.

4. Les fonctions MLPPP sur le terminal ATM effectuent un traitement ultérieur.

Examinez le processus d’encapsulation de paquet lorsqu’un paquet passe dans le mode ATM vers le mode Frame Relay en mode transparent :

1. Le terminal ATM encapsule le paquet dans un en-tête MLPPPoA. Il segmente ensuite les paquets en cellules et les transfère hors du segment ATM.

2. Le protocole IWF reçoit le paquet, le transfère à son interface Frame Relay et ajoute un en-tête Frame Relay de deux octets.

3. Le point d’extrémité Frame Relay examine l’en-tête du paquet reçu. Si les quatre premiers octets après l’en-tête Frame Relay de deux octets sont 0xfefe03cf, le protocole IWF traite le paquet comme un paquet MLPPPoFR légal.

4. Les fonctions MLPPP sur le point d’extrémité Frame Relay effectuent un traitement ultérieur.

Les illustrations suivantes montrent le format des paquets MLPPPoA et MLPPPoFR.

Figure 6. Surcharge MLPPPoA. Seul le premier fragment porte un en-tête PPP.

Figure 7. Surcharge MLPPPoFR. Seul le premier fragment porte un en-tête PPP.

Bande passante VoIP requise

Lors du provisionnement de la bande passante pour la VoIP, la surcharge de la liaison de données doit être incluse dans les calculs de bande passante. Le tableau 4 indique les besoins en bande passante par appel pour la VoIP en fonction du codec et de l'utilisation du protocole RTP (Real-time Transport Protocol) compressé. Les calculs du tableau 4 supposent un scénario idéal pour la compression d'en-tête RTP (cRTP), en d'autres termes, aucune somme de contrôle UDP ou erreur de transmission. Les en-têtes sont alors systématiquement compressés de 40 octets à deux octets.

Tableau 4 - Besoins en bande passante par appel VoIP (Kbits/s).

Mode FRF.8	Transparent				Traduction				Frame Relay vers Frame Relay
Direction Du Trafic	Frame Relay vers ATM		ATM vers Frame Relay		Frame Relay vers ATM		ATM vers Frame Relay
Tronçon Frame Relay ou ATM du circuit virtuel permanent	Relais de trames	GAB	GAB	Relais de trames	Relais de trames	GAB	GAB	Relais de trames
G729 - Échantillons de 20 ms - Pas de cRTP	27.6	42.4	42.4	28.4	27.6	42.4	42.4	27.6	26.8
G729 - Échantillons 20 ms - cRTP	12.4	21.2	21.2	13.2	12.4	21.2	21.2	12.4	11.6
G729 - Échantillons de 30 ms - Pas de cRTP	20.9	28.0	28.0	21.4	20.9	28.0	28.0	20.9	20.3
G729 - Échantillons de 30 ms - cRTP	10.8	14.0	14.0	11.4	10.8	14.0	14.0	10.8	10.3
G711 - Échantillons de 20 ms - Pas de cRTP	83.6	106.0	106.0	84.4	83.6	106.0	106.0	83.6	82.8
G711 - Échantillons 20 ms - cRTP	68.4	84.8	84.8	69.2	68.4	84.8	84.8	68.4	67.6
G711 - Échantillons de 30 ms - Pas de cRTP	76.3	97.9	97.9	76.8	76.3	97.9	97.9	76.3	75.8
G711 - Exemples 30 ms - cRTP	66.3	84.0	84.0	66.8	66.3	84.0	84.0	66.3	65.7

Étant donné que la surcharge varie sur chaque branche du circuit virtuel permanent, nous vous recommandons de concevoir le scénario le plus défavorable. Prenons le cas d'un appel G.279 avec échantillonnage de 20 ms et cRTP sur un circuit virtuel permanent transparent. Sur la branche Frame Relay, la bande passante requise est de 12,4 kbits/s dans un sens et de 13,2 kbits/s dans l’autre. Par conséquent, nous vous recommandons d'effectuer un provisionnement basé sur 3,2 Kbits/s par appel.

À des fins de comparaison, le tableau indique également les besoins en bande passante VoIP sur un circuit virtuel permanent Frame Relay de bout en bout configuré avec la fragmentation FRF.12. Comme indiqué dans le tableau, le protocole PPP consomme entre 0,5 kbits/s et 0,8 kbits/s de bande passante supplémentaire par appel pour prendre en charge les octets d’en-tête d’encapsulation supplémentaires. Par conséquent, nous vous recommandons d’utiliser FRF.12 avec des circuits virtuels Frame Relay de bout en bout.

Le protocole cRTP (Compressed RTP) sur ATM nécessite la version 12.2(2)T du logiciel Cisco IOS®. Lorsque cRTP est activé avec MLPoFR et MLPoATM, la compression d'en-tête TCP/IP est automatiquement activée et ne peut pas être désactivée. Cette restriction résulte de la RFC 2509, qui n'autorise pas la négociation PPP de la compression d'en-tête RTP sans négocier également la compression d'en-tête TCP.

Traduction et prise en charge transparente sur les périphériques Cisco

À l'origine, LFI exigeait que les périphériques IWF utilisent le mode transparent. Plus récemment, le Forum Frame Relay a introduit FRF.8.1 pour prendre en charge le mode de traduction. Cisco a introduit la prise en charge de FRF.8.1 et du mode de traduction dans les versions suivantes du logiciel Cisco IOS :

• 12.0(18)W5(23) pour les gammes LS1010 et Catalyst 8500 avec un module FR-PAM 4CE1 (CSCdt39211)

• 12.2(3)T et 12.2(2) sur les routeurs Cisco IOS avec interfaces ATM, tels que le PA-A3 (CSCdt70724)

Certains fournisseurs de services ne prennent pas encore en charge la traduction PPP sur leurs périphériques FRF.8. Dans ce cas, le fournisseur doit configurer ses circuits virtuels permanents pour le mode transparent.

Matériel et logiciels

Cette configuration utilise le matériel et les logiciels suivants :

• Terminal ATM : PA-A3-OC3 dans un routeur de la gamme 7200 exécutant le logiciel Cisco IOS Version 12.2(8)T. (Remarque : LFI est pris en charge sur les PA-A3-OC3 et PA-A3-T3 uniquement. Elle n'est pas prise en charge sur les cartes de ports OC-12 IMA et ATM.)

• Périphérique IWF - LS1010 avec module d'adaptateur de port T3 multicanal fractionné et logiciel Cisco IOS version 12.1(8)EY.

• Point d'extrémité Frame Relay : PA-MC-T3 dans un routeur de la gamme 7200 exécutant le logiciel Cisco IOS version 12.2(8)T.

Schéma de topologie

Configurations

Cette section montre comment configurer la fonctionnalité LFI sur une liaison FRF.8 en mode transparent. Il utilise un modèle virtuel sur les deux points d'extrémité du routeur, à partir duquel l'interface d'accès virtuelle du bundle MLP est clonée. LFI prend en charge les interfaces de numérotation et les modèles virtuels pour spécifier les paramètres de couche de protocole de MLPPP. La version 12.2(8)T du logiciel Cisco IOS porte à 200 le nombre de modèles virtuels uniques pouvant être configurés par routeur. Les versions précédentes prennent en charge jusqu'à 25 modèles virtuels par routeur. Cette limitation peut constituer un problème d’évolutivité sur un routeur de distribution ATM si chaque circuit virtuel permanent doit posséder une adresse IP unique. Pour contourner ce problème, utilisez IP comme non numéroté ou remplacez les modèles virtuels par des interfaces de numérotation sur des liaisons numérotées.

Cisco IOS version 12.1(5)T a introduit la prise en charge de LFI sur une seule liaison membre par offre groupée MLPPP. Ainsi, cette configuration n'utilise qu'un seul circuit virtuel à chaque point d'extrémité. La prise en charge de plusieurs circuits virtuels par ensemble est prévue pour une prochaine version de Cisco IOS.

Point de terminaison Frame Relay

La carte de ports T3 multicanaux fractionnés nécessite la création d'un groupe de canaux et la spécification des tranches de temps. Par défaut, aucune interface n'existe. FRAMEside#show ip int brief Interface IP-Address OK? Method Status Protocol FastEthernet0/0 172.16.142.231 YES NVRAM up up Loopback1 191.1.1.1 YES NVRAM up up Utilisez la commande show diag pour déterminer la carte de ports installée. Dans cet exemple, le PA T3 se trouve dans le logement 3. Les versions actuelles de Cisco IOS affichent désormais la référence remplaçable sur site (FRU) à commander en cas de panne matérielle. FRAMEside#show diag 3 Slot 3: CT3 single wide Port adapter, 1 port Port adapter is analyzed Port adapter insertion time 13:16:35 ago EEPROM contents at hardware discovery: Hardware revision 1.0 Board revision A0 Serial number 23414844 Part number 73-3037-01 FRU Part Number: PA-MC-T3= (SW) Test history 0x0 RMA number 00-00-00 EEPROM format version 1 EEPROM contents (hex): 0x20: 01 A0 01 00 01 65 48 3C 49 0B DD 01 00 00 00 00 0x30: 50 00 00 00 00 10 30 00 FF FF FF FF FF FF FF FF L'exécution de la commande show controller t3 affiche les alarmes et les statistiques de la couche physique. FRAMEside#show controller t3 3/0 T3 3/0 is up. Hardware is CT3 single wide port adapter CT3 H/W Version : 1.0.1, CT3 ROM Version : 1.1, CT3 F/W Version : 2.4.0 FREEDM version: 1, reset 0 resurrect 0 Applique type is Channelized T3 No alarms detected. FEAC code received: No code is being received Framing is M23, Line Code is B3ZS, Clock Source is Internal Rx throttle total 0, equipment customer loopback Data in current interval (75 seconds elapsed): 2 Line Code Violations, 1 P-bit Coding Violation 0 C-bit Coding Violation, 1 P-bit Err Secs 0 P-bit Severely Err Secs, 0 Severely Err Framing Secs 0 Unavailable Secs, 1 Line Errored Secs 0 C-bit Errored Secs, 0 C-bit Severely Errored Secs [output omitted] Sélectionnez un T1 en mode de configuration de contrôleur T3, créez un groupe de canaux et attribuez des intervalles de temps au groupe. FRAMEside(config)#controller t3 3/0 b13-8-7204(config-controller)#? Controller configuration commands: cablelength cable length in feet (0-450) clock Specify the clock source for a T3 link default Set a command to its defaults description Controller specific description equipment Specify the equipment type for loopback mode exit Exit from controller configuration mode framing Specify the type of Framing on a T3 link help Description of the interactive help system idle Specify the idle pattern for all channels on a T3 interface loopback Put the entire T3 line into loopback mdl Maintenance Data Link Configuration no Negate a command or set its defaults shutdown Shut down a DS3 link (send DS3 Idle) t1 Create a T1 channel b13-8-7204(config-controller)#t1 ? <1-28> T1 Channel number <1-28> b13-8-7204(config-controller)#t1 1 channel-group ? <0-23> Channel group number b13-8-7204(config-controller)#t1 1 channel-group 1 ? timeslots List of timeslots in the channel group b13-8-7204(config-controller)#t1 1 channel-group 1 timeslots ? <1-24> List of timeslots which comprise the channel b13-8-7204(config-controller)#t1 1 channel-group 1 timeslots 1-2 b13-8-7204(config-controller)# 13:22:28: %LINK-3-UPDOWN: Interface Serial3/0/1:1, changed state to down 13:22:29: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial3/0/1:1, changed state to down 13:22:46: %LINK-3-UPDOWN: Interface Serial3/0/1:1, changed state to up 13:22:47: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial3/0/1:1, changed state to up 13:23:07: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial3/0/1:1, changed state to down Remarque : si l'interface distante connectée n'est pas configurée de la même manière, la couche liaison de la nouvelle interface multicanal fractionnée s'active, mais le protocole de ligne reste inactif. L’interface série 3/0/1:1 identifie la nouvelle interface multicanal fractionné. Configurez l’interface pour l’encapsulation Frame Relay, puis activez le protocole FRTS (Frame Relay Traffic Shaping) sur l’interface principale. FRAMEside(config)#int serial 3/0/1:1 FRAMEside(config-if)#encapsulation frame-relay ietf FRAMEside(config-if)#frame-relay traffic-shaping !--- FRTS must be enabled for MLPoFR. Configurez une classe de mappage Frame Relay pour appliquer les paramètres de mise en forme du trafic au circuit virtuel Frame Relay (qui sera créé ci-dessous). FRAMEside(config)#map-class frame-relay mlp FRAMEside(config-map-class)#frame-relay cir ? <1-45000000> Applied to both Incoming/Outgoing CIR, Bits per second in Incoming CIR out Outgoing CIR FRAMEside(config-map-class)#frame-relay cir 128000 FRAMEside(config-map-class)#frame-relay mincir 128000 FRAMEside(config-map-class)#frame-relay bc ? <300-16000000> Applied to both Incoming/Outgoing Bc, Bits in Incoming Bc out Outgoing Bc <cr> FRAMEside(config-map-class)#frame-relay bc 1280 !--- Configure a burst committed (Bc) value of 1/100th of the CIR or 1280 bps. FRAMEside(config-map-class)#frame-relay be 0 !--- Configure an excess burst (Be) value of 0. FRAMeside(config-map-class)#no frame-relay adaptive-shaping Créez une stratégie de service QoS. Utilisez les mêmes paramètres que le côté ATM. Voir ci-dessous pour référence. FRAMEside#show policy-map example Policy Map example Class voice Weighted Fair Queueing Strict Priority Bandwidth 110 (kbps) Burst 2750 (Bytes) Class class-default Weighted Fair Queueing Flow based Fair Queueing Bandwidth 0 (kbps) Max Threshold 64 (packets) Créez une interface de modèle virtuelle et appliquez les paramètres MLPPP. Appliquez également la politique de service QoS au circuit virtuel. FRAMEside(config)#interface Virtual-Template1 FRAMEside(config-if)#ip address 1.1.1.2 255.255.255.0 FRAMEside(config-if)#service-policy output example FRAMEside(config-if)#ppp multilink FRAMEside(config-if)#ppp multilink fragment-delay 10 FRAMEside(config-if)#ppp multilink interleave FRAMEside(config-if)#end Créez une sous-interface et attribuez le numéro DLCI (Frame Relay Data Link Connection Identifier). Appliquez ensuite l'encapsulation PPP, le modèle virtuel et la classe de mappage. FRAMEside(config)#int serial 3/0/1:1.1 point FRAMEside(config-subif)#frame-relay interface-dlci ? <16-1007> Define a switched or locally terminated DLCI FRAMEside(config-subif)#frame-relay interface-dlci 20 ppp ? Virtual-Template Virtual Template interface FRAMEside(config-subif)#frame-relay interface-dlci 20 ppp Virtual-Template 1 FRAMEside(config-fr-dlci)#class mlp Utilisez la commande show frame-relay pvc pour confirmer vos paramètres virtual-template et map-class sur le circuit virtuel. FRAMEside#show frame-relay pvc 20 PVC Statistics for interface Serial3/0/1:1 (Frame Relay DTE) DLCI = 20, DLCI USAGE = LOCAL, PVC STATUS = INACTIVE, INTERFACE = Serial3/0/1:1.1 input pkts 0 output pkts 0 in bytes 0 out bytes 0 dropped pkts 0 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 0 out DE pkts 0 out bcast pkts 0 out bcast bytes 0 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec pvc create time 00:03:24, last time pvc status changed 00:03:24 Bound to Virtual-Access1 (down, cloned from Virtual-Template1) cir 128000 bc 1280 be 0 byte limit 160 interval 10 mincir 128000 byte increment 160 Adaptive Shaping none pkts 0 bytes 0 pkts delayed 0 bytes delayed 0 shaping inactive traffic shaping drops 0 Queueing strategy: fifo Output queue 0/40, 0 drop, 0 dequeued Utilisez la commande show controller serial 3/0/1:1 pour confirmer que la liaison Frame Relay est dans un état up et sans alarmes de couche physique. Un numéro de circuit virtuel est attribué à chaque interface multicanal fractionné. Dans la sortie suivante, channel-group 1 (3/0/1:1) se voit attribuer un numéro de circuit virtuel de 0. FRAMEside#show controller serial 3/0/1:1 CT3 SW Controller 3/0 ROM ver 0x10001, h/w ver 1.0.1, f/w ver 2.4.0, FREEDM rev 1 !--- FREEDM is the HDLC controller on the channelized T3 port adapter. It extracts data from the 24 timeslots of a T1, validates the CRC, and checks for any other frame errors. T3 linestate is Up, T1 linestate 0x00000002, num_active_idb 1 Buffer pool size 640, particle size 512, cache size 640, cache end 128/127 Rx desctable 0xF1A5A20, shadow 0x628C6AFC, size 512, spin 128 !--- When it initializes, the interface driver builds a control structure known as the receive ring. The receive ring consists of a list of 512 packet buffer descriptors. As packets arrive, FREEDM DMAs the data into the buffer to which a descriptor points. rx queue 0xF1B8000, cache 0xF1B8000, fq base 0xF1B8800 rdq base 0xF1B8000, host_rxrdqr 0xF1B8004, host_rxfqw 0xF1B8804 Tx desctable 0xF1A7A60, shadow 0x628B6AD0, size 4096, spin 256 !--- When it initializes, the interface driver also creates the transmit queue or transmit ring. In the case of the channelized T3 PA, the driver creates a queue of 4096 entries and sets all fields in the descriptors to NULL or empty. tx queue 0xF1C0000, cache 0xF1C0000 host_txrdqw 1802, fq base 0xF1C4000, host_txfqr 0xF1C5C20 dynamic txlimit threshold 4096 TPD cache 0x628C7A54, size 4096, cache end 4096/4094, underrun 0 RPD cache 0x628C7328, size 448, cache end 0 Freedm fifo 0x628AA7B0, head ptr 0x628AA7C8, tail ptr 0x628AB7A8, reset 0 PCI bus 6, PCI shared memory block 0xF1A454C, PLX mailbox addr 0x3D820040 FREEDM devbase 0x3D800000, PLX devbase 0x3D820000 Rx overruns 0, Tx underruns 0, tx rdq count 0 !--- The "tx rdq count" indicates the number of outstanding transmit packets in FREEDM's "transmit ready" queue. This queue holds a packet before it reaches the transmit ring. Tx bad vc 0 FREEDM err: cas 0, hdl 0, hdl_blk 0, ind_prov 0, tavail 0, tmac busy 0, rmac b usy 0 rxrdq_wt 0x2, rxrdq_rd 0x1, rxsfq_wt 0x201, rxsfq_rd 0x206 VC 0 (1:1) is enabled, T1 1 is enabled/Up, rx throttle 0 Interface Serial3/0/1:1 is up (idb status 0x84208080) xmitdelay 0, max pak size 1608, maxmtu 1500, max buf size 1524 started 8, throttled 0, unthrottled 0, in_throttle FALSE VC config: map 0xC0000000, timeslots 2, subrate 0xFF, crc size 2, non-inverted data freedm fifo num 3, start 0x628AA7B0, end 0x628AA7C0, configured = TRUE Rx pkts 0, bytes 0, runt 0, giant 0, drops 0 crc 0, frame 0, overrun 0, abort 1, no buf 0 Tx pkts 194313, bytes 2549490, underrun 0, drops 0, tpd udr 0 tx enqueued 0, tx count 0/36/0, no buf 0 tx limited = FALSE !--- The "tx count x/y/z" counter includes the following information: !--- "x" = Number of transmit ring entries in use. !--- "y" = Maximum number of packets allowed on the transmit queue. !--- "z" = Number of times that the transmit limit has been exceeded.

Configuration LS1010

Utilisez la commande show hardware pour confirmer que votre LS1010 est équipé d'un module PAM (Frame Relay Port Adapter Module) multicanal fractionné. LS1010#show hardware LS1010 named LS1010, Date: 07:36:40 UTC Mon May 13 2002 Feature Card's FPGA Download Version: 11 Slot Ctrlr-Type Part No. Rev Ser No Mfg Date RMA No. Hw Vrs Tst EEP ---- ------------ ---------- -- -------- --------- -------- ------- --- --- 0/0 155MM PAM 73-1496-03 A0 02829507 May 07 96 00-00-00 3.1 0 2 1/0 1CT3 FR-PAM 73-2972-03 A0 12344261 May 17 99 00-00-00 3.0 0 2 2/0 ATM Swi/Proc 73-1402-03 B0 03824638 Sep 14 96 00-00-00 3.1 0 2 2/1 FeatureCard1 73-1405-03 B0 03824581 Sep 14 96 00-00-00 3.2 0 2 Utilisez la commande show ip int brief pour identifier l'interface du contrôleur. LS1010#show ip int brief Interface IP-Address OK? Method Status Protocol ATM0/0/0 unassigned YES unset up up ATM0/0/1 unassigned YES unset down down ATM0/0/2 unassigned YES unset down down ATM0/0/3 unassigned YES unset down down ATM-P1/0/0 unassigned YES unset up up T3 1/0/0 unassigned YES unset up up Créez une interface multicanaux fractionnés et sélectionnez les mêmes intervalles de temps que la carte de ports série (PA). LS1010(config)#controller t3 1/0/0 LS1010(config-controller)#channel-group 1 t1 ? <1-28> T1 line number <1-28> LS1010(config-controller)#channel-group 1 t1 1 timeslots ? <1-24> List of timeslots which comprise the channel LS1010(config-controller)#channel-group 1 t1 1 timeslot 1-2 LS1010(config-controller)# 2w1d: %LINK-3-UPDOWN: Interface Serial1/0/0:1, changed state to up 2w1d: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0/0:1, changed state to up Configurez l’encapsulation Frame Relay sur la nouvelle interface série. En outre, remplacez le type d’interface de gestion locale (LMI) NNI par DCE. LS1010(config)#int serial 1/0/0:1 LS1010(config-if)#encap frame ? ietf Use RFC1490 encapsulation LS1010(config-if)#encap frame ietf LS1010(config-if)#frame-relay intf-type dce Utilisez la commande show interface serial pour confirmer l’encapsulation Frame Relay. LS1010#show int serial 1/0/0:1 Serial1/0/0:1 is up, line protocol is up Hardware is FRPAM-SERIAL MTU 4096 bytes, BW 128 Kbit, DLY 0 usec, reliability 139/255, txload 1/255, rxload 1/255 Encapsulation FRAME-RELAY IETF, loopback not set Keepalive set (10 sec) LMI enq sent 32, LMI stat recvd 0, LMI upd recvd 0 LMI enq recvd 40, LMI stat sent 40, LMI upd sent 0, DCE LMI up LMI DLCI 1023 LMI type is CISCO frame relay DCE !--- By default, the serial PAM and the serial PA use LMI type Cisco. The serial PAM should show DCE LMI status of "up", and the serial PA should show DTE LMI status of "up". Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 0 Last input 00:00:03, output 00:00:05, output hang never Last clearing of "show interface" counters 00:06:40 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue :0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 44 packets input, 667 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 5 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 71 packets output, 923 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions Timeslots(s) Used: 1-2 on T1 1 Frames Received with: DE set: 0, FECN set :0, BECN set: 0 Frames Tagged : DE: 0, FECN: 0 BECN: 0 Frames Discarded Due to Alignment Error: 0 Frames Discarded Due to Illegal Length: 0 Frames Received with unknown DLCI: 5 Frames with illegal Header : 0 Transmit Frames with FECN set :0, BECN Set :0 Transmit Frames Tagged FECN : 0 BECN : 0 Transmit Frames Discarded due to No buffers : 0 Default Upc Action : tag-drop Default Bc (in Bits) : 32768 LS1010#show frame lmi LMI Statistics for interface Serial1/0/0:1 (Frame Relay DCE) LMI TYPE = CISCO< Invalid Unnumbered info 0 Invalid Prot Disc 0 Invalid dummy Call Ref 0 Invalid Msg Type 0 Invalid Status Message 0 Invalid Lock Shift 0 Invalid Information ID 0 Invalid Report IE Len 0 Invalid Report Request 0 Invalid Keep IE Len 0 Num Status Enq. Rcvd 120 Num Status msgs Sent 120 Num Update Status Sent 0 Num St Enq. Timeouts 0 Avant de configurer le circuit virtuel permanent, assurez-vous que l’interface ATM est active/active. LS1010#show int atm 0/0/0 ATM0/0/0 is up, line protocol is up Hardware is oc3suni MTU 4470 bytes, sub MTU 4470, BW 155520 Kbit, DLY 0 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ATM, loopback not set Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue :0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 1000 bits/sec, 2 packets/sec 253672 packets input, 13444616 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 2601118 packets output, 137859254 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out Outre les deux interfaces physiques, le LS1010 utilise une interface logique pour relier le côté ATM et le côté Frame Relay. L’interface logique est identifiée comme « atm-p1 » sur la pseudo-interface ATM. LS1010#show int atm-p1/0/0 ATM-P1/0/0 is up, line protocol is up Hardware is ATM-PSEUDO MTU 4470 bytes, sub MTU 4470, BW 45000 Kbit, DLY 0 usec, reliability 0/255, txload 1/255, rxload 1/255 Encapsulation ATM, loopback not set Keepalive not supported Encapsulation(s): 2000 maximum active VCs, 0 current VCCs VC idle disconnect time: 300 seconds Last input never, output never, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue :0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 0 packets input, 0 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 0 packets output, 0 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out En mode de configuration d’interface série, configurez le circuit virtuel permanent d’interfonctionnement. interface Serial1/0/0:1 no ip address encapsulation frame-relay IETF no arp frame-relay frame-relay intf-type dce frame-relay pvc 20 service transparent interface ATM0/0/0 1 100 Confirmez votre configuration à l'aide de la commande show vc interface atm. LS1010#show vc int atm 0/0/0 Interface Conn-Id Type X-Interface X-Conn-Id Encap Status ATM0/0/0 0/5 PVC ATM0 0/39 QSAAL UP ATM0/0/0 0/16 PVC ATM0 0/35 ILMI UP ATM0/0/0 1/100 PVC Serial1/0/0:1 20 UP

Terminaux ATM

Assurez-vous que vous utilisez une carte de ports ATM PA ou PA-A3 améliorée. Utilisez la commande show interface atm pour confirmer. ATMside#show int atm 1/0/0 ATM1/0/0 is up, line protocol is up Hardware is cyBus ENHANCED ATM PA MTU 4470 bytes, sub MTU 4470, BW 149760 Kbit, DLY 80 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ATM, loopback not set Encapsulation(s): AAL5 4095 maximum active VCs, 0 current VCCs [output omitted] Configurez les paramètres de couche ATM du circuit virtuel permanent (PVC). Dans cette configuration, nous utilisons une sous-interface point à point avec un débit de cellule soutenu (SCR) de 150 kbits/s. Cette valeur a été choisie pour être supérieure d'environ 15 % au débit de données garanti de 128 kbits/s du point d'extrémité Frame Relay. Les 15 % supplémentaires permettent de s'assurer que le circuit virtuel fournit une bande passante équivalente au trafic utilisateur réel des deux côtés de la connexion tout en prenant en charge la surcharge supplémentaire du côté ATM. (Voir aussi Configuration du formatage du trafic sur les circuits virtuels permanents Frame Relay vers ATM Service Interworking (FRF.8).) ATMside(config)#int atm 1/0/0.1 point ATMside(config-subif)#pvc 1/100 ATMside(config-if-atm-vc)#vbr-nrt 300 150 ? <1-65535> Maximum Burst Size(MBS) in Cells <cr> ATMside(config-if-atm-vc)#vbr-nrt 300 150 ATMside(config-if-atm-vc)#end ATMside(config-if-atm-vc)#tx-ring-limit 4 !--- Tune down the transmit ring to push most queueing to the layer-3 queues, where our service policy will apply. Vérifiez que votre circuit virtuel apparaît dans la table des circuits virtuels. Exécutez la commande show atm vc. Notez que le routeur attribue une taille de rafale maximale (MBS) par défaut de 94, car nous n'avons pas entré de valeur explicite. ATMside#show atm vc VCD / Peak Avg/Min Burst Interface Name VPI VCI Type Encaps SC kbps kbps Cells Sts 1/0/0.1 1 1 100 PVC SNAP VBR 300 150 94 UP Créez une stratégie de service QoS. Dans la politique présentée ci-dessous, nous avons créé quatre classes, y compris la classe par défaut créée par le routeur. Créez une carte de classe pour les paquets VoIP (Voice over IP). ATMside(config)#class-map voice ATMside(config-cmap)#match ip rtp ? <2000-65535> Lower bound of UDP destination port ATMside(config-cmap)#match ip rtp 16384 ? <0-16383> Range of UDP ports ATMside(config-cmap)#match ip rtp 16384 16383 !--- Cisco IOS H.323 devices use this UDP port range to transmit VoIP packets. Créez une carte-classe pour les paquets de signalisation vocale. Cet exemple utilise la connexion rapide H.323. (Reportez-vous également à la section « Directives de configuration LLQ » de VoIP sur les liaisons PPP avec qualité de service (LLQ / IP RTP Priority, LFI, cRTP.) class-map voice-signaling match access-group 103 ! access-list 103 permit tcp any eq 1720 any access-list 103 permit tcp any any eq 1720 Créez un policy-map nommé et affectez des actions QoS à chaque classe. Cet exemple attribue une mise en file d'attente prioritaire aux paquets utilisateur VoIP avec la commande priority et une garantie de bande passante minimale aux paquets de signalisation d'appel avec la commande bandwidth. Tout autre trafic est acheminé vers la classe par défaut de la classe, qui sépare le trafic en flux de couche IP et fournit une mise en file d'attente équitable entre les flux. policy-map example class call-control bandwidth percent 10 class voice priority 110 class class-default fair-queue Confirmez votre configuration. ATMside#show policy-map example Policy Map example Class call-control bandwidth percent 10 Class voice priority 110 Class class-default fair-queue Créez un modèle virtuel et appliquez-lui la stratégie de service QoS. interface Virtual-Template1 bandwidth 150 ip address 1.1.1.1 255.255.255.0 service-policy output example ppp multilink ppp multilink fragment-delay 10 ppp multilink interleave !--- You select a fragment size indirectly by specifying the maximum tolerable serialization delay. The recommended maximum per-hop serialization delay for voice environments is 10 milliseconds (ms). LFI also requires ppp multilink interleave. Appliquez le modèle virtuel et l’encapsulation PPP multiliaison au circuit virtuel permanent ATM. ATMside(config)#int atm 1/0/0.1 ATMside(config-subif)#pvc 1/100 ATMside(config-if-atm-vc)#protocol ppp ? Virtual-Template Virtual Template interface dialer pvc is part of dialer profile ATMside(config-if-atm-vc)#protocol ppp Virtual-Template 1 Confirmez vos paramètres sur le circuit virtuel permanent ATM. ATMside#show run int atm 1/0/0.1 Building configuration... Current configuration : 127 bytes ! interface ATM1/0/0.1 point-to-point pvc 1/100 vbr-nrt 300 150 tx-ring-limit 4 protocol ppp Virtual-Template1 ! end Le routeur crée automatiquement une interface d'accès virtuel. Si le protocole MLPPP n'est pas configuré sur le point d'extrémité Frame Relay, l'état de l'interface d'accès virtuel est up/down. ATMside#show int virtual-access 1 Virtual-Access1 is up, line protocol is down Hardware is Virtual Access interface Internet address is 1.1.1.1/24 MTU 1500 bytes, BW 150 Kbit, DLY 100000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation PPP, loopback not set DTR is pulsed for 5 seconds on reset LCP Listen, multilink Closed Closed: LEXCP, BRIDGECP, IPCP, CCP, CDPCP, LLC2, BACP, IPV6CP Bound to ATM1/0/0.1 VCD: 1, VPI: 1, VCI: 100 Cloned from virtual-template: 1

Commandes show et debug

Terminaux ATM

Utilisez les commandes suivantes sur le terminal ATM pour vérifier que l’interface LFI fonctionne correctement. Avant d'exécuter les commandes debug, référez-vous à la section Informations importantes sur les commandes Debug.

• show ppp multilink - LFI utilise deux interfaces d'accès virtuel, l'une pour PPP et l'autre pour le bundle MLP. Utilisez la commande show ppp multilink pour différencier les deux.

  ATMside#show ppp multilink 
  Virtual-Access2, bundle name is FRAMEside 
  
  !--- The bundle interface is assigned to VA 2.
  
    Bundle up for 01:11:55 
    Bundle is Distributed 
    0 lost fragments, 0 reordered, 0 unassigned 
    0 discarded, 0 lost received, 1/255 load 
    0x1E received sequence, 0xA sent sequence 
    Member links: 1 (max not set, min not set) 
      Virtual-Access1, since 01:11:55, last rcvd seq 00001D  187 weight 
  
  !--- The PPP interface is assigned to VA 1.
  
  

• show interface virtual-access 1 - Confirmez que l'interface d'accès virtuel est up/up et incrémente les compteurs de paquets d'entrée et de sortie.

  ATMside#show int virtual-access 1 
  Virtual-Access1 is up, line protocol is up 
    Hardware is Virtual Access interface 
    Internet address is 1.1.1.1/24 
    MTU 1500 bytes, BW 150 Kbit, DLY 100000 usec, 
       reliability 255/255, txload 1/255, rxload 1/255 
    Encapsulation PPP, loopback not set 
    DTR is pulsed for 5 seconds on reset 
    LCP Open, multilink Open 
    Bound to ATM1/0/0.1 VCD: 1, VPI: 1, VCI: 100 
    Cloned from virtual-template: 1 
    Last input 01:11:30, output never, output hang never 
    Last clearing of "show interface" counters 2w1d 
    Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 
    Queueing strategy: fifo 
    Output queue :0/40 (size/max) 
    5 minute input rate 0 bits/sec, 0 packets/sec 
    5 minute output rate 0 bits/sec, 0 packets/sec 
       878 packets input, 13094 bytes, 0 no buffer 
       Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 
       0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
       255073 packets output, 6624300 bytes, 0 underruns 
       0 output errors, 0 collisions, 0 interface resets 
       0 output buffer failures, 0 output buffers swapped out 
       0 carrier transitions 
  

• show policy-map int virtual-access 2 - Confirmez que la stratégie de service QoS est liée à l'interface du bundle MLPPP.

  ATMside#show policy-map int virtual-access 2 
   Virtual-Access2 
  
    Service-policy output: example 
  
      queue stats for all priority classes: 
        queue size 0, queue limit 27 
        packets output 0, packet drops 0 
        tail/random drops 0, no buffer drops 0, other drops 0 
  
      Class-map: call-control (match-all) 
        0 packets, 0 bytes 
        5 minute offered rate 0 bps, drop rate 0 bps 
        Match: access-group 103 
        queue size 0, queue limit 3 
        packets output 0, packet drops 0 
        tail/random drops 0, no buffer drops 0, other drops 0 
        Bandwidth: 10%, kbps 15 
  
      Class-map: voice (match-all) 
        0 packets, 0 bytes 
        5 minute offered rate 0 bps, drop rate 0 bps 
        Match: ip rtp 16384 16383 
        Priority: kbps 110, burst bytes 4470, b/w exceed drops: 0 
  
      Class-map: class-default (match-any) 
        0 packets, 0 bytes 
        5 minute offered rate 0 bps, drop rate 0 bps 
        Match: any 
        queue size 0, queue limit 5 
        packets output 0, packet drops 0 
        tail/random drops 0, no buffer drops 0, other drops 0 
        Fair-queue: per-flow queue limit 2
  

• debug ppp packet et debug atm packet - Utilisez ces commandes si toutes les interfaces sont up/up, mais vous ne pouvez pas envoyer de requête ping de bout en bout. En outre, vous pouvez utiliser ces commandes pour capturer des messages de veille PPP, comme illustré ci-dessous.

  2w1d: Vi1 LCP-FS: I ECHOREQ [Open] id 31 len 12 magic 0x52FE6F51 
  2w1d: ATM1/0/0.1(O): 
  VCD:0x1 VPI:0x1 VCI:0x64 DM:0x0 SAP:FEFE CTL:03  Length:0x16 
  2w1d: CFC0 210A 1F00 0CB1 2342 E300 0532 953F 
  2w1d: 
  2w1d: Vi1 LCP-FS: O ECHOREP [Open] id 31 len 12 magic 0xB12342E3 
  
  !--- This side received an Echo Request and responded with an outbound Echo Reply.
  
  2w1d: Vi1 LCP: O ECHOREQ [Open] id 32 len 12 magic 0xB12342E3 
  2w1d: ATM1/0/0.1(O): 
  VCD:0x1 VPI:0x1 VCI:0x64 DM:0x0 SAP:FEFE CTL:03  Length:0x16 
  2w1d: CFC0 2109 2000 0CB1 2342 E300 049A A915 
  2w1d: Vi1 LCP-FS: I ECHOREP [Open] id 32 len 12 magic 0x52FE6F51 
  2w1d: Vi1 LCP-FS: Received id 32, sent id 32, line up
  
  !--- This side transmitted an Echo Request and received an inbound Echo Reply.
  
  

Point de terminaison Frame Relay

Utilisez les commandes suivantes sur le point d’extrémité Frame Relay pour vérifier que l’interface LFI fonctionne correctement. Avant d'exécuter les commandes debug, référez-vous à la section Informations importantes sur les commandes Debug.

• show ppp multilink - LFI utilise deux interfaces d'accès virtuel, l'une pour PPP et l'autre pour le bundle MLP. Utilisez la commande show ppp multilink pour différencier les deux.

  FRAMEside#show ppp multilink 
  
  Virtual-Access2, bundle name is ATMside 
    Bundle up for 01:15:16 
    0 lost fragments, 0 reordered, 0 unassigned 
    0 discarded, 0 lost received, 1/255 load 
    0x19 received sequence, 0x4B sent sequence 
    Member links: 1 (max not set, min not set) 
      Virtual-Access1, since 01:15:16, last rcvd seq 000018  59464 weight 
  

• show policy-map interface virtual-access - Confirmez que la stratégie de service QoS est liée à l'interface du bundle MLPPP.

  FRAMEside#show policy-map int virtual-access 2 
   Virtual-Access2 
    Service-policy output: example 
  
      Class-map: voice (match-all) 
        0 packets, 0 bytes 
        5 minute offered rate 0 bps, drop rate 0 bps 
        Match: ip rtp 16384 16383 
        Weighted Fair Queueing 
          Strict Priority 
          Output Queue: Conversation 264 
          Bandwidth 110 (kbps) Burst 2750 (Bytes) 
          (pkts matched/bytes matched) 0/0 
          (total drops/bytes drops) 0/0 
  
      Class-map: class-default (match-any) 
        27 packets, 2578 bytes 
        5 minute offered rate 0 bps, drop rate 0 bps 
        Match: any 
        Weighted Fair Queueing 
          Flow Based Fair Queueing 
          Maximum Number of Hashed Queues 256 
          (total queued/total drops/no-buffer drops) 0/0/0 
  
  

• debug frame packet et debug ppp packet - Utilisez ces commandes si toutes les interfaces sont up/up, mais que vous ne pouvez pas envoyer de requête ping de bout en bout.

  FRAMEside#debug frame packet 
  Frame Relay packet debugging is on 
  FRAMEside# 
  FRAMEside#ping 1.1.1.1 
  Type escape sequence to abort. 
  Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds: 
  !!!!! 
  Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/40 ms 
  FRAMEside# 
  2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 
  2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 
  2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 28 
  2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 
  2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 
  2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 28 
  2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 
  2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 
  2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 28 
  2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 
  2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52
  
  

Mise en file et LFI

MLPPPoA et MLPPPoFR clonent deux interfaces d'accès virtuel depuis l'interface de numérotation ou le modèle virtuel. L’une de ces interfaces représente la liaison PPP et l’autre l’interface de l’ensemble MLP. Utilisez la commande show ppp multilink pour déterminer l'interface spécifique utilisée pour chaque fonction. Au moment de l'écriture de ce document, un seul circuit virtuel par groupe est pris en charge, et donc une seule interface d'accès virtuel doit apparaître dans la liste des membres de groupe dans la sortie show ppp multilink.

Outre les deux interfaces d’accès virtuel, chaque circuit virtuel permanent est associé à une interface principale et à une sous-interface. Chacune de ces interfaces fournit une certaine forme de mise en file d’attente. Cependant, seule l'interface d'accès virtuel représentant l'interface de groupement prend en charge la mise en file d'attente de fantaisie via une stratégie de service QoS appliquée. Les trois autres interfaces doivent avoir une mise en file d’attente FIFO. Lors de l'application d'une stratégie de service à un modèle virtuel, le routeur affiche le message suivant :

cr7200(config)#interface virtual-template 1
cr7200(config)#service-policy output Gromit
Class Base Weighted Fair Queueing not supported on interface Virtual-Access1

Remarque : la mise en file d'attente pondérée basée sur les classes est prise en charge sur l'interface de bundle MLPPP uniquement.

Ces messages sont normaux. Le premier message indique qu'une stratégie de service n'est pas prise en charge sur l'interface d'accès virtuel PPP. Le deuxième message confirme que la politique de service est appliquée à l'interface d'accès virtuel du groupe MLP. Pour confirmer le mécanisme de mise en file d'attente sur l'interface de l'ensemble MLP, utilisez les commandes show interface virtual-access, show queue virtual-access, et show policy-map interface virtual-access.

MLPPPoFR nécessite l'activation de Frame Relay Traffic Shaping (FRTS) sur l'interface physique. FRTS active les files d'attente par circuit virtuel. Sur les plates-formes telles que les gammes 7200, 3600 et 2600, FRTS est configuré avec les deux commandes suivantes :

• Formatage du trafic frame-relay sur l’interface principale

• map-class avec des commandes de mise en forme.

Les versions actuelles de Cisco IOS impriment le message d'avertissement suivant si MLPPoFR est appliqué sans FRTS.

"MLPoFR not configured properly on Link x Bundle y"

Si ce message d'avertissement s'affiche, assurez-vous que FRTS a été configuré sur l'interface physique et que la stratégie de service QoS a été associée au modèle virtuel. Pour vérifier la configuration, utilisez les commandes show running-config serial interface et show running-config virtual-template. Lorsque MLPPPoFR est configuré, le mécanisme de mise en file d'attente de l'interface passe à la fonction FIFO double, comme illustré ci-dessous. La file d'attente à priorité élevée gère les paquets vocaux et les paquets de contrôle, tels que l'interface de gestion locale (LMI), et la file d'attente à priorité faible gère les paquets fragmentés, probablement des paquets de données ou non vocaux.

Router#show int serial 6/0:0 
    Serial6/0:0 is up, line protocol is down 
      Hardware is Multichannel T1 
      MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, 
         reliability 255/255, txload 1/255, rxload 1/255 
      Encapsulation FRAME-RELAY, crc 16, Data non-inverted 
      Keepalive set (10 sec) 
      LMI enq sent  236, LMI stat recvd 0, LMI upd recvd 0, DTE LMI down 
      LMI enq recvd 353, LMI stat sent  0, LMI upd sent  0 
      LMI DLCI 1023  LMI type is CISCO  frame relay DTE 
      Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 0 
      Last input 00:00:02, output 00:00:02, output hang never 
      Last clearing of "show interface" counters 00:39:22 
      Queueing strategy: dual fifo 
      Output queue: high size/max/dropped 0/256/0
 !--- high-priority queue

      Output queue 0/128, 0 drops; input queue 0/75, 0 drops
 !--- low-priority queue

      5 minute input rate 0 bits/sec, 0 packets/sec 
      5 minute output rate 0 bits/sec, 0 packets/sec 
         353 packets input, 4628 bytes, 0 no buffer 
         Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 
         0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
         353 packets output, 4628 bytes, 0 underruns 
         0 output errors, 0 collisions, 0 interface resets 
         0 output buffer failures, 0 output buffers swapped out 
         0 carrier transitions 
      no alarm present 
      Timeslot(s) Used:12, subrate: 64Kb/s, transmit delay is 0 flags

LFI utilise deux couches de mise en file d'attente : le niveau de regroupement MLPPP, qui prend en charge la mise en file d'attente de fantaisie, et le niveau PVC, qui prend uniquement en charge la mise en file d'attente FIFO. L’interface de l’ensemble conserve sa propre file d’attente. Tous les paquets MLP passent par l'ensemble MLP et les couches d'accès virtuel avant la couche Frame Relay ou ATM. LFI surveille la taille des files d'attente matérielles des liaisons membres et retire les paquets des files d'attente matérielles lorsqu'ils sont inférieurs à un seuil, qui était à l'origine une valeur de deux. Sinon, les paquets sont mis en file d'attente dans la file d'attente du bundle MLP.

Dépannage et problèmes connus

Le tableau suivant répertorie les problèmes connus avec LFI sur les liens FRF et se concentre sur les étapes de dépannage à suivre pour isoler vos symptômes d'un bogue résolu.

Symptôme	Étapes de dépannage	Bogues résolus
Débit réduit sur la branche ATM ou Frame Relay	Envoyez une requête ping avec des paquets de différentes tailles de 100 octets à la MTU Ethernet. Les paquets volumineux connaissent-ils des délais d’attente ?	CSCdt59038 - Avec des paquets de 1 500 octets et une fragmentation définie sur 100 octets, il y a 15 paquets fragmentés. Le retard a été causé par plusieurs niveaux de file d'attente. CSCdu18344 - Avec FRTS, les paquets sont retirés de la file d'attente plus lentement que prévu. La fonction MLPPP bundle dequeue vérifie la taille de file d'attente de la file d'attente du formateur de trafic. Le FRTS a été trop lent pour effacer cette file d'attente.
Paquets dans le désordre	Exécutez la commande show ppp multilink. Recherchez les valeurs d'incrémentation pour les compteurs « fragments perdus », « ignorés » et « réception perdue ». Virtual-Access4, bundle name is xyz Bundle up for 03:56:11 2524 lost fragments, 3786 reordered, 0 unassigned 1262 discarded, 1262 lost received, 1/255 load 0x42EA1 received sequence, 0xCF7 sent sequence Member links: 1 (max not set, min not set) Virtual-Access1, since 03:59:02, last rcvd seq 042EA0 400 weight Activez debug ppp multi events et recherchez les messages « Lost fragment » et « Out of sync with peer ». *Mar 17 09:14:08.216: Vi4 MLP: Lost fragment 3FED9 in 'dhartr21' (all links have rcvd higher seq#) *Mar 17 09:14:08.232: Vi4 MLP: Received lost fragment seq 3FED9, expecting 3FEDC in 'dhartr21' *Mar 17 09:14:08.232: Vi4 MLP: Out of sync with peer, resyncing to last rcvd seq# (03FED9) *Mar 17 09:14:08.236: Vi4 MLP: Unusual jump in seq number, from 03FEDC to 03FEDA	CSCdv89201 - Lorsque l'interface ATM physique est encombrée, les fragments MLP sont abandonnés ou reçus dans le désordre à l'extrémité distante. Ce problème concerne uniquement les modules de réseau ATM des gammes 2600 et 3600. Il résulte de la façon dont le pilote d'interface commutait incorrectement les paquets sur le chemin rapide (comme avec la commutation rapide ou Cisco Express Forwarding). Plus précisément, le deuxième fragment du paquet en cours a été envoyé après le premier fragment du paquet suivant
Perte de connectivité de bout en bout lorsque la gamme 3600 exécute IWF en mode transparent	Changez le mode en translational et testez à nouveau.	CSCdw1409 - Vérifie que CEF recherche l'emplacement correct des octets pour commencer le traitement des en-têtes d'encapsulation des paquets MLPPP

Informations connexes

• Configuration de la fragmentation et de l’entrelacement des liaisons pour les circuits virtuels Frame Relay et ATM
• Définition et déploiement d'un protocole PPP à liaisons multiples sur Frame Relay et ATM
• RFC2364, PPP sur AAL5, juillet 1998
• RFC1973, PPP dans Frame Relay, juin 1996
• RFC1717, Protocole PPP multiliaison (MP), nov. 1994
• Accord de mise en oeuvre d’interfonctionnement de services PVC Frame Relay / ATM FRF.8
• Plus d'informations ATM
• Outils et ressources - Cisco Systems
• Assistance et documentation techniques - Cisco Systems