Multichassis Multilink PPP (MMP) (2è partie)

Introduction

Ce document continue à décrire la prise en charge du protocole PPP multiliaison (MP) dans un environnement de pile ou multichâssis (parfois appelé MMP, pour le protocole PPP multiliaison multichâssis), sur les plates-formes de serveur d'accès de Cisco Systems.

Ce document est la deuxième partie d'un document en deux parties. Référez-vous à la première partie de ce document pour plus d'informations.

Conditions préalables

Les conditions requises pour ce document sont indiquées dans la première partie de ce document.

Exemples

AS5200 dans une pile (avec numéroteurs)

Lorsque des numéroteurs sont configurés sur les interfaces physiques, il n'est pas nécessaire de spécifier l'interface de modèle virtuel. L'interface d'accès virtuel agit comme une interface passive, appuyée entre l'interface de numérotation et les interfaces physiques associées à l'interface de numérotation.

En bref, vous devez uniquement définir le nom du groupe de piles, le mot de passe commun et les membres du groupe de piles de tous les membres de la pile. Aucune interface de modèle virtuel n'est définie, comme illustré dans 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 provient d'un contrôleur 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

Une fois l'interface de l'offre groupée créée, elle est clonée avec uniquement les commandes PPP de l'interface de numérotation. Les liaisons PPP projetées suivantes sont également clonées avec les commandes PPP de l’interface de numérotation. La Figure 3 montre comment l'interface de numérotation se trouve au-dessus de l'interface du bundle. Comparez-le à la Figure 2, dans laquelle il n'y a pas d'interface de numérotation.

Les interfaces PRI et BRI par défaut sont des interfaces de numérotation ; un PRI configuré sans numéroteur explicite (via la commande dialer rotatif) est toujours une interface de numérotation sur Serial0:23, comme illustré 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

Utilisation d'un serveur de déchargement

systema est désigné comme serveur de déchargement (à l'aide de la commande sgbp semences-bid). Tous les autres membres du groupe de piles doivent être définis avec la commande sgbp semences-bid default (ou, si vous ne définissez pas la commande graine-bid, elle est définie par défaut 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

Serveur de déchargement avec interfaces physiques

Si le serveur de déchargement désigné a également des interfaces physiques (par exemple, PRI) qui souhaitent desservir le même groupe de recherche telco que les autres membres de la pile, vous pouvez le configurer pour ce faire en combinant les configurations indiquées dans les sections de ce document intitulées AS5200 dans une pile (avec des numéroteurs) et à l'aide d'un serveur de déchargement.

Une liaison PPP projetée déchargée et ses interfaces de bundle reposent sur des modèles virtuels pour une source de configuration. Une connexion qui a la première liaison arrive sur un périphérique physique connecté à une interface de numérotation, et la source de configuration pour l'interface de l'offre groupée et toutes les liaisons PPP projetées suivantes est la configuration de l'interface de numérotation. Par conséquent, ces variations coexistent, en fonction du membre de pile sur lequel la première liaison arrive.

Cette configuration n'est pas recommandée en raison de la complexité des configurations requises sur les interfaces de numérotation et de modèle virtuel.

Interfaces asynchrones, série et autres non-numéroteurs

Bien que vous puissiez configurer des périphériques asynchrones et série en tant qu'interfaces de numérotation (dans ce cas, il revient à AS5200 dans une pile (avec numéroteurs), comme indiqué dans cette section de ce document), vous pouvez choisir de prendre en charge le multichâssis MP sans configuration de numérotation pour les interfaces asynchrones, série et autres non-numérotation. La source de toute configuration est ensuite définie dans l'interface de modèle virtuel, comme indiqué 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

Appel sortant à partir d'un multichâssis

Actuellement, la configuration multichâssis ne prend pas en charge la numérotation, car le protocole L2F (Layer 2 Forwarding) ne prend pas en charge la numérotation.

Par conséquent, il n'y a aucun moyen pour le serveur de déchargement (où une route est usurpée, sur un profil de numérotation, etc.) d'initier une numérotation sur le membre de pile frontal du même groupe de piles. Toutes les routes usurpées doivent être installées sur les membres de la pile frontale, car il s'agit de celles qui ont des connexions de numérotation physique (telles que PRI).

Voici quelques solutions de contournement :

• Lorsque la commande sgbp ppp-forward est exécutée sur le membre frontal de la pile, cela signifie que tous les appels multiliaison PPP et PPP sont automatiquement transférés au gagnant de l'offre du protocole SGBP (Stack Group Bidding Protocol), tel qu'un serveur de déchargement.

  Vous devez vous fier à la numérotation NAS (Network Access Server) et laisser la convergence de routage IP (IP uniquement) suivre son cours. Par exemple, pour composer le numéro 1.1.1.1, placez cette adresse dans l'instruction dialer map sur le NAS et placez une route 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
  

  Lorsque la numérotation se connecte à l'homologue distant, la connexion PPP est formée entre l'homologue distant et le serveur de déchargement. Le membre de la pile frontale est complètement ignoré. PPP sur le serveur de déchargement installe ensuite une route hôte vers l’homologue—1.1.1.1. À ce stade, le protocole de routage IP converge de vers la route hôte au niveau du serveur de déchargement, car la métrique de routage gravite la route là-bas.

  Remarque : la convergence du routage entraîne une latence.

• Lorsque la commande sgbp ppp-forward n'est pas définie sur le membre frontal de la pile, cela signifie que seuls les appels multiliaison PPP sont automatiquement transférés au gagnant de l'offre SGBP, tel qu'un serveur de déchargement. Ainsi, un numéroteur du membre frontal de la pile vers un homologue distant s'étend sur la connexion PPP entre le frontal et le pair distant, de la même manière que si le NAS ne faisait pas partie d'un groupe de piles.

  Remarque : Cela se produit tant que la connexion est PPP (et non PPP multiliaison).

Numérotation vers un multichâssis

Si le routage IP (tel que EIGRP (Enhanced Interior Gateway Routing Protocol) et OSPF (Open Shortest Path First)) circule entre le client et le membre de la pile qui finit par remporter l'offre (tel que le serveur de déchargement), voici quelques conseils à suivre :

Empêcher l'installation d'une route connectée côté client

Configurez le client 1.1.1.2 où 1.1.1.2 est l'adresse du NAS (le transitaire de trame transparent), comme indiqué ci-dessous.

  int bri0

  dialer map 1.1.1.2 ....

Si EIGRP, par exemple, s'exécute entre le client et le serveur de déchargement, la table de routage sur le serveur de déchargement indique que pour accéder à 1.1.1.2, la route doit passer par l'interface d'accès virtuel. En effet, le protocole PPP IP Control Protocol (IPCP) du côté client installe une route connectée 1.1.1.2 à l'interface BRI. Le protocole EIGRP annonce ensuite cette route au serveur de déchargement sur la session PPP (sur L2F). Le protocole EIGRP sur le serveur de déchargement indique donc que pour accéder à 1.1.1.2, il doit router vers le client—la route 1.1.1.1 du client est vers l'interface d'accès virtuel.

Maintenant, vous avez un paquet destiné au client 1.1.1.1. Le routage IP envoie le paquet à l’interface d’accès virtuelle. L’interface d’accès virtuel encapsule l’encapsulation UDP/L2F/PPP et envoie le paquet au NAS L2F—1.1.1.2. Tout est normal à ce stade. Ensuite, au lieu d’envoyer le paquet via (par exemple) l’interface Ethernet, le routage IP l’envoie à nouveau via l’interface d’accès virtuelle. En effet, la table de routage indique que pour accéder au NAS, il doit passer par le client. Cela crée une boucle de routage et désactive efficacement l'entrée et la sortie sur le tunnel L2F.

Pour éviter cela, n'autorisez pas IPCP à installer une route connectée côté client.

Remarque : ceci ne concerne que si un protocole de routage IP est exécuté entre le client et la passerelle domestique Cisco.

La configuration du client est la suivante :

  int bri0

  no peer neighbor-route

Cartes de numérotation sur le client

Lorsque le client compose un numéro vers un environnement multichâssis, définissez toujours les numéroteurs pour chaque gagnant potentiel du bundle multiliaison. Par exemple, s'il existe quatre serveurs de déchargement dans la pile multichâssis, quatre cartes de numérotation doivent être définies côté client.

Exemple :

  client 1.1.1.1

  int bri0

  dialer map 1.1.1.3 ...

Dans cet exemple, 1.1.1.3 n'est qu'un serveur de déchargement.

Un paquet destiné à 1.1.1.2 route vers l'accès de base et le numéroteur compose la destination car il existe une correspondance de mappage de numérotation. Le serveur de déchargement 1.1.1.4 remporte l'offre et la session PPP y est prévue. Le protocole EIGRP est échangé entre le client et le serveur de déchargement. La table de routage IP sur le client est remplie avec une route 1.1.1.4 (serveur de déchargement) vers BRI0. Maintenant, sur le client, un paquet destiné à 1.1.1.4 est routé vers BRI0. Cependant, le numéroteur ne peut pas composer, car il n'y a pas de correspondance de numérotation.

Remarque : Définissez toujours des cartes de numérotation pour tous les gagnants potentiels des soumissions SGBP sur les clients chaque fois que l'accès aux serveurs de déchargement est une exigence des clients.

Configuration et restrictions

• L'image j d'entreprise est requise pour le multichâssis MP.

• Un seul groupe de piles peut être défini pour chaque serveur d'accès.

• Les liaisons WAN à haute latence entre les membres de la pile, provoquant des retards de réassemblage des MP, peuvent entraîner une inefficacité des MP multichâssis.

• Les interfaces sont prises en charge pour les périphériques PRI, [M]BRI, série et asynchrones.

• La numérotation n'est pas prise en charge.

Configuration des configurations d’interface par protocole

À toutes fins pratiques, ne configurez pas d'adresse de protocole spécifique 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 à partir duquel un nombre quelconque d'interfaces d'accès virtuel sont clonées dynamiquement. Vous ne devez pas spécifier d'adresse spécifique à chaque protocole d'interface à l'interface de modèle virtuel. Étant donné qu'une adresse IP doit être unique pour chaque interface réseau, la spécification d'une adresse IP unique sur l'interface de modèle virtuel est erronée. Effectuez plutôt les opérations suivantes :

  interface virtual-template 1

  ip unnum e0

  :

Configuration des configurations globales de protocole

Un client qui se connecte à un seul routeur d'accès et attend du serveur d'accès qu'il ait une adresse globale unique (comme DECnet) compose désormais en fait le groupe de pile multiliaison multichâssis composé de plusieurs serveurs d'accès. Dans ce type de situation, terminez le groupe de pile de manière déterministe sur un seul serveur d'accès. Pour ce faire, émettez la commande sgbp semences-bid offload sur le serveur d'accès désigné (ou spécifiez la soumission la plus élevée).

Dépannage

La première chose à faire en cas de problème est de revenir à un seul membre de pile, en désactivant tous les autres membres de la pile. Testez ensuite vos connexions multiliaison PPP et passez par l'authentification CHAP (Challenge Handshake Authentication Protocol) habituelle et la configuration d'interface pour détecter les erreurs de configuration, etc. Une fois que vous êtes convaincu que cela fonctionne, activez les autres membres de la pile, puis procédez comme suit :

1. Assurez-vous que SGBP est opérationnel.

2. Débogage de multiliaison PPP.

3. Déboguer VPN et L2F.

S'assurer que SGBP fonctionne correctement

Exécutez la commande show sgbp pour vous assurer que tous les états membres sont ACTIFS. Sinon, recherchez les états IDLE, AUTHOK ou ACTIVE. Comme mentionné précédemment, IDLE 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 la commande debug sgbp hellos et debug sgbp error. L'authentification entre deux membres de la pile, par exemple entre systema et systembe, doit être la suivante (sur 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

systema envoie un défi de type CHAP et reçoit une réponse de system. De même, systembe envoie un défi et reçoit une réponse de systema.

Si l'authentification échoue, vous voyez :

  %SGBP-7-AUTHFAILED - Member systemb failed authentication

Cela signifie que le mot de passe system distant pour stackq ne correspond pas au mot de passe défini sur systema.

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

Cela signifie que systema n'a pas de nom d'utilisateur ou de mot de passe défini localement ou via TACACS+.

En général, définissez un secret commun à tous les membres de la pile pour la pile de groupe de piles. Vous pouvez les définir localement ou via TACACS+.

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

  username stackq password blah

Ce secret commun est de faciliter la soumission et l'arbitrage des membres de la pile SGBP.

Référez-vous à la section Débogage de multiliaison PPP de ce document pour une discussion sur l'authentification de liaison PPP lorsqu'un client distant se connecte aux membres de la pile.

Dans le cas de problèmes de câblage ou de routage, une erreur courante consiste à faire en sorte que l'adresse IP source du membre de la pile (qui est en fait reçue dans le message Hello SGBP) soit différente de l'adresse IP définie localement pour le même membre de la 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

Cela signifie que l'adresse IP source du Hello SGBP reçu de systembe ne correspond pas à l'adresse IP configurée localement pour systembe (via la commande sgbp member). Corrigez cela en accédant à system et en vérifiant les interfaces multiples par lesquelles le Hello SGBP peut transmettre le message.

Une autre cause courante d'erreur est :

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

Cela signifie que vous n'avez pas de système défini localement, mais un autre membre de pile le fait.

Débogage de multiliaison PPP

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

Cet exemple illustre l'authentification CHAP, car elle est plus impliquée. Par exemple, il utilise une plate-forme Cisco en tant que client avec les noms d'utilisateur locaux (TACACS+ (Terminal Access Controller Access Control System Plus) est également pris en charge, mais n'est pas indiqué ici).

#config

username stackq password blah

#config

username userx password blah

Aucune interface de numérotation impliquée

Comme il n'y a pas d'interface de numérotation sur le serveur de déchargement, il doit y avoir une autre source de configuration d'interface des interfaces d'accès virtuelles. La réponse est les interfaces de modèles virtuels.

1. Assurez-vous tout d'abord que le numéro de modèle virtuel global multiliaison 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 (telles que PRI, BRI, asynchrone et 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 d'adresse IP spécifique sur le modèle virtuel. En effet, les interfaces d'accès virtuel projetées sont toujours clonées à partir de l'interface de modèle virtuel. Si une liaison PPP suivante est également projetée à un membre de la pile avec une interface d'accès virtuel déjà clonée et active, vous avez des adresses IP identiques sur les deux interfaces virtuelles, ce qui entraîne une route erronée entre elles.

Interfaces de numérotation impliquées

Lorsque des numéroteurs sont configurés sur les interfaces physiques, il n'est pas nécessaire de spécifier une interface de modèle virtuel, car la configuration de l'interface réside dans l'interface de numérotation. Dans ce cas, l'interface d'accès virtuel agit en tant qu'interface passive, appuyée entre l'interface de numérotation et les interfaces membres associées à l'interface de numérotation.

Remarque : L'interface de numérotation Dialer 1 s'affiche dans la session multiliaison PPP 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 NCP

Les états LCP sur toutes les interfaces membres doivent être UP. Les protocoles IPCP, ATCP et autres protocoles NCP doivent être activés uniquement sur l'interface du bundle.

La sortie show int de l'interface de l'offre groupée Virtual-Access4 doit se lire comme suit :

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

Toutes les autres interfaces membres doivent avoir la sortie show int suivante :

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

Débogage de VPN/L2F

Activez les options suivantes :

  debug vpn event
  debug vpn error

Lorsque l'interface physique accepte l'appel entrant et est maintenant transférée au membre de la pile cible, les éléments suivants s'affichent :

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

Sur le membre de la pile cible, si les éléments suivants s'affichent :

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

Vérifiez ensuite la définition de votre interface de modèle virtuel. En règle générale, l'interface de modèle virtuel doit correspondre aux paramètres de l'interface PPP de l'interface physique qui a accepté un appel entrant.

Mémoriser la configuration minimale (en utilisant 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, cela signifie que L2F a correctement projeté la liaison PPP du membre de pile qui a pris l'appel entrant pour le membre de pile où réside l'interface de l'offre groupée pour le même client (ou va créer, comme dans le scénario de déchargement).

Une erreur courante est l'échec de la définition du nom d'utilisateur pour le nom de pile commun (stackq) ou l'absence de correspondance du mot de passe de la pile sur tous les membres de la pile.

Utilisez la commande suivante:

  debug vpdn l2f-error

Le message suivant s'affiche :

  L2F Tunnel authentication failed for stackq

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

Informations connexes

• Partie 1 du présent document
• Fonctionnalités PPP d'accès virtuel dans le logiciel Cisco IOS
• Présentation de VPDN
• Support technique - Cisco Systems