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.
Los requisitos previos para este documento se dan en la primera parte de este documento.
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:
Figura 3: Una pila de grupo de pila compuesta por systema, systembajb y systemc. El link de systema se configura en la interfaz del marcador.interface Serial0:23 ip unnum e0 dialer map ..... encap ppp ppp authen chap dialer-group 1 dialer rot 1 ppp multilink
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).
Figura 4: systema como servidor de descarga.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
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.
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
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).
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:
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
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.
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.
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 :
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).
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:
Asegúrese de que SGBP está en funcionamiento.
Debug PPP multilink.
Debug VPN y L2F.
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.
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í).
Usuario cliente | Cada miembro de stack stackq |
---|---|
#config username stackq password blah |
#config username userx password blah |
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.
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
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.
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)
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
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.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
09-Sep-2005 |
Versión inicial |