WAN : Protocolo punto a punto (PPP)

Multilink de multichasis PPP (MMP) (parte 2)

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


Introducción

Este documento continúa describiendo el soporte para el multilink ppp (MP) en un “stack” o el entorno de chasis múltiples (a veces llamado MMP, para el multilink de multichasis PPP), en las plataformas del Access Server de Cisco Systems.

Este documento es parte dos de un documento bipartito. Refiera a la parte una de este documento para más información.

prerrequisitos

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

Ejemplos

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 interfaz pasiva, reforzada entre la interfaz del dialer y las interfaces físicas asociadas a la interfaz del dialer.

En fin, usted necesita solamente definir el nombre del grupo de pila, la contraseña común, y a los miembros del grupo Stack a través de todos los miembros de pila. No se define ninguna interfaz de plantilla virtual, tal y como se muestra en del 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 es de 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 cree el bundle interface, se reproduce con solamente los comandos PPP de la interfaz del dialer. Los links PPP proyectados subsiguientes también se reproducen con los comandos PPP de la interfaz del dialer. El cuadro 3 muestra cómo la interfaz del dialer se sienta encima del bundle interface. Compárelo con el cuadro 2, en el cual no hay interfaz del dialer.

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

interface Serial0:23
  ip unnum e0
  dialer map .....
  encap ppp
  ppp authen chap
  dialer-group 1
  dialer rot 1
  ppp multilink
Figura 3: Un grupo de pila – stackq – consistir en el systema, el systemb, y el systemc. el link de los systema se configura en la interfaz del dialer.

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

Uso de un servidor de descarga

el systema se señala un Servidor de descarga (usando el comando sgbp seed-bid). El resto de los miembros del grupo Stack deben ser definidos con el comando default de la germen-oferta del sgbp (o, si usted no define el comando de la germen-oferta del thesgbp, omite 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
Figura 4: systema como Servidor de descarga.

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

Servidor de descarga con interfaces físicas

Si el Servidor de descarga señalado también tiene interfaces físicas (por ejemplo, PRI) deseando servir al mismo grupo Hunt de la compañía telefónica que los otros miembros de pila, usted puede configurarlo para hacer tan combinando las configuraciones mostradas en las secciones de este documento titulado AS5200 en un stack (con los marcadores) y usando a un Servidor de descarga.

Un link PPP proyectado descargado y sus interfaces del conjunto confían en las plantillas virtuales para una fuente de configuración. Una conexión que tiene el primer link llega un dispositivo físico conectado con una interfaz del dialer, y la fuente de la configuración para el bundle interface y todos los links PPP proyectados subsiguientes es la configuración de la interfaz del dialer. Por lo tanto, estas variaciones coexisten, dependiente sobre el miembro de pila en quien el primer link llega.

Esta configuración no es recomendado debido a la complejidad de las configuraciones requeridas en el marcador y las interfaces de plantilla virtual.

Interfaces asíncronas, seriales y de no marcador

Mientras que usted puede configurar asíncrono y los dispositivos en serie como interfaces del dialer (en este caso invierte al AS5200 en un stack (con los marcadores), tal y como se muestra en de esa sección de este documento), usted puede elegir soportar Multichassis MP sin ninguna configuración del dialer para asíncrono, serial, y otras interfaces de no dialer. La fuente de toda la configuración entonces se define en la interfaz de plantilla virtual, como se muestra abajo.

#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 del chasis múltiple no soporta el dialout, porque el protocolo de la expedición de la capa 2 (L2F) no soporta el dialout.

Por lo tanto, no hay manera para el Servidor de descarga (donde está spoofed una ruta, en un perfil de marcado, y así sucesivamente) de iniciar un dial en el miembro de pila de extremo frontal en el mismo grupo de pila. Cualquier ruta del spoofed se debe instalar en el miembros de pila de extremo frontal, porque éstos son los que está con las conexiones de marcado físicas (tales como PRI).

Algunas soluciones alternativas son como sigue:

  • Cuando publican el comando sgbp ppp-forward en el miembro de pila de extremo frontal, éste significa que todas las llamadas PPP y del multilink PPP están remitidas automáticamente al ganador hecho una oferta del protocolo stack group bidding (SGBP), tal como un Servidor de descarga.

    Usted tiene que confiar en el servidor de acceso a la red (NAS) que marca hacia fuera y deje la convergencia del Routing IP (para el IP solamente) toman su curso. Por ejemplo, para marcar 1.1.1.1, ponga este direccionamiento en la sentencia del mapa de marcado en el NAS y ponga una Static ruta en el NAS, como sigue:

      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 el dial conecta con el peer remoto, la conexión PPP se forma entre el peer remoto y el Servidor de descarga. Desvían al miembro de pila de extremo frontal totalmente. El PPP en el Servidor de descarga entonces instala una ruta del host al par — 1.1.1.1. En este momento, el IP Routing Protocol converge a la ruta del host en el Servidor de descarga porque la métrica de ruteo gravita la ruta allí.

    Nota: Rutear los resultados de la convergencia en el tiempo de espera.

  • Cuando no definen al comando sgbp ppp-forward en el miembro de pila de extremo frontal, éste significa que solamente las llamadas del multilink PPP están remitidas automáticamente al ganador de la licitación SGBP, tal como un Servidor de descarga. Así, un marcador del miembro de pila de extremo frontal a un peer remoto atraviesa la conexión PPP entre el frontal y el peer remoto — el mismo comportamiento como si el NAS no fuera parte de al grupo de pila.

    Nota: Esto sucede mientras la conexión sea PPP recto (y no multilink PPP).

Llamada a un Multichassis

Si usted tiene Routing IP (tal como Enhanced Interior Gateway Routing Protocol (EIGRP) y Open Shortest Path First (OSPF)) están fluyendo entre el cliente y el miembro de pila que gana eventual la oferta (tal como el Servidor de descarga), aquí algunas extremidades a seguir:

Evite el instalar de un Routeconectad en el lado del cliente

Configure al cliente 1.1.1.2 donde está el direccionamiento 1.1.1.2 del NAS (el trama-promotor transparente), como se muestra abajo.

  int bri0

  dialer map 1.1.1.2 ....

Si usted tiene EIGRP, por ejemplo, el ejecutarse entre el cliente y el Servidor de descarga, la tabla de ruteo en el Servidor de descarga indica que eso conseguir a 1.1.1.2 la ruta debe pasar a través de la interfaz de acceso virtual. Esto es porque el protocolo ppp ip control (IPCP) en el lado del cliente instala un Routeconectad 1.1.1.2 a la interfaz BRI. El EIGRP entonces hace publicidad de esta ruta al Servidor de descarga sobre la sesión PPP (sobre el L2F). El EIGRP en el Servidor de descarga indica así eso para conseguir a 1.1.1.2, él debe rutear al cliente — la ruta 1.1.1.1 del cliente está a la interfaz de acceso virtual.

Ahora, usted tiene un paquete destinado para el cliente 1.1.1.1. El Routing IP envía el paquete a la interfaz de acceso virtual. La interfaz de acceso virtual encapsula el protocolo de datos IP/User (la encapsulación UDP)/L2F/PPP y envía el paquete al L2F NAS — 1.1.1.2. Todo es normal en este momento. Entonces, en vez de mandar el paquete a través (por ejemplo) de la interfaz de Ethernet, el Routing IP la envía a través de la interfaz de acceso virtual otra vez. Esto es porque la tabla de ruteo indica eso para conseguir al NAS, él debe pasar a través del cliente. Esto crea un Routing Loop y inhabilita con eficacia la entrada y salida sobre el túnel L2F.

Para prevenir esto, no permita que el IPCP instale un Routeconectad en el lado del cliente.

Nota: Esto pertenece solamente cuando usted tiene cierto IP Routing Protocol que se ejecuta entre el cliente y el gateway de inicio de Cisco.

La configuración del cliente es como sigue:

  int bri0

  no peer neighbor-route

Mapas de marcado en el cliente

Cuando el cliente está marcando a un entorno de chasis múltiples, defina siempre los marcadores a cada ganador potencial del agrupamiento de links múltiples. Por ejemplo, si hay cuatro Servidores de descarga en el stack del multichassis, allí debe ser cuatro Mapas de marcado 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 apenas un Servidor de descarga.

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

Nota: Defina siempre los Mapas de marcado para todos los potenciales ganadores de la licitación SGBP en los clientes siempre que acceder a los Servidores de descarga sea un requisito de los clientes.

Configuración y restricciones

  • La j-imagen de la empresa se requiere para Multichassis MP.

  • Solamente un grupo de pila puede ser definido para cada servidor de acceso.

  • Los links PÁLIDOS de la Latencia alta entre los miembros de pila, causando los retardos del nuevo ensamble MP, pueden hacer Multichassis MP ser ineficaces.

  • Las interfaces se soportan para el PRI, el [M] BRI, el serial, y los dispositivos asíncronos.

  • El dialout no se soporta.

Especificación de configuraciones de interfaz por protocolo

En realidad, no configure a 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 sirve como plantilla de la cual cualquier número de interfaces de acceso virtual se reproduzca dinámicamente. Usted no debe especificar un direccionamiento del protocol específico del por interface a la interfaz de plantilla virtual. Porque una dirección IP debe ser única para cada interfaz de la red, especificar un IP Address único en la interfaz de plantilla virtual es erróneo. En lugar, haga el siguiente:

  interface virtual-template 1

  ip unnum e0

  :

Especificación de configuraciones de protocolos globales

Un cliente que marca en un solo router de acceso y ahora espera que el servidor de acceso tenga una dirección global única (tal como DECNet) marca realmente al grupo de pila del multilink de multichasis que consiste en vario Access Servers. En este tipo de situación, termine al grupo de pila determinista en un único servidor de acceso. Para hacer eso, publicar el comando sgbp seed-bid offload en el servidor de acceso señalado (o especificar la oferta más alta).

Resolución de problemas

La primera cosa a hacer si usted tiene problemas es volver a un solo miembro de pila, inhabilitando al resto de los miembros de pila. Después pruebe sus conexiones de links múltiples PPP y pase con la autenticación y la configuración de la interfaz usuales del Challenge Handshake Authentication Protocol (CHAP) para los errores en configuración y así sucesivamente. Cuando le satisfacen trabaja, habilita a los otros miembros de pila, después sigue de la forma siguiente:

  1. Aseegurese el SGBP es en servicio.

  2. Haga el debug del multilink PPP.

  3. Haga el debug del VPN y el L2F.

Asegurar que SGBP está activa y funcionando correctamente

Publique el comando show sgbp de aseegurarse que todos los estados miembros son ACTIVOS. Si no, mire hacia fuera para la MARCHA LENTA, el AUTHOK, o los estados ACTIVOS. Según lo mencionado previamente, la MARCHA LENTA es un estado válido para todos los miembros de pila remotos que estén intencionalmente inactivos.

Si usted encuentra un problema como se describe anteriormente, gire el debug sgbp hellos y el comando debug sgbp error. La autenticación entre dos miembros de pila, por ejemplo entre el systema y el systemb, debe estar como sigue (en el 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

el systema envía un desafío del Grieta-estilo y recibe una respuesta del systemb. Semejantemente, el systemb envía un desafío y recibe una respuesta del systema.

Si la autenticación falla, usted ve:

  %SGBP-7-AUTHFAILED - Member systemb failed authentication

Esto significa que el contraseña del sistema “b” para el stackq no hace juego la contraseña definida en el systema.

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

Esto significa que el systema no tiene un nombre de usuario o una contraseña definida localmente o con el TACACS+.

Defina generalmente un secreto común a través de todos los miembros de pila para el stackq del grupo de pila. Usted puede definirlos localmente o con el TACACS+.

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

  username stackq password blah

Este secreto común es facilitar arbitraje y licitación SGBP de miembro pila.

Refiera a la sección del multilink PPP del debugging de este documento para una discusión de la autenticación del link PPP cuando un cliente remoto marca adentro a los miembros de pila.

En el caso del cableado o de los problemas de ruteo, un error común está teniendo la dirección IP de origen del miembro de pila (que se recibe realmente en el mensaje de los saludos SGBP) diferente de la dirección IP localmente definida para el mismo miembro de 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 de los saludos SGBP recibidos del systemb no hace juego la dirección IP configurada localmente para el systemb (a través del comando sgbp member). Corrija esto yendo al systemb y marcando para saber si hay interfaces múltiples por las cuales los saludos SGBP puedan transmitir el mensaje.

Otra causa común para los errores es:

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

Esto significa que usted no hace el systemk definir localmente, pero otro miembro de pila hace.

Depuración de múltiples links de PPP

La primera cosa a marcar es si el cliente y el miembro de pila autenticados en el PPP correctamente.

Este ejemplo demuestra la autenticación CHAP, pues está más implicado. Como ejemplo conocido, utiliza una Plataforma de Cisco como un cliente junto con los nombres de usuario local (el Terminal Access Controller Access Control System más (TACACS+) se soporta también, pero no se muestra aquí).

Userx del cliente Cada miembro del stackq del stack
#config

username stackq password blah
#config

username userx password blah

Ningunas interfaces del dialer implicadas

Puesto que no hay interfaz del dialer en el Servidor de descarga, necesita ser otra fuente de configuración de la interfaz de las interfaces de acceso virtual. La respuesta es interfaces de plantilla virtual.

  1. Primero aseegurese el número de la plantilla virtual global del multilink se define en cada miembro de pila.

      #config
      Multilink virtual-template 1
    
  2. Si usted no ha configurado ninguna interfaces del dialer para las interfaces físicas en la pregunta (tal como PRI, BRI, asíncrono, y sincro'nico serial), usted puede definir:

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

    Nota: Usted no define una dirección IP específica en la plantilla virtual. Esto es porque las interfaces de acceso virtual proyectadas se reproducen siempre de la interfaz de plantilla virtual. Si un link PPP subsiguiente también consigue proyectado a un miembro de pila con una interfaz de acceso virtual reproducida ya y activa, usted tiene IP Addresses idénticos en las dos interfaces virtuales, haciendo el IP rutear erróneamente entre ellas.

Interfaces del dialer implicadas

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 dialer. En este caso, la interfaz de acceso virtual actúa como interfaz pasiva, reforzada entre la interfaz del dialer y las interfaces de miembro asociadas a la interfaz del dialer.

Nota: La interfaz del dialer, Dialer1, se visualiza en la sesión de link múltiple PPP como sigue:

  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 de miembro deben estar PARA ARRIBA. El IPCP, el ATCP, y otros NCP deben estar para arriba solamente en el bundle interface.

La salida de la demostración internacional del bundle interface Virtual-Access4 debe leer como sigue:

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

El resto de las interfaces de miembro deben tener la demostración siguiente internacional hecha salir:

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

Depuración de VPN/L2F

Gire el siguiente:

  debug vpn event
  debug vpn error

Cuando la interfaz física valida la llamada entrante y ahora se remite al miembro de pila de destino, usted ve el siguiente:

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

En el miembro de pila de destino, si usted ve el siguiente:

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

Entonces marque su definición de su interfaz de plantilla virtual. Generalmente, la interfaz de plantilla virtual debe hacer juego los parámetros de interfaz PPP de la interfaz física que validó una llamada entrante.

Recuerde la configuración mínima (usando la GRIETA como un ejemplo):

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

Usted puede ver el siguiente:

Virtual-Access1 VPN PPP LCP accepted sent & rcv CONFACK

Si usted ve el mensaje antedicho, significa que el L2F ha proyectado con éxito el link PPP del miembro de pila que primero llevó la llamada entrante el miembro de pila donde reside el bundle interface para el mismo cliente (o creará, como en el escenario de la descarga).

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

‘Ejecute el siguiente comando:

  debug vpdn l2f-error

Los resultados del siguiente mensaje:

  L2F Tunnel authentication failed for stackq

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


Información Relacionada


Document ID: 14945