Multichassis Multilink PPP (MMP) (parte 2)

Introducción

Este documento continúa describiendo el soporte para PPP de links múltiples (MP) en un entorno de "pila" o de varios chasis (a veces llamado MMP, para PPP de links múltiples multichasis), en las plataformas de servidor de acceso de Cisco Systems.

Este documento es la segunda parte de un documento de dos partes. Consulte la primera parte de este documento para obtener más información.

Prerequisites

Los requisitos previos para este documento se dan en la primera parte de este documento.

Examples

AS5200 en Stack (con marcadores)

Cuando los marcadores se configuran en las interfaces físicas, no hay necesidad de especificar la interfaz de plantilla virtual en absoluto. La interfaz de acceso virtual actúa como una interfaz pasiva, apuntalada entre la interfaz del marcador y las interfaces físicas asociadas con la interfaz del marcador.

En resumen, sólo necesita definir el nombre del grupo de pila, la contraseña común y los miembros del grupo de pila en todos los miembros de la pila. No se define ninguna interfaz de plantilla virtual, como se muestra en el siguiente ejemplo:

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

El siguiente ejemplo proviene de un controlador 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

Después de que se crea la interfaz de agrupamiento, se clona con solamente los comandos PPP de la interfaz del marcador. Los links PPP proyectados subsiguientes también se clonan con los comandos PPP de la interfaz del marcador. La figura 3 muestra cómo la interfaz del marcador se encuentra en la parte superior de la interfaz del paquete. Compárelo con la Figura 2, en la que no hay interfaz de marcador.

Los PRI y BRI son de forma predeterminada interfaces de marcador; un PRI configurado sin un marcador explícito (a través del comando dialer rotary) sigue siendo una interfaz de marcador en Serial0:23, como se muestra en el siguiente ejemplo:

interface Serial0:23
  ip unnum e0
  dialer map .....
  encap ppp
  ppp authen chap
  dialer-group 1
  dialer rot 1
  ppp multilink

Uso de un servidor de descarga

systema se designa como servidor de descarga (mediante el comando sgbp seed-bid). Todos los demás miembros del grupo de pila deben definirse con el comando sgbp seed-bid default (o, si no define el comando gbp seed-bid, lo predeterminado es esto).

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

Servidor de descarga con interfaces físicas

Si el servidor de descarga designado también tiene interfaces físicas (por ejemplo, PRI) que desean servir al mismo grupo de búsqueda de la compañía telefónica que los otros miembros de la pila, puede configurarlo para hacerlo combinando las configuraciones mostradas en las secciones de este documento titulado AS5200 en una pila (con marcadores) y usando un servidor de descarga.

Un link PPP proyectado descargado y sus interfaces de agrupamiento dependen de las plantillas virtuales para un origen de configuración. Una conexión que tiene el primer link llega a un dispositivo físico conectado a una interfaz de marcador, y el origen de la configuración para la interfaz de agrupamiento y todos los links PPP proyectados subsiguientes es la configuración de la interfaz del marcador. Por lo tanto, estas variaciones coexisten, según el miembro de la pila al que llega el primer link.

Esta configuración no se recomienda debido a la complejidad de las configuraciones requeridas en las interfaces del marcador y de la plantilla virtual.

Interfaces asíncronas, seriales y de no marcador

Aunque puede configurar dispositivos asíncronos y seriales como interfaces de marcador (en cuyo caso vuelve a AS5200 en una pila (con marcadores), como se muestra en esa sección de este documento), puede optar por admitir MP de varios chasis sin ninguna configuración de marcador para interfaces asíncronas, seriales y otras interfaces que no sean de marcador. El origen de toda la configuración se define luego en la interfaz de plantilla virtual, como se muestra a continuación.

#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

Llamadas salientes desde un Multichassis

Actualmente, la configuración de varios chasis no admite el marcado de salida, porque el protocolo de reenvío de capa 2 (L2F) no admite el marcado de salida.

En consecuencia, no hay manera de que el servidor de descarga (donde se falsifica una ruta, en un perfil de marcador, etc.) inicie una marcación en el miembro de pila de extremo frontal en el mismo grupo de pila. Las rutas simuladas se deben instalar en los miembros de la pila frontal, porque son las que tienen las conexiones de marcación física (como PRI).

Algunas soluciones son las siguientes:

• Cuando se ejecuta el comando sgbp ppp-forward en el miembro de pila frontal, esto significa que todas las llamadas PPP y PPP multilink se reenvían automáticamente al ganador de la licitación del protocolo de puja de grupo de pila (SGBP), como un servidor de descarga.

  Debe confiar en que el servidor de acceso a la red (NAS) marque y deje que la convergencia de routing IP (solo para IP) siga su curso. Por ejemplo, para marcar 1.1.1.1, coloque esta dirección en la sentencia dialer map en el NAS y coloque una ruta estática en el NAS, de la siguiente manera:

    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
  

  Cuando la marcación se conecta al par remoto, la conexión PPP se forma entre el par remoto y el servidor de descarga. El miembro de la pila frontal se omite por completo. PPP en el servidor de descarga instala luego una ruta de host al par—1.1.1.1. En este punto, el protocolo de ruteo IP converge de a la ruta host en el servidor de descarga porque la métrica de ruteo gravita la ruta allí.

  Nota: La convergencia de routing da como resultado latencia.

• Cuando el comando sgbp ppp-forward no se define en el miembro de pila de front-end, esto significa que solamente las llamadas multilink PPP se reenvían automáticamente al ganador de la puja SGBP, como un servidor de descarga. Por lo tanto, un marcador del miembro de la pila frontal a un peer remoto expande la conexión PPP entre el peer frontal y el peer remoto, el mismo comportamiento que si el NAS no fuera parte de un grupo de la pila.

  Nota: Esto sucede siempre que la conexión sea PPP recta (y no multilink PPP).

Llamada a un Multichassis

Si tiene un routing IP (como Enhanced Interior Gateway Routing Protocol (EIGRP) y Open Shortest Path First (OSPF)) que fluye entre el cliente y el miembro de la pila que finalmente gana la oferta (como el servidor de descarga), a continuación le ofrecemos algunos consejos:

Impedir la instalación de una ruta conectada en el lado del cliente

Configure el cliente 1.1.1.2 donde 1.1.1.2 es la dirección del NAS (el reenvío de tramas transparente), como se muestra a continuación.

  int bri0

  dialer map 1.1.1.2 ....

Si tiene EIGRP, por ejemplo, ejecutándose entre el cliente y el servidor de descarga, la tabla de ruteo en el servidor de descarga indica que para llegar a 1.1.1.2 la ruta debe pasar a través de la interfaz de acceso virtual. Esto se debe a que el protocolo de control IP PPP (IPCP) del lado del cliente instala una ruta conectada 1.1.1.2 a la interfaz BRI. EIGRP luego anuncia esta ruta al servidor de descarga a través de la sesión PPP (sobre L2F). EIGRP en el servidor de descarga indica entonces que para llegar a 1.1.1.2, debería rutear al cliente—la ruta 1.1.1.1 del cliente es a la interfaz de acceso virtual.

Ahora, tiene un paquete destinado al cliente 1.1.1.1. IP Routing envía el paquete a la interfaz de acceso virtual. La interfaz de acceso virtual encapsula la encapsulación de protocolo de datos de usuario/IP (UDP)/L2F/PPP y envía el paquete al NAS L2F—1.1.1.2. Todo es normal en este momento. A continuación, en lugar de enviar el paquete a través (por ejemplo) de la interfaz Ethernet, el routing IP lo envía de nuevo a través de la interfaz de acceso virtual. Esto se debe a que la tabla de ruteo indica que para llegar al NAS, debe atravesar el cliente. Esto crea un loop de ruteo y deshabilita de manera efectiva la entrada y salida sobre el túnel L2F.

Para evitar esto, no permita que IPCP instale una ruta conectada en el lado del cliente.

Nota: Esto sólo se aplica cuando se ejecuta algún protocolo de ruteo IP entre el cliente y Cisco Home Gateway.

La configuración del cliente es la siguiente:

  int bri0

  no peer neighbor-route

Mapas del marcador en el cliente

Cuando el cliente marca a un entorno de varios chasis, defina siempre los marcadores para cada posible ganador del paquete de links múltiples. Por ejemplo, si hay cuatro servidores de descarga en la pila de varios chasis, debería haber cuatro mapas de marcador definidos en el lado del cliente.

Por ejemplo:

  client 1.1.1.1

  int bri0

  dialer map 1.1.1.3 ...

En este ejemplo, 1.1.1.3 es sólo un servidor de descarga.

Un paquete destinado a 1.1.1.2 rutea al BRI, y el marcador marca el destino porque hay una coincidencia de correspondencia de marcador. El servidor de descarga 1.1.1.4 gana realmente la oferta y la sesión PPP se proyecta allí. EIGRP se intercambia entre el cliente y el servidor de descarga. La tabla de IP Routing en el cliente se llena con una ruta 1.1.1.4 (servidor de descarga) a BRI0. Ahora, en el cliente, un paquete destinado a 1.1.1.4 se rutea a BRI0. El marcador, sin embargo, no puede marcar porque no hay coincidencia de marcador.

Nota: Defina siempre mapas de marcador para todos los posibles ganadores de ofertas SGBP en los clientes siempre que el acceso a los servidores de descarga sea un requisito de los clientes.

Configuración y restricciones

• La imagen j empresarial es necesaria para MP de varios chasis.

• Sólo se puede definir un grupo de pila para cada servidor de acceso.

• Los enlaces WAN de alta latencia entre los miembros de la pila, lo que provoca retrasos en el reensamblado de MP, puede provocar que el MP de varios chasis sea ineficiente.

• Las interfaces son compatibles con dispositivos PRI, [M]BRI, seriales y asincrónicos.

• No se admite la marcación saliente.

Especificación de configuraciones de interfaz por protocolo

Para todos los fines prácticos, no configure una dirección de protocolo específica en la plantilla virtual.

  interface virtual-template 1

  ip address 1.1.1.2 255.0.0.0

  :

La interfaz de plantilla virtual funciona como una plantilla a partir de la cual se clona dinámicamente cualquier número de interfaces de acceso virtual. No debe especificar una dirección específica de protocolo por interfaz para la interfaz de plantilla virtual. Debido a que una dirección IP debe ser única para cada interfaz de red, especificar una dirección IP única en la interfaz de plantilla virtual es erróneo. En su lugar, haga lo siguiente:

  interface virtual-template 1

  ip unnum e0

  :

Especificación de configuraciones de protocolos globales

Un cliente que marca en un único router de acceso y espera que el servidor de acceso tenga una dirección global única (como DECnet) ahora marca al grupo de pila multilink de varios chasis formado por varios servidores de acceso. En este tipo de situación, finalice el grupo de pila determinísticamente en un único servidor de acceso. Para hacerlo, ejecute el comando sgbp seed-bid offload en el servidor de acceso designado (o especifique la oferta más alta).

Resolución de problemas

Lo primero que hay que hacer si hay problemas es volver a un único miembro de la pila, desactivando todos los demás miembros de la pila. A continuación, pruebe las conexiones multilink PPP y pase por la autenticación habitual del protocolo de autenticación por desafío mutuo (CHAP) y la configuración de la interfaz para detectar errores en la configuración, etc. Cuando esté satisfecho de que funcione, active los demás miembros de la pila y, a continuación, continúe de la siguiente manera:

1. Asegúrese de que SGBP está en funcionamiento.

2. Debug PPP multilink.

3. Debug VPN y L2F.

Asegurar que SGBP está activa y funcionando correctamente

Ejecute el comando show sgbp para asegurarse de que todos los estados miembros estén ACTIVOS. De lo contrario, busque los estados IDLE, AUTHOK o ACTIVE. Como se mencionó anteriormente, IDLE es un estado válido para todos los miembros de pila remotos que están intencionalmente inactivos.

Si encuentra un problema como se describe anteriormente, active el comando debug sgbp hellos y debug sgbp error. La autenticación entre dos miembros de la pila, por ejemplo entre systema y systembajb, debe ser la siguiente (en 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 envía un desafío al estilo CHAP y recibe una respuesta de systembajb. De manera similar, systembajb envía un desafío y recibe una respuesta de systema.

Si falla la autenticación, verá:

  %SGBP-7-AUTHFAILED - Member systemb failed authentication

Esto significa que la contraseña remota del sistema para stackq no coincide con la contraseña definida en systema.

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

Esto significa que systema no tiene un nombre de usuario o una contraseña definidos localmente o a través de TACACS+.

En general, defina un secreto común en todos los miembros de la pila para la pila de grupo de pila. Puede definirlos localmente o a través de TACACS+.

Un nombre de usuario local definido en cada miembro de la pila es:

  username stackq password blah

Este secreto común es facilitar la licitación y el arbitraje de SGBP de los miembros de la pila.

Refiérase a la sección Debugging PPP Multilink de este documento para una discusión de la autenticación de link PPP cuando un cliente remoto marca a los miembros de la pila.

En el caso de problemas de cableado o ruteo, un error común es que la dirección IP de origen del miembro de la pila (que en realidad se recibe en el mensaje hello SGBP) sea diferente de la dirección IP definida localmente para el mismo miembro de la pila.

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

Esto significa que la dirección IP de origen del saludo de SGBP recibido del systembajb no coincide con la dirección IP configurada localmente para systembajb (a través del comando sgbp member). Corrija esto yendo a systembajb y comprobando las interfaces múltiples por las cuales el saludo SGBP puede transmitir el mensaje.

Otra causa común de errores es:

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

Esto significa que no tiene systemk definido localmente, pero sí lo tiene otro miembro de stack.

Depuración de múltiples links de PPP

Lo primero que hay que comprobar es si el cliente y el miembro de la pila se autenticaron correctamente en PPP.

Este ejemplo muestra la autenticación CHAP, ya que está más involucrada. Como ejemplo familiar, utiliza una plataforma de Cisco como cliente junto con nombres de usuario locales (también se admite Terminal Access Controller Access Control System Plus (TACACS+), pero no se muestra aquí).

#config

username stackq password blah

#config

username userx password blah

No hay interfaces de marcador involucradas

Dado que no hay interfaz de marcador en el servidor de descarga, debe haber otra fuente de configuración de interfaz de interfaces de acceso virtual. La respuesta son las interfaces de plantilla virtuales.

1. En primer lugar, asegúrese de que el número de plantilla virtual global multilink esté definido en cada miembro de la pila.

     #config
     Multilink virtual-template 1
   

2. Si no ha configurado ninguna interfaz de marcador para las interfaces físicas en cuestión (como PRI, BRI, asíncrono y serial síncrona), puede definir:

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

   Nota: No define una dirección IP específica en la plantilla virtual. Esto se debe a que las interfaces de acceso virtual proyectadas siempre se clonan desde la interfaz de plantilla virtual. Si un link PPP subsiguiente también se proyecta a un miembro de la pila con una interfaz de acceso virtual ya clonada y activa, tiene direcciones IP idénticas en las dos interfaces virtuales, lo que hace que IP rutee erróneamente entre ellas.

Interfaces del marcador involucradas

Cuando los marcadores se configuran en las interfaces físicas, no hay necesidad de especificar una interfaz de plantilla virtual, porque la configuración de la interfaz reside en la interfaz del marcador. En este caso, la interfaz de acceso virtual actúa como una interfaz pasiva, apuntalada entre la interfaz del marcador y las interfaces miembro asociadas con la interfaz del marcador.

Nota: La interfaz del marcador, Dialer 1, se muestra en la sesión multilink PPP de la siguiente manera:

  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 y NCP

Los estados LCP en todas las interfaces miembro deben ser UP. IPCP, ATCP y otros NCP deben estar activos solamente en la interfaz del paquete.

La interfaz del paquete Virtual-Access4 show int output debe ser la siguiente:

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

Todas las demás interfaces miembro deben tener el siguiente resultado show int:

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

Depuración de VPN/L2F

Active lo siguiente:

  debug vpn event
  debug vpn error

Cuando la interfaz física acepta la llamada entrante y ahora se reenvía al miembro de la pila de destino, verá lo siguiente:

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

En el miembro de la pila de destino, si ve lo siguiente:

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

A continuación, compruebe la definición de la interfaz de plantilla virtual. Generalmente, la interfaz de plantilla virtual debe coincidir con los parámetros de interfaz PPP de la interfaz física que aceptó una llamada entrante.

Recuerde la configuración mínima (utilizando CHAP como ejemplo):

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

Puede ver lo siguiente:

Virtual-Access1 VPN PPP LCP accepted sent & rcv CONFACK

Si ve el mensaje anterior, significa que L2F ha proyectado correctamente el link PPP desde el miembro de la pila que primero llevó la llamada entrante al miembro de la pila donde reside la interfaz del paquete para el mismo cliente (o creará, como en el escenario de descarga).

Un error común es no definir el nombre de usuario para el nombre de pila común (stackq) o no coincidir con la contraseña de pila en todos los miembros de la pila.

‘Ejecute el siguiente comando:

  debug vpdn l2f-error

Los siguientes resultados del mensaje:

  L2F Tunnel authentication failed for stackq

Corrija la coincidencia de nombre de usuario y contraseña en cada miembro de pila en este caso.

Información Relacionada

• Parte 1 de este documento
• Funciones PPP de Acceso Virtual en Cisco IOS Software
• Introducción a VPDN’
• Soporte Técnico - Cisco Systems

Historial de revisiones