Multichasis Multilinks PPP (MMP)

Introducción

Este documento describe el soporte de PPP de enlaces múltiples (MP) en un entorno de pila o de chasis múltiples (denominado a veces MMP, siglas de Multichassis Multilink PPP), en las plataformas de servidor de acceso del sistema Cisco.

Prerequisites

Requirements

No hay requisitos previos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

La información que se presenta en este documento se originó a partir de dispositivos dentro de un ambiente de laboratorio específico. All of the devices used in this document started with a cleared (default) configuration. Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener un comando antes de ejecutarlo.

“Términos relacionados”

Este es un glosario de términos que este documento utiliza:

• Servidor de acceso: plataformas de servidor de acceso de Cisco, incluidas las interfaces ISDN y asíncronas para proporcionar acceso remoto.

• L2F: protocolo de reenvío de capa 2 (L2) (RFC de borrador experimental). Ésta es la tecnología de nivel de link subyacente para ambos multichasis MP y VPN.

• Vínculo: punto de conexión que proporciona un sistema. Un link puede ser una interfaz de hardware dedicada (como una interfaz asincrónica) o un canal en una interfaz de hardware multicanal (como PRI o BRI).

• MP: Multilink PPP Protocol (consulte RFC 1717 ).

• Multichasis MP-MP + SGBP + L2F + Vtemplate.

• PPP: protocolo punto a punto (consulte RFC 1331 ).

• Grupo rotativo: grupo de interfaces físicas asignadas para marcar o recibir llamadas. El grupo actúa como un grupo desde el que puede utilizar cualquier enlace para marcar o recibir llamadas.

• SGBP: Stack Group Bidding Protocol.

• Grupo de pila: conjunto de dos o más sistemas configurados para funcionar como un grupo y admitir paquetes MP con enlaces en diferentes sistemas.

• VPDN: red de marcado privada virtual. El reenvío de links PPP desde un Proveedor de servicios de Internet (ISP) a una gateway de inicio de Cisco.

• Vtemplate: interfaz de plantilla virtual.

Nota: Para obtener información sobre los RFC a los que se hace referencia en este documento, vea RFCs y otras normas estándar admitidas en Cisco IOS Release 11.3-No. 523, un boletín del producto; Cómo obtener RCF y documentos estándar; o RFC Index para un link directamente a InterNIC.

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

Definición del problema

MP proporciona a los usuarios ancho de banda adicional a demanda con la capacidad de dividir y recombinar paquetes a través de una canalización lógica (conjunto) que forman múltiples links.

Esto reduce la latencia de transmisión a través de los enlaces WAN lentos y también proporciona un método para aumentar la unidad de recepción máxima.

En el extremo de transmisión, MP posibilita la fragmentación de un sólo paquete en múltiples paquetes para su transmisión en múltiples links PPP. En el extremo receptor, MP provee el reensamblado de paquetes de links PPP múltiples al paquete original nuevamente.

Cisco admite MP en sistemas finales autónomos, es decir, varios enlaces MP del mismo cliente pueden terminar en el servidor de acceso. Sin embargo, los ISP, por ejemplo, prefieren asignar cómodamente un único número rotatorio a varios PRI en varios servidores de acceso y hacer que su estructura de servidores sea escalable y flexible según las necesidades empresariales.

En Cisco IOS® Software Release 11.2 Cisco proporciona dicha funcionalidad, de modo que múltiples links MP del mismo cliente pueden terminar en diferentes servidores de acceso. Aunque los links MP individuales del mismo paquete pueden terminar en diferentes servidores de acceso, en lo que respecta al cliente MP, esto es similar a la terminación en un único servidor de acceso.

Para lograr este objetivo, MP utiliza MP multichasis.

Información general funcional

La figura 1 ilustra el uso de MP en un único servidor de acceso de Cisco para admitir esta función.

Figura 1: MP en un único servidor de acceso de Cisco

La figura 1 muestra cómo las interfaces miembros de MP se conectan a una interfaz de agrupamiento. En un sistema independiente sin MP multichasis activados, las interfaces miembro son siempre interfaces físicas.

Para admitir un entorno apilado, además de MP, se necesitan estos tres subcomponentes adicionales:

• SGBP

• Vtemplate

• L2F

En las siguientes secciones de este documento se explican estos componentes en detalle.

SGBP

En un entorno de servidor de acceso múltiple, el administrador de red puede designar un grupo de servidores de acceso para que pertenezcan a un grupo de pila.

Supongamos que un grupo de pila consta del Sistema A y el Sistema B. Un cliente MP remoto llamado userx tiene el primer link MP terminado en el Sistema A (systema). El usuariox del agrupamiento se forma en el sistema a. El siguiente link MP del userx finaliza ahora en Sistema B (systemb). SGBP ubica ese agrupamiento donde reside el userx (usuario x) en el systema (sistema a). En este punto, otro componente, L2F, proyecta el segundo link MP de systemb a systema. El link MP proyectado luego se une al agrupamiento en systema.

Por lo tanto, SGBP ubica la ubicación de agrupamiento de un miembro de pila dentro de un grupo de pila definido. SGBP también intercede por un miembro de pila designado para la creación del agrupamiento. En el ejemplo, cuando se recibe el primer link MP en systema, tanto systema como systemb (y todos los demás miembros del grupo de pila) realmente pujan por la creación del agrupamiento. La puja de systema es mayor (porque aceptó el primer link), por lo que SGBP la designa para la creación de paquetes.

Esta descripción del proceso de licitación de SGBP es algo simplista. En la práctica, una oferta de SGBP de un miembro de la pila es una función de la localidad, una métrica ponderada configurable por el usuario, el tipo de CPU, el número de paquetes MP, etc. Este proceso de licitación permite la creación del paquete en un sistema designado, incluso en uno que no tenga interfaces de acceso. Por ejemplo, un entorno apilado puede constar de 10 sistemas de servidor de acceso y dos 4500, un grupo de pila de 12 miembros de pila.

Nota: Cuando las pujas son iguales, como entre dos 4500, SGBP designa aleatoriamente a uno como ganador de la puja. Puede configurar los 4500 para que siempre sobrepujen a los demás miembros de la pila. Los 4500 se convierten así en servidores MP multichasis de descarga especializados en fragmentadores y reensambladores de paquetes MP, una tarea adecuada para su mayor potencia de CPU en relación con los servidores de acceso.

En resumen, SGBP es el mecanismo de arbitraje y ubicación de multichasis MP.

Interfaces de acceso virtual

Las interfaces de acceso virtual sirven como interfaces de agrupamiento (ver Figuras 1 y Figura 2) y como links PPP proyectados (ver Figura 2). Estas interfaces se crean dinámicamente y se devuelven al sistema a demanda.

Las interfaces de plantillas virtuales funcionan como depósitos de la información de configuración a partir de la cual se clonan las interfaces de acceso. Las configuraciones de la interfaz del marcador actúan como otra fuente de información de configuración. El método para elegir el origen de la configuración desde el cual clonar una interfaz de acceso virtual se hace evidente en Multichassis Multilink PPP (MMP) (Parte 2).

L2F

L2F proporciona la proyección de link PPP real a un sistema extremo designado.

L2F realiza la operación PPP estándar hasta la fase de autenticación, donde se identifica al cliente remoto. La fase de autenticación no se completa localmente. El L2F, suministrado con el miembro de pila de destino de SGBP, proyecta el link PPP al miembro de pila de destino, donde la fase de autenticación se reanuda y se completa en el link PPP proyectado. Por lo tanto, el éxito o error de autenticación final se realiza en el miembro de la pila de destino.

Se dice que la interfaz física original que aceptó la llamada entrante es L2F reenviada. La interfaz correspondiente que L2F crea dinámicamente (cuando la autenticación PPP es exitosa) es una interfaz de acceso virtual proyectada.

Nota: La interfaz de acceso virtual proyectada también se clona desde la interfaz de plantilla virtual (si se ha definido).

La Figura 2 describe un grupo de pila stackq que consta de systema, systemb y systemc.

Figura 2: Llamada del cliente a una pila

1. Llamadas userx del cliente. El primer link en systema recibe la llamada. SGBP intenta ubicar algún agrupamiento por userx existente entre los miembros de grupo de pila. Si no hay ninguno, y debido a que MP se negocia en el PPP, se crea una interfaz de agrupamiento en systema.

2. systember recibe la segunda llamada de userx. SGBP ayuda a determinar que systema es donde reside el conjunto. L2F ayuda a reenviar el link de systemba a systema. Se crea un link PPP proyectado en el sistema. El link proyectado luego se incorpora a la interfaz de agrupamiento.

3. systemc recibe la tercera llamada de userx. Una vez más, el SGBP detecta que el sistema está donde reside el paquete. L2F se utiliza para reenviar el link del sistema C al sistema A. Se crea un link PPP proyectado en el sistema. El link proyectado luego se incorpora a la interfaz de agrupamiento.

Nota: Una interfaz de conjunto representa el conjunto en systema. Por cada llamador único, el miembro de MP crea una interfaz a partir de la misma terminación del llamador o se origina desde una interfaz de agrupamiento.

Interfaz del usuario final

Aquí se especifica nominalmente la interfaz de usuario Vtemplate. Consulte Especificación Funcional de la Plantilla Virtual para obtener detalles.

SGBP

1. sgbp group <name>

   Este comando global define un grupo de pila, asigna un nombre al grupo y convierte al sistema en miembro de ese grupo de pila.

   Nota: Sólo puede definir un grupo de pilas globalmente.

   Defina un grupo de pila denominado stackq:

   systema(config)#sgbp group stackq
   

   Nota: El desafío PPP CHAP o la solicitud PPP PAP de systema ahora lleva el nombre stackq. Cuando define el nombre del grupo de pila en el servidor de acceso, el nombre generalmente reemplaza el nombre de host definido para el mismo sistema.

2. sgbp member <peer-name> <peer-IP-address>

   Este comando global especifica peers en el grupo de pila. En este comando, <peer-name> es el nombre de host y <peer-IP-address> es la dirección IP del miembro de pila remoto. De esta manera, necesita definir una entrada para cada miembro del grupo de la pila en la pila, excepto usted mismo. un servidor de nombres de dominio (DNS) puede resolver los nombres de mismo nivel. Si dispone de un DNS, no es necesario introducir la dirección IP.

   systema(config)#sgbp member systemb 1.1.1.2
   	
      systema(config)#sgbp member systemc 1.1.1.3 

3. sgbp seed-bid {default | descarga | forward-only | <0-9999>}

   El peso configurable con el que el miembro de la pila puja por un paquete.

   Si el parámetro predeterminado es definido por todos los miembros de la pila, el miembro de la pila que recibe la primera llamada para el usuario userx siempre gana la licitación, y los hosts, la interfaz del agrupamiento maestro. Todas las llamadas subsiguientes del mismo usuario a otro miembro de la pila se proyectan a este miembro. Si no define un sgbp seed-bid, se utiliza el valor predeterminado.

   Si se define la descarga, envía la oferta precalibrada por plataforma que se aproxima a la potencia de la CPU, menos la carga del paquete.

   Si < 0-9999 > está configurado, la oferta enviada es el valor configurado por el usuario menos la carga del paquete.

   La carga del conjunto se define como el número de paquetes activos en el miembro de la pila.

   1. Cuando tenga miembros de pila equivalentes apilados para recibir llamadas en un grupo rotatorio a través de varios PRI, ejecute el comando sgbp seed-bid default across all stack members. Un ejemplo de partes de la pila equivalentes sería un grupo de pila de cuatro AS5200. El valor 1/130 de VPI/VCI es asignado a ambos extremos del PVC entre en router 7500 y el Router A. Todas las llamadas subsiguientes del mismo usuario a otro miembro de la pila se proyectan a este éste último. Si las múltiples llamadas ingresan de manera concurrente en los miembros múltiples de pila, el mecanismo SGBP de desempate entra en acción.

   2. Cuando tiene una CPU de mayor potencia disponible como miembro de la pila en relación con los demás miembros de la pila, puede que desee aprovechar la potencia relativa más alta de ese miembro de la pila sobre el resto (por ejemplo, una o más CPU de mayor potencia disponibles como miembro de la pila en relación con los otros miembros de la pila similares; por ejemplo, un 4500 y cuatro AS5200). Puede establecer el miembro de pila de alta potencia designado como el servidor de descarga con el comando sgbp seed-bid offload. En ese caso, el servidor de descarga alberga el paquete principal. Todas las llamadas de otros miembros de la pila se proyectan a este miembro de la pila. En realidad, se pueden definir uno o más servidores de descarga; si las plataformas son las mismas (equivalentes), las ofertas son iguales. El mecanismo para desempatar de SGBP realiza el desempate y designa una de las plataformas como la ganadora.

      Nota: Si designa dos plataformas diferentes como servidores de descarga, el que tenga mayor potencia de CPU ganará la licitación.

   3. Si ha ordenado o exactamente las mismas plataformas y desea designar una o más plataformas como servidores de descarga, puede establecer manualmente el valor de la oferta para que sea significativamente mayor que el resto con el comando sgbp seed-bid 9999. Por ejemplo, un 4700 (designado por el valor de seed-bid más alto), dos 4000 y un 7000. Para determinar el valor de oferta inicial asociado con sus plataformas particulares, utilice show sgbp.

   4. En un entorno de varios chasis en el que los miembros de la pila del cliente siempre descargan en uno o más servidores de descarga, hay casos en los que el miembro de la pila del cliente no puede realmente descargar, como cuando el paquete de links múltiples se forma localmente. Esto podría suceder, por ejemplo, cuando todos los servidores de descarga están caídos. Si el administrador de red prefiere que la llamada entrante cuelgue, ejecute el comando sgbp seed-bid forward-only.

4. sgbp ppp-forward

   Cuando se define el envío de PPP SGBP, tanto las llamadas PPP como MP se proyectan al ganador de la licitación de SGBP. De forma predeterminada, sólo se reenvían las llamadas de MP.

5. show sgbp

   Este comando muestra el estado de los miembros del grupo de pila. Los estados pueden ser ACTIVE (ACTIVO), CONNECTING (CONECTANDO), WAITINFO (INFORMACIÓN DE ESPERA) o IDLE (INACTIVO). ACTIVE en cada miembro del grupo de pila es el mejor estado. CONNECTING y WAITINFO son estados de transición y sólo debe verlos cuando se encuentre en transición a ACTIVE. IDLE indica que el grupo de pila systema no puede detectar el miembro de pila remoto systemd. Si, por ejemplo, systemd se desactiva por mantenimiento, no hay motivo para preocuparse. De lo contrario, observe algunos problemas de ruteo u otros problemas entre este miembro de la pila y systemd.

   systema#show sgbp
     Group Name: stack Ref: 0xC38A529
     Seed bid: default, 50, default seed bid setting
   	
        Member Name: systemb State: ACTIVE  Id: 1
        Ref: 0xC14256F
        Address: 1.1.1.2 
   	
        Member Name: systemc State: ACTIVE  Id: 2
        Ref: 0xA24256D
        Address: 1.1.1.3 Tcb: 0x60B34439
   	
        Member Name: systemd State: IDLE Id: 3
        Ref: 0x0
        Address: 1.1.1.4 
   	

6. show sgbp queries

   Muestra el valor de licitación actual del simiente.

   systema# show sgbp queries
     Seed bid: default, 50
   	
     systema# debug sgbp queries
     %SGBPQ-7-MQ:    Bundle: userX  State: Query_to_peers   OurBid: 050
     %SGBPQ-7-PB:    1.1.1.2 		State: Open_to_peer  Bid: 000  Retry: 0
     %SGBPQ-7-PB:    1.1.1.3		 State: Open_to_peer  Bid: 000  Retry: 0
     %SGBPQ-7-PB:    1.1.1.4		 State: Open_to_peer  Bid: 000  Retry: 0
     %SGBPQ-7-MQ:    Bundle: userX  State: Query_to_peers   OurBid: 050
     %SGBPQ-7-PB:    1.1.1.2		State: Rcvd     Bid: 000  Retry: 0
     %SGBPQ-7-PB:    1.1.1.3		State: Rcvd     Bid: 000  Retry: 0
     %SGBPQ-7-PB:    1.1.1.4		State: Rcvd     Bid: 000  Retry: 0
     %SGBPQ-7-DONE: Query #9 for bundle userX, count 1, master is local
   

MP

1. multilink virtual-template <1-9>

   Este es el número de plantilla virtual mediante el cual la interfaz de agrupamiento MP clona sus parámetros de interfaz. Este es un ejemplo de cómo un MP se asocia a una plantilla virtual. También se debe definir una interfaz de plantilla virtual:

   systema(config)#multilink virtual-template 1
     systema(config)#int virtual-template 1
     systema(config-i)#ip unnum e0
     systema(config-i)#encap ppp
     systema(config-i)#ppp multilink
     systema(config-i)#ppp authen chap
   

2. show ppp miltilink

   Este comando muestra la información de agrupamiento para los agrupamientos MP:

   systema#show ppp multilink
     Bundle userx 2 members, Master link is Virtual-Access4
     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.2)
   

   Este ejemplo muestra, en el miembro del grupo de pila systema en el grupo de pila stackq, que la interfaz de conjunto userx tiene su interfaz de conjunto establecida como Virtual-Access4. Dos interfaces de miembro se unen a esta interfaz de conjunto. El primero es un canal PRI local y el segundo es una interfaz proyectada desde el sistema miembro del grupo de pila.

Examples

Consulte Multichassis Multilink PPP (MMP) (Parte 2) para ver estos ejemplos:

• AS5200 en una pila con marcadores

• Uso de un servidor de descarga

• Servidor de descarga con interfaces físicas

• Interfaces asíncronas, seriales y de no marcador

• Llamadas salientes desde un Multichassis

• Llamada a un Multichassis

Consulte también las secciones sobre:

• Configuración y restricciones

• Resolución de problemas

Información Relacionada

• Páginas de soporte de tecnología de acceso y marcado
• Soporte Técnico y Documentación - Cisco Systems

Historial de revisiones