Routeur 75xx/76xx - Configuration et vérification des fonctions distribuées

Introduction

Ce document vous aide à comprendre, configurer et vérifier ces fonctionnalités :

• Protocole point à point multiliaison distribué (dMLP)

• Fragmentation et entrelacement de liaison distribuée (LFI)

• Ligne louée LFI distribuée (dLFIoLL)

• LFI distribué sur Frame Relay (dLFIoFR)

• Distributed LFI over ATM (dLFIoATM)

• Différences entre la distribution MLP (dMLP) et dLFIoLL

• Multilink Frame Relay distribué (dMLFR)

• Routage à établissement de connexion à la demande distribué (DDR)

Conditions préalables

Conditions requises

Les lecteurs de ce document doivent connaître les fonctionnalités distribuées pour Cisco 7500/7600/6500.

Components Used

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

• Toutes les plates-formes Cisco 7500 et 7600

  Remarque : Les informations de ce document s'appliquent également aux plates-formes 6500.

• Versions pertinentes du logiciel Cisco IOS®, que ce tableau répertorie :

Prise en charge des fonctionnalités distribuées pour chaque filiale et plate-forme

Fonctionnalité	Cartes de ports (PA)1 prises en charge	Plateformes 7500		Plateformes 7600
		Versions principales du logiciel Cisco IOS	Versions de Cisco IOS (provisoires)	Versions principales du logiciel Cisco IOS	Versions du logiciel Cisco IOS (provisoires)
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 versions ultérieures 12.0(9)S et ultérieures	12.2SX 12.1E2	—
dLFIoLL	Chan-PA PA-4T+ PA-8T	12,2T 12,3 12,3T 12,0S	12.2(8)T et versions ultérieures 12.0(24)S et ultérieures	12,2 SX	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 versions ultérieures	12,2 SX	12.2(17)SXB et ultérieures
dLFIoATM	PA-A3 PA-A6	12,2T 12,3 12,3T	12.2(4)T3 et versions ultérieures	12,2 SX	12.2(17)SXB et ultérieures
dMLFR	Chan-PA PA-4T+ PA-8T	12,0 S 12,3 T	12.0(24)S et versions ultérieures 12.3(4)T et ultérieures	12,2 SX	12.2(17)SXB et ultérieures
QoS sur dMLP	Chan-PA PA-4T+ PA-8T	12,0 S 12,2T 12,3 12,3T	12.0(24)S et versions ultérieures 12.2(8)T et ultérieures	12,2 SX	12.2(17)SXB et ultérieures
MPLS sur dMLP MPLS sur dLFIoLL	Chan-PA PA-4T+ PA-8T	12,2 T 12,3	12.2(15)T11 et versions ultérieures 12.3(5a) et ultérieures	12,2 SX	12.2(17)SXB et ultérieures
DDR distribué	PA-MC-xT1 PA-MC-xE1 PA-MC-xTE1 PA-MCX-xTE1	12,3 T	12.3(7)T et ultérieures	—	—

Remarque : Soyez au courant de ces informations :

1. Ces PA prennent en charge les fonctionnalités distribuées :

   • 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 12.1E du logiciel Cisco IOS prend en charge ces fonctionnalités sur les plates-formes 7500 et 7600.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Fonctionnalités distribuées

Ces fonctionnalités sont expliquées dans ce document :

• MLP distribué

• Intervalle LFI distribué

• Intervalle LFI distribué sur ligne louée

• Interface LFI distribuée sur Frame Relay

• Distributed LFI over ATM

• Différences entre dMLP et dLFIoLL

• MLFR distribué

• Numéroteur distribué

• Plates-formes et cartes de ligne prenant en charge les fonctionnalités distribuées

MLPPP distribué

La fonctionnalité de protocole point à point multiliaison distribué (dMLP) vous permet de combiner des lignes T1/E1 complètes ou fractionnées dans une carte de ligne (VIP, FlexWAN) sur un routeur de la gamme Cisco 7500 ou 7600 en un ensemble qui possède la bande passante combinée de plusieurs liaisons. Pour ce faire, vous utilisez un bundle MLP distribué. Un utilisateur peut choisir le nombre de bundles dans un routeur et le nombre de liens par bundle. Cela permet à l'utilisateur d'augmenter la bande passante des liaisons réseau au-delà de celle d'une seule ligne T1/E1 sans avoir à acheter une ligne T3. Dans le non-dMLP, tous les paquets sont commutés par le processeur de routage (RP); par conséquent, cette mise en oeuvre affecte les performances du RP, avec une utilisation élevée du CPU pour seulement quelques lignes T1/E1 exécutant MLP. Avec dMLP, le nombre total de bundles pouvant être gérés sur le routeur est augmenté, car le chemin de données est géré et limité par le processeur et la mémoire de la carte de ligne. dMLP vous permet de regrouper les T1/E1 fractionnés à partir de DS0 (64 Kbits/s).

Intervalle LFI distribué

La fonction dLFI prend en charge le transport du trafic en temps réel (voix, par exemple) et du trafic en temps non réel (données, par exemple) sur les circuits virtuels Frame Relay et ATM à faible débit et sur les lignes louées, sans entraîner de retard excessif sur le trafic en temps réel.

Cette fonctionnalité est mise en oeuvre à l’aide du protocole multiliaison PPP (MLP) sur Frame Relay, ATM et lignes louées. La fonctionnalité divise un paquet de données volumineux en une séquence de fragments plus petits, afin de permettre aux paquets en temps réel sensibles au délai et aux paquets en temps non réel de partager la même liaison. Les fragments sont ensuite entrelacés avec les paquets en temps réel. Du côté récepteur de la liaison, les fragments sont réassemblés et le paquet est reconstitué.

La fonction dLFI est souvent utile dans les réseaux qui envoient du trafic en temps réel via la mise en file d’attente à faible latence distribuée (par exemple, la voix), mais qui ont des problèmes de bande passante. Cela retarde le trafic en temps réel en raison du transport de paquets de données volumineux et moins sensibles au temps. Vous pouvez utiliser la fonction dLFI dans ces réseaux pour démonter les paquets de données volumineux en plusieurs segments. Les paquets de trafic en temps réel peuvent alors être envoyés entre ces segments des paquets de données. Dans ce scénario, le trafic en temps réel n'est pas soumis à un long délai pendant qu'il attend que les paquets de données de faible priorité traversent le réseau. Les paquets de données sont réassemblés du côté récepteur de la liaison, de sorte que les données sont livrées intactes.

La taille de fragment de la liaison est calculée en fonction du délai de fragment sur le bundle multiliaison, configuré avec la commande ppp multilink fragment-delay n, où :

fragment size = bandwidth × fragment-delay / 8

Cette taille de fragment représente uniquement la charge utile IP. Il n'inclut pas les octets d'encapsulation (taille de fragment = poids - octets d'encapsulation). Les termes “ poids ” et “ taille de fragment ” sont visibles dans la sortie de la commande show ppp multilink sur le RP. Si le délai de fragment n'est pas configuré, la taille de fragment par défaut est calculée pour un délai de fragment maximal de 30.

Remarque : avec des liaisons de bande passante variable, la taille de fragment choisie est basée sur la liaison avec la bande passante la plus faible.

Intervalle LFI distribué sur ligne louée

La fonction dLFIoLL étend la fonctionnalité de fragmentation et d'entrelacement de liaison distribuée aux lignes louées. Le LFI distribué est configuré avec la commande ppp multilink interleave sur l'interface de groupe multiliaison. Il est conseillé d'utiliser une interface LFI distribuée sur des interfaces multiliaison avec une bande passante inférieure à 768 Kbits/s. En effet, le délai de sérialisation des paquets de 1 500 octets pour une bande passante supérieure à 768 Kbits/s se situe dans des limites de délai acceptables et n'a pas besoin d'être fragmenté.

Interface LFI distribuée sur Frame Relay

La fonction dLFIoFR est une extension de la fonction Multilink PPP over Frame Relay (MLPoFR). MLP est utilisé pour la fragmentation. Cette fonctionnalité est similaire à FRF.12, qui prend en charge la fragmentation et peut interlaisser des paquets de priorité élevée via la mise en file d'attente à faible latence.

La commande ppp multilink interleave sur le modèle virtuel est requise pour activer l'entrelacement sur l'interface d'accès virtuel associée. Outre l'activation de la commutation CEF distribuée sur l'interface série, cette commande est une condition préalable au fonctionnement de LFI distribuée.

Remarque : à moins d’utiliser l’interconnexion Frame Relay/ATM, il est recommandé d’utiliser FRF.12 plutôt que dLFIoFR, car l’utilisation de la bande passante est meilleure avec FRF.12

Distributed LFI over ATM

La fonction dLFIoATM est une extension de la fonction MLPoATM (Multilink PPP over ATM). MLP est utilisé pour la fragmentation.

La commande ppp multilink interleave sur le modèle virtuel est requise pour activer l'entrelacement sur l'interface d'accès virtuel associée. Outre l'activation de la commutation CEF distribuée sur l'interface série, cette commande est une condition préalable au fonctionnement de LFI distribuée.

Avec dLFIoATM, il est très important de sélectionner une taille de fragment qui fait que les paquets s'insèrent dans les cellules ATM de telle manière qu'ils ne provoquent pas de remplissage inutile dans les cellules ATM. Par exemple, si la taille du fragment sélectionné est de 124 octets, cela signifie qu'une charge utile IP de 124 octets passerait finalement à 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 (Taille de l'en-tête PID du premier fragment) + 8 = 144 octets. Cela signifie que ce paquet utilisera trois cellules ATM pour transférer la charge utile et, par conséquent, utilisera la cellule la plus efficacement compressée.

Différences entre dMLP et dLFIoLL

dMLP ne prend pas en charge la fragmentation du côté transmission, contrairement à dLFIoLL.

Remarque : L'entrelacement et la fragmentation utilisés avec plusieurs liaisons dans l'ensemble multiliaison pour le trafic vocal ne garantissent pas que le trafic vocal reçu via plusieurs liaisons dans l'ensemble sera reçu dans l'ordre. L’ordre correct de la voix est géré au niveau des couches supérieures.

MLFR distribué

La fonctionnalité MLFR distribuée introduit des fonctionnalités basées sur le Contrat de mise en oeuvre Frame Relay Forum Multilink Frame Relay UNI/NNI (FRF.16) aux routeurs des gammes Cisco 7500 et 7600 compatibles avec les cartes de ligne. La fonctionnalité MLFR distribuée offre un moyen économique d'augmenter la bande passante pour des applications particulières, car elle permet d'agréger plusieurs liaisons série en un seul ensemble de bande passante. MLFR est pris en charge sur les interfaces UNI (User-to-Network Interfaces) et NNI (Network-to-Network Interfaces) dans les réseaux Frame Relay.

Le bundle est composé de plusieurs liaisons série, appelées liaisons de bundle. Chaque liaison d'offre groupée d'une offre groupée correspond à une interface physique. Les liaisons d’ensemble sont invisibles pour la couche liaison de données Frame Relay, de sorte que la fonctionnalité Frame Relay ne peut pas être configurée sur ces interfaces. La fonctionnalité Frame Relay régulière que vous voulez appliquer à ces liaisons doit être configurée sur l’interface de l’offre groupée. Les liaisons de bundle sont visibles par les périphériques homologues.

DDR distribué

La fonction DDR distribuée permet la commutation distribuée sur les interfaces de numérotation. Sans cette fonctionnalité, tout le trafic entrant doit être acheminé vers l’hôte pour commutation. Avec elle, seuls les paquets de contrôle sont envoyés au RP, alors que la décision de commutation est prise sur les VIP eux-mêmes après l'établissement d'une connexion.

La configuration de numéroteur hérité et la configuration de profil de numéroteur ne sont prises en charge qu’avec l’encapsulation PPP. MLP sur les interfaces de numérotation est également pris en charge. La qualité de service n'est pas prise en charge avec la commutation distribuée sur les interfaces de numérotation.

Caractéristiques distribuées Conditions requises et restrictions

Conditions préalables

Voici les conditions générales requises pour toutes ces fonctionnalités distribuées :

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

• La commutation dCEF doit être activée sur l'interface série du membre, qui fait partie du bundle MLP.

• La commutation dCEF doit être activée sur la liaison physique des interfaces dLFIoFR et dLFIoATM.

• La configuration d'interleave est requise pour distribuer LFIoFR et LFIoATM.

• Configurez la bande passante requise sur l'interface Virtual-Template pour les interfaces dLFIoFR et dLFIoATM.

• Lorsque les débogages PPP sont activés sur le RP, vous pouvez observer le MLP : Transfert vers un message d'interface incorrect sur le processeur de commutation de route (RSP). Comme ce message est déroutant et indésirable, en particulier s'il s'agit de paquets CDP (Cisco Discovery Protocol), vous devez configurer no cdp enable sur les liaisons membres de l'offre groupée.

• Toutes les liaisons membres du bundle doivent avoir le keepalive activé.

Restrictions

Ces restrictions générales s'appliquent à toutes ces fonctionnalités distribuées :

• Les lignes T1 et E1 ne peuvent pas être mélangées dans une offre groupée.

• Le délai différentiel maximum pris en charge est de 30 ms.

• Toutes les lignes d'un ensemble doivent résider sur la même carte de port (PA).

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

• VIP ou FlexWAN CEF est limité à IP uniquement ; tous les autres protocoles sont envoyés au RSP.

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

• De nombreux mécanismes de mise en file d’attente plus anciens ne sont pas pris en charge par dLFI. Ces mécanismes comprennent :

  • Mise en file d'attente équitable sur une interface de modèle virtuel

  • Détection aléatoire sur une interface de modèle virtuelle

  • Mise en file d'attente personnalisée

  • Mise en file d'attente par priorité

• La mise en file d'attente équitable, la détection aléatoire (dWRED) et la mise en file d'attente par priorité peuvent être configurées dans une stratégie de trafic avec l'interface de ligne de commande QoS modulaire.

• Une seule liaison par bundle MLP est prise en charge lorsque vous utilisez dLFIoFR ou dLFIoATM. Si plusieurs liaisons sont utilisées dans un bundle MLP lors de l'utilisation dLFIoFR ou dLFIoATM, dLFI est automatiquement désactivé. Lors de l'utilisation dLFI sur des lignes louées, plusieurs liaisons peuvent être configurées avec dLFI dans l'offre MLP.

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

• Seule la voix sur IP est prise en charge ; La fonction dLFI ne prend pas en charge les fonctions Voice over Frame Relay et Voice over ATM.

• La configuration CRTP (Compressed Real-Time Protocol) ne doit pas être configurée sur l'interface multiliaison, lorsque vous utilisez cette combinaison de fonctionnalités :

  • Interface multiliaison activée avec LFI

  • Le bundle multiliaison comporte plusieurs liaisons membres

  • La stratégie QoS avec fonction de priorité est activée sur l'interface multiliaison

Avec la configuration dMLP et dLFI, les paquets de priorité ne transportent pas l'en-tête et le numéro de séquence MLP, et MLP distribuera les paquets de priorité sur toutes les liaisons membres. Par conséquent, les paquets compressés par CRTP peuvent arriver hors-service sur le routeur récepteur. Cela interdit au protocole CRTP de décompresser l’en-tête de paquet et force le protocole CRTP à abandonner les paquets.

Recommandations

Il est recommandé que les liaisons membres d'un bundle aient la même bande passante. Si vous ajoutez des liaisons de bande passante inégales à l'ensemble, cela conduira à un grand nombre de réordonnancement de paquets, ce qui entraînera une diminution du débit global de l'ensemble des paquets.

Il est recommandé d'utiliser le VIP2-50 (avec 8 Mo de SRAM) ou supérieur avec ces fonctionnalités distribuées.

Nombre de bundles et de liaisons et besoins en mémoire

Reportez-vous à Distributed Multilink Point-to-Point Protocol pour les routeurs de la gamme Cisco 7500.

Matériel et logiciel MLPPP ou MLFR sur cartes de ligne SIP 7600

MLP et MLFR peuvent être basés sur des logiciels ou du matériel. Dans les MLP ou MLFR basés sur le matériel, Freedm fournit la fonctionnalité de multiliaison et les en-têtes MLP sont ajoutés par la puce Freedm. Dans les MLP ou MLFR basés sur logiciel, le processeur de la carte de ligne SIP fournit la fonctionnalité de multiliaison (similaire aux implémentations VIP et FlexWAN).

Il s'agit des limitations et conditions d'exécution de MLP ou MLFR basés sur le matériel.

• Il ne peut y avoir que 336 offres groupées par carte de ligne et 168 offres groupées par évaluation de la position de sécurité (SPA) (Freedm).

• Il ne peut y avoir qu'un maximum de 12 DS1/E1 par bundle.

• Toutes les liaisons doivent appartenir au même SPA (Freedm).

• Toutes les liaisons du bundle doivent fonctionner à la même vitesse.

• La taille du fragment TX peut être 128, 256 ou 512. Une taille de fragment configurée CLI est mappée à la taille de fragment prise en charge la plus proche.

  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 du fragment RX peut être comprise entre 1 et 9,6 Ko.

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

Dans le LFI matériel, s'il n'y a qu'une seule liaison dans le bundle et si c'est DS1/E1, alors la fragmentation et l'entrelacement seront effectués par Freedm.

Le résultat de show ppp multilink indique si l'implémentation matérielle est en cours d'exécution.

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 multilink est basé sur un logiciel, la sortie show ppp multilink n'aura pas Multilink dans Hardware dans la sortie.

Vie d’un paquet

Chemin De Données Rx

1. Paquet reçu par le pilote.

2. L'encapsulation est cochée : comme suit :

   1. Encapsulation de base :

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

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

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

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

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

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

   2. Traitement d’encapsulation supplémentaire :

      Pour ET_PPP, le NLPID est reniflé.

      • Pour dMLP, le NLPID est MULTILINK.

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

        1. Paquets VoIP : ils n'ont pas d'en-tête MLP et ont un NLPID qui indique IP.

        2. Data Packets : le NLPID est MULTILINK.

      • Pour dDialer, les paquets n'ont pas d'en-tête MLP et ont un NLPID qui indique IP.

        Remarque : Dans ce cas, vous pouvez configurer dCRTP (Distributed Compressed Real-Time Protocol). Si c'est le cas, l'en-tête est décompressé avant d'être traité ultérieurement.

3. Pour ET_FRAME_RELAY, si la liaison sur laquelle le paquet est reçu est configurée pour dMLFR, le paquet est traité pour dMLFR

4. Pour dLFIoFR et dLFIoATM, le type d'encapsulation est ET_FRAME_RELAY et ET_ATM, respectivement ; mais il y a un en-tête PPP. L’en-tête PPP, comme avec dLFIoLL, indique si le paquet est un paquet vocal ou un paquet de données. Si dCRTP est configuré, l'en-tête est décompressé avant tout traitement ultérieur. Les paquets vocaux sont commutés immédiatement.

   Un paquet de données fragmenté devra être réassemblé avant d’être commuté.

   Avec ET_PPP, vous pouvez croiser des paquets de liaison PPP ; et avec ET_FRAME_RELAY, vous pouvez rencontrer des paquets de contrôle MLFR. Tous ces paquets de contrôle sont punis au RP pour traitement.

5. En fonction du décodage susmentionné, le paquet est vérifié pour déterminer le type de commutation dont il a besoin. Le type de liaison détermine si le paquet doit être commuté IP ou MPLS. Les paquets sont ensuite attribués aux fonctions de commutation respectives.

6. Avec l'offre groupée associée à des fonctionnalités distribuées, le vecteur de commutation rapide turbo IP est volé. Ceci est fait parce que le paquet est reçu sur la liaison membre ; toutefois, il doit être traité de telle sorte qu'il soit reçu sur l'offre groupée.

   Vous devez également vérifier les paquets de contrôle qui sont acheminés vers l'hôte. Principalement en dMLFR, il y a des paquets LMI (Local Management Interface) qui ne sont pas des paquets de contrôle MLFR. Dans ce cas, une partie différente de l’espace numérique dLCI est utilisée. Chaque fois que l’identificateur dLCI est décodé pour tomber dans cet espace, le paquet est pointé vers l’hôte, car il est reconnu comme un paquet LMI.

   Les paquets VoIP (mis en file d'attente à faible latence) sont simplement commutés sans l'ajout de l'en-tête MLP. Les fonctionnalités distribuées peuvent recevoir et réassembler des paquets, lorsque des paquets de données fragmentés sont reçus. Le processus de réassemblage est expliqué dans une section ultérieure.

   Si le paquet doit être commuté par étiquette, il est ensuite transmis à la routine de commutation par étiquette, en dMLP. Sinon, s'il doit être commuté IP, il est transmis à la routine de commutation IP.

   Remarque : Tous les paquets non IP sont punis sur l'hôte, en dMLFR.

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

   • Effectuez le traitement nécessaire des paquets, au cas où des fonctionnalités seraient configurées. En outre, lorsque Distributed Dialer est utilisé, effectuez ici les mises à jour du compteur d'inactivité lorsqu'un ” de paquets intéressant “ est reçu. Référez-vous à dialer idle-timeout (interface) , dialer fast-idle (interface) et Configuration d'un profil de numérotation pour plus d'informations sur le paramètre de configuration du minuteur d'inactivité.

   Sur les routeurs 75xx, la contiguïté indique le tx_acc_ptr pour l'interface de sortie. Si l'interface de sortie est une interface d'accès virtuelle, tx_acc_ptr est NULL. Dans ce cas, corrigez l'encapsulation et récupérez le tx_acc_ptr à partir de la clé fib. Cette correction de recherche et d’encapsulation est nécessaire dans dLFIoFR et dLFIoATM. Dans dLFIoLL, la liaison est traitée comme faisant partie d'un bundle multiliaison.

   Remarque : la durée de vie du paquet est ajustée ici et la vérification de la fragmentation IP est effectuée. Le statut_mci est défini sur RXTYPE_DODIP pour tous les paquets.

8. Une fois la décision de commutation prise, le paquet est prêt à être expédié à partir de l’interface. L’interface est vérifiée pour déterminer si elle prend en charge la commutation locale. Si c'est le cas, il est envoyé directement par envoi rapide. Dans le cas contraire, une tentative est faite pour le commutateur de la mémoire cache de route.

   Notez que, dans le cas où QoS est configuré pour l'interface, le vecteur de commutation local est volé par QoS. HQF met le paquet en file d'attente et le traite plus avant, avant qu'il ne soit finalement envoyé hors de l'interface. C'est le cas avec dLFI. Pour les dLFI, la fragmentation et l'entrelacement sont définis. QoS gère l'invocation de notre routine de fragmentation et interfère les paquets fragmentés avec les paquets vocaux qui seront mis en file d'attente prioritaire (si LLQ est configuré). Cela permet de s'assurer que les paquets VoIP ne subissent pas le retard requis pour expédier des paquets de données énormes via la liaison.

Chemin de données Tx

Le vip_dtq_customer obtient le paquet et le numéro d'interface, à partir duquel il obtient la commande idb. La routine fast send qui correspond à la base de données idb est appelée :

i) Envois rapides

1. En dMFR, la structure fr_info est récupérée à partir de la table qui correspond à if_index à fr_info. Les paquets de contrôle sont simplement envoyés. L’en-tête de trame donne l’identificateur dLCI, qui vous aidera à déterminer s’il s’agit d’un paquet LMI ou d’un paquet de données. Le champ dlci de l’en-tête de trame est remplacé par le numéro de séquence dmfr. Des numéros de séquence distincts sont utilisés pour les paquets LMI et de données.

   Remarque : Des numéros dLCI distincts sont utilisés pour des ID deLCI distincts.

2. En dMLP, les paquets de contrôle sont envoyés avec une priorité définie sur élevée. Avec les paquets de données, si dCRTP est configuré, l'en-tête est compressé. L'en-tête VIP MLP qui inclut les informations de séquencement est ajouté et envoyé à partir des liens membres.

3. En dLFI, HQF intercepte les paquets à envoyer via l'interface. S'il s'agit d'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 les paquets de données, il appelle le code de fragmentation dLFI, qui retourne des fragments au code QoS, qui sont ensuite entrelacés avec le trafic prioritaire pour que les exigences de délai du trafic vocal soient satisfaites. En outre, si dCRTP est configuré, seul l’en-tête du paquet vocal est compressé. Les en-têtes des paquets de données sont laissés tels quels.

4. Dans dDialer, le paquet est classifié afin de réinitialiser le compteur d'inactivité de la liaison de sortie avant l'envoi du paquet. Cette opération est effectuée après le choix de la liaison de sortie, dans le cas où plusieurs liaisons sont liées au même numéroteur. Aucun en-tête n'est ajouté aux paquets de numérotation. Ainsi, le séquençage et le réassemblage des paquets ne sont pas pris en charge sur les interfaces de numérotation.

Remarque : Dans dMLP, dDialer, dMLFR et dLFI avec plusieurs liaisons, la liaison physique sur laquelle le trafic est transféré dépend de l'encombrement de la liaison. Si la liaison est congestionnée, passez à la liaison suivante, etc. (dMLFR, dMLP sans QoS, et dDialer fonctions choisissent également des liens en fonction du nombre d'octets placés sur la liaison. Il choisit la liaison suivante, si la liaison actuelle a déjà transmis son quota d'octets, sur une base circulaire. Ce quota est déterminé par le frag_bytes pour la liaison. Pour les interfaces membres du numéroteur, la valeur par défaut de la bande passante de l'interface est frag_bytes.)

Remarque : dans les configurations HQF sur les interfaces du VIP de sortie, HQF vole le vecteur dtq_Consumer. Le paquet DMA vers le VIP de sortie passe d'abord par le contrôle HQF. Si QoS est configuré sur l'interface de sortie, HQF se lance pour traiter le paquet, avant que le paquet ne soit rapidement envoyé hors de l'interface.

Réassemblage

Les interfaces de numérotation simple ne prennent pas en charge le réassemblage et le séquençage. Pour activer cette fonctionnalité sur les interfaces de numérotation, vous devez configurer MLP sur les interfaces de numérotation. Si cela est fait, les chemins Rx et Tx sont identiques aux chemins dMLP. Lorsque des paquets sont reçus, le numéro de séquence est vérifié par rapport au numéro de séquence attendu.

• Si les numéros de séquence correspondent :

  1. Si le paquet est un paquet non fragmenté, le réassemblage n'est pas nécessaire. Passez à d'autres étapes de commutation.

  2. Si le paquet est un fragment, vérifiez les bits de début et de fin et construisez le paquet au fur et à mesure de la réception des fragments.

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

  1. Si le numéro de séquence se trouve dans la fenêtre prévue des numéros de séquence, placez-le dans la liste “ fragments non attribués triés. ” Plus tard, lorsqu'un numéro de séquence attendu n'est pas reçu, cette liste est vérifiée, au cas où le paquet était stocké ici.

  2. Si le numéro de séquence ne se trouve pas dans la fenêtre, ignorez-le et signalez “ fragment perdu reçu. ” Si un délai d’attente se produit plus tard pendant l’attente de ce paquet, le récepteur est resynchronisé et recommence avec le paquet suivant reçu.

Dans tous ces cas, un flux de paquets correctement ordonné est envoyé à partir de cette interface. Si des fragments sont reçus, un paquet complet est formé, puis envoyé.

Configuration, vérification et débogage des fonctionnalités distribuées

Cette section couvre les commandes show et debug disponibles pour vérifier et déboguer chacune des fonctionnalités distribuées.

Configuration et vérification dMFR

Exemple de configuration 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 FR et prend donc en charge la plupart des configurations FR.

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érifier l'état de l'offre groupée 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

Cela indique que deux interfaces sont ajoutées correctement et qu'une interface n'a pas encore négocié les messages LIP MLFR.

Pour obtenir plus d'informations sur le bundle MFR et les liens de membre, é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 débogage MFR

Ces débogages sont utiles pour dépanner les problèmes où un lien n'est pas ajouté au bundle.

debug frame-relay multilink control

Remarque : Lorsqu'aucune interface MFR ou interface série spécifique n'est spécifiée, le débogage est activé pour toutes les liaisons MFR. Cela peut être surprenant si le routeur possède un grand nombre de liaisons MFR.

Pour déboguer les paquets MFR reçus au niveau du RP, ainsi que pour déboguer les activités de contrôle MFR, ce débogage est utile :

debug frame-relay multilink

Remarque : Dans le cas d'un trafic dense, cela peut submerger le processeur.

Vérifier l'état de l'offre groupée dMLFR sur le LC

show frame-relay multilink

Note : Actuellement, ce n'est pas disponible sur le LC, mais il sera bientôt ajouté. Jusque-là, utilisez show ppp multilink.

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

Configuration et vérification de dMLP/dLFIoLL

Configuration PPP multiliaison

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

Exemple de configuration 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 ppp chap hostname M1 ne signifie pas vraiment que l'authentification CHAP est activée. La chaîne M1 de cette commande agit en tant que discriminateur de point d'extrémité et n'est requise que s'il y a plusieurs faisceaux de liaisons multiples entre les deux mêmes routeurs. Dans un tel cas, toutes les liaisons qui appartiennent à une offre groupée doivent avoir le même discriminateur de point de terminaison et aucune des deux liaisons qui appartiennent à une offre groupée différente ne doit avoir le même discriminateur de point de terminaison.

Paramètres de configuration facultatifs

[no] ppp multilink interleave

Cela permet l'entrelacement sur le bundle multiliaison. Cela fonctionne avec l'interface de ligne de commande QoS modulaire. Les paquets de haute priorité sont transmis sans ajout de la séquence et de l'en-tête MLP, tandis que les autres paquets sont fragmentés et transmis avec la séquence et l'en-tête MLP.

Remarque : Lorsque l'entrelacement est activé avec plusieurs liaisons, il est possible que le trafic prioritaire soit réorganisé. Lorsque l'entrelacement est activé ou désactivé, une réinitialisation de l'offre groupée est requise pour l'activer dans la carte de ligne.

ppp multilink mrru local value

Indique l'unité de réception maximale sur la multiliaison ; les paquets jusqu'à cette taille seront acceptés par l'interface multiliaison. La taille ici exclut l'en-tête MLP.

ppp multilink mrru remote value

Ceci spécifie le MRRU minimum que l'extrémité distante doit prendre en charge. Si le MRRU de l'extrémité distante est inférieur à cette valeur, la négociation de l'offre échoue.

ppp multilink fragment delay seconds

Indique le délai autorisé en millisecondes (ms) causé par un fragment de données. En d'autres termes, la valeur de délai est utilisée pour calculer la taille de fragment maximale autorisée. La mise en oeuvre distribuée diffère de la mise en oeuvre de Cisco IOS de ces manières :

1. La fragmentation n'est pas effectuée, sauf si l'entrelacement est activé.

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

ppp multilink fragment disable

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

Vérifier l'état de l'offre groupée 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. Lorsque l'offre groupée est en mode distribué, elle est affichée dans la sortie de show ppp multilink :

   L'offre groupée est distribuée

   Si ce n'est pas le cas, l'offre groupée n'est pas distribuée pour une raison quelconque.

2. Lorsque ppp multilink interleave est configuré et activé sur la carte de ligne, la sortie show ppp multilink inclut les statistiques dLFI où :

   • Fragmented : indique le nombre de fragments transmis et reçus.

   • Unfragmented : indique le nombre de paquets qui ont été transmis ou reçus sans être fragmentés.

   • Reassembly : indique le nombre de paquets complets qui ont été réassemblés. Lorsque l'entrelacement 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 du fragment dans l'exemple précédent est de 760 octets.

Vérifier l'état de l'offre groupée 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 maintenus par dLCI, avec le numéro de séquence dans l'ensemble utilisé pour le dLCI LMI.

Champ	Description
dmlp_ipc_config_count	Nombre de messages IPC reçus par le LC pour la configuration multiliaison ou MLFR
dmlp_bundle_count	Nombre de bundles MLP et MLFR dans le LC
dmlp_ipc_nombre_panne	Nombre de messages de configuration ayant entraîné une défaillance dans LC. Doit être 0 ; si elle n'est pas nulle, il pourrait y avoir un problème.
vecteurs de balise	Indique les vecteurs idb à tag_optimum_fs et idb à ip2tag_optimum_fs utilisés dans la commutation de balises.
board_encap	Indique le vecteur board_encap utilisé pour ajouter 2 octets d'encapsulation de carte, s'il existe des liaisons canalisées dans une plate-forme 7500. Doit être NULL, si la liaison contient des interfaces non canalisées.
max_particules	Nombre maximal de particules pouvant être détenues dans la mémoire tampon de réassemblage
mrru	Taille maximale du paquet qui est accepté sans tenir compte de l'encapsulation MLP. Ne s'applique pas à l'interface MLFR.
seq_window_size	Taille de fenêtre maximale pour les numéros de séquence
work_pak	Indique le pak en cours de réassemblage. NULL, si aucun.
working_pak_cache	Pointeur vers le chemin statique utilisé pour le réassemblage. Ceci est attribué lorsque le premier paquet non complet est reçu par l'offre groupée.
liste_de_frag	Première entrée dans la file d'attente de réassemblage. Si l'entrée n'est pas NULL et ne change pas, elle indique que le minuteur n'exécute pas de problème logiciel.
fin_frag_una	Dernière entrée dans la file d'attente de réassemblage
rcved_end_bit	Indique que l'offre groupée a reçu un bit de fin, donc qu'elle recherche un bit de début.
is_loss_frag	Est vrai si un fragment est déclaré perdu. Ceci est effacé lorsqu'un fragment avec la séquence attendue est reçu.
resync_count	Indique le nombre de fois où le récepteur n'était pas synchronisé avec l'émetteur et a dû se resynchroniser en commençant par le dernier fragment séquencé reçu.
délai	Indique que le délai de réassemblage a expiré et que les paquets sont traités à partir de la file d'attente de réassemblage.
timer_start	Nombre de fois où le minuteur de réassemblage a été démarré
timer_exécution	Indique si le minuteur de réassemblage est en cours d'exécution.
timer_count	Indique le nombre de fois où le minuteur de réassemblage a expiré.
lien_terminal_suivant	La liaison sur laquelle le paquet suivant sera transmis
Membre	Bit qui indique les membres présents.
Congestion	Champ non utilisé dans toutes les branches. Indique les liaisons membres qui ne sont pas encombrées.
dmlp_orig_pak_vers_hôte	Vecteur utilisé pour envoyer des paquets au RP.
dmlp_orig_fastsend	L'envoi rapide du pilote d'origine avant MLP ou MLFR a modifié l'envoi rapide du pilote.
fragments perdus	Nombre de fragments perdus (le récepteur n'a pas reçu ces fragments). Cette opération est désactivée périodiquement lorsqu’une mise à jour est envoyée à l’hôte.
Réordonné	Nombre de fragments reçus dans l'ordre prévu. Cette opération est désactivée périodiquement lorsqu’une mise à jour est envoyée à l’hôte.
Rejeté	Nombre de fragments rejetés car un paquet complet n'a pas pu être créé
reçu perdu	Nombre de fragments reçus qui auraient été perdus. Cela indique que le délai d'interconnexion est supérieur au délai de réassemblage dMLP de 30 ms.

Configuration et vérification dLFIoFR et 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érifier l'état de l'offre groupée 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 : L'offre groupée sera distribuée uniquement lorsque ppp multilink interleave est configuré sous le modèle virtuel ; sans cette commande, le bundle ne sera pas distribué.

Vérifier l'état de l'offre groupée dLFIoFR/ATM sur le LC

Pour vérifier que le dLFI fonctionne correctement au niveau du LC, émettez 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 doit y avoir une couche prioritaire et une couche WFQ. La fragmentation se fera au niveau de la couche feuille de la WFQ.

Configuration et vérification du dDDR

Le routage à établissement de connexion à la demande distribué est activé lorsque vous activez ip cef distribué sur la configuration globale et ip route-cache distribué 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'existe aucune autre configuration spéciale pour le DDR distribué. Une configuration supplémentaire suit une configuration DDR normale.

Vérification du routage à établissement de connexion à la demande

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érotation nous indique le type de numérotation utilisé. RNIS implique une configuration de numérotation héritée et PROFILE implique une configuration de profil de numérotation. L'état du numéroteur indique l'état actuel du numéroteur. L'état d'une interface de numérotation non connectée sera inactif. Le compteur d'inactivité est réinitialisé chaque fois qu'un trafic intéressant est vu. Si ce compteur expire un jour, l'interface se déconnecte immédiatement. Le compteur d'inactivité est un paramètre configurable. Pour plus d'informations, référez-vous à Configuration de DDR homologue à homologue avec des profils de numérotation.

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 les mêmes que celles pour dMLP.

Débogage dMLP et dDDR

Débogues disponibles au niveau du RP

dDDR

debug dialer [events | packets | forwarding | map]

Émettez cette commande pour déboguer les fonctions de chemin de contrôle comme la configuration des appels et ainsi de suite. Pour plus d'informations, référez-vous aux événements debug dialer.

debug ip cef dialer

Émettez cette commande pour déboguer les événements de numérotation liés au CEF. Pour plus d'informations, reportez-vous à Dialer CEF.

Débogues disponibles sur LC

dMLP

Débogage du chemin de contrôle : debug multilink event

Débogage du chemin de données : debug multilink fragments

Débogage des erreurs de chemin d'accès et de contrôle des données : debug multilink error

Débogage dMLP sur les cartes de ligne SIP

Dumping des paquets en fonction de CI : Les paquets de données et les paquets de contrôle peuvent être abandonnés sur des cartes de ligne en fonction de l'ci de contrôle et de la séquence ci.

tester hw-module subslot_num dump ci CI-NUM [rx|tx] num_packets_to_dump

Les CI peuvent être obtenus de la manière suivante :

!--- 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 numéro vc, qui peut être obtenu à partir de la sortie de show interface serial CT3_interface_name .

Vous pouvez désormais obtenir les informations de CI à partir de la console SPA. Redirigez d'abord le résultat des commandes de console SPA vers le RP avec la commande spa_redirect rp ct3_freedm336.

La commande spa_ct3_test freedm show linkrec vc affiche les informations de CI nécessaires.

dMFR

Débogage du chemin de contrôle : debug dmfr event

Débogage du chemin de données : debug dmfr packets

Débogage des erreurs de chemin d'accès et de contrôle des données : debug dmfr error

Dumping des paquets en fonction de CI : Voir dMLP.

dLFI

Débogage du chemin de contrôle : debug dlfi event

Débogage du chemin de données : debug dlfi fragments

Débogage des erreurs de chemin d'accès et de contrôle des données : debug dlfi error

dDDR

Il n'existe aucune commande de débogage spéciale ; vous devez utiliser des débogages dMLP.

Dans le cas de dLFIoLL, les débogages dMLP et dLFI peuvent devoir être utilisés. Ces débogages ne sont pas conditionnels et, par conséquent, déclencheront tous les bundles.

Forum aux questions

1. Qu'est-ce que le dMLP ?

   dMLP est une abréviation de Distributed Multilink PPP (comme indiqué dans RFC1990 ). Cette fonctionnalité est prise en charge par les plates-formes distribuées, telles que les gammes Cisco 7500 et 7600. dMLP vous permet de combiner des lignes T1/E1 (dans un VIP sur un routeur de la gamme Cisco 7500 ou un FlexWAN dans un routeur de la gamme 7600) en un ensemble qui possède la bande passante combinée de plusieurs lignes T1/E1. Cela permet aux clients d'augmenter la bande passante au-delà de T1/E1 sans avoir à acheter une ligne T3/E3.

2. Qu'est-ce que “ ” distribué dans dMLP ?

   Le terme “ ” distribué implique que la commutation de paquets est effectuée par le VIP et non par le RSP. Pourquoi ? Les capacités de commutation RSP sont plutôt limitées et il reste beaucoup plus à faire. Le VIP capable de commuter des paquets décharge cet exercice du RSP. Cisco IOS basé sur RSP gère toujours les liaisons. La création et le retrait des offres groupées sont effectués par le RSP. En outre, le traitement du plan de contrôle PPP est toujours effectué par RSP, y compris la gestion de tous les paquets de contrôle PPP (LCP, Authentication et NCP). Cependant, une fois qu'un bundle est établi, le traitement des paquets MLP est remis au VIP pour commutation par le processeur embarqué. Le moteur dMLP (sur le VIP) gère toutes les procédures MLP, y compris la fragmentation, l'entrelacement, l'encapsulation, l'équilibrage de charge entre plusieurs liaisons, ainsi que le tri et le réassemblage des fragments entrants. Les fonctions effectuées par le VIP dans un système 7500 sont exécutées par le Flexwan/Enhanced-FlexWAN dans un système basé sur 7600.

3. Comment savoir si le bundle est distribué ou non ?

   Exécutez la commande show ppp multilink sur 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 je mets à niveau vers RSP16 ou SUP720, mes performances dMLP seront-elles meilleures ?

   Non. Les performances de commutation dMLP (ou toute fonctionnalité distribuée) dépendent du VIP ou du FlexWAN en question. Par exemple, les performances d'un VIP6-80 sont meilleures que celles du VIP2-50.

5. Quels ports puis-je utiliser avec cette fonction ?

   • 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 uniquement)

6. Combien de liaisons peuvent être configurées dans une seule offre ?

   Cette réponse comporte de nombreux aspects. Le principal goulot d'étranglement est la puissance du processeur de la carte de ligne (VIP/FlexWAN/Enhanced-FlexWAN2). La limite maximale est de 56 liaisons par bundle, mais souvent vous ne pouvez pas configurer ces nombreuses liaisons (et ont autant de commutation de trafic), soit en raison de la puissance du CPU ou des tampons limités. Ces nombres sont basés sur cette recommandation (basée sur le processeur et la mémoire sur VIP/FlexWAN/Enhanced-FlexWAN2) :

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

   VIP2-50 (avec 8 Mo de SRAM) T1 max = 16

   VIP4-80 T1 max = 40

   VIP6-80 T1 max = 40

   FlexWAN max T1 = sera mis à jour prochainement

   Enhanced-FlexWAN max E1 = 21 E1 par baie (42 E1 au total par carte de ligne)

7. Y a-t-il un changement dans les performances si je configure 3 bundles avec 3 T1 chacun ou 1 bundle avec 9 T1 ?

   Il n'y a pas de changement dans les performances, comme le prouvent les tests de laboratoire. Cependant, avec un grand nombre de T1 dans un seul bundle (par exemple 24 ou 28 T1 dans un seul bundle), il y a des problèmes avec le manque de mémoires tampon. Il est fortement recommandé de ne pas avoir plus de 8 liaisons membres (T1/E1) dans une seule offre groupée.

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

   La bande passante d'un bundle ne doit pas être configurée. Il s’agit de la bande passante totale de toutes les liaisons membres. Si vous avez 4 T1 dans le bundle, la bande passante du bundle est de 6,144 Mbits/s.

9. Laquelle est la meilleure ? Équilibrage de charge CEF ou dMLP ?

   Il n'y a pas de réponse simple à cela. Vos besoins décident lequel est le meilleur.

   PROS de MLP :

   • L'équilibrage de charge CEF s'applique uniquement au trafic IP. MLP équilibre l'ensemble du trafic envoyé sur une offre groupée.

   • MLP gère l'ordre des paquets. La propriété intellectuelle elle-même tolère la réorganisation, ce qui n'a pas d'importance pour vous ; en fait, le coût supplémentaire lié à la maintenance du séquençage peut être une raison d'éviter les MLP. Le protocole IP est destiné aux réseaux qui peuvent fournir des datagrammes dans le désordre, et tout ce qui utilise le protocole IP est censé être capable de gérer la réorganisation. Cependant, malgré cela, la réalité est que la réorganisation peut encore poser un vrai problème.

   • MLP fournit une connexion logique unique au système homologue.

   • La qualité de service est prise en charge sur les offres multiliaison.

   • MLP fournit des fonctionnalités de bande passante dynamique, car l'utilisateur peut ajouter ou supprimer des liens de membre en fonction des besoins actuels.

   • MLP peut regrouper un plus grand nombre de liaisons, alors que l'équilibrage de charge CEF est limité à 6 chemins IP parallèles.

   • L'équilibrage de charge CEF par flux limite la bande passante maximale d'un flux donné à un T1. Par exemple, les clients qui utilisent des passerelles vocales peuvent avoir beaucoup d'appels avec la même source et la même destination et, par conséquent, n'utiliser qu'un seul chemin.

   CONS de MLP :

   • MLP ajoute une surcharge supplémentaire à chaque paquet ou trame

   • MLP consomme beaucoup de CPU ; dMLP est une carte de ligne gourmande en CPU.

10. Comment configurer plusieurs ensembles entre deux routeurs ?

    Multilink détermine le regroupement auquel une liaison doit se joindre en fonction du nom de l'homologue et du discriminateur de point de terminaison. Pour créer plusieurs ensembles distincts entre deux systèmes, la méthode standard consiste à forcer certaines liaisons à s'identifier différemment. La méthode recommandée est l'utilisation de la commande ppp chap hostname name.

11. Puis-je avoir des liens de membre de différents PA ?

    Non. Si vous voulez exécuter dMLP, il n'est pas pris en charge. Cependant, si des liaisons de membres sont ajoutées à partir de différents PA, le contrôle est donné au RSP et à son non-dMLP. MLP fonctionne toujours, mais les avantages de dMLP ont disparu.

12. Puis-je mélanger des liens de membre des deux baies ?

    Non. Si vous voulez exécuter dMLP, il n'est pas pris en charge. Cependant, si des liaisons membres sont ajoutées à partir de différents PA, le contrôle est donné au RSP et il n'est plus dMLP. MLP fonctionne toujours, mais les avantages de dMLP ont disparu.

13. Puis-je avoir des liens de membre sur différents VIP ou FlexWAN ?

    Non. Si vous voulez exécuter dMLP, il n'est pas pris en charge. Cependant, si des liaisons de membres sont ajoutées à partir de différents PA, le contrôle est donné au RSP et à son non-dMLP. MLP fonctionne toujours, mais les avantages de dMLP ont disparu.

14. Puis-je avoir des liaisons de membres sur différents ports à partir d'un seul PA ?

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

    Oui. Tant qu'il provient du même AP, il n'y a pas de problème.

15. Puis-je regrouper des ports T3 ou E3 ?

    Non. Seules vitesses DS0, n*DS0, T1 et E1 sont autorisées avec dMLP pour 7500/VIP, 7600/FlexWAN et 7600/FlexWAN2.

    Remarque : le protocole MLPPP distribué est pris en charge uniquement pour les liaisons membres configurées à des débits T1/E1 ou T1/E1 inférieurs. Les interfaces STM-1/T3/T1 multicanaux fractionnés prennent également en charge dMLPPP à des vitesses T1/E1 ou T1/E1 à débit inférieur. Le protocole MLPPP distribué n'est pas pris en charge pour les liaisons membres configurées à des débits d'interface T3/E3 ClearChannel ou supérieurs.

16. Quels sont “ fragments ” réorganisés ?

    Si le fragment ou le paquet reçu ne correspond pas au numéro de séquence attendu, le compteur réorganisé est incrémenté. Pour des tailles de paquets variables, cela est inévitable. Pour les paquets de taille fixe, cela peut également se produire parce que le pilote PA traite les paquets reçus sur une liaison et ne passe pas à tour de rôle (comme cela est fait en dMLP lors de la transmission des paquets). La réorganisation ne signifie pas la perte de paquets.

17. Quels sont “ fragments ” perdus ?

    Chaque fois que le fragment ou le paquet est reçu dans le désordre et que vous découvrez que des fragments ou des paquets hors ordre sont reçus sur toutes les liaisons, le compteur fragments perdus est incrémenté. Un autre cas est celui où les fragments en panne sont stockés dans la liste et atteignent une limite (décidée en fonction de la SRAM sur VIP et de ce qui est assigné pour l'ensemble), le compteur de fragments perdus est incrémenté et le numéro de séquence suivant dans la liste est pris pour traitement.

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

    1. Numéros de séquence : Si vous attendez l'arrivée d'un fragment avec le numéro de séquence N et que tous les liens reçoivent un fragment avec un numéro de séquence supérieur à N, vous savez que le fragment N doit être perdu, car il n'y a aucun moyen qu'il puisse légalement arriver derrière des fragments plus nombreux sur la même liaison.

    2. timeout  : Si vous attendez trop longtemps un fragment, vous finirez par le déclarer perdu et passer à autre chose.

    3. Débordement de la mémoire tampon de réassemblage : Si vous attendez l'arrivée du fragment N et que d'autres fragments (dont les numéros de séquence sont supérieurs à N) arrivent sur certaines liaisons, vous devez les placer dans une mémoire tampon de réassemblage jusqu'à ce que le fragment N apparaisse. Il y a une limite à la quantité de mémoire tampon que vous pouvez mettre en mémoire tampon. Si la mémoire tampon déborde, vous déclarez à nouveau le fragment N comme perdu, et recommencez le traitement avec tout ce qui se trouve dans la mémoire tampon.

19. Qu'est-ce “ reçu perdu ”

    Il existe deux raisons possibles de perte de fragments ou de paquets reçus :

    1. Si le fragment ou le paquet reçu se trouve en dehors de la fenêtre de plage de séquences prévue, le paquet est abandonné en le marquant comme reçu perdu.

    2. Si le fragment ou le paquet reçu se trouve dans la fenêtre de plage de séquences prévue, mais que vous ne pouvez pas allouer un en-tête de paquet pour recadrer ce paquet, le paquet est abandonné et marqué comme reçu perdu.

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

    No.

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

    Non, pas dans le chemin distribué. Il n'est pas recommandé de configurer la compression d'en-tête PFC parce que nous revenons en mode non distribué si nous recevons des trames ou des paquets d'en-tête compressés. Si vous voulez continuer à exécuter 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 dMLP ?

    Non, car la compression logicielle ne fonctionne pas sur le chemin distribué.

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

    Pas avec Vanilla dMLP. Il n'y a aucun problème avec la réception des fragments avec Vanilla dMLP, mais du côté de la transmission, la fragmentation ne se produit pas. La fragmentation du côté transmission est prise en charge lorsque ppp multilink interleave est configuré sur l'interface dMLP.

24. Pouvons-nous envoyer une requête ping aux liaisons membres d'un bundle MLP ?

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

25. Existe-t-il une dépendance sur la taille de fragment MTU et MLP de liaison ?

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

26. Est-il possible de configurer deux ensembles MLP entre une seule paire de routeurs ?

    Oui, c'est possible. Toutefois, cela pourrait entraîner une altération de l'équilibrage de charge. Il peut s’avérer utile sur des bancs d’essai, de simuler plus de deux routeurs en utilisant seulement deux routeurs, mais il n’a aucune valeur réelle évidente.

    Tous les liens qui vont à un homologue commun doivent être placés dans le même bundle. Par définition, une offre groupée est l'ensemble de liaisons qui vont à un homologue particulier.

    Une ” homologue “ est identifiée par les valeurs Username et Endpoint Discriminator qu'elle offre pendant les phases LCP et d'authentification. Si vous essayez de créer plusieurs faisceaux entre deux routeurs, cela signifie que vous essayez de faire de chaque routeur une mascarade de plus d'un homologue à son homologue. Ils doivent s'identifier de manière appropriée.

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 bundle doivent être appliqués au niveau du bundle et non au niveau de la liaison de membre. Cependant, la configuration d'un algorithme de file d'attente ne doit pas affecter la manière dont les paquets sont commutés hors du bundle.

28. Pourquoi la limite de tx-quque est définie sur 26 par défaut pour les liaisons membres d'un bundle multiliaison lorsque dMLP est activé sur un Cisco 7500 ?

    Pour toute interface série de bande passante T1/E1, la limite tx-queue-limit est d'environ 4 ou 5. Lorsque vous combinez des T1/E1 en multiliaison, la bande passante augmente pour le bundle. Comme la commutation aurait lieu en fonction de la bande passante de l'interface MLP, vous devez augmenter la limite de tx-queue des liaisons membres. Seule une des liaisons membres, appelée liaison principale, est utilisée pour la commutation. Par conséquent, sa limite de tx-queue doit être augmentée.

    De plus, cette valeur est une valeur empirique choisie après avoir testé puis ajusté à cette valeur. En général, les déploiements ne comportent pas plus de 4 à 6 liaisons T1/E1 dans une offre groupée. Une valeur de 26 peut parfaitement prendre en charge 6 à 8 liaisons T1/E1, et par conséquent cette valeur a été choisie.

29. Qu'est-ce que le retard différentiel et sa valeur dans la mise en oeuvre dMLP ?

    dMLP prend en charge un délai différentiel de 30 ms. Cela signifie que si un fragment est reçu à un moment T et qu'il est en panne (en attendant un numéro d'ordre 100, mais nous avons reçu 101). Si le numéro de séquence 100 n'est pas reçu avant T+30 ms, 100 sera déclaré perdu et si vous pouvez commencer le traitement à partir de 101, vous le feriez. Si vous ne pouvez pas commencer par 101 (s'il s'agit d'un fragment de milieu), vous recherchez le fragment qui a le fragment de début (par exemple, 104) et qui commence à partir de là.

30. Que se passe-t-il lorsque les paquets sont fragmentés au niveau IP avec multiliaison sur 7500 ?

    Si les paquets sont fragmentés au niveau IP, ils sont transportés sans être réassemblés au niveau des sauts intermédiaires mais sont réassemblés au niveau du routeur de destination.

31. Que se passe-t-il lorsque les paquets sont fragmentés au niveau MLP sur 7500 ?

    Si les paquets sont fragmentés au niveau MLP et si les paquets réassemblés sont supérieurs à MRRU, les paquets sont abandonnés sur multiliaison. La fragmentation côté émission est prise en charge sur dMLP uniquement avec dLFI. Les paquets sont fragmentés au niveau MLP uniquement si la taille de paquet est supérieure à la taille de trame et inférieure à la taille de MRRU. Si les paquets sont envoyés plus que le MRRU et s'ils ne sont pas fragmentés au niveau IP, alors l'autre extrémité abandonne toutes les tailles de paquets qu'ils ne sont pas fragmentés au niveau MLP parce que les paquets sont plus que le MRRU.

32. Comment le MRRU est-il calculé ?

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

    1. Pour les nouvelles liaisons de membre arrivant, le MRRU est de nouveau négocié au niveau LCP conformément au MRRU configuré sur les liaisons de membre.

    2. Valeur configurée sur l'interface de liaison avec la commande ppp multilink mru interface.

    3. Si elle n'est pas configurée, la valeur héritée de la configuration de la commande ppp multilink mru sur l'interface parente.

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

    5. MRRU par défaut de 1524.

Améliorations du débogage

Ces améliorations seront prises en compte à l'avenir. La planification n'est pas encore terminée.

• Activez la commande debug frame-relay multilink sur le LC.

• Améliorez les CLI de débogage actuelles par interface et le nombre spécifié de paquets.

• Pour dDDR, la fonctionnalité QoS n'est pas encore prise en charge. Cela ne peut être pris en compte qu'avec une analyse de rentabilisation appropriée.

Informations connexes

• Numéroteur CEF
• Configuration du routage DDR homologue à homologue avec des profils de numérotation
• MPLS - Prise en charge PPP multiliaison
• Protocole point à point multiliaison distribué pour les routeurs de la gamme Cisco 7500
• Relais de trames multiliaison distribué (FRF.16)
• Fragmentation et entrelacement de liaison distribuée sur des lignes louées
• VoIP sur liaisons PPP avec qualité de service (LLQ / IP RTP Priority, LFI, cRTP)
• Notes techniques de dépannage - Routeurs de la gamme Cisco 7500
• Page d'assistance produit du routeur - Cisco Systems
• Support et documentation techniques - Cisco Systems