WAN : Protocole point à point (PPP)

Multilink PPP pour DDR - Configuration de base et vérification

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


Contenu


Introduction

Multilink PPP (également désigné MP, MPPP, MLP ou Multilink) permet de répartir le trafic sur plusieurs liens WAN physiques tout en assurant la fragmentation et le réassemblage des paquets, le séquencement, l'interopérabilité multiconstructeur et l'équilibrage de charge du trafic en amont et en aval.

MPPP permet des paquets à fragmenter. Ces fragments sont envoyés simultanément au-dessus de plusieurs liens point par point à la même adresse distante. Les plusieurs liens physiques sont soulevés en réponse à un seuil de charge défini par l'utilisateur. Ce chargement peut être mesuré sur juste le trafic d'arrivée, sur juste le trafic sortant, ou sur l'un ou l'autre ; cependant, il ne peut pas être mesuré sur le chargement combiné des les deux le trafic en entrée et en sortie.

Pour des connexions de cadran, MPPP peut être configuré pour des accès de base RNIS (BRIs) et des accès primaires (PRIs), aussi bien que pour des interfaces de série asynchrone. Il peut également être configuré pour des interfaces de liaison série sans numérotation, bien que cette fonctionnalité ne soit pas spécifiquement adressée dans ce document. Ce document adressera la configuration de MPPP de base pour le Routage à établissement de connexion à la demande (DDR). Le PPP de Multichassis Multilink ne sera pas couvert dans ce document ; voyez le pour en savoir plus de documentation du PPP de Multichassis Multilink (MMP).

Avant de commencer

Conventions

Pour plus d'informations sur les conventions des documents, référez-vous aux Conventions utilisées pour les conseils techniques de Cisco.

Conditions préalables

Aucune condition préalable spécifique n'est requise pour ce document.

Composants utilisés

Les informations dans ce document sont basées sur les versions de logiciel et de matériel ci-dessous.

  • Le PPP à liaisons multiples a été introduit la première fois dans la version de logiciel 11.0(3) de ½ du ¿  de Cisco IOSïÂ

  • Le Logiciel Cisco IOS version 11.3 a été utilisé dans cet exemple.

Les informations présentées dans ce document ont été créées à partir de périphériques dans 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 vous travaillez dans un réseau opérationnel, assurez-vous de bien comprendre l'impact potentiel de toute commande avant de l'utiliser.

Quel PPP à liaisons multiples fait

MPPP est une méthode pour séparer, recombiner, et ordonnancer des datagrammes à travers de plusieurs liaisons de données logiques. Voir le RFC 1990leavingcisco.com RFC 1990 pour une bonne description de MPPP. Il a été initialement motivé par le désir d'exploiter de plusieurs canaux de support dans le RNIS, mais il s'applique également à n'importe quelle situation dans laquelle les plusieurs liens de PPP connectent deux systèmes, y compris des liaisons asynchrones.

Le trafic conduit à travers un lien MPPP par l'intermédiaire de son interface de contrôle (une interface d'Access virtuelle) sera fragmenté, avec les fragments étant envoyés à travers les différents liens physiques. À l'extrémité distante du lien, les fragments sont rassemblés et expédiés au prochain saut vers leur destination finale.

Configurer le PPP à liaisons multiples

Cette section adresse les commandes et les différentes méthodes de configurer MPPP sur un routeur.

Commandes

Commande requise Description
ppp multilink Configurez la commande de ppp multilink (sur des Routeurs) sous l'interface physique et l'interface de numérotation (si utilisant des Profils de composeur).

Remarque: Si vous ajoutez cette commande, vous devez déconnecter toutes les connexions existantes et puis rebrancher pour que les nouveaux paramètres de multilink soient appliqués. Puisque le multilink est négocié pendant l'établissement d'appel, aucune modification au multilink n'est mise en application sur les connexions qui se sont terminées la négociation du Link Control Protocol (LCP).

dialer load-threshold 5 sortant Reliez le chargement (dont de 1 à 255) au delà le numéroteur initiera un autre appel à la destination. La bande passante est définie comme rapport de 255, où 255 seraient de 100 pour cent de la bande passante disponible. Dans cet exemple, le canal supplémentaire sera amené quand le chargement sortant sur le lien est de 5/255 ou 2 pour cent. Variez cette valeur selon vos besoins. L'argument sortant place le calcul de charge à faire seulement sur le trafic sortant. L'argument d'arrivée fait la même chose, mais pour le trafic d'arrivée seulement. Utilisant l'un ou l'autre d'argument place le chargement en tant que plus grand des chargements sortants et d'arrivée.

Conseil : Souvent, les clients configureront le seuil de charge 1 de commande dialer parce qu'ils veulent que tous leurs canaux B soient utilisés immédiatement pour chaque appel. La théorie derrière ceci est que si tous les canaux B montent immédiatement et le canal entier RNIS est utilisé pour chaque appel, l'appel devrait être plus court dans la durée parce que cela prendra moins de temps de transférer les données d'utilisateur.

Tandis que cette théorie est bruit, dans la pratique c'est une bonne idée de ne jamais placer votre valeur de dialer load-threshold à n'importe quoi moins que « 3". L'établissement de cette valeur à quelque chose moins que « 3" peut faire monter les plusieurs canaux RNIS immédiatement qui peuvent mener au conflit entre les deux canaux et un manque de se connecter à l'un d'entre eux.
Commandes facultatives Description
secondes de ppp timeout multilink link remove Cette commande peut être utilisée pour empêcher les connexions multiliaison du lien instable quand le chargement varie. Par exemple, quand le seuil de charge est placé à 15 (c'est-à-dire, 15/255 = 6 pour cent) et le trafic dépasse le seuil, des lignes supplémentaires sont évoquées. Quand le trafic tombe au-dessous du seuil, les lignes supplémentaires sont abandonnées. Dans les situations où les débits de données sont fortement variables, il est avantageux que les plusieurs canaux restent pendant une période spécifiée même si le seuil de charge tombe au-dessous de la valeur spécifiée. Assignez ces délais d'attente multiliaison pour être inférieurs cela spécifié pour le dialer idle-timeout qui contrôle le délai d'attente pour tous les liens.
secondes de ppp timeout multilink link add Cette commande peut être utilisée pour empêcher de plusieurs liens d'être ajouté au paquet de député britannique jusqu'à ce que le trafic élevé soit reçu pour un intervalle spécifié. Ceci peut empêcher des rafales de trafic d'évoquer inutilement des lignes supplémentaires.
maximum-lien de ppp multilink ou ppp multilink links maximum (IOS 12.2 ou plus élevés) Le positionnement de valeur dans le ppp multilink links maximum de commande spécifie le nombre maximal de liens permis dans un paquet. Quand plus de liens que le nombre assigné avec le ppp multilink links maximum d'essai de commande pour entrer dans le paquet, MLP arrête ses canaux de numéroteur pour réduire le nombre de liens. Ceci peut être utilisé pour empêcher une connexion multiliaison d'évoquer trop de connexions.
minute-lien de ppp multilink ou ppp multilink links minimum (IOS 12.2 ou plus élevés) Le positionnement de valeur dans le ppp multilink links minimum de commande spécifie le nombre minimal de liaisons que MLP essayera de maintenir dans un paquet. Tentatives MLP à l'appel les liens supplémentaires d'obtenir le nombre spécifié par l'argument de liens, même si le chargement ne dépasse pas le seuil de charge. Ceci peut être utilisé pour forcer un certain nombre de canaux
multilink bundle-name Cette commande peut être utilisée pour changer les critères avec lesquels un ensemble multiliaison est identifié.

Legs DDR

Adresses de cette section comment configurer le PPP à liaisons multiples utilisant le legs DDR (rotary-group et Cartes de composeur).

Méthode 1 : Seulement une interface physique - ex. LE RNIS

Puisque des interfaces RNIS sont considérées des interfaces de « numéroteur », peu de commandes sont exigées pour faire un RNIS relier capable d'établir des rapports MPPP. Par exemple, il n'est pas nécessaire de configurer un groupe rotatif de routeurs d'appels à moins que vous utilisiez plus d'un BRI ou PRI.

/image/gif/paws/10239/mppp-ddr1.gif

Être suit un exemple d'un BRI configuré pour établir une connexion PPP simple de Connexion à la demande :

!
interface BRI0
 ip address 192.168.12.3 255.255.255.240
 encapsulation ppp
 dialer map IP 192.168.12.1 name ROUTER1 5554321
 dialer-group 1
 ppp authentication chap
 isdn spid1 40855512120000 5551212
 isdn spid2 40855512340000 5551234
!

Seulement deux commandes doivent être ajoutées à la configuration de cette interface pour rendre MPPP possible. Le routeur à l'autre bout de l'appel doit être pareillement configuré. Ces deux commandes sont :

ppp multilink 
dialer load-threshold load [outbound | inbound | either]

Méthode 2 : Plusieurs interfaces physiques - Le RNIS, async, et interface série

Dans les circonstances où deux interfaces physiques ou plus doivent être empaquetées ensemble (par exemple, en utilisante async ou en les interfaces série, ou en plus d'une interface RNIS) une différente méthode doivent être utilisées. Dans des ces cas, un groupe rotatif de routeurs d'appels doit être configuré et une interface de numérotation doit être ajoutée à la configuration du routeur afin de contrôler la connexion MPPP. En bref, une interface « logique » doit contrôler les interfaces « physiques ».

Afin d'accomplir ceci, vous devez :

  1. Placez les interfaces physiques dans un groupe tournant.

  2. Créez (« numéroteur ») une interface logique comme pôle pour le groupe tournant.

  3. Configurez l'interface de numérotation pour faire MPPP.

Suivez ces étapes pour configurer MPPP sur des plusieurs interfaces :

  1. Mettez les interfaces physiques dans un groupe tournant à l'aide de la commande de nombre de groupe rotatif de routeurs d'appels. Dans cet exemple, l'interface asynchrone est mise dans le groupe tournant 1 :

    router#configure terminal
    Enter configuration commands, one per line.  End with CNTL/Z.
    router(config)#interface async 1
    router(config-if)#dialer rotary-group 1
    router(config-if)#^Z
    router#

    Remarque: Soyez sûr de n'utiliser l'aucune commande de configuration d'interface d'arrêt si le routeur n'a été jamais configuré ou si le routeur a été placé de nouveau à sa configuration par défaut.

  2. Pour créer une interface de numérotation, utilisez la commande de configuration globale de nombre d'interface dialer. Dans cet exemple, l'interface dialer 1 est créée :

    router#configure terminal
    Enter configuration commands, one per line.  End with CNTL/Z.
    router(config)#interface dialer 1
    router(config-if)#end
    router#

    Remarque: L'argument de nombre de la commande d'interface dialer doit être identique que le nombre du groupe tournant configuré dans l'étape 1.

    Utilisez la commande show running-config de voir la configuration par défaut d'une interface de numérotation :

    !
    interface Dialer1
     no ip address
     no cdp enable
    !
  3. Ensuite, configurez l'interface de numérotation afin de placer ou recevoir des appels. Les commandes essentielles pour MPPP sont identiques que dans l'étape 1 :

    !
    interface Dialer1
     ip address 192.168.10.1 255.255.255.0
     encapsulation ppp
     dialer in-band
     dialer idle-timeout 300
     dialer map ip 192.168.10.11 name RemoteRouter broadcast 5551234
     dialer load-threshold 100
     dialer-group 1
     no fair-queue
     ppp multilink
     ppp authentication chap
    !

    Pour des exemples des configurations complètes DDR avec MPPP, voyez la page de support de PPP

Profils de composeur

Configurer le PPP à liaisons multiples sur des Profils de composeur est semblable à celui pour le legs DDR. La commande de ppp multilink doit être configurée sur l'interface physique et l'interface de numérotation. La commande de dialer load-threshold devrait être configurée sur l'interface de numérotation. Exemple :

mppp-ddr2.gif

interface BRI0
       no ip address
       encapsulation ppp
       dialer pool-member 1
       isdn switch-type basic-5ess
       ppp authentication chap
       ppp multilink
     
! -- Configure multilink on both physical and dialer interfaces

     !
     interface Dialer1
       ip address 172.22.85.1 255.255.255.0 
       encapsulation ppp
       dialer pool 1
     
! -- Defines the pool of physical resources from which the Dialer 

     
! -- interface may draw B channels as needed.

       dialer remote-name R1
       dialer string 6661000
       dialer load-threshold 128 outbound
       dialer-group 5
       ppp authentication chap
       ppp multilink

! -- Configure multilink on both physical and dialer interfaces

Pour plus d'informations sur des Profils de composeur référez-vous au document configurant et dépannage des Profils de composeur

Vérifiez l'exécution MPPP

Afin de vérifier le bon fonctionnement d'une connexion MPPP, utilisez la commande de debug ppp negotiation. Les éléments indispensables qui doivent être négociés pendant la phase LCP sont le maximum reçoivent l'unité reconstruite (MRRU) et le discriminateur de point d'extrémité (EndpointDisc) :

As1 LCP: O CONFREQ [Listen] id 1 len 26
As1 LCP:    AuthProto CHAP (0x0305C22305)
As1 LCP:    MagicNumber 0x10963BD1 (0x050610963BD1)
As1 LCP:    MRRU 1524 (0x110405F4)
As1 LCP:    EndpointDisc 1 Local (0x13070174657374)
As1 LCP: I CONFREQ [REQsent] id 3 Len 27
As1 LCP:    MRU 1500 (0x010405DC)
As1 LCP:    MagicNumber 0x2CBF9DAE (0x05062CBF9DAE)
As1 LCP:    MRRU 1500 (0x110405DC)
As1 LCP:    EndpointDisc 1 Local (0x1306011AC16D)
As1 LCP: I CONFACK [REQsent] id 1 Len 26
As1 LCP:    AuthProto CHAP (0x0305C22305)
As1 LCP:    MagicNumber 0x10963BD1 (0x050610963BD1)
As1 LCP:    MRRU 1524 (0x110405F4)
As1 LCP:    EndpointDisc 1 Local (0x13070174657374)
As1 LCP: O CONFACK [ACKrcvd] id 3 Len 24
As1 LCP:    MRU 1500 (0x010405DC)
As1 LCP:    MagicNumber 0x2CBF9DAE (0x05062CBF9DAE)
As1 LCP:    MRRU 1500 (0x110405DC)
As1 LCP:    EndpointDisc 1 Local (0x1306011AC16D)
As1 LCP: State is Open

Comme avec les autres éléments de la négociation LCP, le MRRU et l'EndpointDisc doivent être étés d'accord sur par les deux extrémités de la connexion pendant l'échange de CONFREQs et de CONFACKs. Les deux extrémités de la connexion doivent envoyer CONFACKs pour que le protocole soit établi. Pour plus d'informations sur la façon lire la sortie de debug ppp negotiation référez-vous derrière la sortie de debug ppp negotiation de document compréhension.

Après que MPPP ait été avec succès négocié pendant la phase LCP de la négociation PPP et le protocole d'authentification CHAP (Challenge Handshake Authentication Protocol) ou le Password Authentication Protocol (PAP) se sont terminés avec succès, une interface d'Access virtuelle sera créée par le logiciel de Cisco IOS pour représenter le paquet MPPP. Pour plus d'informations sur les utilisations et la théorie derrière les interfaces d'Access virtuelles, voyez s'il vous plaît les fonctionnalités PPP d'accès virtuel dans la documentation Cisco IOS.

La création de l'interface d'Access virtuelle est signalée dans le debug ppp negotiation sorti par ce qui suit :

As1 PPP: Phase is VIRTUALIZED

De ce point en avant, la négociation PPP des protocoles de contrôle de réseau est manipulée par l'interface d'Access virtuelle. Exemple :

Vi1 PPP: Treating connection as a dedicated line
Vi1 PPP: Phase is ESTABLISHING, Active Open
Vi1 LCP: O CONFREQ [Closed] id 1 Len 37
...
Vi1 PPP: Phase is UP
Vi1 IPCP: O CONFREQ [Closed] id 1 len 10
Vi1 IPCP:    Address 192.168.10.1 (0x0306C0A80A01)
...

Une fois que la connexion MPPP a été établie, les informations sur la connexion peuvent être trouvées dans la sortie de la commande de show ppp multilink :

router#show ppp multilink 
Virtual-Access1, bundle name is RemoteRouter
   0 lost fragments, 0 reordered, 0 unassigned, sequence 0x29/0x17 rcvd/sent
   0 discarded, 0 lost received, 1/255 load
   Member links: 1 (max not set, min not set)
     Async1

Le nom de l'ensemble est le nom d'utilisateur authentifié du périphérique connecté de client. Les liaisons membres sont une liste des interfaces physiques qui sont les membres actifs du paquet. Dans l'exemple ci-dessus, seulement un lien est actuellement - en activité, toutefois le routeur peut ajouter plus de liens au paquet à un certain point. Pour déconnecter un lien spécifique (plutôt que le paquet entier) utilisant l'interface de clear interface de commande. Par exemple, clear interface Async1.

La commande dont nommer la convention sera premier essayé (comme vu dans le nom de l'ensemble) peut être changée utilisant le multilink bundle-name de commande.

En outre, la commande d'interface d'exposition est valide pour l'interface d'Access virtuelle car elle est pour n'importe quel autre examen médical ou interface logique. Le même type d'informations sera présenté comme apparaîtrait dans n'importe quelle autre sortie d'interface d'exposition.

router#show interface virtual-access 1
Virtual-Access1 is up, line protocol is up 
Hardware is Virtual Access interface
Description: Multilink PPP to RemoteRouter

! -- This VAccess interface is conencted to "RemoteRouter"

Internet address is 192.168.10.1/24
MTU 1500 bytes, BW 7720 Kbit, DLY 100000 usec, 
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation PPP, loopback not set
Keepalive set (10 sec)
DTR is pulsed for 5 seconds on reset
LCP Open, multilink Open

! -- multilink state should be Open for a successful connection

Open: IPCP
Last input 00:00:01, output never, output hang never
Last clearing of "show interface" counters 04:25:13
Queueing strategy: fifo
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
5 minute input rate 12000 bits/sec, 2 packets/sec
5 minute output rate 12000 bits/sec, 2 packets/sec
2959 packets input, 2075644 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
2980 packets output, 2068142 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions

Informations connexes


Document ID: 10239