Qualité de service (QoS) : Mécanismes d'efficacité de liaison QoS

Configuration et vérification des fonctionnalités distribuées sur les routeurs Cisco 75xx et 76xx

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 avril 2015) | Commentaires


Contenu


Introduction

Ce document vous aide à comprendre, configurer, et vérifier ces caractéristiques :

  • Protocole de point-à-point distribué de Multilien (dMLP)

  • Fonction Link Fragmentation and Interleaving (LFI) distribué

  • LFI distribué au-dessus de ligne louée (dLFIoLL)

  • LFI distribué au-dessus de Relais de trames (dLFIoFR)

  • LFI distribué au-dessus d'atmosphère (dLFIoATM)

  • Différences entre MLP distribué (dMLP) et dLFIoLL

  • Relais de trames distribué de Multilien (dMLFR)

  • Routage sur demande distribué de cadran (DDR)

Conditions préalables

Conditions requises

Les lecteurs de ce document devraient avoir la connaissance des caractéristiques distribuées pour Cisco 7500/7600/6500.

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

  • Tout le Cisco 7500 et 7600 Plateformes

    Remarque: Les informations dans ce document appliquent également à 6500 Plateformes.

  • Versions logicielles appropriées de ½ du ¿  de Cisco IOSïÂ, que ce tableau présente :

Soutien distribué de caractéristiques de chaque branchement et plate-forme

- - -
Caractéristique Adaptateurs de port (PAs) 1 pris en charge 7500 Plateformes 7600 Plateformes
Versions du logiciel Cisco IOS importantes Versions de Cisco IOS (intérim) Versions du logiciel Cisco IOS importantes Versions du logiciel Cisco IOS (intérim)
dMLP Chan-PA PA-4T+ PA-8T 12.0T 12.0S 12.1 12.1T 12.2 12.2T 12.3 12.3T 12.2S 12.1E2 12.0(3)T et 12.0(9)S postérieur et plus tard 12.2SX 12.1E2
dLFIoLL Chan-PA PA-4T+ PA-8T 12.2T 12.3 12.3T 12.0S 12.2(8)T et 12.0(24)S postérieur et plus tard 12.2SX 12.2(17)SXB et ultérieures
dLFIoFR Chan-PA PA-4T+ PA-8T 12.2T 12.3 12.3T 12.2(4)T3 et plus tard 12.2SX 12.2(17)SXB et ultérieures
dLFIoATM PA-A3 PA-A6 12.2T 12.3 12.3T 12.2(4)T3 et plus tard 12.2SX 12.2(17)SXB et ultérieures
dMLFR Chan-PA PA-4T+ PA-8T 12.0S 12.3T 12.0(24)S et 12.3(4)T postérieur et plus tard 12.2SX 12.2(17)SXB et ultérieures
QoS sur le dMLP Chan-PA PA-4T+ PA-8T 12.0S 12.2T 12.3 12.3T 12.0(24)S et 12.2(8)T postérieur et plus tard 12.2SX 12.2(17)SXB et ultérieures
MPLS sur le dMLP MPLS sur le dLFIoLL Chan-PA PA-4T+ PA-8T 12.2T 12.3 12.2(15)T11 et plus tard 12.3(5a) et plus tard 12.2SX 12.2(17)SXB et ultérieures
DDR distribué PA-MC-xT1 PA-MC-xE1 PA-MC-xTE1 PA-MCX-xTE1 12.3T 12.3(7)T et plus tard

Remarque: Rendez-vous compte de ces informations :

  1. Ces caractéristiques distribuées par support de PAs :

    • CT3IP

    • PA-MC-T3

    • PA-MC-2T3+

    • PA-MC-E3

    • PA-MC-2E1

    • PA-MC-2T1

    • PA-MC-4T1

    • PA-MC-8T1

    • PA-MC-8E1

    • PA-MC-8TE1+

    • PA-MC-STM-1

  2. La version du logiciel Cisco IOS 12.1E prend en charge ces caractéristiques sur 7500 et 7600 Plateformes.

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Conventions

Pour plus d'informations sur les conventions de documents, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Caractéristiques distribuées

Ces caractéristiques sont expliquées dans ce document :

  • MLP distribué

  • LFI distribué

  • LFI distribué au-dessus de ligne louée

  • LFI distribué au-dessus de Relais de trames

  • LFI distribué au-dessus d'atmosphère

  • Différences entre le dMLP et le dLFIoLL

  • MLFR distribué

  • Numéroteur distribué

  • Plateformes et linecards qui prennent en charge les caractéristiques distribuées

MLPPP distribué

La caractéristique distribuée de protocole de point-à-point de Multilien (dMLP) te permet pour combiner les pleines ou fractionnaires lignes T1/E1 dans un linecard (VIP, FlexWAN) sur un routeur de gamme Cisco 7500 ou 7600 dans un paquet qui a la bande passante combinée de plusieurs liens. Vous employez un paquet distribué MLP pour faire ceci. Un utilisateur peut choisir le nombre de paquets dans un routeur et le nombre de liens par paquet. Ceci permet à l'utilisateur pour augmenter la bande passante de liaisons réseau au delà de cela d'une ligne T1/E1 simple sans nécessité d'acheter une ligne de T3. Dans le non-dMLP, tous les paquets sont commutés par le processeur d'artère (RP) ; donc, cette implémentation affecte la représentation du RP, avec l'utilisation du CPU élevé pour seulement quelques T1/E1 raye MLP courant. Avec le dMLP, le nombre total de paquets qui peuvent être manipulés sur le routeur est augmenté, car le chemin de données est manipulé et limité par la CPU et mémoire de linecard. le dMLP te permet pour empaqueter T1/E1 fractionnaire, à partir de DS0 (64 Kbits/s) en avant.

LFI distribué

Les prises en charge de fonctionnalité de dLFI le transport du trafic en temps réel (tel que la Voix) et du trafic de temps machine (tel que des données) sur un Relais de trames et des circuits virtuels ATM plus à vitesse réduite (VCs) et sur des lignes louées sans entraîner le retard excessif au trafic en temps réel.

Cette caractéristique est mise en application utilisant le PPP à liaisons multiples (MLP) au-dessus du Relais de trames, de l'atmosphère, et des lignes louées. La caractéristique fragmente un grand paquet de données dans un ordre de plus petits fragments, pour activer les paquets en temps réel sensibles au retard et les paquets de temps machine pour partager la même chose joignent. Les fragments sont alors intercalés avec les paquets en temps réel. Du côté réception du lien, les fragments sont rassemblés et le paquet est reconstruit.

La caractéristique de dLFI est souvent utile dans les réseaux qui envoient le trafic en temps réel par l'intermédiaire du Fonction Distributed Low Latency Queuing (tel que la Voix) mais a des problèmes de bande passante. Ceci retarde le trafic en temps réel dû au transport de grands, moins sensibles au temps paquets de données. Vous pouvez employer la caractéristique de dLFI dans ces réseaux, pour désassembler les grands paquets de données dans de plusieurs segments. Les paquets en temps réel du trafic alors peuvent être envoyés entre ces segments des paquets de données. Dans ce scénario, le trafic en temps réel n'éprouve pas un retard prolongé tandis qu'il attend les paquets de données à basse priorité pour traverser le réseau. Les paquets de données sont rassemblés au côté réception du lien, ainsi les données sont fournies intactes.

La taille de fragment du lien est calculée a basé sur le retard de fragment sur l'ensemble multiliaison, configuré avec la commande du ppp multilink fragment delay n, où :

fragment size = bandwidth � fragment-delay / 8

Cette taille de fragment représente la charge utile d'IP seulement. Il n'inclut pas les octets d'encapsulation (taille de fragment = poids ? des octets d'encapsulation). Les termes « poids » et « taille de fragment » sont comme vus dans la sortie de la commande de show ppp multilink sur le RP. Si le retard de fragment n'est pas configuré, la taille de fragment par défaut est calculée pour un fragment-retard maximum de 30.

Remarque: Avec des liens de bande passante variable, la taille de fragment choisie est basée sur le lien avec la moins bande passante.

LFI distribué au-dessus de ligne louée

La caractéristique de dLFIoLL étend la fonctionnalité distribuée de fragmentation de liaison et d'interfoliage aux lignes louées. LFI distribué est configuré avec la commande de ppp multilink interleave sur l'interface de multilink group. Il est recommandé que vous utilisiez LFI distribué sur des interfaces multiliaison avec la bande passante moins de 768 Kbps. C'est parce que le retard de fabrication en série pour 1500 paquets d'octet pour de plus grand que 768 Kbps de bande passante est dans des limites de délai acceptables et n'a pas besoin d'être fragmenté.

LFI distribué au-dessus de Relais de trames

La caractéristique de dLFIoFR est une extension du PPP à liaisons multiples au-dessus de la caractéristique de Relais de trames (MLPoFR). MLP est utilisé pour la fragmentation. Cette caractéristique est semblable au FRF.12, qui prend en charge la fragmentation et peut intercaler les paquets prioritaires par l'intermédiaire de la basse Mise en file d'attente de latence.

La commande de ppp multilink interleave sur le virtual-template est exigée pour activer l'interfoliage sur l'interface d'accès virtuel associée. En plus de l'activation de la commutation de CEF distribué sur l'interface série, cette commande est un préalable à LFI distribué à fonctionner.

Remarque: À moins que vous utilisiez le Relais de trames à l'Interconnexion de réseaux atmosphère, il est recommandé que vous utilisez le FRF.12 plutôt que le dLFIoFR, parce que l'utilisation de bande passante est meilleure avec le FRF.12

LFI distribué au-dessus d'atmosphère

La caractéristique de dLFIoATM est une extension du PPP à liaisons multiples au-dessus de la caractéristique atmosphère (MLPoATM). MLP est utilisé pour la fragmentation.

La commande de ppp multilink interleave sur le virtual-template est exigée pour activer l'interfoliage sur l'interface d'accès virtuel associée. En plus de l'activation de la commutation de CEF distribué sur l'interface série, cette commande est un préalable à LFI distribué à fonctionner.

Avec le dLFIoATM, il est très important que vous sélectionniez une taille de fragment qui fait les paquets pour s'adapter en cellules atmosphère de telle manière qu'ils n'entraînent pas la remplissage inutile dans les cellules atmosphère. Par exemple, si la taille de fragment sélectionnée est de 124 octets, ceci signifie qu'une charge utile d'IP de 124 octets irait finalement en tant que 124 + 10 (en-tête MLP) + 8 (en-tête SNAP) = 142 octets. Il est important de noter que le premier fragment sortirait avec 124 + 10 + 2 (fragmentez d'abord la taille d'en-tête PID) + 8 = 144 octets. Ceci signifie que ce paquet emploiera trois cellules atmosphère pour transférer la charge utile et, par conséquent, utiliserait la cellule emballée le plus efficacement.

Différences entre le dMLP et le dLFIoLL

le dMLP ne prend en charge pas la fragmentation du côté de transmission, tandis que le dLFIoLL fait.

Remarque: L'interfoliage et la fragmentation utilisés avec plus d'un lien dans l'ensemble multiliaison pour le trafic vocal ne garantit pas que le trafic vocal reçu par l'intermédiaire de plusieurs liens dans le paquet sera reçu dans la commande. La commande correcte de la Voix est manipulée aux couches supérieures.

MLFR distribué

La caractéristique distribuée MLFR introduit la fonctionnalité basée sur l'accord d'implémentation du Relais de trames UNI/NNI de Multilien de Forum Frame Relay (FRF.16) aux Routeurs linecard-activés de gammes Cisco 7500 et 7600. La caractéristique distribuée MLFR fournit un moyen plus économique d'augmenter la bande passante pour des applications particulières parce qu'elle permet de plusieurs liaisons série à agréger dans un seul paquet de bande passante. MLFR est pris en charge sur les interfaces d'Utilisateur-à-réseau (UNI) et les interfaces entre réseaux (NNI) dans des réseaux de Relais de trames.

Le paquet se compose de plusieurs liaisons série, appelé des liens de paquet. Chaque lien de paquet dans un paquet correspond à une interface physique. Les liens de paquet sont invisibles à la couche liaison de données de Relais de trames, ainsi la fonctionnalité de Relais de trames ne peut pas être configurée sur ces interfaces. La fonctionnalité régulière de Relais de trames que vous voulez s'appliquer à ces liens doit être configurée sur l'interface de paquet. Les liens de paquet sont visibles pour scruter des périphériques.

DDR distribué

La caractéristique distribuée DDR permet la commutation distribuée sur des interfaces de numérotation. Sans cette caractéristique, tout le trafic d'accès distant doit être donné un coup de volée à l'hôte pour le changement. Avec lui, seulement des paquets de contrôle sont envoyés jusqu'au RP, tandis que la décision de commutation est faite sur les VIPs eux-mêmes après qu'une connexion ait été établie.

La configuration existante de numéroteur et la configuration de profil du numéroteur sont prises en charge seulement avec l'encapsulation PPP. MLP sur des interfaces de numérotation est également pris en charge. QoS n'est pas pris en charge avec la commutation distribuée sur des interfaces de numérotation.

Conditions préalables et restrictions distribuées de caractéristiques

Conditions préalables

Ce sont des préalables généraux à toutes ces caractéristiques distribuées :

  • La commutation distribuée de Cisco Express Forwarding (dCEF) doit être activée globalement.

  • la commutation de dCEF doit être activée sur l'interface série de membre, qui font partie de paquet MLP.

  • la commutation de dCEF doit être activée sur le lien physique des interfaces de dLFIoFR et de dLFIoATM.

  • La configuration d'entrelacement est exigée pour distribuer LFIoFR et LFIoATM.

  • Configure a exigé la bande passante sur l'interface de modèle virtuel pour des interfaces de dLFIoFR et de dLFIoATM.

  • Quand le PPP met au point sont activés sur le RP, vous pourrait observer le MLP : Expédié pour faire du tort le message d'interface sur le processeur de commutation routage (RSP). Puisque ce message est embrouillant et non désiré — particulièrement si le message est pour des paquets de Protocole CDP (Cisco Discovery Protocol) — vous ne devez configurer aucun cdp enable sur les liaisons membres du paquet.

  • Toutes les liaisons membres du paquet devraient avoir la keepalive activée.

Restrictions

Ce sont des restrictions générales pour toutes ces caractéristiques distribuées :

  • Des lignes de t1 et d'E1 ne peuvent pas être mélangées dans un paquet.

  • Le retard différentiel pris en charge par maximum est 30 ms.

  • Toutes les lignes dans un paquet doivent résider sur le même adaptateur de port (PA).

  • La compression matérielle n'est pas prise en charge.

  • Le VIP ou le CEF de FlexWAN est limité à l'IP seulement ; tous autres protocoles sont envoyés au RSP.

  • La fragmentation n'est pas prise en charge du côté de transmission pour le dMLP et le dMLFR.

  • Plusieurs des mécanismes de mise en file d'attente plus anciens ne sont pas pris en charge par le dLFI. Ces mécanismes incluent :

    • Foire-Mise en file d'attente sur une interface de modèle virtuel

    • Random-detect sur une interface de modèle virtuel

    • Mise en file d'attente faite sur commande

    • File d'attente à priorité déterminée

  • La Mise en file d'attente équitable, la détection aléatoire (dWRED), et la file d'attente à priorité déterminée peuvent être configurées dans une stratégie de trafic avec le QoS modulaire CLI.

  • Seulement un lien par paquet MLP est pris en charge, quand vous utilisez le dLFIoFR ou le dLFIoATM. Si plus d'un lien est utilisé dans un paquet MLP en utilisant le dLFIoFR ou le dLFIoATM, le dLFI est automatiquement désactivé. En utilisant le dLFI au-dessus des lignes louées, plus d'un lien peut être configuré avec le dLFI dans le paquet MLP.

  • Avec le dLFIoATM, seulement aal5snap et aal5mux sont pris en charge. L'encapsulation aal5nlpid et aal5ciscopp ne sont pas prises en charge.

  • Seulement la voix sur ip est prise en charge ; La Voix au-dessus du Relais de trames et la Voix au-dessus de l'atmosphère ne sont pas prises en charge par la caractéristique de dLFI.

  • La configuration de Protocole CRTP (Compressed Real-Time Protocol) ne devrait pas être configurée sur l'interface multiliaison, quand vous utilisez cette combinaison de caractéristique :

    • Interface multiliaison avec LFI activé

    • L'ensemble multiliaison a plus les liaisons membres d'une

    • La stratégie QoS avec la configuration prioritaire est activée sur l'interface multiliaison

Avec la configuration de dMLP et de dLFI, les paquets prioritaires ne portent pas l'en-tête et le numéro de séquence MLP, et MLP distribuera les paquets prioritaires à travers toutes les liaisons membres. En conséquence, les paquets qui sont compressés par CRTP peuvent arriver en panne au routeur récepteur. Ceci interdit CRTP de décompresser l'en-tête de paquet et force CRTP pour relâcher les paquets.

Recommandations

Les liaisons membres d'il est recommandé que dans un paquet ont la même bande passante. Si vous ajoutez la bande passante inégale lie au paquet, il mènera pour diviser en lots du paquet commandant à nouveau, qui fera diminuer le débit global de paquet.

VIP2-50 (avec 8 Mo SRAM) ou plus élevé est recommandé pour être utilisé avec ces configurations distribuées.

Nombre de paquets et liens et mémoires réquises

Référez-vous au protocole point-à-point distribué de Multilien pour le Routeurs de la gamme Cisco 7500.

Matériel et logiciel MLPPP ou MLFR sur des Linecards de 7600 SIP

MLP et MLFR peuvent être logiciel ou réalisés par matériel. Dans le matériel basé MLP ou MLFR, Freedm fournit la fonctionnalité de multilink et les en-têtes MLP sont ajoutées par la puce de Freedm. En logiciel basé MLP ou MLFR, la CPU de linecard de SIP fournit la fonctionnalité de multilink (qui est semblable au VIP et aux réalisations de FlexWAN).

Ce sont les limites et les conditions pour exécuter MLP ou MLFR basé par matériel.

  • Il peut y a seulement un maximum de 336 paquets par linecard et de 168 paquets par estimation de choix de sécurité (STATION THERMALE) (Freedm).

  • Il peut y a seulement un maximum de 12 DS1/E1 par paquet.

  • Tous les liens devraient appartenir à la même STATION THERMALE (Freedm).

  • Tous les liens dans le paquet devraient fonctionner à la même vitesse.

  • La taille de fragment TX peut être 128, 256, ou 512. Une taille de fragment configurée par CLI est tracée à la plus quasi- taille de fragment prise en charge.

    IF (0 < cli_fragment_size – 6 < 256)
    configured_fragment_size = 128
    Else IF (cli_fragment_size < 512)
    	configured_fragment_size = 256
    Else
    	configured_fragment_size = 512
  • La taille de fragment RX peut être 1 à 9.6 KO.

  • Le format propriétaire de Cisco ne peut pas être pris en charge (MLFR).

Dans le matériel LFI, s'il y a seulement un lien dans le paquet et si c'est DS1/E1 puis la fragmentation et interfoliage sera faite par Freedm.

La sortie du show ppp multilink affiche si l'implémentation de matériel s'exécute.

Multilink1, bundle name is M1
  Bundle up for 00:14:51
  Bundle is Distributed

  0 lost fragments, 0 reordered, 0 unassigned
  0 discarded, 0 lost received, 1/255 load
   Member links: 1 active, 0 inactive (max not set, min not set)
   Se6/1/0/1:0, since 00:14:51, no frags rcvd
  Distributed fragmentation on. Fragment size 512.  Multilink in Hardware.

Si le multilink est articulé autour d'un logiciel puis la sortie de show ppp multilink n'aura pas Multilien dans le matériel dans la sortie.

Vie d'un paquet

Chemin de données de Rx

  1. Paquet reçu par le gestionnaire.

  2. L'encapsulation est vérifiée : comme suit

    1. Encapsulation de base :

      1. Dans le dMLP, le type d'encapsulation pour l'interface d'entrée est ET_PPP.

      2. Dans le dMLFR, le type d'encapsulation pour l'interface d'entrée est ET_FRAME_RELAY.

      3. Dans le dLFIoLL, le type d'encapsulation pour l'interface d'entrée est ET_PPP.

      4. Dans le dLFIoFR, le type d'encapsulation pour l'interface d'entrée est ET_FRAME_RELAY.

      5. Dans le dLFIoATM, le type d'encapsulation pour l'interface d'entrée est ET_ATM.

      6. Dans le dDialer, le type d'encapsulation est ET_PPP.

    2. Traitement supplémentaire d'encapsulation :

      Pour ET_PPP, le NLPID est reniflé.

      • Pour le dMLP, le NLPID est MULTILIEN.

      • Pour le dLFIoLL, il y a deux choses à considérer :

        1. Paquets VoIP — Ceux-ci n'ont pas une en-tête MLP et ont un NLPID qui indique l'IP.

        2. Paquets de données — Le NLPID est MULTILIEN.

      • Pour le dDialer, les paquets n'auront pas une en-tête MLP et ont un NLPID qui indiquent l'IP.

        Remarque: Dans ce cas, vous pouvez configurer le dCRTP (Protocol en temps réel comprimé distribué). Si oui, l'en-tête est décompressée avant une transformation plus ultérieure.

  3. Pour ET_FRAME_RELAY, si le lien sur lequel le paquet est reçu est configuré pour le dMLFR puis le paquet est traité pour le dMLFR

  4. Pour le dLFIoFR et le dLFIoATM, le type d'encapsulation est ET_FRAME_RELAY et ET_ATM, respectivement ; mais dans cela il y a une en-tête de PPP. L'en-tête de PPP, comme avec le dLFIoLL, indiquera si le paquet est un paquet vocal ou un paquet de données. Si le dCRTP est configuré, l'en-tête est décompressée avant une transformation plus ultérieure. Des paquets vocaux sont commutés immédiatement.

    Un paquet de données fragmenté devra être rassemblé avant qu'il soit commuté.

    Avec ET_PPP, vous pourriez trouver des paquets par hasard de lien de PPP ; et avec ET_FRAME_RELAY, vous pourriez trouver des paquets de contrôle par hasard MLFR. Tous ces paquets de contrôle sont donnés un coup de volée au RP pour le traitement.

  5. Selon décoder mentionné ci-dessus, le paquet est vérifié le type de le commuter exige. Le type de lien déterminera si le paquet doit IP-être commuté ou MPLS-commuté. Les paquets sont alors donnés aux fonctions de commutation respectives.

  6. Avec l'empaquetement en même temps que les caractéristiques distribuées, le vecteur de commutation rapide IP turbo est dérobé. Ceci est fait parce que le paquet est reçu sur la liaison membre ; cependant, il doit traiter tels qu'il est reçu sur le paquet.

    Vous devez également vérifier les paquets de contrôle qui sont donnés un coup de volée à l'hôte. Principalement dans le dMLFR, il y a les paquets locaux de l'interface de gestion (LMI) qui ne sont pas des paquets de contrôle MLFR. Pour ces derniers, une différente partie de l'espace de nombre de dLCI est utilisée. Toutes les fois que le dLCI est décodé pour tomber dans cet espace, le paquet est donné un coup de volée jusqu'à l'hôte, parce qu'on l'identifie pour être un paquet LMI.

    Des paquets VoIP (alignés dans la file d'attente à faible latence) sont juste commutés sans ajout de l'en-tête MLP. Les caractéristiques distribuées peuvent recevoir et rassembler des paquets, quand des paquets de données fragmentés sont reçus. Le processus de réassemblage est expliqué dans une section postérieure.

    Si le paquet doit balise-être commuté, il est alors passé à la routine de balise-commutation, dans le dMLP. Autrement, s'il doit IP-être commuté, il est passé à la routine de Commutation IP.

    Remarque: Tous les paquets non-IP sont donnés un coup de volée pour héberger, dans le dMLFR.

  7. IP : La fonction de Commutation IP est commune à tous les paquets. Il fait principalement trois choses :

    • Faites le traitement nécessaire des paquets, au cas où toutes les caractéristiques seraient configurées. Également, quand le numéroteur distribué est utilisé, tournez au ralenti les mises à jour de temporisateur ici quand un « paquet intéressant » est reçu. Référez-vous au dialer idle-timeout (interface), au dialer fast-idle (interface), et à configurer un profil du numéroteur pour des détails du paramètre de veille de configuration de temporisateur.

    Sur les Routeurs 75xx, la contiguïté indiquera le tx_acc_ptr pour l'interface de sortie. Si l'interface de sortie est une interface d'accès virtuelle, le tx_acc_ptr est NUL. Dans ce cas, réparez l'encapsulation et obtenez le tx_acc_ptr du hwidb de bobard. Ces consultation et encapsulation réparent est en hausse nécessaire dans le dLFIoFR et le dLFIoATM. Dans le dLFIoLL, le lien est traité en tant qu'élément d'un ensemble multiliaison.

    Remarque: Le TTL pour le paquet est ajusté ici, et la fragmentation IP de vérifier est faite. Le mci_status est placé à RXTYPE_DODIP pour tous les paquets.

  8. La décision de commutation étant pris, le paquet est prêt à être expédié de l'interface. L'interface est vérifiée pour déterminer si elle prend en charge la commutation locale. S'il fait, il est envoyé directement par l'intermédiaire du fastsend. Autrement, une tentative est faite au commutateur de route-cache il.

    Notez que, au cas où QoS serait configuré pour l'interface, le vecteur de commutation locale est dérobé par QoS. HQF mettra le paquet et le processus en file d'attente supplémentaire le paquet, avant qu'il soit finalement envoyé hors de l'interface. C'est le cas avec le dLFI. Pour le dLFI, la fragmentation et l'interfoliage est placée. QoS manipule l'invocation de notre routine de fragmentation et intercale les paquets fragmentés avec les paquets vocaux qui seront alignés dans la file d'attente prioritaire (si LLQ est configuré). Ceci s'assure que les paquets VoIP ne souffrent pas du retard exigé pour expédier les paquets de données énormes par le lien.

Chemin de données de Tx

Le vip_dtq_consumer obtient le paquet et obtient le nombre d'interface, dont il obtient la BID. La routine de fastsend qui correspond à la BID s'appelle :

i) Fastsends

  1. Dans le dMFR, la structure de fr_info est récupérée de la table qui apparie l'if_index au fr_info. Des paquets de contrôle sont juste envoyés. L'en-tête de trame donnera le dLCI, qui vous aidera à déterminer si c'est un paquet LMI ou un paquet de données. Le champ de dlci dans l'en-tête de trame est remplacé avec le numéro de séquence de dmfr. Des numéros de séquence distincts sont utilisés pour le LMI et les paquets de données.

    Remarque: Des numéros de séquence distincts sont utilisés pour les dLCIs distincts.

  2. Dans le dMLP, des paquets de contrôle sont envoyés avec le positionnement prioritaire à la haute. Avec des paquets de données, si le dCRTP est configuré, l'en-tête est compressée. L'en-tête du VIP MLP qui inclut les informations de séquençage est ajoutée et envoyée hors des liaisons membres.

  3. Dans le dLFI, HQF intercepte les paquets à envoyer par l'interface. Si c'est un paquet vocal, le paquet vocal est placé dans la file d'attente prioritaire (si LLQ est configuré) et est envoyé hors de l'interface sans encapsulation MLP. Avec des paquets de données, il appelle le code de fragmentation de dLFI, qui renvoie les fragments au code de QoS, qui sont alors intercalés avec le trafic prioritaire de sorte que les exigences de retard du trafic vocal soit répondues. En outre, si le dCRTP est configuré, seulement l'en-tête pour le paquet vocal est compressée. Des en-têtes de paquet de données sont laissées pendant qu'elles sont.

  4. Dans le dDialer, le paquet est classifié afin de remettre à l'état initial le compteur de durée d'inactivité du lien de sortie avant que le paquet soit envoyé. Ceci est fait après que le lien de sortie soit choisi, au cas où plusieurs liens seraient liés au même numéroteur. Aucune en-tête n'est ajoutée aux paquets de numéroteur. Ainsi, en ordonnançant et rassemblez des paquets ne sont pas pris en charge sur des interfaces de numérotation.

Remarque: Dans le dMLP, le dDialer, le dMLFR, et le dLFI avec plusieurs liens, le lien physique sur lequel le trafic est expédié dépend de l'encombrement du lien. Si le lien est congestionné, déplacez-vous au prochain lien et ainsi de suite. (le dMLFR, le dMLP sans QoS, et les caractéristiques de dDialer choisissent également des liens basés sur le nombre d'octets étant mis sur le lien. Il choisit le prochain lien, si le lien en cours a déjà transmis son quota d'octets, sur une base circulaire. Ce quota est décidé par les frag_bytes pour le lien. Pour des interfaces de membre de numéroteur, des frag_bytes est placés à la valeur par défaut de la bande passante d'interface.)

Remarque: Dans des configurations HQF sur les interfaces du VIP de sortie, HQF dérobe le vecteur de dtq_consumer. Le paquet DMA'd au VIP de sortie passe d'abord par le contrôle HQF. Si QoS est configuré sur l'interface de sortie, HQF donne un coup de pied dedans pour traiter le paquet, avant que le paquet soit fastsent hors de l'interface.

Réassemblage

Les interfaces ordinaires de dDialer ne prennent en charge pas le réassemblage et le séquençage. Pour activer ceci sur des interfaces de numérotation, MLP au-dessus des interfaces de numérotation devra être configuré. Si ceci est fait, le chemin de Rx et de Tx sont identique aux chemins de dMLP. Quand des paquets sont reçus, le numéro de séquence est vérifié contre le numéro de séquence prévu.

  • Si les numéros de séquence s'assortissent :

    1. Si le paquet est un paquet unfragmented puis le réassemblage n'est pas exigé. Procédez d'autres à étapes de commutation.

    2. Si le paquet est un fragment, alors vérifiez le commencer et finissez les bits et construisez le paquet au fur et à mesure que les fragments sont reçus.

  • Si les numéros de séquence ne s'assortissent pas :

    1. Si le numéro de séquence est dans la fenêtre prévue des numéros de séquence alors la mettait dans « la liste non affectée triée de fragment. » Plus tard, quand un numéro de séquence prévu n'est pas reçu, cette liste est vérifiée, au cas où le paquet était enregistré ici.

    2. Si le numéro de séquence n'est pas dans la fenêtre, jetez-la et signalez « le fragment perdu reçu. » Si une minuterie se produit plus tard tout en attendant ce paquet, le récepteur resynced, et il commence de nouveau par le paquet suivant reçu.

En tout de ces cas, un flux de paquets correctement commandé est envoyé hors de cette interface. Si des fragments sont reçus, un paquet complet est formé et puis envoyé.

Configurant, vérifiant, et caractéristiques distribuées par débogage

Cette section couvre les commandes d'exposition et de débogage qui sont disponibles pour vérifier et mettre au point chacune des caractéristiques distribuées.

Configurant et vérifiant le dMFR

Configuration d'échantillon MFR

interface MFR1
 no ip address

interface MFR1.1 point-to-point
 ip address 181.0.0.2 255.255.0.0
 frame-relay interface-dlci 16

Remarque: L'interface MFR est comme une autre interface de relais de trame et par conséquent prend en charge la majeure partie de la configuration franc.

interface Serial5/0/0/1:0
 no ip address
 encapsulation frame-relay MFR1
 tx-queue-limit 26

interface Serial5/0/0/2:0
 no ip address
 encapsulation frame-relay MFR1
 tx-queue-limit 26

interface Serial5/0/0/3:0
 no ip address
 encapsulation frame-relay MFR1

Vérifiez l'état de paquet MFR sur le RP

show frame-relay multilink

Bundle: MFR1, State = up, class = A, fragmentation disabled
BID = MFR1
Bundle links:
 Serial5/0/0/3:0, HW state = up, link state = Add_sent, LID = Serial5/0/0/3:0
 Serial5/0/0/2:0, HW state = up, link state = Up, LID = Serial5/0/0/2:0
 Serial5/0/0/1:0, HW state = up, link state = Up, LID = Serial5/0/0/1:0

Ceci indique que deux interfaces sont ajoutées correctement, et une interface n'a pas encore négocié les messages de LÈVRE MLFR.

Pour obtenir plus d'informations sur le paquet et des liaisons membres MFR, émettez cette commande :

show frame-relay multilink mfr1 detailed

Bundle: MFR1, State = up, class = A, fragmentation disabled
BID = MFR1
No. of bundle links = 3, Peer's bundle-id = MFR1
Rx buffer size = 36144, Lost frag timeout = 1000
Bundle links:
 Serial5/0/0/3:0, HW state = up, link state = Add_sent, LID = Serial5/0/0/3:0
   Cause code = none, Ack timer = 4, Hello timer = 10,
   Max retry count = 2, Current count = 0,
   Peer LID = , RTT = 0 ms
   Statistics:
   Add_link sent = 35, Add_link rcv'd = 0,
   Add_link ack sent = 0, Add_link ack rcv'd = 0,
   Add_link rej sent = 0, Add_link rej rcv'd = 0,
   Remove_link sent = 0, Remove_link rcv'd = 0,
   Remove_link_ack sent = 0, Remove_link_ack rcv'd = 0,
   Hello sent = 0, Hello rcv'd = 0,
   Hello_ack sent = 0, Hello_ack rcv'd = 0,
   outgoing pak dropped = 0, incoming pak dropped = 0
  Serial5/0/0/2:0, HW state = up, link state = Up, LID = Serial5/0/0/2:0
   Cause code = none, Ack timer = 4, Hello timer = 10,
   Max retry count = 2, Current count = 0,
   Peer LID = Serial6/1/0/2:0, RTT = 32 ms
   Statistics:
   Add_link sent = 0, Add_link rcv'd = 0,
   Add_link ack sent = 0, Add_link ack rcv'd = 0,
   Add_link rej sent = 0, Add_link rej rcv'd = 0,
   Remove_link sent = 0, Remove_link rcv'd = 0,
   Remove_link_ack sent = 0, Remove_link_ack rcv'd = 0,
   Hello sent = 7851, Hello rcv'd = 7856,
   Hello_ack sent = 7856, Hello_ack rcv'd = 7851,
   outgoing pak dropped = 0, incoming pak dropped = 0
  Serial5/0/0/1:0, HW state = up, link state = Up, LID = Serial5/0/0/1:0
   Cause code = none, Ack timer = 4, Hello timer = 10,
   Max retry count = 2, Current count = 0,
   Peer LID = Serial6/1/0/1:0, RTT = 32 ms
   Statistics:
   Add_link sent = 0, Add_link rcv'd = 0,
   Add_link ack sent = 0, Add_link ack rcv'd = 0,
   Add_link rej sent = 0, Add_link rej rcv'd = 0,
   Remove_link sent = 0, Remove_link rcv'd = 0,
   Remove_link_ack sent = 0, Remove_link_ack rcv'd = 0,
   Hello sent = 7851, Hello rcv'd = 7856,
   Hello_ack sent = 7856, Hello_ack rcv'd = 7851,
   outgoing pak dropped = 0, incoming pak dropped = 0

Commandes de debug MFR

Ceux-ci met au point sont utiles pour dépanner des questions où un lien n'obtient pas ajouté au paquet.

debug frame-relay multilink control

Remarque: Quand une interface ou une interface série de la particularité MFR n'est pas spécifiée, ceci active mettent au point pour tous les liens MFR. Ceci peut être primordialement, si le routeur a un grand nombre de liens MFR.

Pour mettre au point les paquets MFR qui sont reçus au RP, aussi bien que mettre au point les activités de contrôle MFR, ceci mettent au point est utile :

debug frame-relay multilink

Remarque: Sous la circulation dense, ceci peut accabler la CPU.

Vérifiez l'état de paquet de dMLFR sur le LC

show frame-relay multilink

Remarque: Actuellement, ce n'est pas disponible sur le LC, mais on l'ajoutera bientôt. Jusque-là, show ppp multilink d'utilisation.

Bundle MFR1, 2 members
  bundle 0x62DBDD20, frag_mode 0
  tag vectors 0x604E8004 0x604C3628
  Bundle hwidb vector 0x6019271C
  idb MFR1, vc 0, RSP vc 0
  QoS disabled, fastsend (mlp_fastsend), visible_bandwidth 3072
  board_encap 0x60577554, hw_if_index 0, pak_to_host 0x0
  max_particles 400, mrru 1524, seq_window_size 0x200
  working_pak 0x0, working_pak_cache 0x0
  una_frag_list 0x0, una_frag_end 0x0, null_link 0
  rcved_end_bit 1, is_lost_frag 0, resync_count 0
  timeout 0, timer_start 0, timer_running 0, timer_count 0
  next_xmit_link Serial0/0:1, member 0x3, congestion 0x3
dmlp_orig_pak_to_host 0x603E7030
dmlp_orig_fastsend 0x6035DBC0
bundle_idb->lc_ip_turbo_fs 0x604A7750
  0 lost fragments, 0 reordered, 0 unassigned
  0 discarded, 0 lost received
  0x0 received sequence, 0x58E sent sequence
 DLCI: 16
  769719 lost fragments, 22338227 reordered, 
                                0 unassigned
  27664 discarded, 27664 lost received
  0xF58 received sequence, 0x8DE sent sequence
 timer count 767176
  Member Link: 2 active
   Serial0/0:0, id 0x1, fastsend 0x60191E34, lc_turbo 0x601913AC, PTH 0x603E7030, OOF 0
   Serial0/0:1, id 0x2, fastsend 0x60191E34, lc_turbo 0x601913AC, PTH 0x603E7030, OOF 0

Configurant et vérifiant dMLP/dLFIoLL

Configuration de PPP à liaisons multiples

interface Multilink1
 ip address 151.0.0.2 255.255.0.0
 no cdp enable
 ppp chap hostname M1
 ppp multilink
!

Configuration d'échantillon sous l'interface série :

interface Serial5/0/0/4:0
 no ip address
 encapsulation ppp
 tx-queue-limit 26
 no cdp enable
 ppp chap hostname M1
 ppp multilink group 1
!
interface Serial5/0/0/5:0
 no ip address
 encapsulation ppp
 tx-queue-limit 26
 no cdp enable
 ppp chap hostname M1
 ppp multilink group 1
!

Remarque: La commande du ppp chap hostname M1 ne signifie pas vraiment que l'authentification CHAP est activée. La chaîne M1 dans cette commande agit en tant que fin-point-discriminateur et est seulement exigée si là va être plus d'un ensemble multiliaison entre les mêmes deux Routeurs. En pareil cas, tous les liens qui appartiennent à un paquet devraient n'avoir le même discriminateur de point d'extrémité, et aucun deux liens qui appartiennent à un paquet différent devraient avoir le même discriminateur de point d'extrémité.

Paramètres de configuration facultatifs

[non] ppp multilink interleave

Ceci active l'interfoliage sur l'ensemble multiliaison. Ceci fonctionne en même temps que QoS modulaire CLI. Des paquets prioritaires seront transmis sans ajout de l'ordre et d'en-tête MLP, alors que d'autres paquets seront fragmentés et transmis par l'ordre et l'en-tête MLP.

Remarque: Quand intercaler est activé avec plus d'un lien, il est possible que le trafic prioritaire obtiendra commandé à nouveau. Quand intercaler est activé ou désactivé, une remise du paquet est exigée pour l'obtenir a lancé dans le linecard.

ppp multilink mrru local value

Ceci spécifie le maximum reçoivent l'unité sur le multilink ; des paquets jusqu'à cette taille seront reçus par l'interface multiliaison. La taille ici exclut l'en-tête MLP.

ppp multilink mrru remote value

Ceci spécifie le minimum MRRU que l'extrémité distante devrait prendre en charge. Si l'extrémité distante MRRU est inférieure cette valeur, alors la négociation de paquet échouera.

ppp multilink fragment delay seconds

Ceci spécifie le retard permis en quelques millisecondes (ms) provoquées par un fragment de données. En d'autres termes, la valeur du retard est utilisée pour calculer la taille de fragment maximum permise. L'implémentation distribuée diffère de l'implémentation de Cisco IOS de ces manières :

  1. La fragmentation n'est pas exécutée à moins qu'intercaler soit activé.

  2. Avec des liens de bande passante variable, la taille de fragment choisie est basée sur la moins interface de bande passante.

ppp multilink fragment disable

Cette commande n'ajoute aucune fonctionnalité dans l'implémentation distribuée. La fragmentation se produit seulement quand intercaler est activé ; et, quand intercaler est activé, la commande de ppp multilink fragment disable est ignorée.

Vérifiez l'état de paquet de dMLP sur le RP

show ppp multilink

Multilink1, bundle name is M1
Endpoint discriminator is M1
Bundle up for 00:09:09, 1/255 load
Receive buffer limit 24000 bytes, frag timeout 1000 ms
Bundle is Distributed
  0/0 fragments/bytes in reassembly list
  0 lost fragments, 0 reordered
  0/0 discarded fragments/bytes, 0 lost received
  0x9 received sequence, 0x0 sent sequence
dLFI statistics:
          DLFI Packets    Pkts In   Chars In   Pkts Out  Chars Out
            Fragmented          0          0          0          0
          UnFragmented          9       3150          0          0
           Reassembled          9       3150          0          0
      Reassembly Drops          0
   Fragmentation Drops          0
      Out of Seq Frags          0
Member links: 2 active, 0 inactive (max not set, min not set)
  Se5/0/0/4:0, since 00:09:09, 768 weight, 760 frag size
  Se5/0/0/5:0, since 00:09:09, 768 weight, 760 frag size
  1. Quand le paquet est dans le mode distribué, ceci est affiché dans la sortie du show ppp multilink :

    Le paquet est distribué

    Sinon, alors le paquet pour quelque raison n'est pas distribué.

  2. Quand le ppp multilink interleave est configuré et activé au linecard, la sortie de show ppp multilink inclut les statistiques de dLFI où :

    • Fragmenté — Indique le compte de fragments qui ont été transmis et reçus.

    • Unfragmented — Indique le compte de paquets qui ont été transmis ou reçus sans obtenir fragmenté.

    • Rassemblé — Indique le nombre de pleins paquets qui ont été rassemblés. Quand intercaler n'est pas activé, la sortie ressemble à ceci :

      Multilink1, bundle name is M1
        Endpoint discriminator is M1
        Bundle up for 00:00:00, 0/255 load
        Receive buffer limit 24000 bytes, frag timeout 1000 ms
        Bundle is Distributed
          0/0 fragments/bytes in reassembly list
          0 lost fragments, 0 reordered
          0/0 discarded fragments/bytes, 0 lost received
          0x0 received sequence, 0x2 sent sequence
        Member links: 2 active, 0 inactive (max not set, min not set)
          Se5/0/0/5:0, since 00:00:00, 768 weight, 760 frag size
          Se5/0/0/4:0, since 00:00:03, 768 weight, 760 frag size
      

La taille de fragment dans l'exemple précédent est de 760 octets.

Vérifiez l'état de paquet de dMLP sur le LC

show ppp multilink

dmlp_ipc_config_count 24
dmlp_bundle_count 2
dmlp_ipc_fault_count 1
dmlp_il_inst 0x60EE4340, item count 0
0, store 0, hwidb 0x615960E0, bundle 0x622AA060, 0x60579290, 0x6057A29C
1, store 0, hwidb 0x615985C0, bundle 0x622AA060, 0x60579290, 0x6057A29C
2, store 0, hwidb 0x0, bundle 0x0,
3, store 0, hwidb 0x0, bundle 0x0,
4, store 0, hwidb 0x0, bundle 0x0,
5, store 0, hwidb 0x0, bundle 0x0,
6, store 0, hwidb 0x0, bundle 0x0,
7, store 0, hwidb 0x0, bundle 0x0,
8, store 0, hwidb 0x0, bundle 0x0,
9, store 0, hwidb 0x0, bundle 0x0,

Bundle Multilink1, 2 members
  bundle 0x622AA060, frag_mode 0
  tag vectors 0x604E8004 0x604C3628
  Bundle hwidb vector 0x6057B198
  idb Multilink1, vc 4, RSP vc 4
  QoS disabled, fastsend (qos_fastsend), visible_bandwidth 3072
  board_encap 0x60577554, hw_if_index 0, pak_to_host 0x0
  max_particles 400, mrru 1524, seq_window_size 0x8000
  working_pak 0x0, working_pak_cache 0x0
  una_frag_list 0x0, una_frag_end 0x0, null_link 0
  rcved_end_bit 1, is_lost_frag 1, resync_count 0
  timeout 0, timer_start 0, timer_running 0, timer_count 1
  next_xmit_link Serial0/0:3, member 0x3, congestion 0x3
dmlp_orig_pak_to_host 0x603E7030
dmlp_orig_fastsend 0x6035DBC0
bundle_idb->lc_ip_turbo_fs 0x604A7750
  0 lost fragments, 0 reordered, 0 unassigned
  0 discarded, 0 lost received
  0xC3 received sequence, 0x0 sent sequence
  Member Link: 2 active
   Serial0/0:4, id 0x1, fastsend 0x60579290, lc_turbo 0x6057A29C, PTH 0x60579A18, OOF 0
   Serial0/0:3, id 0x2, fastsend 0x60579290, lc_turbo 0x6057A29C, PTH 0x60579A18, OOF 0

Avec le dMFR, les numéros de séquence sont mis à jour sur a par-dLCI base, avec le numéro de séquence dans le paquet utilisé pour le dLCI LMI.

Champ Description
dmlp_ipc_config_count Nombre de messages IPC reçus par le LC pour le multilink ou la configuration MLFR
dmlp_bundle_count Le nombre de MLP et de MLFR empaquette dans le LC
dmlp_ipc_fault_count Nombre de messages de configuration qui ont eu comme conséquence la panne dans le LC. Devrait être 0 ; s'il est différent de zéro puis il pourrait y a un problème.
vecteurs de balise Indique la BID aux tag_optimum_fs et la BID aux vecteurs ip2tag_optimum_fs utilisés dans la commutation de balise.
board_encap Indique le vecteur de board_encap qui est utilisé pour ajouter 2 octets d'encapsulation de panneau, s'il y a les liens canalisés dans une plate-forme 7500. Devrait être NUL, si le lien contient les interfaces non-canalisées.
max_particles Nombre maximal de particules qui peuvent être tenues dans le tampon de réassemblage
mrru La taille maximale du paquet qui sont reçus sans considérer l'encapsulation MLP. Pas applicable pour l'interface MLFR.
seq_window_size La taille de la fenêtre maximum pour des numéros de séquence
working_pak Indique le PAK en cours sous le réassemblage. NULL, si aucun.
working_pak_cache Pointeur à la charge statique PAK qui est utilisée pour le réassemblage. Ceci est alloué quand le premier paquet non-complet est reçu par le paquet.
una_frag_list Première entrée dans la file d'attente de réassemblage. Si l'entrée n'est pas NULLE et ne change pas, elle indique que le temporisateur n'exécute pas un problème logiciel.
una_frag_end Dernière entrée dans la file d'attente de réassemblage
rcved_end_bit Indique que le paquet a reçu un bit d'extrémité, ainsi il chasse pour un bit de commencer.
is_lost_frag Est vrai, si un fragment est déclaré perdu. Ceci obtient effacé quand un fragment avec l'ordre prévu est reçu.
resync_count Indique le nombre de fois qui le récepteur était hors de sync avec l'émetteur et a dû resync en commençant par le dernier fragment ordonnancé reçu.
délai d'attente Indique que le délai d'attente de réassemblage s'est produit et des paquets sont traités de la file d'attente de réassemblage.
timer_start Le nombre de le temporisateur de réassemblage de fois a été commencé
timer_running Indique si le temporisateur de réassemblage s'exécute.
timer_count Indique le nombre de fois que le temporisateur de réassemblage a expirées.
next_xmit_link Le lien sur lequel le paquet suivant sera transmis
Membre Champ de bit qui indique les membres présents.
Encombrement Champ non utilisé dans tous les branchements. Indique quelles liaisons membres ne sont pas congestionnées.
dmlp_orig_pak_to_host Le vecteur utilisé pour donner un coup de volée des paquets au RP.
dmlp_orig_fastsend Le fastsend d'origine de gestionnaire avant MLP ou MLFR a modifié le fastsend du gestionnaire.
fragments perdus Le nombre de fragments qui ont été perdus (le récepteur n'a pas reçu ces fragments). Ceci est périodiquement effacé quand une mise à jour est envoyée à l'hôte.
Commandé à nouveau Nombre de fragments qui ont été reçus hors de la commande prévue. Ceci est périodiquement effacé quand une mise à jour est envoyée à l'hôte.
Jeté Nombre de fragments jetés parce qu'un paquet complet ne pourrait pas être fait
perdu reçu Le nombre de fragments a reçu qui vraisemblablement ont été perdus. Ceci indique que le retard de liaison est plus grand que le délai d'attente de réassemblage de dMLP de 30 ms.

Configurant et vérifiant le dLFIoFR et le dLFIoATM

class-map voip
 match ip precedence 3

policy-map llq
 class voip
  priority

int virtual-template1
 service-policy output llq
 bandwidth 78 
 ppp multilink
 ppp multilink interleave
 ppp multilink fragment-delay 8


int serial5/0/0/6:0
encapsulation frame-relay
frame-relay interface-dlci 16 ppp virtual-template1

!--- Or


int ATM4/0/0
  no ip address
int ATM4/0/0.1 point-to-point
  pvc 5/100
  protocol ppp virtual-template 1

Vérifiez l'état de paquet dLFIoFR/ATM sur le RP

show ppp multilink

Virtual-Access3, bundle name is dLFI
  Endpoint discriminator is dLFI
  Bundle up for 00:01:11, 1/255 load
  Receive buffer limit 12192 bytes, frag timeout 1524 ms
  Bundle is Distributed
    0/0 fragments/bytes in reassembly list
    0 lost fragments, 0 reordered
    0/0 discarded fragments/bytes, 0 lost received
    0x0 received sequence, 0x0 sent sequence
  dLFI statistics:
            DLFI Packets    Pkts In   Chars In   Pkts Out  Chars Out
              Fragmented          0          0          0          0
            UnFragmented          0          0          0          0
             Reassembled          0          0          0          0
        Reassembly Drops          0
     Fragmentation Drops          0
        Out of Seq Frags          0
  Member links: 1 (max not set, min not set)
    Vi2, since 00:01:11, 240 weight, 230 frag size

Remarque: Le paquet deviendra distribué seulement quand le ppp multilink interleave est configuré sous le modèle virtuel ; sans cette commande, le paquet ne sera pas distribué.

Vérifiez l'état de paquet dLFIoFR/ATM sur le LC

Pour vérifier le dLFI fonctionne en effet correctement au LC, émettent cette commande :

show hqf interface

Interface Number 6 (type 22) Serial0/0:5

   blt (0x62D622E8, index 0, hwidb->fast_if_number=35) layer PHYSICAL
   scheduling policy: FIFO
   classification policy: NONE
   drop policy: TAIL
   blt flags: 0x0

   qsize 0 txcount 3 drops 0 qdrops 0 nobuffers 0
   aggregate limit 16 individual limit 4 availbuffers 16
   weight 1 perc 0.00 ready 1 shape_ready 1 wfq_clitype 0
   visible_bw 64 allocated_bw 64 qlimit_tuned 0 vc_encap 2
   quantum 1500 credit 0 backpressure_policy 0 nothingoncalQ 1

     next layer HQFLAYER_FRAMEDLCI_IFC (max entries 1024)

     blt (0x62D620E8, index 0, hwidb->fast_if_number=35) layer FRAMEDLCI_IFC
     scheduling policy: FIFO
     classification policy: NONE
     drop policy: TAIL
     blt flags: 0x0
  
     qsize 0 txcount 1 drops 0 qdrops 0 nobuffers 0
     aggregate limit 16 individual limit 4 availbuffers 16
     weight 1 perc 0.00 ready 1 shape_ready 1 wfq_clitype 0
     visible_bw 64 allocated_bw 64 qlimit_tuned 0 vc_encap 2
     quantum 1500 credit 0 backpressure_policy 0 nothingoncalQ 1

     blt (0x62D621E8, index 16, hwidb->fast_if_number=35) layer FRAMEDLCI_IFC
     scheduling policy: WFQ
     classification policy: PRIORITY_BASED
     drop policy: TAIL
     frag policy: root
     blt flags: 0x0
  
     qsize 0 txcount 2 drops 0 qdrops 0 nobuffers 0
     aggregate limit 16 individual limit 4 availbuffers 16
     weight 1 perc 0.00 ready 1 shape_ready 1 wfq_clitype 0
     visible_bw 64 allocated_bw 64 qlimit_tuned 0 vc_encap 2
     quantum 240 credit 0 backpressure_policy 0 nothingoncalQ 1

       next layer HQFLAYER_PRIORITY (max entries 256)

       blt (0x62D61FE8, index 0, hwidb->fast_if_number=35) layer PRIORITY
       scheduling policy: FIFO
       classification policy: NONE
       drop policy: TAIL
       frag policy: leaf
       blt flags: 0x0
    
       qsize 0 txcount 0 drops 0 qdrops 0 nobuffers 0
       aggregate limit 8 individual limit 2 availbuffers 8
       weight 0 perc 0.99 ready 1 shape_ready 1 wfq_clitype 0
       visible_bw 32 allocated_bw 32 qlimit_tuned 0 vc_encap 2
       quantum 240 credit 0 backpressure_policy 0 nothingoncalQ 1

       blt (0x62D61CE8, index 1, hwidb->fast_if_number=35) layer PRIORITY
       scheduling policy: FIFO
       classification policy: NONE
       drop policy: TAIL
       blt flags: 0x0
       Priority Conditioning enabled
       qsize 0 txcount 0 drops 0 qdrops 0 nobuffers 0
       aggregate limit 0 individual limit 0 availbuffers 0
       weight 1 perc 0.00 ready 1 shape_ready 1 wfq_clitype 0
       visible_bw 0 allocated_bw 0 qlimit_tuned 0 vc_encap 2
       quantum 240 credit 0 backpressure_policy 0 nothingoncalQ 1

       PRIORITY: bandwidth 32 (50%)
                 last 0 tokens 1500 token_limit 1500

       blt (0x62D61EE8, index 255, hwidb->fast_if_number=35) layer PRIORITY
       scheduling policy: WFQ
       classification policy: CLASS_BASED
       drop policy: TAIL
       frag policy: MLPPP (1)
         frag size: 240, vc encap: 0, handle: 0x612E1320
       blt flags: 0x0
    
       qsize 0 txcount 2 drops 0 qdrops 0 nobuffers 0
       aggregate limit 8 individual limit 2 availbuffers 8
       weight 1 perc 0.01 ready 1 shape_ready 1 wfq_clitype 0
       visible_bw 32 allocated_bw 32 qlimit_tuned 0 vc_encap 2
       quantum 1 credit 0 backpressure_policy 0 nothingoncalQ 1

           next layer HQFLAYER_CLASS_HIER0 (max entries 256)

           blt (0x62D61DE8, index 0, hwidb->fast_if_number=35) layer CLASS_HIER0
           scheduling policy: FIFO
           classification policy: NONE
           drop policy: TAIL
           frag policy: leaf
           blt flags: 0x0
        
           qsize 0 txcount 2 drops 0 qdrops 0 nobuffers 0
           aggregate limit 8 individual limit 2 availbuffers 8
           weight 1 perc 50.00 ready 1 shape_ready 1 wfq_clitype 0
           visible_bw 32 allocated_bw 32 qlimit_tuned 0 vc_encap 2
           quantum 240 credit 0 backpressure_policy 0 nothingoncalQ 1

Il devrait y a une couche prioritaire et une couche WFQ. La fragmentation sera faite au blt de couche de feuille WFQ.

Configurant et vérifiant le dDDR

Le DDR distribué est lancé quand vous activez l'ip cef distribué sur la configuration globale et l'ip route-cache distribués sur les interfaces de numérotation.


!--- Global configuration that enables distributed CEF switching.

ip cef distributed

--- Enable distributed switching on the dialer interface (on the D-channel interface).

int serial 3/1/0:23
	ip route-cache distributed

!--- Or, enable it on the dialer interface.

int Dialer1
	ip route-cache distributed

Il n'y a aucune autre configuration spéciale pour le DDR distribué. Plus loin la configuration suit la configuration normale DDR.

Vérifiez le routage sur demande distribué de cadran

BOX2002# show isdn status

Global ISDN Switchtype = primary-net5
ISDN Serial3/1/0:23 interface

--- Network side configuration.

        dsl 0, interface ISDN Switchtype = primary-net5
    Layer 1 Status:
        ACTIVE
    Layer 2 Status:
        TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED


The ISDN status should be MULTIPLE_FRAME_ESTABLISHED. 
This means that the physical layer is ready for ISDN connectivity.


    Layer 3 Status:
        0 Active Layer 3 Call(s)
    Active dsl 0 CCBs = 0
    The Free Channel Mask:  0x807FFFFF
    Number of L2 Discards = 0, L2 Session ID = 6

EDGE# show dialer

Serial6/0:0 - dialer type = ISDN
Idle timer (120 secs), Fast idle timer (20 secs)
Wait for carrier (30 secs), Re-enable (15 secs)
Dialer state is data link layer up
Time until disconnect 119 secs
Current call connected never
Connected to 54321

Serial6/0:1 - dialer type = ISDN
Idle timer (120 secs), Fast idle timer (20 secs)
Wait for carrier (30 secs), Re-enable (15 secs)
Dialer state is idle

Le type de numéroteur nous indique le type de numéroteur utilisé. Le RNIS implique la configuration existante de numéroteur et le PROFIL implique la configuration de profil du numéroteur. L'état du numéroteur indique l'état actuel du numéroteur. L'état d'une interface de numérotation non liée sera de veille. Le temporisateur de veille est remis à l'état initial toutes les fois que le trafic intéressant est vu. Si ce temporisateur expire jamais, l'interface déconnectera immédiatement. Le temporisateur de veille est un paramètre configurable. Pour de plus amples informations, référez-vous à configurer le peer-to-peer DDR avec des Profils de composeur.

show ppp multilink

!--- From LC for dialer profile.

dmlp_ipc_config_count 2
dmlp_bundle_count 1
dmlp_il_inst 0x60EE4340, item count 0
0, store 0, hwidb 0x0, bundle 0x0,
1, store 0, hwidb 0x0, bundle 0x0,
2, store 0, hwidb 0x0, bundle 0x0,
3, store 0, hwidb 0x0, bundle 0x0,
4, store 0, hwidb 0x0, bundle 0x0,
5, store 0, hwidb 0x0, bundle 0x0,
6, store 0, hwidb 0x0, bundle 0x0,
7, store 0, hwidb 0x0, bundle 0x0,
8, store 0, hwidb 0x0, bundle 0x0,
9, store 0, hwidb 0x0, bundle 0x0,

Bundle Dialer1, 1 member
  bundle 0x62677220, frag_mode 0
  tag vectors 0x604E8004 0x604C3628
  Bundle hwidb vector 0x0
  idb Dialer1, vc 22, RSP vc 22
  QoS disabled, fastsend (mlp_fastsend), visible_bandwidth 56
  board_encap 0x60577554, hw_if_index 0, pak_to_host 0x0
  max_particles 200, mrru 1524, seq_window_size 0x8000
  working_pak 0x0, working_pak_cache 0x0
  una_frag_list 0x0, una_frag_end 0x0, null_link 0
  rcved_end_bit 1, is_lost_frag 0, resync_count 0
  timeout 0, timer_start 0, timer_running 0, timer_count 0
  next_xmit_link Serial1/0:22, member 0x1, congestion 0x1
dmlp_orig_pak_to_host 0x603E7030
dmlp_orig_fastsend 0x60381298
bundle_idb->lc_ip_turbo_fs 0x604A7750
  0 lost fragments, 0 reordered, 0 unassigned
  0 discarded, 0 lost received
  0x0 received sequence, 0x0 sent sequence
  Member Link: 1 active
   Serial1/0:22, id 0x1, fastsend 0x60579290, lc_turbo 0x6057A29C, PTH 0x60579A18, OOF 0

Les variables affichées sont identiques que ceux pour le dMLP.

DMLP et dDDR de débogage

Debugs disponibles au RP

dDDR

debug dialer [events | packets | forwarding | map]

Émettez cette commande de mettre au point des fonctions de chemin de contrôle comme l'établissement d'appel et ainsi de suite. Pour de plus amples informations, référez-vous au debug dialer events.

debug ip cef dialer

Émettez cette commande de mettre au point des événements de numérotation liés à la CEF. Pour de plus amples informations, référez-vous à la Fonction Dialer CEF.

Debugs disponibles au LC

dMLP

Contrôlez l'élimination des imperfections de chemin : mettez au point l'événement de multilink

Élimination des imperfections de chemin de données : mettez au point les fragments de multilink

Élimination des imperfections d'erreur de chemin de données et de chemin de contrôle : mettez au point l'erreur de multilink

DMLP de débogage sur des Linecards de SIP

Vidant des paquets basés sur ci : Des paquets de données et les paquets de contrôle peuvent être vidés sur des linecards basés sur ci de contrôle et ci d'ordre.

ci CI-NUM [rx de vidage mémoire de subslot_num de hw-module de test|num_packets_to_dump de tx]

Le cis peut être obtenu de cette manière :


!--- Issue show controller serial interface
 for CTE1.

SIP-200-6# show controller serial 6/0/0:0

SPA 6/0 base address 0xB8000000 efc 1

Interface Serial6/0/0:0 is administratively down
Type 0xD Map 0x7FFFFFFF, Subrate 0xFF, mapped 0x1, maxmtu 0x5DC
Mtu 1500, max_buffer_size 1524, max_pak_size 1608 enc 84
ROM rev: 0, FW OS rev: 0x00000000 Firmware rev: 0x00000000
  idb=0x42663A30, pa=0x427BF6E0, vip_fci_type=0, port_per_spa=0
  SPA port type is set
  Host SPI4 in sync 
  SPA=0x427BF6E0 status=00010407, host=00000101, fpga=0x427EDF98
  cmd_head=113, cmd_tail=113, ev_head=184, ev_tail=184
  ev_dropped=0, cmd_dropped=0

!--- Start Link Record Information.

 tag 0, id 0, anyphy 0, anyphy_flags 3, state 0
 crc 0, idle 0, subrate 0, invert 0, priority 0
 encap hdlc
 corrupt_ci 65535, transparent_ci 1

!--- End Link Record Information.

Interface Serial6/0/0:0 is administratively down
Channel Stats:
  in_throttle=0, throttled=0, unthrottled=0, started=1
  rx_packets=0, rx_bytes=0, rx_frame_aborts=0,  rx_crc_errors=0
  rx_giants=0, rx_non_aligned_frames=0, rx_runts=0,  rx_overruns=0
  tx_packets=0, tx_bytes=0, tx_frame_aborts=0
  is_congested=0, mapped=1, is_isdn_d=0, tx_limited=1
  fast_if_number=15, fastsend=0x403339E4
  map=0x7FFFFFFF, turbo_vector_name=Copperhead to Draco switching
  lc_ip_turbo_fs=403A9EEC, lc_ip_mdfs=403A9EEC

Pour CT3, vous devez obtenir le vc numérique, qui peut être obtenu de la sortie de l'interface CT3_interface_name séquentiel d'exposition.

Maintenant les informations ci peuvent être obtenues de la console de STATION THERMALE. Réorientez d'abord la sortie des commandes de console de STATION THERMALE au RP avec la commande du spa_redirect RP ct3_freedm336.

La commande du linkrec vc d'exposition de freedm spa_ct3_test affiche les informations nécessaires ci.

dMFR

Contrôlez l'élimination des imperfections de chemin : mettez au point l'événement de dmfr

Élimination des imperfections de chemin de données : mettez au point les paquets de dmfr

Élimination des imperfections d'erreur de chemin de données et de chemin de contrôle : mettez au point l'erreur de dmfr

Vidant des paquets basés sur ci : Voir le dMLP.

dLFI

Contrôlez l'élimination des imperfections de chemin : mettez au point l'événement de dlfi

Élimination des imperfections de chemin de données : mettez au point les fragments de dlfi

Élimination des imperfections d'erreur de chemin de données et de chemin de contrôle : mettez au point l'erreur de dlfi

dDDR

Il n'y a aucune commande de débogage spéciale ; vous devriez utiliser le dMLP met au point.

En cas de dLFIoLL, le dMLP et le dLFI met au point pourraient devoir être utilisés. Ceux-ci met au point ne sont pas conditionnels et, par conséquent, déclencheront pour tous les paquets.

Forum aux questions

  1. Quel est dMLP ?

    le dMLP est abréviation le PPP à liaisons multiples distribué (comme stipulé dans RFC1990leavingcisco.com ). Cette caractéristique est prise en charge en les Plateformes distribuées, comme la gamme Cisco 7500 et la gamme 7600. le dMLP te permet pour combiner les lignes T1/E1 — dans un VIP sur un routeur de gamme Cisco 7500 ou un FlexWAN dans un routeur de gamme 7600 — dans un paquet qui a la bande passante combinée des plusieurs lignes T1/E1. Ceci permet à des clients pour augmenter la bande passante au delà de T1/E1 sans nécessité d'acheter une ligne T3/E3.

  2. Que « est distribué » dans le dMLP ?

    Le terme « distribué » implique que la commutation de paquets n'est faite par le VIP et pas le RSP. Pourquoi ? Les capacités de commutation RSP sont plutôt limitées, et il a beaucoup plus d'importants travaux de faire. Le VIP étant capable des paquets de commutation débarque cette activité du RSP. le Cisco IOS basé sur RSP gère toujours les liens. La création du lot et la désinstallation sont faites par le RSP. Supplémentaire, le procédé plat de contrôle de PPP est encore fait par RSP, y compris la manipulation de tous les paquets de contrôle de PPP (LCP, authentification, et le NCPs). Cependant, une fois qu'un paquet est établi, la manipulation des paquets MLP est retournée au VIP pour commuter par la CPU à bord. L'engine de dMLP (sur le VIP) traite toutes les procédures MLP, y compris la fragmentation, l'interfoliage, l'encapsulation, l'Équilibrage de charge parmi de plusieurs liens, et trier et le réassemblage des fragments d'arrivée. Les fonctions faites par le VIP dans un système 7500 sont faites par le Flexwan/améliorées-FlexWAN dans un système basé par 7600.

  3. Comment est-ce que je sais si le paquet est distribué ou pas ?

    Émettez la commande de show ppp multilink à la console du routeur :

    Router# show ppp multilink
    
    Multilink1, bundle name is udho2
      Bundle up for 00:22:46
      Bundle is Distributed
      174466 lost fragments, 95613607 reordered, 129 unassigned
      37803885 discarded, 37803879 lost received, 208/255 load
      0x4D987C received sequence, 0x9A7504 sent sequence
      Member links: 28 active, 0 inactive (max not set, min not set)
        Se11/1/0/27:0, since 00:22:46, no frags rcvd
        Se11/1/0/25:0, since 00:22:46, no frags rcvd
    
    
    !--- Output suppressed.
    
    
  4. Si j'améliore à RSP16 ou à SUP720, mes performances de dMLP seront-elles meilleures ?

    Non. La performance de commutation du dMLP (ou de toute caractéristique distribuée) dépend du VIP ou du FlexWAN en question. Par exemple, la représentation d'un VIP6-80 sera meilleure que la représentation avec VIP2-50.

  5. Quel PAs est-ce que je peux utiliser avec cette configuration ?

    • PA-MC-T3

    • PA-MC-2T3+

    • PA-MC-E3

    • PA-MC-2E1

    • PA-MC-2T1

    • PA-MC-4T1

    • PA-MC-8T1

    • PA-MC-8E1

    • PA-MC-STM-1

    • PA-MC-8TE1+

    • PA-4T+

    • PA-8T

    • CT3IP-50 (7500 seulement)

  6. Combien de liens peuvent être configurés dans un seul paquet ?

    Il y a beaucoup de facettes à cette réponse. L'étranglement primaire est la puissance CPU du linecard (VIP/FlexWAN/Enhanced-FlexWAN2). La limite dure est 56 liens par paquet, mais beaucoup de fois que vous ne pouvez pas configurer ces beaucoup (et avoir que beaucoup de commutation du trafic), due à la puissance CPU ou aux mémoires tampons limitées. Ces nombres sont basés sur cette instruction (basée sur la CPU et la mémoire sur le VIP/FlexWAN/Enahnced-FlexWAN2) :

    VIP2-50 (avec 4 Mo SRAM) T1 = 12 maximum

    VIP2-50 (avec 8MB SRAM) T1 = 16 maximum

    VIP4-80 T1 = 40 maximum

    VIP6-80 T1 = 40 maximum

    FlexWAN maximum T1 = sera mis à jour sous peu

    E1 = 21 maximum améliorés-FlexWAN E1 par baie (agrégat 42 E1 par linecard)

  7. Y a-t-il un changement de représentation si je configure 3 paquets avec 3 T1 chacuns ou 1 paquet avec 9 T1 ?

    Il n'y a aucun changement de représentation, comme prouvé dans des essais en laboratoire. Cependant, avec l'un grand nombre T1 dans un seul paquet (dites 24 ou 28 T1 dans un seul paquet), il y a des questions avec l'exécution hors des mémoires tampons. Son fortement recommandé que vous pour ne pas avoir plus de 8 liaisons membres (T1/E1) dans un seul paquet.

  8. Comment la bande passante d'un paquet est-elle déterminée ?

    La bande passante d'un paquet ne doit pas être configurée. Son la bande passante agrégée de toutes les liaisons membres. Si vous avez 4 T1 dans le paquet, alors la bande passante du paquet est 6.144Mbps.

  9. Quel est meilleur ? Équilibrage de charge CEF ou dMLP ?

    Il n'y a aucune réponse simple à ceci. Vos besoins décident lesquels est meilleur.

    AVANTAGES de MLP :

    • L'équilibrage de charge CEF s'applique seulement au trafic IP. MLP équilibre tout le trafic envoyé au-dessus d'un paquet.

    • MLP met à jour la commande des paquets. IP lui-même est tolérant du réarrangement, ainsi ceci peut ne pas importer à vous ; en fait, le surcoût entraîné en mettant à jour le séquençage peut être une raison d'éviter MLP. L'IP est destiné pour les réseaux qui peuvent livrer des datagrammes en panne, et quelque chose utilisant l'IP est censé pouvoir traiter le réarrangement. Cependant, en dépit de ce fait, la réalité est que le réarrangement peut encore poser un problème réel.

    • MLP fournit une connexion logique simple au système de pair.

    • QoS est pris en charge sur des ensembles multiliaisons.

    • MLP fournit des capacités dynamiques de bande passante, comme l'utilisateur peut ajouter ou retirer des liaisons membres basées sur les besoins en cours.

    • MLP peut empaqueter de plus grands nombres de liens, tandis que l'équilibrage de charge CEF est limité à 6 chemins parallèles IP.

    • l'équilibrage de charge CEF de Par-écoulement limite la bande passante maximum de n'importe quel écoulement donné à un t1. Par exemple, les clients à l'aide des Passerelles voix peuvent faire utiliser beaucoup d'appels avec la mêmes source et destination et, par conséquent, seulement un chemin.

    INCONVÉNIENTS de MLP :

    • MLP ajoute le temps système supplémentaire à chaque paquet ou trame

    • MLP est CPU intensive ; le dMLP est CPU de linecard intensive.

  10. Comment est-ce que je peux configurer de plusieurs paquets entre deux Routeurs ?

    Multilien détermine quel paquet un lien joindra basé sur le nom et le discriminateur de point d'extrémité du pair. Pour créer de plusieurs paquets distincts entre deux systèmes, la méthode standard est de forcer certains des liens pour s'identifier différemment. La méthode recommandée est l'utilisation de la commande de nom de ppp chap hostname.

  11. Est-ce que je peux avoir des liaisons membres de PAs différent ?

    Non. Si vous voulez exécuter le dMLP, alors il n'est pas pris en charge. Cependant, si des liaisons membres sont ajoutées du PAs différent, puis le contrôle n'est plus donné à RSP et à son pas dMLP. MLP fonctionne toujours, mais les avantages du dMLP sont allés.

  12. Est-ce que je peux mélanger des liaisons membres des deux baies ?

    Non. Si vous voulez exécuter le dMLP, alors il n'est pas pris en charge. Cependant, si des liaisons membres sont ajoutées du PAs différent, puis le contrôle est donné à RSP et ce n'est plus dMLP. MLP fonctionne toujours, mais les avantages du dMLP sont allés.

  13. Est-ce que je peux avoir des liaisons membres à travers différents VIPs ou FlexWANs ?

    Non. Si vous voulez exécuter le dMLP, alors il n'est pas pris en charge. Cependant, si des liaisons membres sont ajoutées du PAs différent, puis le contrôle n'est plus donné à RSP et à son pas dMLP. MLP fonctionne toujours, mais les avantages du dMLP sont allés.

  14. Est-ce que je peux avoir des liaisons membres à travers les ports différents d'une PA simple ?

    (Par exemple, une liaison membre de chaque port CT3 d'un PA-MC-2T3+.)

    Oui. Tant que il est de la même PA, il n'y a aucune question.

  15. Est-ce que je peux empaqueter des ports de T3 ou d'E3 ?

    Non. On laisse seulement DS0, n*DS0, vitesses de t1, et d'E1 avec le dMLP pour 7500/VIP, 7600/FlexWAN, et 7600/FlexWAN2.

    Remarque: Le MLPPP distribué est pris en charge seulement pour des liaisons membres configurées à T1/E1 ou à vitesses du débit intermédiaire T1/E1. Les interfaces STM-1/T3/T1 canalisées prennent en charge également le dMLPPP à T1/E1 ou à vitesses du débit intermédiaire T1/E1. Le MLPPP distribué n'est pas pris en charge pour des liaisons membres configurées au clear-channel T3/E3 ou aux vitesses plus élevées d'interface.

  16. Quels sont les fragments « commandés à nouveau » ?

    Si le fragment ou le paquet reçu n'apparie pas le numéro de séquence prévu, alors le compteur commandé à nouveau est incrémenté. Pour des longueurs de paquet variables, ceci est forcé pour se produire. Pour les paquets à taille fixe, ceci peut également se produire parce que le gestionnaire PA traite les paquets qui ont reçu sur un lien et ne s'attaquent pas à la base circulaire (comme est fait dans le dMLP tout en transmettant les paquets). Reordered ne signifie pas la perte de paquets.

  17. Quels sont les fragments « perdus » ?

    Toutes les fois que le fragment ou le paquet est en panne reçu et vous constatez que des fragments ou les paquets en panne sont reçus sur tous les liens, les fragments perdus contre- est incrémentés. Un autre cas est quand les fragments en panne sont enregistrés dans la liste et elle atteint une limite (décidée basé sur SRAM sur le VIP et celui qui soit assigné pour le paquet), les fragments perdus contre- est incrémenté et le prochain numéro de séquence dans la liste est pris pour le traitement.

  18. Comment le dMLP détecte-il les fragments perdus ?

    1. Numéros de séquence : Si vous attendez un fragment avec le numéro de séquence N pour arriver, et tous les liens reçoivent un fragment avec un supérieur à N de numéro de séquence, vous savez que le fragment N doit être perdu, parce qu'il n'y a aucune manière elle pourrait légalement arriver derrière des fragments numérotés plus élevés sur le même lien.

    2. Délai d'attente : Si vous reposez trop long attendant un fragment, vous par la suite le déclarerez comme perdu et vous déplacerez en fonction.

    3. Dépassement de tampon de réassemblage : Si vous attendez le fragment N pour arriver, et en attendant autre fragmente (avec le supérieur à de numéros de séquence N) arrivent sur certains des liens, alors vous devez garer ces fragments dans un tampon de réassemblage jusqu'au fragment N révèle. Il y a une limite à combien vous pouvez mettre en mémoire tampon. Si les débordements de tampon, vous déclarent de nouveau le fragment N comme perdu, et reprennent le traitement avec celui qui soit dans la mémoire tampon.

  19. Ce qui sont « perdus reçus ? »

    Il y a deux possibles raison pour les fragments ou les paquets reçus perdus :

    1. Si le fragment ou le paquet reçu est hors de la fenêtre prévue de plage d'ordre, le paquet est lâché en la marquant pendant que perdu reçu.

    2. Si le fragment ou le paquet reçu est dans la fenêtre prévue de plage d'ordre, mais vous ne pouvez pas allouer une en-tête de paquet au re-parent ce paquet, alors le paquet est lâché et marqué en tant que perdu reçu.

  20. Le cryptage est-il pris en charge avec le dMLP ?

    Non.

  21. Prenons en charge-nous la compression d'en-tête PFC ?

    Non, pas dans le chemin distribué. Le routeur d'extrémité n'est pas recommandé pour configurer la compression d'en-tête PFC parce que nous retombons au mode non-distribué si nous recevons les trames ou les paquets comprimés d'en-tête. Si vous voulez continuer d'exécuter le dMLP, la compression d'en-tête PFC doit être désactivée aux deux extrémités.

  22. La compression logicielle est-elle prise en charge avec le dMLP ?

    Non, parce que la compression logicielle ne fonctionnera pas dans le chemin distribué.

  23. La fragmentation est-elle prise en charge du côté de transmission ?

    Pas avec le dMLP de vanille. Il n'y a aucune question avec recevoir des fragments avec le dMLP de vanille, mais du côté de transmission, la fragmentation ne se produit pas. La fragmentation de côté de transmission est prise en charge quand le ppp multilink interleave est configuré sur l'interface de dMLP.

  24. Pouvons-nous cingler les liaisons membres d'un paquet MLP ?

    Non, vous ne pouvez pas configurer une adresse IP sur les liaisons membres.

  25. Y a-t-il une dépendance sur la taille de fragment de MTU et MLP de lien ?

    Non. La taille de MTU n'a rien à faire avec la taille de fragment MLP, autre que la restriction évidente qu'un fragment MLP, comme aucune autre trame, ne peut pas dépasser les tailles du MTU des liaisons série.

  26. Est-il possible de configurer deux paquets MLP entre une seule paire de Routeurs ?

    Oui, c'est possible. Cependant, ceci a pu mener à l'Équilibrage de charge altéré. Il peut être utile sur des bancs d'essai, pour simuler plus de deux Routeurs à l'aide de juste deux Routeurs, mais il n'a aucune valeur du monde réel évidente.

    Tous les liens qui vont à un pair commun doivent être mis dans le même paquet. Par définition, un paquet est l'ensemble de liens qui vont à un pair particulier.

    Un « pair » est identifié par les valeurs de nom d'utilisateur et de discriminateur de point d'extrémité qu'il offre pendant LCP et phases d'authentification. Si vous essayez de créer de plusieurs paquets entre deux Routeurs, alors il signifie que vous essayez d'inciter chaque routeur à déguiser en tant qu'étant plus qu'un pair simple à son homologue. Ils doivent s'identifier convenablement.

  27. Les liaisons membres peuvent-elles avoir différents algorithmes de Mise en file d'attente ?

    Tous les mécanismes de mise en file d'attente liés à un paquet doivent être appliqués au niveau de paquet et pas au niveau de liaison membre. Cependant, configurer un algorithme de file d'attente ne devrait pas affecter comment les paquets sont commutés hors du paquet.

  28. Pourquoi la tx-quque-limite est-elle placée à 26 en tant que par défaut pour des liaisons membres pour un ensemble multiliaison quand le dMLP est activé sur un Cisco 7500 ?

    Pour n'importe quelle interface série de la bande passante T1/E1, le tx-queue-limit est environ 4 ou 5. Quand vous empaquetez T1s/E1s ensemble dans le multilink, la bande passante augmenterait pour le paquet. Puisque le changement aurait lieu basé sur la bande passante d'interface MLP, vous devez augmenter le tx-queue-limit des liaisons membres. Seulement un des liaisons membres, appelé la liaison principale, est utilisé pour commuter, donc, son besoin de tx-queue-limit d'être augmenté.

    En outre, cette valeur est empirique choisie après avoir testé et puis accordé à cette valeur. Généralement les déploiements n'ont pas plus de 4 à 6 liens T1/E1 dans un paquet. Une valeur de 26 peut couvrir 6 à 8 liens T1/E1 parfaitement, et par conséquent cette valeur a été choisie.

  29. Quel est retard différentiel et sa valeur dans l'implémentation de dMLP ?

    le dMLP prend en charge un retard différentiel de 30 ms. Cela signifierait si un fragment est à la fois T reçu et il est en panne (attendant un numéro de séquence 100, mais nous ont reçu 101). Si le numéro de séquence 100 n'est pas reçu jusqu'au ms T+30, 100 seraient déclarés perdus et si vous pouvez commencer le traitement de 101, vous feriez cela. Au cas où vous ne pourriez pas commencer par 101 (si c'est un fragment moyen), vous rechercheriez le fragment qui a le fragment de commencer (par exemple, 104) et le début de là.

  30. Que se produit quand des paquets sont fragmentés au niveau IP avec le multilink sur 7500 ?

    Si des paquets sont fragmentés au niveau IP, alors ils sont transportés sans réassemblage aux sauts intermédiaires mais sont rassemblés au routeur de destination.

  31. Que se produit quand des paquets sont fragmentés au niveau MLP sur 7500 ?

    Si les paquets sont fragmentés au niveau MLP et si les paquets rassemblés sont plus grands que MRRU, alors des paquets sont lâchés sur le multilink. la fragmentation de Transmettre-side est prise en charge sur le dMLP seulement avec le dLFI. Des paquets sont fragmentés au niveau MLP seulement si le packet_size est plus grand que le frag_size et moins que le MRRU. Si des paquets plus que le MRRU sont envoyés et s'il n'est pas fragmenté au niveau IP, alors l'autre extrémité relâche toute la longueur de paquet qu'ils ne sont pas fragmentés au niveau MLP parce que les paquets sont plus que MRRU.

  32. Comment MRRU est-il calculé ?

    MRRU est calculé selon ces préférences :

    1. Pour les nouvelles liaisons membres étant livré dedans, MRRU est de nouveau négocié au niveau LCP selon le MRRU configuré sur les liaisons membres.

    2. La valeur configurée sur l'interface de lien avec la commande d'interface de ppp multilink mrru.

    3. Sinon configuré, la valeur héritée de la configuration de la commande de ppp multilink mrru sur l'interface de parent.

    4. Si les deux valeurs sont présentes, la valeur d'interface de lien a la priorité.

    5. Le par défaut MRRU de 1524.

Améliorations de debug

Ces améliorations seront prises à l'avenir. La planification n'est pas de se terminer encore.

  • Commande de multilink de debug frame-relay d'enable sur le LC.

  • Améliorez le courant mettent au point CLIs par interface et nombre spécifié de paquets.

  • Pour le dDDR, la fonctionnalité QoS n'est pas encore prise en charge. Ceci peut être pris seulement avec le dossier commercial approprié.


Informations connexes


Document ID: 65403