Multilink PPP (también conocido como MP, MPPP, MLP o Multilink) proporciona un método para separar el tráfico a través de múltiples links WAN físicos mientras proporciona fragmentación y recomposición de paquetes, orden correcto, interoperabilidad entre diversos proveedores y balanceo de carga en el tráfico entrante y saliente.
MPPP permite que se fragmenten los paquetes. Estos fragmentos se envían simultáneamente a través de varios links punto a punto a la misma dirección remota. Los múltiples links físicos se activan en respuesta a un umbral de carga definido por el usuario. Esta carga se puede medir solamente en el tráfico entrante, solamente en el tráfico saliente o en cualquiera de ellos; sin embargo, no se puede medir en la carga combinada del tráfico entrante y el saliente.
Para las conexiones de marcado, MPPP se puede configurar para BRIs (ISDN Basic Rate Interfaces) y PRIs (Primary Rate Interfaces), así como para las interfaces seriales asíncronas. También puede ser configurado para interfaces seriales sin marcado aunque esta funcionalidad no está tratada en este documento específicamente. Este documento tratará la configuración del MPPP básico para el Dial-on-demand Routing (DDR). En este documento no se trata Multichassis Multilink PPP; vea la documentación de Multichassis Multilink PPP (MMP) para obtener más información.
Para obtener más información sobre las convenciones del documento, consulte Convenciones de Consejos Técnicos de Cisco.
No hay requisitos previos específicos para este documento.
La información que contiene este documento se basa en las versiones de software y hardware indicadas a continuación.
Multilink PPP fue introducido por primera vez en la versión 11.0(3) del software del IOS® de Cisco.
En este ejemplo se utilizó la versión de software Cisco IOS 11.3.
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.
MPPP es un método para dividir, recombinar y ordenar datagramas a través de múltiples links de datos lógicos. Consulte RFC 1990 RFC 1990 para obtener una buena descripción de MPPP. Originalmente, estaba motivado por el deseo de explotar varios canales portadores en ISDN, pero es igualmente aplicable a cualquier situación en la que varios links PPP se conectan a dos sistemas, incluyendo links asíncronos.
El tráfico ruteado a través de un link MPPP mediante su interfaz de control (una interfaz de acceso virtual) será fragmentado, y los fragmentos se enviarán a través de diversos links físicos. En el extremo remoto del link, los fragmentos se recomponen y se remiten al salto siguiente hacia su destino final.
Esta sección trata los comandos y los diferentes métodos de configurar MPPP en un router.
Comando necesario | Descripción |
---|---|
multilink ppp | Configure el comando PPP multilink PPP (en ambos routers) bajo la interfaz física y la interfaz del marcador (si utiliza perfiles de marcador). Nota: Si agrega este comando, debe desconectar cualquier conexión existente y luego volver a conectarse para que se apliquen los nuevos parámetros multilink. Dado que el multilink se negocia durante la configuración de la llamada, los cambios al multilink no se implementan en las conexiones que han completado la negociación LCP (Link Control Protocol). |
dialer load-threshold 5 outbound | Carga de la interfaz (de 1 a 255) más allá de la cual el marcador iniciará otra llamada al destino. El ancho de banda está definido como un índice de 255, donde 255 sería el 100 por ciento del ancho de banda disponible. En este ejemplo, el canal adicional se activará cuando la carga saliente sobre el link es el 5/255 o 2 por ciento. Varíe este valor según sus necesidades. El argumento outbound establece el cálculo de la carga que se hará solamente en el tráfico saliente. El argumento inbound hace los mismo, pero para el tráfico entrante solamente. Utilizando el argumento either establece la carga como la mayor entre las cargas saliente y entrante. Sugerencia: A menudo, los clientes configurarán el comando dialer load-threshold 1 porque desean que todos sus canales B se utilicen inmediatamente para cada llamada. La teoría detrás de esto es que si todos los canales B suben de repente y se utiliza todo el conducto ISDN para cada llamada, la llamada debe tener una duración menor porque tomará menos tiempo transferir los datos del usuario. Aunque esta teoría es sólida, en la práctica es una buena idea no establecer nunca el valor de umbral de carga del marcador en un valor menor de "3". Establecer este valor algo menor que "3" puede provocar que múltiples canales ISDN se activen a la vez, lo que puede provocar la contención entre ambos canales y una falla para conectar con cualquiera de ellos. |
Comandos opcionales | Descripción |
ppp timeout multilink link remove seconds | Es posible que este comando sea utilizado para evitar el “flapping” en las conexiones de links múltiples cuando varía la carga. Por ejemplo, cuando el umbral de carga se establece en 15 (es decir, 15/255 = 6 por ciento) y el tráfico supera el umbral, se activan líneas adicionales. Cuando el tráfico desciende el umbral, se suprimen las líneas adicionales. En los casos donde la velocidad de los datos varía mucho, es beneficioso para los diferentes canales permanecer en funcionamiento por un periodo de tiempo aun cuando el umbral de la carga sea menor al valor especificado. Asigna este tiempo de espera multilink para que sea menor al especificado por el tiempo de espera inactivo del dialer que controla el tiempo de espera para todos los links. |
ppp timeout multilink link add seconds | Este comando se puede utilizar para evitar que se añadan múltiples links al conjunto MP hasta que se reciba un tráfico elevado durante un intervalo especificado. Esto puede evitar que las ráfagas de tráfico activen innecesariamente líneas adicionales. |
ppp multilink max-link o ppp multilink links maximum (IOS 12.2 o superior) | El valor establecido en el comando ppp multilink links maximum especifica el número máximo de links permitidos en un conjunto. Cuando más links que el número asignado con el comando ppp multilink links maximum intentan entrar en el conjunto, MLP cuelga sus canales de marcador para reducir el número de links. Esto se puede utilizar para evitar que una conexión multilink active demasiadas conexiones. |
ppp multilink min-link o ppp multilink links minimum (IOS 12.2 o superior) | El valor establecido en el comando ppp multilink links minimum especifica el número mínimo de links que MLP intentará mantener en un conjunto. MLP intenta marcar links adicionales para obtener el número especificado por el argumento links, incluso si la carga no excede el umbral de carga. Esto se puede utilizar para forzar la activación de un determinado número de canales |
multilink bundle-name | Este comando se puede utilizar para cambiar los criterios con los cuales se identifica un conjunto multilink. |
Esta sección trata de cómo configurar Multilink PPP utilizando el DDR heredado (grupo rotatorio y mapas de marcador).
Dado que las interfaces ISDN se consideran ser interfaces de "Dialer", se necesitan pocos comandos para hacer una interfaz ISDN capaz de establecer conexiones MPPP. Por ejemplo, no es necesario configurar un grupo rotativo de marcadores a menos que esté utilizando más de una BRI o PRI.
El siguiente es un ejemplo de una BRI configurada para realizar una simple conexión de Llamada bajo demanda PPP:
! interface BRI0 ip address 192.168.12.3 255.255.255.240 encapsulation ppp dialer map IP 192.168.12.1 name ROUTER1 5554321 dialer-group 1 ppp authentication chap isdn spid1 40855512120000 5551212 isdn spid2 40855512340000 5551234 !
Solamente hay que añadir dos comandos a esta configuración de interfaz para hacer posible MPPP. El router en el otro extremo de la llamada debe estar configurado de manera similar. Estos dos comandos son:
ppp multilink
dialer load-threshold load [outbound | inbound | either]
En los casos en que dos o más interfaces físicas deben ser agrupadas (por ejemplo, al utilizar interfaces asíncronas o seriales o más de una interfaz ISDN), se debe utilizar un método diferente. En estos casos, se debe configurar un grupo rotatorio de marcador y se debe añadir una interfaz de Dialer a la configuración del router para controlar la conexión MPPP. En resumen, una interfaz "lógica" debe controlar las interfaces "físicas".
Para lograrlo, debe hacer lo siguiente:
Ponga las interfaces físicas en un grupo rotatorio.
Cree una interfaz lógica ("Dialer") como principal para el grupo rotatorio.
Configure la interfaz de marcado para que lleve a cabo MPPP.
Siga estos pasos para configurar MPPP en varias interfaces:
Coloque las interfaces físicas en un grupo rotativo utilizando el comando dialer rotary-group number. En este ejemplo, se pone a la interfaz asíncrona en el grupo rotativo 1:
router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. router(config)#interface async 1 router(config-if)#dialer rotary-group 1 router(config-if)#^Z router#
Nota: Asegúrese de utilizar el comando de configuración de la interfaz no shutdown si el router nunca se ha configurado o si el router se ha restablecido a su configuración predeterminada.
Para crear una interfaz de marcado, use el comando interface dialer number global configuration. En este ejemplo, se crea la interfaz Dialer 1:
router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. router(config)#interface dialer 1 router(config-if)#end router#
Nota: El argumento number del comando interface dialer debe ser el mismo que el número del grupo rotatorio configurado en el Paso 1.
Utilice el comando show running-config para ver la configuración predeterminada de una interfaz de marcador:
! interface Dialer1 no ip address no cdp enable !
Luego, configure la interfaz del marcador para realizar o recibir llamadas. Los comandos esenciales ara MPPP son los mismos que en el Paso 1:
! interface Dialer1 ip address 192.168.10.1 255.255.255.0 encapsulation ppp dialer in-band dialer idle-timeout 300 dialer map ip 192.168.10.11 name RemoteRouter broadcast 5551234 dialer load-threshold 100 dialer-group 1 no fair-queue ppp multilink ppp authentication chap !
Consulte la página de soporte PPP para ver ejemplos de las configuraciones DDR completas con MPPP
La configuración de Multilink PPP en perfiles de marcador es similar a la de DDR heredado. El comando multilink ppp se debe configurar tanto en la interfaz física como en la interfaz de marcador. El comando dialer load-threshold se debe configurar en la interfaz Dialer. Por ejemplo,
interface BRI0 no ip address encapsulation ppp dialer pool-member 1 isdn switch-type basic-5ess ppp authentication chap ppp multilink ! -- Configure multilink on both physical and dialer interfaces ! interface Dialer1 ip address 172.22.85.1 255.255.255.0 encapsulation ppp dialer pool 1 ! -- Defines the pool of physical resources from which the Dialer ! -- interface may draw B channels as needed. dialer remote-name R1 dialer string 6661000 dialer load-threshold 128 outbound dialer-group 5 ppp authentication chap ppp multilink ! -- Configure multilink on both physical and dialer interfaces
Para obtener más información sobre los perfiles de marcador, refiérase al documento Configuración y Troubleshooting de Perfiles de Dialer
Para verificar el funcionamiento correcto de una conexión MPPP, utilice el comando debug ppp negotiation. Los elementos decisivos que se deben negociar en la fase LCP son la Maximun Receive Reconstructed Unit (MRRU) (Unidad reconstruida de recepción máxima) y el Discriminador de punto final (EndpointDisc):
As1 LCP: O CONFREQ [Listen] id 1 len 26 As1 LCP: AuthProto CHAP (0x0305C22305) As1 LCP: MagicNumber 0x10963BD1 (0x050610963BD1) As1 LCP: MRRU 1524 (0x110405F4) As1 LCP: EndpointDisc 1 Local (0x13070174657374) As1 LCP: I CONFREQ [REQsent] id 3 Len 27 As1 LCP: MRU 1500 (0x010405DC) As1 LCP: MagicNumber 0x2CBF9DAE (0x05062CBF9DAE) As1 LCP: MRRU 1500 (0x110405DC) As1 LCP: EndpointDisc 1 Local (0x1306011AC16D) As1 LCP: I CONFACK [REQsent] id 1 Len 26 As1 LCP: AuthProto CHAP (0x0305C22305) As1 LCP: MagicNumber 0x10963BD1 (0x050610963BD1) As1 LCP: MRRU 1524 (0x110405F4) As1 LCP: EndpointDisc 1 Local (0x13070174657374) As1 LCP: O CONFACK [ACKrcvd] id 3 Len 24 As1 LCP: MRU 1500 (0x010405DC) As1 LCP: MagicNumber 0x2CBF9DAE (0x05062CBF9DAE) As1 LCP: MRRU 1500 (0x110405DC) As1 LCP: EndpointDisc 1 Local (0x1306011AC16D) As1 LCP: State is Open
Como ocurre con los demás elementos de la negociación LCP, MRRU y EndpointDisc deben acordarse entre ambos extremos de la conexión durante el intercambio de CONFREQs y los CONFACKs. Ambos extremos de la conexión deben enviar CONFACK para que se establezca el protocolo. Para obtener más información sobre cómo leer debug ppp negotiation output refiérase al documento Cómo Comprender la Salida de debug ppp negotiation.
Después de que MPPP se haya negociado con éxito durante la fase LCP de la negociación PPP, y que CHAP (Challenge Handshake Authentication Protocol) o PAP (Password Authentication Protocol) se haya completado con éxito, Cisco IOS Software creará una interfaz de acceso virtual para representar el conjunto MPPP. Para obtener más información sobre los usos y la teoría que hay detrás de las interfaces de acceso virtual, vea Funciones PPP de Acceso Virtual en la documentación de Cisco IOS.
La creación de la interfaz de acceso virtual se señala en la salida de debug ppp negotiation de la manera siguiente:
As1 PPP: Phase is VIRTUALIZED
A partir de este punto, la negociación PPP de los Protocolos de control de la red es administrada por la interfaz de Acceso virtual. Por ejemplo:
Vi1 PPP: Treating connection as a dedicated line Vi1 PPP: Phase is ESTABLISHING, Active Open Vi1 LCP: O CONFREQ [Closed] id 1 Len 37 ... Vi1 PPP: Phase is UP Vi1 IPCP: O CONFREQ [Closed] id 1 len 10 Vi1 IPCP: Address 192.168.10.1 (0x0306C0A80A01) ...
Una vez que se ha establecido la conexión de MPPP, puede encontrar la información de la conexión en el resultado del comando show ppp multilink:
router#show ppp multilink Virtual-Access1, bundle name is RemoteRouter 0 lost fragments, 0 reordered, 0 unassigned, sequence 0x29/0x17 rcvd/sent 0 discarded, 0 lost received, 1/255 load Member links: 1 (max not set, min not set) Async1
El nombre de agrupamiento es el nombre de usuario autenticado del dispositivo cliente conectado. Los links miembro son una lista de interfaces físicas que son los miembros activos del agrupamiento. En el ejemplo anterior, sólo hay un link activo actualmente, sin embargo el router puede agregar más links al agrupamiento en algún momento.Para desconectar un link específico (en lugar de todo el agrupamiento) usando el comando clear interface interface. Por ejemplo, clear interface Async1.
El orden según cuál convención de nomenclatura se intentará primero (como se ve en el nombre de conjunto) se puede cambiar utilizando el comando multilink bundle-name .
Además, el comando show interface es válido para la interfaz de acceso virtual igual que para otra interfaz física o lógica. El mismo tipo de información se presentará como aparecería en cualquier otra salida de show interface.
router#show interface virtual-access 1 Virtual-Access1 is up, line protocol is up Hardware is Virtual Access interface Description: Multilink PPP to RemoteRouter ! -- This VAccess interface is conencted to "RemoteRouter" Internet address is 192.168.10.1/24 MTU 1500 bytes, BW 7720 Kbit, DLY 100000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation PPP, loopback not set Keepalive set (10 sec) DTR is pulsed for 5 seconds on reset LCP Open, multilink Open ! -- multilink state should be Open for a successful connection Open: IPCP Last input 00:00:01, output never, output hang never Last clearing of "show interface" counters 04:25:13 Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 12000 bits/sec, 2 packets/sec 5 minute output rate 12000 bits/sec, 2 packets/sec 2959 packets input, 2075644 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 2980 packets output, 2068142 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
09-Sep-2005 |
Versión inicial |