Mode de transfert asynchrone (ATM) : Gestion de trafic ATM

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

17 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Ce document fournit un aperçu technique de Fonction Link Fragmentation and Interleaving (LFI) au-dessus d'un Relais de trames à la connexion de l'interworking atmosphère (IWF) (comme défini par le Forum Frame Relay ou l'accord FRF.8), aussi bien qu'une configuration d'échantillon pour l'usage du LS1010 ou du Catalyst 8500 comme le périphérique IWF dans le nuage BLÊME. LFI emploie les capacités intégrées de fragmentation de l'encapsulation du protocole point-à-point de multilink (MLPPP) au-dessus de l'atmosphère et du Relais de trames pour fournir une solution de bout en bout de fragmentation et d'interfoliage pour des liaisons à bas débit avec des bandes passantes de jusqu'à 768 Kbps.

Conditions préalables

Conditions requises

Ce document exige une compréhension de ce qui suit :

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 de documents, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Pourquoi MLPPP au-dessus d'atmosphère et de Relais de trames ?

La fragmentation est une technique principale pour contrôler le retard et la variation de délai de fabrication en série sur des liaisons à bas débit portant le trafic en temps réel et de temps machine. Le retard de fabrication en série est le retard fixe exigé pour synchroniser une trame de voix ou de données sur l'interface réseau, et on le lie directement au rythme d'horloge sur le joncteur réseau. Un indicateur supplémentaire est nécessaire pour séparer les trames pour de basses vitesses d'horloge et petites tailles de trame.

LFI emploie les capacités intégrées de fragmentation de MLPPP pour empêcher le retard et instabilité (variations de retard) provoqué par de grands paquets de taille variable étant alignés entre les paquets vocaux relativement petits. Avec LFI, des paquets plus grands qu'une taille de fragment configurée sont encapsulés dans une en-tête MLPPP. RFC 1990leavingcisco.com définit l'en-tête MLPPP aussi bien que ce qui suit :

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

  • (E) le bit nding de fragment est un positionnement de champ d'un bit à 1 sur le dernier fragment et le positionnement à 0 pour tout l'autre fragmente.

  • Le champ d'ordre est un nombre 24-bit ou 12-bit qui est incrémenté pour chaque fragment transmis. Par défaut, le champ d'ordre est 24 bits longs, mais peut être négocié pour être seulement 12 bits avec l'option de configuration LCP décrite ci-dessous.

En plus de la fragmentation, des paquets sensibles au retard doivent être programmés avec la priorité adéquate entre les fragments d'un grand paquet. Avec la fragmentation, la mise en file d'attente pondérée (WFQ) se rend compte «  » de si un paquet fait partie d'un fragment ou est unfragmented. WFQ assigne un numéro de séquence à chaque paquet de arrivée et puis programme des paquets basés sur ce nombre.

La fragmentation Layer-2 fournit une solution supérieure à toutes autres approches en résolvant le « problème de grand-paquet. » Le tableau suivant présente les avantages et les inconvénients d'autres solutions potentielles.

Solution potentielle Avantages Inconvénients
Abandonnez la transmission du grand paquet et remettez-la dans la file derrière le trafic sensible de retard.
  • Remet seulement la transmission de paquets à plus tard.
  • Quand le paquet est retransmis, le même problème peut se poser. Si les paquets sont continuellement remis et même lâchés dans la file, la famine de bande passante peut résulter.
  • Quelques interfaces physiques ne prennent en charge pas la transmission abandonnée ou introduisent une baisse de performances pour faire ainsi (comme remettre à l'état initial la file d'attente de transmission entière).
Fragmentez le grand paquet utilisant des techniques de fragmentation de réseau-couche.
  • L'IP et les CLNP prennent en charge la fragmentation à n'importe quel routeur, avec le réassemblage se produisant à la destination host.
  • Peut éviter la nécessité de fragmenter le grand paquet avec la détection de MTU.
  • Emploie un mécanisme global pour surmonter quel est essentiellement un problème local (d'un-saut) - tous les sauts en aval doivent traiter un plus grand nombre de paquets pour commuter, même si tous les liens ultérieurs sont rapides.
  • Vide l'option de la compression d'en-tête TCP/IP.
  • Beaucoup d'applications ne reçoivent pas la fragmentation et placer « ne fragmentez pas » mordu dans l'en-tête IP. Ces paquets seront lâchés si fragmentés. Des applications qui ne sont pas capables de recevoir les paquets fragmentés seront rendues inopérables dans cet environnement.
Fragmentez le paquet utilisant des techniques de couche de liaison.
  • Pris en charge avec tout paquet de la couche réseau ou paquet traversier.
  • Fournit la fragmentation de par-lien plutôt qu'exigeant des paquets fragmentés d'être de bout en bout transporté. Seulement les Routeurs reliés au lien lent doivent faciliter la manipulation et le réassemblage des paquets supplémentaires.

La taille de fragment idéale pour le protocole point-à-point de multilink au-dessus de l'atmosphère (MLPPPoATM) devrait permettre aux fragments pour s'insérer dans un multiple précis des cellules atmosphère. Voyez configurer la fragmentation de liaison et l'intercaler pour le Relais de trames et les circuits virtuels ATM pour des conseils sur sélectionner des valeurs de fragmentation.

En-têtes de MLPPPoA et de MLPPPoFR

Une configuration typique de FRF.8 comprend ce qui suit :

  • Un point d'extrémité en relais de trame

  • Un point d'extrémité ATM

  • Un périphérique de l'interworking (IWF)

Chaque point final encapsule des données et des paquets vocaux dans une en-tête d'encapsulation layer-2, qui communique le protocole encapsulé et transporté dans la trame ou la cellule. Relais de trames et en-têtes d'encapsulation de l'ID de Protocol de couche de réseau support atmosphère (NLPID). Le document électrotechnique de la Commission ISO/International (IEC) TR 9577 définit des valeurs réputées NLPID pour un nombre choisi de protocoles. Une valeur de 0xCF est assignée au PPP.

RFC 1973leavingcisco.com définit le PPP dans le Relais de trames et l'en-tête de MLPPPoFR, alors que RFC 2364leavingcisco.com définit le PPP au-dessus d'AAL5 et de l'en-tête de MLPPPoA. Les deux en-têtes emploient une valeur NLPID de 0xCF pour identifier le PPP comme protocole encapsulé.

Chacune de ces en-têtes est illustrée dans la figure 1 ci-dessous.

/image/gif/paws/24041/mlpppoatm_encaps.gif

Schéma 1. PPP au-dessus de l'en-tête AAL5, de l'en-tête de MLPPPoA avec l'encapsulation NLPID, et de l'en-tête de MLPPPoA avec le multiplexage de circuit virtuel

Remarque: L'en-tête de MLPPPoFR inclut également un champ d'indicateur de à un octet de 0x7e, qui n'est pas affiché dans la figure 1. Après les en-têtes, l'octet le numéro 5 des champs commence de PPP ou MLPPP protocole.

Tableau 1 - FRF.8 transparent contre FRF.8 translationnel.

mlpppoatm_headers.gif

mlpppoatm_nlpid_frag_ex.gif

Figure 2. Comment le paquet de MLPPPoATM est fragmenté utilisant NLPID.

mlpppoatm_vcmux_frag_ex.gif

Figure 3. Comment le paquet de MLPPPoATM est fragmenté utilisant le multiplexage de circuit virtuel.

/image/gif/paws/24041/mlpofr_atm_header.gif

La signification des valeurs d'octet sont affichées ci-dessous :

  • 0xFEFE - Identifie la destination et les points d'accès de source de service (sèves) dans l'en-tête de Contrôle de la liaison logique (LLC). Une valeur de 0xFEFE indique que ce qui suit ensuite est une en-tête de la court-forme NLPID, qui est utilisée avec des protocoles ayant une valeur définie NLPID.

  • 0x03 - Champ de contrôle utilisé avec beaucoup d'encapsulations, y compris le High-Level Data Link Control (HDLC). Indique également que le contenu du paquet se compose des informations non numérotées.

  • 0xCF - Valeur réputée NLPID pour le PPP.

FRF.8 transparent contre des modes de traduction

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

  • Transparent - Périphérique IWF en avant les en-têtes d'encapsulation inchangées. Il n'exécute aucune mappage, fragmentation ou réassemblage de Protocol-en-tête.

  • Traduction - Le périphérique IWF effectue le mappage de Protocol-en-tête entre les deux en-têtes d'encapsulation pour expliquer de petites différences entre les types d'encapsulation.

Le mode configuré sur le périphérique IWF, qui peut être un commutateur de campus ATM Cisco ou un routeur de gamme 7200 avec un adaptateur de port ATM PA-A3, change le nombre d'octets d'en-tête layer-2 sur l'atmosphère et les segments de Relais de trames de l'interworking joignent. Regardons plus en détail ce temps système.

Les deux tables suivantes affichent les octets supplémentaires pour des paquets de données et des paquets de la voix sur ip (VoIP).

Tableau 2 - Liaison de données supplémentaire dans les octets pour un paquet de données au-dessus d'un lien FRF.8.

Mode FRF.8 Transparent Traduction
Direction du trafic Relais de trames à l'atmosphère Atmosphère au Relais de trames Relais de trames à l'atmosphère Atmosphère au Relais de trames
Relais de trames ou tronçon atmosphère de PVC Relais de trames Atmosphère Atmosphère Relais de trames Relais de trames Atmosphère Atmosphère Relais de trames
                 
Indicateur de trame (0x7e) 1 0 0 1 1 0 1 0
En-tête de relais de trame 2 0 0 2 2 0 0 2
LLC DSAP/SSAP (0xfefe) 0 0 2 2 0 2 2 0
Le LLC contrôlent (0x03) 1 1 1 1 1 1 1 1
NLPID (0xcf pour le PPP) 1 1 1 1 1 1 1 1
ID MLP Protocol (0x003d) 2 2 2 2 2 2 2 2
Numéro de séquence MLP 4 4 4 4 4 4 4 4
ID de protocole PPP (1er frag seulement) 2 2 2 2 2 2 2 2
Charge utile (couche 3+) 0 0 0 0 0 0 0 0
Couche d'adaptation atmosphère (AAL)5 0 8 8 0 0 8 8 0
Frame Check Sequence (FCS) 2 0 0 2 2 0 0 2
                 
Temps système total (octets) 15 18 20 17 15 20 20 15

Tableau 3 - Liaison de données supplémentaire dans les octets pour un paquet VoIP au-dessus d'un lien FRF.8.

Mode FRF.8 Transparent Traduction Relais de trames au Relais de trames
Direction du trafic Relais de trames à l'atmosphère Atmosphère au Relais de trames Relais de trames à l'atmosphère Atmosphère au Relais de trames  
Relais de trames ou tronçon atmosphère de PVC Relais de trames Atmosphère Atmosphère Relais de trames Relais de trames Atmosphère Atmosphère Relais de trames
                   
Indicateur de trame (0x7e) 1 0 0 1 1 0 0 1 1
En-tête de relais de trame 2 0 0 2 2 0 0 2 2
LLC DSAP/SSAP (0xfefe) 0 0 2 2 0 2 2 0 0
Le LLC contrôlent (0x03) 1 1 1 1 1 1 1 1 1
NLPID (0xcf pour le PPP) 1 1 1 1 1 1 1 1 1
ID DE PPP 2 2 2 2 2 2 2 2 0
Charge utile (Protocole UDP (User Datagram Protocol) +RTP+Voice IP+) 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
                   
Temps système total (octets) 9 12 14 11 9 14 14 9 7

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

  • Des paquets plus petits que la taille de fragmentation spécifiée sont encapsulés seulement dans une en-tête de PPP et pas dans une en-tête MLPPP. De même, des paquets plus grands que la taille de fragmentation spécifiée sont encapsulés dans une en-tête de PPP et une en-tête MLPPP. Ainsi, les paquets VoIP ont jusqu'à huit octets moins de temps système.

  • Seulement le premier fragment du PPP à liaisons multiples (MLP) inclut un champ d'ID de protocole PPP. Ainsi, le premier fragment porte deux byes supplémentaires de temps système.

  • En mode transparent, les en-têtes d'encapsulation sont passées sans changement par le périphérique IWF. Ainsi, le temps système varie dans chaque direction et sur chaque segment. Spécifiquement, débuts d'une en-tête de MLPPPoA avec une en-tête de la court-forme NLPID de 0xFEFE. En mode transparent, cette en-tête est passée sans changement par le périphérique IWF du segment atmosphère au segment de Relais de trames. Cependant, dans le Relais de trames à la direction atmosphère, aucune une telle en-tête n'existe en mode transparent sur l'un ou l'autre de segment.

  • Dans à mode de traduction, le périphérique IWF change les en-têtes d'encapsulation. Ainsi, le temps système est identique sur chaque segment dans l'un ou l'autre de direction. Spécifiquement, en atmosphère à la direction de Relais de trames, le point d'extrémité ATM encapsule le paquet dans une en-tête de MLPPPoA. Le périphérique IWF retire l'en-tête NLPID avant de passer la trame restante au segment de Relais de trames. Dans le Relais de trames à la direction atmosphère, le périphérique IWF de nouveau manipule la trame et ajoute une en-tête au début NLPID avant de passer la trame segmentée au point d'extrémité ATM.

  • Quand concevoir le FRF joint avec MLP, soit sûr d'expliquer le nombre correct d'octets supplémentaires de liaison de données. Un tel temps système influence la quantité de bande passante consommée par chaque appel VoIP. Il joue également un rôle en déterminant la taille de fragment de l'optimum MLP. Optimiser la taille de fragment pour adapter un nombre entier de cellules atmosphère est essentiel, en particulier sur PVCs à basse vitesse où une importante quantité de bande passante peut être gaspillée sur compléter la dernière cellule à un multiple égal de 48 octets.

Pour la clarté, marchons par les étapes du processus d'encapsulation de paquets quand un paquet entre dans le Relais de trames à la direction atmosphère avec le mode transparent :

  1. Le point d'extrémité en relais de trame encapsule le paquet dans une en-tête de MLPPPoFR.

  2. Le périphérique IWF retire l'en-tête de relais de trame à deux bits avec l'identificateur de connexion de liaison de données (DLCI). Il puis en avant le paquet restant à l'interface ATM de l'IWF, qui segmente le paquet dans des cellules et en avant lui à travers le segment atmosphère.

  3. Le point d'extrémité 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 comme étant le paquet un paquet valide de MLPPPoA.

  4. Les fonctions MLPPP sur le point d'extrémité ATM exécutent une transformation plus ultérieure.

Regardez le processus d'encapsulation de paquets quand un paquet entre en atmosphère à la direction de Relais de trames avec le mode transparent :

  1. Le point d'extrémité ATM encapsule le paquet dans une en-tête de MLPPPoA. Il segmente alors les paquets dans des cellules et en avant elles le segment atmosphère.

  2. L'IWF reçoit le paquet, en avant il à son interface de Relais de trames, et ajoute une en-tête de relais de trame au début à deux bits.

  3. Le point d'extrémité en relais de trame examine l'en-tête du paquet reçu. Si les quatre premiers octets après que l'en-tête de relais de trame à deux bits soient 0xfefe03cf, l'IWF traite le paquet comme paquet juridique de MLPPPoFR.

  4. Les fonctions MLPPP sur le point d'extrémité en relais de trame exécutent une transformation plus ultérieure.

Les illustrations suivantes affichent le format des paquets de MLPPPoA et de MLPPPoFR.

/image/gif/paws/24041/mlpppoa-overhead.gif

Le schéma 6. MLPPPoA supplémentaire. Seulement le premier fragment porte une en-tête de PPP.

mlpppofr-overhead.gif

Le schéma 7. MLPPPoFR supplémentaire. Seulement le premier fragment porte une en-tête de PPP.

Bandes passantes nécessaires VoIP

Quand la bande passante de ravitaillement pour le VoIP, le temps système de liaison de données doit être incluse dans les calculs de bande passante. Le tableau 4 affiche les conditions requises de bande passante par appel pour le VoIP selon les codecs et l'utilisation du Protocole RTP (Real-Time Transport Protocol) comprimé. Les calculs dans le tableau 4 assument un scénario le plus optimiste pour la Compression d'en-tête RTP (cRTP), en d'autres termes, aucune erreurs de somme de contrôle ou de transmission d'UDP. Des en-têtes alors sont uniformément compressées de 40 octets à deux octets.

Tableau 4 - Par bandes passantes nécessaires d'appel VoIP (Kbps).

Mode FRF.8 Transparent Traduction Relais de trames au Relais de trames
Direction du trafic Relais de trames à l'atmosphère Atmosphère au Relais de trames Relais de trames à l'atmosphère Atmosphère au Relais de trames  
Relais de trames ou tronçon atmosphère de PVC Relais de trames Atmosphère Atmosphère Relais de trames Relais de trames Atmosphère Atmosphère Relais de trames
                   
G729 - 20 échantillons de ms - aucun cRTP 27.6 42.4 42.4 28.4 27.6 42.4 42.4 27.6 26.8
G729 - 20 échantillons de ms - cRTP 12.4 21.2 21.2 13.2 12.4 21.2 21.2 12.4 11.6
G729 - 30 échantillons de ms - aucun cRTP 20.9 28.0 28.0 21.4 20.9 28.0 28.0 20.9 20.3
G729 - 30 échantillons de ms - cRTP 10.8 14.0 14.0 11.4 10.8 14.0 14.0 10.8 10.3
G711 - 20 échantillons de ms - aucun cRTP 83.6 106.0 106.0 84.4 83.6 106.0 106.0 83.6 82.8
G711 - 20 échantillons de ms - cRTP 68.4 84.8 84.8 69.2 68.4 84.8 84.8 68.4 67.6
G711 - 30 échantillons de ms - aucun cRTP 76.3 97.9 97.9 76.8 76.3 97.9 97.9 76.3 75.8
G711 - échantillons 30ms - cRTP 66.3 84.0 84.0 66.8 66.3 84.0 84.0 66.3 65.7

Puisque le temps système varie sur chaque tronçon du PVC, nous recommandons concevoir pour un pire scénario. Par exemple, considérez le cas d'un appel G.279 avec l'échantillonnage 20 millisecondes et de cRTP à travers un PVC transparent. Sur le tronçon de Relais de trames, la bande passante nécessaire est de 12.4 Kbps dans une direction et de 13.2 Kbps dans l'autre. Ainsi, nous recommandons le ravitaillement basé sur 3.2 Kbps par appel.

Pour la comparaison, la table affiche également la bande passante nécessaire VoIP sur un PVC de bout en bout de Relais de trames configuré avec la fragmentation de FRF.12. Comme observé dans la table, le PPP consomme entre 0.5 Kbps et 0.8 Kbps de bande passante supplémentaire par appel pour prendre en charge les octets supplémentaires d'en-tête d'encapsulation. Ainsi, nous recommandons utilisant le FRF.12 avec le Relais de trames de bout en bout VCs.

Le RTP comprimé (cRTP) au-dessus de l'atmosphère exige la version de logiciel 12.2(2)T de Cisco IOSÝ. Quand le 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 RFC 2509, qui ne permet pas la négociation PPP de la Compression d'en-tête RTP sans Compression d'en-tête TCP également de négociation.

Traduction et support transparent sur des périphériques de Cisco

Initialement, LFI a exigé que les périphériques IWF utilisent le mode transparent. Plus récemment, le Forum Frame Relay a introduit le FRF.8.1 pour prendre en charge à mode de traduction. Cisco ont introduit le soutien du FRF.8.1 et à mode de traduction dans les versions suivantes du logiciel de Cisco IOS :

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

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

Quelques fournisseurs de services ne prennent en charge pas encore la traduction de PPP sur leurs périphériques FRF.8. Toutes les fois que c'est le cas, le fournisseur doit configurer leur PVCs pour le mode transparent.

Matériel et logiciel

Le chapitre d'aperçu de mécanismes d'efficacité de lien répertorie le matériel pris en charge pour la caractéristique LFI. Cette configuration utilise le matériel et le logiciel suivants :

  • Point d'extrémité ATM - PA-A3-OC3 dans un Logiciel Cisco IOS version 2.2(8)T courant de routeur de gamme 7200. (Note : LFI est pris en charge sur le PA-A3-OC3 et le PA-A3-T3 seulement. Il n'est pas pris en charge sur les adaptateurs de port d'OC-12 IMA et atmosphère.)

  • Périphérique IWF - LS1010 avec le module et la version du logiciel Cisco IOS canalisés 12.1(8)EY d'adaptateur de port de T3.

  • Point d'extrémité en relais de trame - PA-MC-T3 dans un Logiciel Cisco IOS version 2.2(8)T courant de routeur de gamme 7200.

Diagramme de topologie

/image/gif/paws/24041/lfi-topology.gif

Configurations

Cette section affiche comment configurer la caractéristique LFI au-dessus d'un lien FRF.8 en mode transparent. Il utilise un modèle virtuel sur les deux points finaux de routeur, desquels l'interface d'accès virtuelle du paquet MLP est copiée. LFI prend en charge des interfaces de numérotation et des modèles virtuels pour spécifier les paramètres de Protocol-couche de MLPPP. Le Logiciel Cisco IOS version 2.2(8)T augmente à 200 le nombre de seuls modèles virtuels qui peuvent être configurés par routeur. Les versions préalables prennent en charge seulement jusqu'à 25 modèles virtuels par routeur. Cette limite peut être un problème d'échantillonnage sur un routeur de distribution atmosphère si chaque PVC est exigé pour avoir une adresse IP unique. Comme contournement, l'IP d'utilisation en tant que non-numéroté ou remplacent les modèles virtuels par des interfaces de numérotation sur les liens numérotés.

La Cisco IOS version 12.1(5)T a introduit le soutien de LFI au-dessus de seulement une liaison membre par paquet MLPPP. Ainsi, cette configuration utilise seulement un circuit virtuel simple à chaque point final. Le soutien de plusieurs VCs par paquet est prévu pour une prochaine version de Cisco IOS.

Point d'extrémité en relais de trame
  1. L'adaptateur canalisé de port de T3 exige que vous créez un channel-group et spécifiez les créneaux horaires. Par défaut, interface n'existe pas.
    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  
    
    
  2. Utilisez la commande de show diag de déterminer l'adaptateur installé de port. Dans cet exemple, la PA de T3 est dans l'emplacement 3. les versions qu'en cours du Cisco IOS affichent maintenant le numéro de pièce (FRU) remplaçable sur place pour commander en cas de défaillance 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 
    
    
  3. Exécuter la commande de T3 de show controller affiche des alarmes et des statistiques de 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] 
    
    
  4. Sélectionnez un t1 du mode configuration de contrôleur de T3, créez un channel-group, et assignez les créneaux horaires 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 reliée n'est pas pareillement configurée, la couche de liaison de la nouvelle interface canalisée est soulevée, mais la ligne protocole reste vers le bas.

  5. L'interface série 3/0/1:1 d'interface identifie la nouvelle interface canalisée. Configurez l'interface pour l'Encapsulation de relais de trames et puis activez le Formatage du trafic de relais de trames (FRTS) 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.
    
    
  6. Configurez une classe de mappage de relais de trame pour s'appliquer des paramètres de formatage du trafic au circuit virtuel à relais de trame (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
    
  7. Créez une stratégie de service QoS. Utilisez les mêmes paramètres comme le côté atmosphère. Voir ci-dessous pour la 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)
  8. Créez une interface de modèle virtuel et appliquez les paramètres MLPPP. Appliquez-vous également la service-stratégie de 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 
    
    
  9. Créez une sous-interface et assignez le nombre de l'identifiant de connexion de liaison de donnée par relais de trame (DLCI). Appliquez alors l'encapsulation PPP, le modèle virtuel, et le map-class.
    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 
    
    
  10. Utilisez la commande de show frame-relay pvc de confirmer vos paramètres de virtual-template et de 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 
    
  11. Employez l'interface série 3/0/1:1 de show controller pour confirmer que le lien de Relais de trames est dans un statut et un espace libre hauts des alarmes de couche physique. Chaque interface canalisée est assignée un nombre de « circuit virtuel ». Dans la sortie suivante, le channel-group 1 (3/0/1:1) est assigné un nombre 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
  1. Utilisez la commande show hardware de confirmer que votre LS1010 est équipé d'un module canalisé d'adaptateur de port de relais de trame (PAM).
    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
    
  2. Utilisez la commande brief du show ip international d'identifier l'interface de 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
    
  3. Créez une interface canalisée et sélectionnez les mêmes créneaux horaires que l'adaptateur de port 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 
    
    
  4. Configurez l'Encapsulation de relais de trames sur la nouvelle interface série. En outre, changez le type local de l'interface de gestion (LMI) de NNI au DCI.
    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 
    
  5. Utilisez la commande séquentielle d'interface d'exposition de confirmer l'Encapsulation de relais de trames.
    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 
    
  6. Avant que vous configuriez le PVC, assurez-vous que l'interface ATM est up/up.
    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 
  7. En plus des deux interfaces physiques, le LS1010 emploie une interface logique pour joindre le côté atmosphère et le côté relais de trame. L'interface logique est identifiée en tant que "atm-p1" sur la pseudo interface atmosphère.
    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 
    
  8. En mode de configuration de l'interface série, configurez le PVC de dialogue.
    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
    
  9. Confirmez votre configuration avec la commande d'interface atm de l'exposition vc.
    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    

Point d'extrémité ATM
  1. Assurez-vous que vous utilisez un port ATM ou un PA-A3 amélioré. Utilisez la commande d'interface atm d'exposition de 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] 
    
  2. Configurez les paramètres d'Atmosphère-couche du circuit virtuel permanent (PVC). Dans cette configuration, nous utilisons une sous-interface point par point avec du débit de cellules soutenu (SCR) de 150 Kbps. Cette valeur a été sélectionnée pour être supérieur à environ de 15% le CIR du point d'extrémité en relais de trame de 128 Kbps. Les aides supplémentaires de 15% pour s'assurer que le circuit virtuel fournit une bande passante équivalente au trafic réel d'utilisateur des deux côtés de la connexion tout en facilitant le temps système supplémentaire du côté atmosphère. (Voyez configurer également le trafic formant sur le Relais de trames à l'interworking de service ATM (FRF.8) PVCs.)
    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.
    
    
  3. Confirmez que votre circuit virtuel apparaît dans la table de circuit virtuel. Exécutez la commande de show atm vc. Notez que le routeur assigne un maximum par défaut de la taille de rafale (mis-bande) de 94 puisque nous n'avons pas écrit une 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 
  4. Créez une stratégie de service QoS. Dans la stratégie affichée ci-dessous, nous avons créé quatre classes, y compris la classe par défaut routeur-créée.
    1. Créez un class-map pour les paquets de la voix sur ip (VoIP).
      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.
      
      
    2. Créez un class-map pour les paquets de signalisation de Voix. Cet exemple utilise H.323 rapide se connectent. (Voyez également la section « d'instructions de configuration LLQ » de VoIP au-dessus des liens de PPP avec la qualité de service (LLQ/IP RTP Priority, LFI, le 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
      
    3. Créez un policy-map Désigné et assignez les actions de QoS à chaque classe. Cet exemple assigne la priorité s'alignant aux paquets d'utilisateur VoIP avec la commande prioritaire et une garantie de bande passante minimale aux paquets d'appel-signalisation avec la commande bandwidth. Tout autre trafic va à la classe par défaut, qui sépare le trafic dans des écoulements d'IP-couche et fournit la foire-queue parmi les écoulements.
      policy-map example 
        class call-control 
          bandwidth percent 10 
        class voice 
           priority 110 
        class class-default 
          fair-queue 
      
      
    4. 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 
      
  5. Créez un modèle virtuel et appliquez-vous la stratégie de service QoS à elle.
    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. 
    
    
    
  6. Appliquez-vous l'encapsulation virtuelle de modèle et de PPP à liaisons multiples au PVC atmosphère.
    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 
    
  7. Confirmez vos configurations sur le PVC atmosphère.
    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 
    
  8. Le routeur crée une interface d'accès virtuel automatiquement. Si vous n'avez pas MLPPP configuré sur le point d'extrémité en relais de trame, le statut de l'interface d'accès virtuel est haut/bas.
    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 d'exposition et de débogage

Point d'extrémité ATM

Utilisez les commandes suivantes sur le point d'extrémité ATM de confirmer que 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 -- un pour le PPP et un pour le paquet MLP. Employez le show ppp multilink pour différencier entre 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.
    
    
  • affichez l'interface virtuel-Access 1 - Confirmez que l'interface d'accès virtuel est up/up et incrémentation des compteurs de paquets d'entrée et 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 international virtuel-Access 2 - Confirmez que la stratégie de service QoS est liée à l'interface de paquet 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
    
  • le paquet de debug ppp et mettent au point le paquet atmosphère - Utilisez ces commandes si toutes les interfaces sont up/up, mais vous ne pouvez pas cingler de bout en bout. En outre, vous pouvez utiliser ces commandes de capturer le Keepalives de 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 d'extrémité en relais de trame

Utilisez les commandes suivantes sur le point d'extrémité en relais de trame de confirmer que 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 -- un pour le PPP et un pour le paquet MLP. Employez le show ppp multilink pour différencier entre 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 virtuel-Access - Confirmez que la stratégie de service QoS est liée à l'interface de paquet 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 
    
    
  • mettez au point le paquet de trame et le paquet de debug ppp - Utilisez ces commandes si toutes les interfaces sont up/up, mais vous ne pouvez pas cingler 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
    
    

Queue et LFI

MLPPPoA et MLPPPoFR copient deux interfaces d'accès virtuel de l'interface de numérotation ou du modèle virtuel. Une telle interface représente le lien de PPP, et l'autre représente l'interface de paquet MLP. Utilisez la commande de show ppp multilink de déterminer l'interface spécifique utilisée pour chaque fonction. En date de cette écriture, seulement un circuit virtuel par paquet est pris en charge, et seulement une interface d'accès virtuel devrait apparaître ainsi dans la liste de paquet-membre dans la sortie de show ppp multilink.

En plus des deux interfaces d'accès virtuel, chaque PVC est associé avec une interface principale et une sous-interface. Chacune de ces interfaces fournit une certaine forme de la queue. Cependant, seulement l'interface d'accès virtuel représentant l'interface de paquet prend en charge la queue de fantaisie par l'intermédiaire d'une stratégie de service QoS appliquée. Les trois autres interfaces doivent avoir la mise en file d'attente FIFO. En appliquant une service-stratégie à un virtual-template, 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: Classez la mise en file d'attente pondérée basée prise en charge sur l'interface de paquet MLPPP seulement.

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

MLPPPoFR a besoin de que le Formatage du trafic de relais de trames (FRTS) soit activé sur l'interface physique. FRTS lance des files d'attente de par-circuit virtuel. Sur des Plateformes telles que les 7200, les 3600, et la gamme 2600, FRTS est configuré avec les deux commandes suivantes :

  • frame-relay traffic-shaping sur l'interface principale

  • map-class avec toutes commandes de formation.

Les versions en cours du Cisco IOS imprime le message d'avertissement suivant si MLPPoFR est appliqué sans FRTS.

"MLPoFR not configured properly on Link x Bundle y"

Si vous voyez ce message d'avertissement, assurez-vous que FRTS a été configuré sur l'interface physique et que la stratégie de service QoS a été reliée au modèle virtuel. Pour vérifier la configuration, utilisez l'interface série de show running-config et les commandes de virtual-template de show running-config. Quand MLPPPoFR est configuré, le mécanisme de mise en file d'attente d'interface change pour conjuguer FIFO, comme illustré ci-dessous. La file d'attente prioritaire manipule des paquets vocaux et les paquets de contrôle, tels que l'interface de gestion locale (LMI), et la file d'attente à basse priorité manipule les paquets fragmentés, vraisemblablement les données ou les paquets 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 queue -- Niveau de paquet MLPPP, qui prend en charge la queue de fantaisie, et niveau PVC, qui prend en charge seulement la mise en file d'attente FIFO. L'interface de paquet met à jour sa propre file d'attente. Tous les paquets MLP passent par le paquet et les couches d'accès virtuelles premier MLP avant que le Relais de trames ou couche atmosphère. LFI surveille la taille du matériel des liaisons membres aligne et retire des paquets de la file d'attente aux files d'attente de matériel quand ils tombent au-dessous d'un seuil, qui était initialement une valeur de deux. Autrement, les paquets sont alignés dans la file d'attente de paquet MLP.

Dépannage et problèmes connus

Les problèmes connus de listes de tableau suivant avec LFI au-dessus des liens et des foyers FRF sur les étapes de dépannage à prendre pour localiser vos symptômes dans une bogue résolue.

Symptôme Étapes de dépannage Bogues résolues
Débit réduit sur le tronçon atmosphère ou le tronçon de Relais de trames
  • Cinglez avec les paquets de taille diverse de 100 octets au MTU d'Ethernets.
  • Les grands paquets éprouvent-ils des délais d'attente ?
CSCdt59038 - Les paquets 1500-byte et la fragmentation étant placé à 100 octets, il y a 15 paquets fragmentés. Le retard a été provoqué par par de plusieurs niveaux de la queue. CSCdu18344 - Avec FRTS, des paquets sont retirés de la file d'attente plus lentement que prévus. Le paquet MLPPP retirent des contrôles de la file d'attente de fonctionnement la taille de file d'attente de la file d'attente de régulateur de trafic. FRTS était trop lent en effaçant cette file d'attente.
Paquets en panne
  • Exécutez la commande de show ppp multilink. Look for incrémentant des valeurs pour « a perdu des fragments », « jeté », et « a perdu » les compteurs reçus.
    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 les événements multi de debug ppp et recherchez « a perdu le fragment » et « hors du sync avec des messages de pair ».
    *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 - Quand l'interface ATM physique est congestionnée, des fragments MLP sont abandonnés ou en panne reçu à l'extrémité distante. Ce problème affecte seulement des modules de réseau ATM sur les gammes 2600 et 3600. Il résulte de la façon dont le gestionnaire d'interface commutait inexactement des paquets dans le chemin rapide (comme avec la commutation rapide ou le Cisco Express Forwarding). Spécifiquement, le deuxième fragment du paquet en cours a été envoyé après que le premier fragment du paquet suivant
Perte de Connectivité de bout en bout quand la gamme 3600 exécute IWF en mode transparent
  • Changez le mode à translationnel et au test de nouveau.
CSCdw11409 - S'assure que des aspects de CEF dans l'emplacement correct d'octet pour commencer traitant les en-têtes d'encapsulation des paquets MLPPP

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 24041