WAN : Protocole point à point (PPP)

Multichassis Multilink PPP (MMP) (2è partie)

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


Contenu


Introduction

Ce document continue à décrire le soutien du PPP à liaisons multiples (député britannique) dans une « pile » ou l'environnement multichâssis (parfois appelé le MMP, pour le PPP de Multichassis Multilink), sur les Plateformes de serveur d'accès de Cisco Systems.

Ce document est la partie deux d'un document en deux parties. Référez-vous à la partie une de ce pour en savoir plus de document.

Conditions préalables

Les préalables à ce document sont donnés dans la partie une de ce document.

Exemples

AS5200 dans une pile (avec des numéroteurs)

Quand des numéroteurs sont configurés sur les interfaces physiques, il n'y a aucun besoin de spécifier l'interface de modèle virtuel du tout. L'interface d'accès virtuelle agit en tant qu'interface passive, étayée entre l'interface de numérotation et les interfaces physiques associées avec l'interface de numérotation.

En bref, vous devez seulement définir le nom de groupe de pile, le mot de passe commun, et les membres du groupe de pile à travers tous les membres de pile. Aucune interface de modèle virtuel n'est définie, suivant les indications de l'exemple suivant :

systema#config
  sgbp group stackq
  sgbp member systemb 1.1.1.2
  sgbp member systemc 1.1.1.3

  username stackq password therock

  int dialer 1
  ip unnum e0
  dialer map .....
  encap ppp
  ppp authen chap
  dialer-group 1
  ppp multilink

  controller T1 0
  framing esf                    
  linecode b8zs                  
  pri-group timeslots 1-24

  interface Serial0:23
  no ip address
  encapsulation ppp
  dialer in-band
  dialer rotary 1
  dialer-group 1

L'exemple suivant est d'un contrôleur d'E1 :

controller E1 0
  framing crc4  
  linecode  hdb3
  pri-group timeslots 1-31
  interface Serial0:15
  no ip address
  encapsulation ppp
  no ip route-cache
  ppp authentication chap
  ppp multilink

Après que l'interface de paquet soit créée, elle est copiée avec seulement les commandes de PPP de l'interface de numérotation. Des liens projetés ultérieurs de PPP sont également copiés avec les commandes de PPP de l'interface de numérotation. La figure 3 affiche comment l'interface de numérotation se repose sur l'interface de paquet. Comparez-le à la figure 2, dans laquelle il n'y a aucune interface de numérotation.

PRIs et BRIs par défaut sont des interfaces de numérotation ; un PRI configuré sans numéroteur explicite (par la commande rotary de numéroteur) est toujours une interface de numérotation sur Serial0:23, comme affiché par l'exemple suivant :

interface Serial0:23
  ip unnum e0
  dialer map .....
  encap ppp
  ppp authen chap
  dialer-group 1
  dialer rot 1
  ppp multilink
Figure 3 : Un groupe de pile ? stackq ? se composer du systema, du systemb, et du systemc. le lien des systema est configuré sur l'interface de numérotation.

/image/gif/paws/14945/figure3-mmp.gif

Utilisant un serveur de débarquement

le systema est indiqué un serveur de débarquement (utilisant la commande de sgbp seed-bid). Tous autres membres du groupe de pile doivent être définis avec la commande de par défaut de sgbp seed-bid (ou, si vous ne définissez pas l'ordre de graine-BID de thesgbp, il se transfère sur ceci).

systema#config
  multilink virtual-template 1
  sgbp group stackq
  sgbp member systemb 1.1.1.2
  sgbp member systemc 1.1.1.3
  sgbp seed-bid offload
  username stackq password therock

  interface virtual-template 1
  ip unnumbered e0
  :

  ppp authen chap
  ppp multilink
Figure 4 : systema en tant que serveur de débarquement.

/image/gif/paws/14945/figure4-mmp.gif

Débarquez le serveur avec des interfaces physiques

S'indiqués débarquent le serveur a également des interfaces physiques (par exemple, PRI) souhaitant servir le même groupe de recherche de compagnie de téléphone que les autres membres de pile, vous peuvent le configurer pour faire ainsi en combinant des configurations affichées dans les sections de ce document intitulé AS5200 dans une pile (avec des numéroteurs) et à l'aide d'un serveur de débarquement.

Un lien projeté débarqué de PPP et ses interfaces de paquet se fondent sur les modèles virtuels pour une source de configuration. Une connexion qui a le premier lien arrive à un périphérique physique connecté à une interface de numérotation, et à la source de configuration pour l'interface de paquet et tous les liens projetés ultérieurs de PPP est la configuration de l'interface du numéroteur. Par conséquent, ces variations coexistent, dépendant sur le membre de pile sur lequel le premier lien arrive.

Cette configuration n'est pas due recommandé à la complexité des configurations exigées sur le numéroteur et les interfaces de modèle virtuel.

Interfaces async, séquentielles, et autres de Non-numéroteur

Tandis que vous pouvez configurer asynchrone et des appareils de la série comme interfaces de numérotation (dans ce cas il retourne à AS5200 dans une pile (avec des numéroteurs), suivant les indications de cette section de ce document), vous pouvez choisir de prendre en charge la député britannique de multichassis sans n'importe quelle configuration de numéroteur pour asynchrone, séquentiel, et d'autres interfaces de non-numéroteur. La source de toute la configuration est alors définie dans l'interface de modèle virtuel, comme affiché ci-dessous.

#config
  multilink virtual-template 1
  sgbp group stackq
  sgbp member systemb 1.1.1.2
  sgbp member systemc 1.1.1.3
  username stackq password therock
  interface virtual-template 1
  ip unnumbered e0
  :
  ppp authen chap
  ppp multilink

  int async 1
  encap ppp 
  ppp multilink 
  ppp authen chap
  :

  line 1
  login 
  autoselect ppp 
  autoselect during-login
  speed 38400
  flow hardware

Composition d'un Multichassis

Actuellement, la configuration de multichassis ne prend en charge pas le dialout, parce que le protocole de l'expédition de la couche 2 (L2F) ne prend en charge pas le dialout.

En conséquence, il n'y a aucune manière pour le serveur de débarquement (où une artère est charriée, sur un profil du numéroteur, et ainsi de suite) d'initier un cadran sur le membre de la pile frontale dans la même chose groupe de pile. Toutes les artères charriées doivent être installées sur les les membres de la pile frontale, parce que ce sont ceux avec les connexions de cadran physiques (telles que le PRI).

Quelques contournements sont comme suit :

  • Quand la commande de sgbp ppp-forward est émise sur le membre de la pile frontale, ceci signifie que tous les appels de PPP et de ppp multilink sont automatiquement expédiés au groupe de pile offrant le gagnant offert de Protocol (SGBP), tel qu'un serveur de débarquement.

    Vous devez compter sur le serveur d'accès à distance (NAS) composant pour sortir et permettez la convergence de Routage IP (pour l'IP seulement) prennent son cours. Par exemple, pour composer 1.1.1.1, mettez cette adresse dans l'instruction de mappage de numéroteur sur le NAS et mettez une artère statique sur le NAS, comme suit :

      ip route 1.1.1.1 255.255.255.255 serial0:23
      int serial0:23
      ip address 3.3.3.3 255.0.0.0
      dialer map ip 1.1.1.1 howard 7771234
    

    Quand le cadran se connecte au pair distant, la connexion PPP est formée entre le pair distant et le serveur de débarquement. Le membre de la pile frontale est complètement évité. Le PPP sur le serveur de débarquement installe alors une route hôte sur le pair — 1.1.1.1. En ce moment, le protocole de routage IP converge de à la route hôte au serveur de débarquement parce que la mesure de routage gravite l'artère là.

    Remarque: Acheminement des résultats de convergence dans la latence.

  • Quand la commande de sgbp ppp-forward n'est pas définie sur le membre de la pile frontale, ceci signifie que seulement des appels de ppp multilink sont automatiquement expédiés au gagnant d'offre SGBP, tel qu'un serveur de débarquement. Ainsi, un numéroteur du membre de la pile frontale à un pair distant répartit la connexion PPP entre le pair frontal et distant — le même comportement comme si le NAS n'était pas une partie d'un groupe de pile.

    Remarque: Ceci se produit tant que la connexion est PPP droit (et pas ppp multilink).

Composition à un Multichassis

Si vous avez le Routage IP (tel que le Protocole EIGPR (Enhanced Interior Gateway Routing Protocol) et le Protocole OSPF (Open Shortest Path First)) circulent entre le client et le membre de pile qui gagne par la suite l'offre (telle que le serveur de débarquement), quelques conseils à suivre :

Empêchez installer une route connectée sur le côté client

Configurez le client 1.1.1.2 où 1.1.1.2 est l'adresse du NAS (le trame-expéditeur transparent), comme affiché ci-dessous.

  int bri0

  dialer map 1.1.1.2 ....

Si vous avez l'EIGRP, par exemple, s'exécuter entre le client et le serveur de débarquement, la table de routage sur le serveur de débarquement indique que cela à obtenir à 1.1.1.2 que l'artère devrait passer par l'interface d'accès virtuelle. C'est parce que le protocole de contrôle IP de PPP (IPCP) sur le côté client installe une route connectée 1.1.1.2 sur l'interface BRI. L'EIGRP annonce alors cette artère au serveur de débarquement au-dessus de la session PPP (au-dessus de L2F). L'EIGRP sur le serveur de débarquement indique ainsi cela pour obtenir à 1.1.1.2, il devrait conduire au client — l'artère 1.1.1.1 du client est à l'interface d'accès virtuelle.

Maintenant, vous avez un paquet destiné pour le client 1.1.1.1. Le Routage IP envoie le paquet à l'interface d'accès virtuelle. L'interface d'accès virtuelle encapsule le protocole de données IP/User (l'encapsulation UDP)/L2F/PPP et envoie le paquet au NAS L2F — 1.1.1.2. Tout est normal en ce moment. Puis, au lieu d'envoyer le paquet par (par exemple) l'interface Ethernet, le Routage IP l'envoie par l'interface d'accès virtuelle de nouveau. C'est parce que la table de routage indique cela pour obtenir au NAS, il doit passer par le client. Ceci crée une boucle de routage et désactive efficacement l'entrée et sortie au-dessus du tunnel L2F.

Pour empêcher ceci, ne permettez pas à IPCP pour installer une route connectée sur le côté client.

Remarque: Ceci concerne seulement quand vous avez un certain protocole de routage IP s'exécutant entre le client et la passerelle domestique de Cisco.

La configuration de client est comme suit :

  int bri0

  no peer neighbor-route

Cartes de composeur sur le client

Quand le client compose à un environnement multichâssis, définissez toujours les numéroteurs à chaque gagnant potentiel de l'ensemble multiliaison. Par exemple, s'il y a quatre débarquent des serveurs dans la pile de multichassis, là devraient être quatre Cartes de composeur définies dans le côté client.

Exemple :

  client 1.1.1.1

  int bri0

  dialer map 1.1.1.3 ...

Dans cet exemple, 1.1.1.3 est juste un débarquent le serveur.

Un paquet destiné pour des artères de 1.1.1.2 au BRI, et le numéroteur compose la destination parce qu'il y a une correspondance de carte de numéroteur. Le serveur 1.1.1.4 de débarquement gagne réellement l'offre et la session PPP est projetée là. L'EIGRP est permuté entre le client et le serveur de débarquement. La table de Routage IP sur le client est remplie d'artère 1.1.1.4 (débarquez le serveur) à BRI0. Maintenant, sur le client, un paquet destiné pour 1.1.1.4 est conduit à BRI0. Le numéroteur, cependant, ne peut pas composer car il n'y a aucune correspondance de numéroteur.

Remarque: Définissez toujours les Cartes de composeur pour tous les gagnants d'offre du potentiel SGBP sur des clients toutes les fois qu'accéder aux serveurs de débarquement est une condition requise des clients.

Configuration et restrictions

  • La j-image d'entreprise est exigée pour la député britannique de multichassis.

  • Seulement un groupe de pile peut être défini pour chaque serveur d'accès.

  • les liens WAN de Haute-latence entre les membres de pile, entraînant le réassemblage de député britannique retarde, peut rendre la député britannique de multichassis inefficace.

  • Des interfaces sont prises en charge pour le PRI, [M] BRI, interface série, et appareils asynchrones.

  • Dialout n'est pas pris en charge.

Configuration des configurations d'interface de Par-Protocol

À toutes fins pratiques, ne configurez pas une adresse spécifique de protocole sur le modèle virtuel.

  interface virtual-template 1

  ip address 1.1.1.2 255.0.0.0

  :

L'interface de modèle virtuel sert de modèle duquel un certain nombre d'interfaces d'accès virtuelles sont dynamiquement copiées. Vous ne devriez pas spécifier une adresse de Protocol-particularité de par-interface à l'interface de modèle virtuel. Puisqu'une adresse IP doit être seule pour chaque interface réseau, spécifier une adresse IP unique sur l'interface de modèle virtuel est erroné. Au lieu de cela, faites ce qui suit :

  interface virtual-template 1

  ip unnum e0

  :

Configuration des configurations globales de Protocol

Un client qui introduit dans un routeur simple d'accès et s'attend à ce que le serveur d'accès ait une seule adresse globale (telle que le DECNet) maintenant compose réellement au groupe de pile de multilink de multichassis se composant de plusieurs serveurs d'accès. Dans ce genre de situation, terminez le groupe de pile de manière déterministe à un unique serveur d'accès. Pour faire cela, émettre le sgbp seed-bid débarquent la commande sur le serveur d'accès indiqué (ou spécifiez l'offre la plus élevée).

Dépannage

La première chose à faire si vous avez des problèmes est de retourner à un membre de pile simple, désactivant tous autres membres de pile. Alors testez vos connexions de ppp multilink et passez par l'authentification et la configuration d'interface habituelles de protocole d'authentification CHAP (Challenge Handshake Authentication Protocol) pour des erreurs dans la configuration et ainsi de suite. Quand vous lui êtes satisfait que fonctionne, activez les autres membres de pile, alors opérez comme suit :

  1. Assurez-vous que SGBP est en service.

  2. Multilink de debug ppp.

  3. Debug VPN et L2F.

La vérification de SGBP est en service correctement

Émettez la commande de show sgbp de s'assurer que tous les Etats membres sont EN ACTIVITÉ. Autrement, regardez pour l'INACTIF, l'AUTHOK, ou les états active. Comme mentionné précédemment, l'INACTIF est un état valide pour tous les membres de la pile distante qui sont intentionnellement inactifs.

Si vous trouvez un problème comme décrit ci-dessus, activez le debug sgbp hellos et mettez au point la commande d'erreur de sgbp. L'authentification entre deux membres de pile, par exemple entre le systema et le systemb, devrait être comme suit (sur le systema) :

  systema# debug sgdp hellos

  %SGBP-7-CHALLENGE: Send Hello Challenge to systemb group stackq
  %SGBP-7-CHALLENGED: Hello Challenge message from member systemb (1.1.1.2)
  %SGBP-7-RESPONSE: Send Hello Response to systemb group stackq
  %SGBP-7-CHALLENGE: Send Hello Challenge to systemb group stackq
  %SGBP-7-RESPONDED: Hello Response message from member systemb (1.1.1.2)
  %SGBP-7-AUTHOK: Send Hello Authentication OK to member systemb (1.1.1.2)
  %SGBP-7-INFO: Addr = 1.1.1.2 Reference = 0xC347DF7
  %SGBP-5-ARRIVING: New peer event for member systemb

le systema envoie un défi de style de la CHAP et reçoit une réponse du systemb. De même, le systemb envoie un défi et reçoit une réponse du systema.

Si l'authentification échoue, vous voyez :

  %SGBP-7-AUTHFAILED - Member systemb failed authentication

Ceci signifie que le mot de passe distant de systemb pour le stackq n'apparie pas le mot de passe défini sur le systema.

  %SGBP-7-NORESP -Fail to respond to systemb group stackq, may not have password

Ceci signifie que le systema n'a pas un nom d'utilisateur ou mot de passe défini localement ou par TACACS+.

Définissez généralement un secret commun à travers tous les membres de pile pour le stackq de groupe de pile. Vous pouvez les définir localement ou par TACACS+.

Un nom d'utilisateur local défini sur chaque membre de pile est :

  username stackq password blah

Ce secret commun est de faciliter le membre de pile offre et arbitrage SGBP.

Référez-vous à la section de ppp multilink d'élimination des imperfections de ce document pour un examen de l'authentification de lien de PPP quand un client distant se connecte aux membres de pile.

Dans le cas des problèmes de câblage ou de routage, une erreur commune a l'adresse IP source du membre de pile (qui est reçue réellement dans le message Hello SGBP) différente de l'adresse IP localement définie pour le même membre de pile.

  systema#debug sgbp error
  %SGBP-7-DIFFERENT - systemb's addr 1.1.1.2 is different from hello's addr 3.3.4.5

Ceci signifie que l'adresse IP source du SGBP bonjour reçu du systemb n'apparie pas l'adresse IP configurée localement pour le systemb (par l'ordre de sgbp member). Corrigez ceci en allant au systemb et en vérifiant les plusieurs interfaces par lesquelles le SGBP bonjour peut transmettre le message.

Une autre cause classique pour des erreurs est :

  %SGBP-7-MISCONF, Possible misconfigured member routerk (1.1.1.6)

Ceci signifie que vous ne faites pas définir le systemk localement, mais un autre membre de pile fait.

Ppp multilink de débogage

La première chose à vérifier est si le client et le membre de pile authentifiés sur le PPP correctement.

Cet exemple explique l'authentification CHAP, car il est plus impliqué. Comme exemple familier, il utilise une plate-forme de Cisco comme un client avec des noms d'utilisateur locaux (le Terminal Access Controller Access Control System Plus (TACACS+) est pris en charge également, mais n'est pas affiché ici).

Userx de client Chaque membre de stackq de pile
#config

username stackq password blah
#config

username userx password blah

Aucune interfaces de numérotation impliquées

Puisqu'il n'y a aucune interface de numérotation sur le serveur de débarquement, il faut une autre source de configuration d'interface des interfaces d'accès virtuelles. La réponse est des interfaces de modèle virtuel.

  1. Assurez-vous d'abord que le nombre virtuel global de modèle de multilink est défini sur chaque membre de pile.

      #config
      Multilink virtual-template 1
    
  2. Si vous n'avez configuré aucune interface de numérotation pour les interfaces physiques en question (tel que le PRI, le BRI, asynchrones, et interface série synchrone), vous pouvez définir :

      interface virtual-template 1
      ip unnumbered e0
      ppp authen chap
      ppp Multilink
    

    Remarque: Vous ne définissez pas une adresse IP spécifique sur le modèle virtuel. C'est parce que des interfaces d'accès virtuelles projetées sont toujours copiées de l'interface de modèle virtuel. Si un lien ultérieur de PPP obtient également projeté à un membre de pile avec une interface d'accès virtuelle déjà copiée et active, vous avez les adresses IP identiques sur les deux interfaces virtuelles, faisant conduire incorrectement l'IP entre elles.

Interfaces de numérotation impliquées

Quand des numéroteurs sont configurés sur les interfaces physiques, il n'y a aucun besoin de spécifier une interface de modèle virtuel, parce que la configuration d'interface réside dans l'interface de numérotation. Dans ce cas, l'interface d'accès virtuelle agit en tant qu'interface passive, étayée entre l'interface de numérotation et les interfaces de membre associées avec l'interface de numérotation.

Remarque: L'interface de numérotation, le numéroteur 1, est affichée en session de ppp multilink comme suit :

  systema#show ppp Multilink
  Bundle userx 2 members, Master link is Virtual-Access4
  Dialer interface is Dialer1
  0 lost fragments, 0 reordered, 0 unassigned, 100/255 load
  0 discarded,  0 lost received, sequence 40/66 rcvd/sent
  members 2
  Serial0:4  
  systemb:Virtual-Access6    (1.1.1.1)

LCP et NCPs

Les états LCP sur toutes les interfaces de membre doivent être EN HAUSSE. IPCP, ATCP, et tout autre NCPs devraient être seulement sur l'interface de paquet.

La sortie de l'exposition international de l'interface Virtual-Access4 de paquet devrait lire comme suit :

  router#show int  Virtual-Access4
  Virtual-Access4 is up, line protocol is up 
          :
      LCP Open, Multilink Open
      Open: ipcp
              :

Toutes autres interfaces de membre devraient avoir l'exposition suivante international sortie :

  router# show int Serial0:4
  Serial0:4 is up, line protocol is up 
          :
  LCP Open, Multilink Open
  Closed:  ipcp

Débogage VPN/L2F

Activez ce qui suit :

  debug vpn event
  debug vpn error

Quand l'interface physique reçoit l'appel entrant et est maintenant expédiée au membre de la pile de destination, vous voyez ce qui suit :

  Serial0:21 VPN Forwarding 
  Serial0:21 VPN vpn_forward_user userx is forwarded

Sur le membre de la pile de destination, si vous voyez ce qui suit :

  Virtual-Access1 VPN PPP LCP not accepting rcv CONFACK
  Virtual-Access1 VPN PPP LCP not accepting sent CONFACK

Vérifiez alors votre définition de votre interface de modèle virtuel. Généralement, l'interface de modèle virtuel doit apparier les paramètres d'interface de PPP de l'interface physique qui a reçu un appel entrant.

Souvenez-vous la configuration minimale (utilisant le CHAP comme exemple) :

  #config
  multilink virtual template 4
  int virtual-template 4
  ip unnum e0
  encap ppp
  ppp authen chap 
  ppp Multilink

Vous pouvez voir ce qui suit :

Virtual-Access1 VPN PPP LCP accepted sent & rcv CONFACK

Si vous voyez le message ci-dessus, il signifie que L2F a avec succès projeté le lien de PPP du membre de pile qui a pris la première fois l'appel entrant au membre de pile où l'interface de paquet pour le même client réside (ou créera, comme dans le scénario de débarquement).

Une erreur commune est défectueuse de définir le nom d'utilisateur pour le nom commun de pile (stackq) ou ne pas apparier le mot de passe de pile sur tous les membres de pile.

Émettez la commande suivante :

  debug vpdn l2f-error

Les résultats de message suivant :

  L2F Tunnel authentication failed for stackq

Corrigez la correspondance de nom d'utilisateur et mot de passe sur chaque membre de pile dans ce cas.


Informations connexes


Document ID: 14945