Redundancia de interfaz de servicios de vínculo
Capacidades e interfaces del paquete de servicio de capa 2
Como se describe en Habilitación de paquetes de servicio, puede configurar la PIC del AS o multiservicios y el ASM interno en la plataforma M7i para usar el paquete de servicio de capa 2 o de capa 3.
Cuando habilita el paquete de servicio de capa 2, el AS o la PIC de multiservicios admiten servicios de vínculo. En el AS o la PIC de multiservicios y el ASM, los servicios de vínculo incluyen lo siguiente:
Componentes CoS de Junos: configuración de colas de programación de CoS en interfaces LSQ lógicas describe cómo funcionan los componentes CoS de Junos en interfaces IQ (
lsq) de servicios de vínculo. Para obtener información detallada sobre los componentes CoS de Junos, consulte la Guía del usuario de clase de servicio (enrutadores y conmutadores EX9200).Compresión de datos mediante el protocolo de transporte en tiempo real (CRTP) comprimido para su uso en la transmisión de voz sobre IP (VoIP).
Nota:En las interfaces LSQ, todo el tráfico de múltiples vínculos de un solo paquete se envía a un único procesador. Si CRTP está habilitado en el paquete, agrega sobrecarga a la CPU. Dado que las interfaces de red T3 solo admiten un vínculo por paquete, asegúrese de configurar una asignación de fragmentación para el tráfico comprimido en estas interfaces y especifique la
no-fragmentationopción. Para obtener más información, consulte Configuración de intercalación de paquetes sensibles al retraso y Configuración de la fragmentación de CoS mediante clase de reenvío en interfaces LSQ.Entrelazado de fragmentos de vínculo (LFI) en vínculos de Frame Relay mediante fragmentación de extremo a extremo FRF.12: el estándar para FRF.12 se define en la especificación FRF.12, Acuerdo de implementación de fragmentación de Frame Relay.
LFI en vínculos de protocolo punto a punto multivínculo (MLPPP).
Multilink Frame Relay (MLFR) de extremo a extremo (FRF.15): el estándar para FRF.15 se define en la especificación FRF.15, Acuerdo de implementación de Multilink Frame Relay de extremo a extremo.
Multilink Frame Relay (MLFR) UNI NNI (FRF.16): el estándar para FRF.16 se define en la especificación FRF.16.1, Acuerdo de implementación de UNI/NNI de Multilink Frame Relay.
MLPPP: el estándar para MLPPP se define en la especificación RFC 1990, The PPP Multilink Protocol (MP).
Extensión multiclase a MLPPP: el estándar se define en la especificación RFC 2686, La extensión multiclase a PPP multivínculo.
Para la interfaz LSQ en el AS o la PIC de multiservicios, la sintaxis de configuración es casi la misma que para las PIC de multivínculo y servicios de vínculo. La diferencia principal es el uso del descriptor lsq de tipo de interfaz en lugar de ml o ls. Cuando se habilita el paquete de servicio de capa 2 en el AS o la PIC de multiservicios, se crean automáticamente las siguientes interfaces:
gr-fpc/pic/port ip-fpc/pic/port lsq-fpc/pic/port lsq-fpc/pic/port:0 ... lsq-fpc/pic/port:N mt-fpc/pic/port pd-fpc/pic/port pe-fpc/pic/port sp-fpc/pic/port vt-fpc/pic/port
Los tipos de grinterfaz , ip, mt, pd, pey vt son interfaces de túnel estándar que están disponibles en el AS o en la PIC de multiservicios, tanto si habilita el paquete de servicio de capa 2 como de capa 3. Estas interfaces de túnel funcionan de la misma manera para ambos paquetes de servicio, con la diferencia de que el paquete de servicio de capa 2 no admite algunas funciones de túnel, como se muestra en la tabla 5 en la página 24. Para obtener más información acerca de las interfaces de túnel, consulte Guía del usuario de interfaces de servicios de cifrado y túnel para dispositivos de enrutamiento.
El tipo sp de interfaz se crea porque lo necesita Junos OS. Para el paquete de servicio de capa 2, la sp interfaz no es configurable, pero no debe deshabilitarla.
El tipo lsq-fpc/pic/port de interfaz es la interfaz IQ de servicios de vínculo físico (lsq). Los tipos lsq-fpc/pic/port:0 de interfaz representan lsq-fpc/pic/port:N paquetes FRF.16. Estos tipos de interfaz se crean cuando se incluye la mlfr-uni-nni-bundles instrucción en el nivel de [edit chassis fpc slot-number pic pic-number] jerarquía. Para obtener más información, consulte Configurar colas de programación de CoS en interfaces LSQ lógicas.
En las interfaces DS0, E1 o T1 de paquetes LSQ, puede configurar la bandwidth instrucción, pero el enrutador no utiliza el valor de ancho de banda si las interfaces están incluidas en un paquete MLPPP o MLFR. El ancho de banda se calcula internamente de acuerdo con los intervalos de tiempo, la trama y la codificación de bytes de la interfaz. Para obtener más información sobre estas propiedades, consulte la biblioteca de interfaces de red de Junos OS para dispositivos de enrutamiento.
Configuración de la redundancia de la interfaz LSQ en varios enrutadores mediante APS SONET
Las interfaces IQ (lsq-) de servicios de vínculo que se emparejan con PIC SONET pueden utilizar la configuración de conmutación de protección automática (APS) que ya está disponible en redes SONET para proporcionar recuperación de fallas. La APS SONET proporciona recuperación de errores sin estado si está configurada en interfaces SONET en un chasis independiente y cada PIC SONET está emparejada con una PIC de AS o multiservicios en el mismo chasis. Si se cumple una de las siguientes condiciones para una falla de APS, la PIC SONET asociada desencadena la recuperación en el circuito de respaldo y su PIC de multiservicios o AS asociada. Las condiciones de falla son:
Falla de la PIC IQ de servicios de vínculo
Error de FPC que hospeda la PIC IQ de servicios de vínculo
Falla del motor de reenvío de paquetes
Fallo del chasis
Las directrices para configurar AP SONET se describen en la biblioteca de interfaces de red de Junos OS para dispositivos de enrutamiento.
En las secciones siguientes se describe cómo configurar las propiedades de tolerancia a fallos:
- Configuración de la asociación entre interfaces LSQ y SONET
- Configuración de la interoperabilidad de APS de SONET con Cisco Systems FRF.16
- Restricciones en la redundancia de APS para interfaces LSQ
Configuración de la asociación entre interfaces LSQ y SONET
Para configurar la asociación entre las PIC de AS o multiservicios que alojan interfaces IQ de servicios de vínculo y las interfaces SONET, incluya la lsq-failure-options instrucción en el nivel de [edit interfaces] jerarquía:
lsq-fpc/pic/port {
lsq-failure-options {
no-termination-request;
[ trigger-link-failure interface-name ];
}
}
Por ejemplo, considere el siguiente escenario de red:
El enrutador principal incluye interfaces
oc3-0/2/0ylsq-1/1/0.El enrutador de respaldo incluye interfaces
oc3-2/2/0ylsq-3/2/0.
Configure SONET APS con oc3-0/2/0 como circuito operativo y oc3-2/2/0 como circuito de protección. Incluya la instrucción para extender la trigger-link-failure falla a las PIC LSQ:
interfaces lsq-1/1/0 {
lsq-failure-options {
trigger-link-failure oc3-0/2/0;
}
}
Debe configurar la lsq-failure-options instrucción únicamente en el enrutador principal. La configuración no se admite en el enrutador de copia de seguridad.
Para impedir que el enrutador envíe mensajes de solicitud de terminación PPP al host remoto si falla la PIC IQ de servicios de vínculo, incluya la no-termination-request instrucción en el nivel de [edit interfaces lsq-fpc/pic/port lsq-failure-options] jerarquía:
[edit interfaces lsq-fpc/pic/port lsq-failure-options] no-termination-request;
Esta funcionalidad también se admite en las PIC de vínculo. Para impedir que el enrutador envíe mensajes de solicitud de terminación PPP al host remoto si falla una PIC de vínculo, incluya la no-termination-request instrucción en el nivel de [edit interfaces interface-name ppp-options] jerarquía.
[edit interfaces interface-name ppp-options] no-termination-request;
La no-termination-request instrucción solo se admite con configuraciones APS MLPPP y SONET y solo funciona con interfaces PPP, PPP sobre Frame Relay y MLPPP en las siguientes PIC:
PIC IQ OC3 canalizadas
PIC IQ OC12 canalizadas
PIC IQ STM1 canalizadas
PIC IQ STM4 canalizadas
Configuración de la interoperabilidad de APS de SONET con Cisco Systems FRF.16
Es posible que los enrutadores de Juniper Networks configurados con APS no interoperen correctamente con Cisco FRF.16. Para habilitar la interoperación, incluya la cisco-interoperability instrucción en el nivel de [edit interfaces lsq-fpc/pic/port mlfr-uni-nni-bundle-options] jerarquía:
[edit interfaces lsq-fpc/pic/port mlfr-uni-nni-bundle-options] cisco-interoperability send-lip-remove-link-for-link-reject;
La send-lip-remove-link-for-link-reject opción solicita al enrutador que envíe un enlace de eliminación de protocolo de integridad de vínculo cuando recibe un mensaje de rechazo de vínculo agregado.
Restricciones en la redundancia de APS para interfaces LSQ
Las siguientes restricciones se aplican a la recuperación de fallas de LSQ:
Solo se aplica a las PIC IQ de servicios de vínculo instaladas en enrutadores de la serie M, excepto para enrutadores M320.
Debe configurar la
failure-optionsinstrucción en interfaces LSQ físicas, no en unidades canalizadas MLFR.Las PIC IQ de servicios de vínculo deben estar asociadas con PIC de vínculo SONET. Las PIC emparejadas se pueden instalar en diferentes enrutadores o en el mismo enrutador; En otras palabras, se admite la recuperación de interchasis e intrachasis
La recuperación de errores no tiene estado; Como resultado, se espera oscilación de rutas y pérdida del estado del vínculo en la recuperación de interchasis, lo que requiere una renegociación de PPP. En la recuperación intrachasis, no se anticipa ningún impacto en el tráfico con la tolerancia a fallos del motor de enrutamiento, pero la tolerancia a fallos de PIC da como resultado la renegociación de PPP.
La conmutación no es reversible: cuando el hardware original se restaura al servicio, el tráfico no vuelve automáticamente a él.
La conmutación normal de APS y la conmutación de APS activada por PIC solo se pueden distinguir si se comprueban los mensajes de registro del sistema.
Nota:Cuando una PIC de AS experimenta una contrapresión persistente como resultado de un alto volumen de tráfico durante 3 segundos, la condición activa un volcado de núcleo automático y un reinicio de la PIC para ayudar a eliminar el bloqueo. Se genera un mensaje de registro del sistema en el nivel LOG_ERR. Este mecanismo se aplica a los paquetes de servicio de capa 2 y de capa 3.
Ver también
Configuración de la redundancia de la interfaz LSQ en un único enrutador mediante APS SONET
La conmutación sin estado de una PIC IQ de servicios de vínculo a otra dentro del mismo enrutador se puede configurar mediante el mecanismo de APS SONET descrito en Configuración de la redundancia de interfaz LSQ en varios enrutadores mediante APS SONET. Cada PIC IQ de servicios de vínculo debe asociarse a una PIC de vínculo SONET especificada en el mismo enrutador.
Para una recuperación completa del intrachasis, incluida la recuperación de la tolerancia a fallos del motor de enrutamiento, se debe habilitar el cambio normal del motor de enrutamiento (GRES) en el enrutador. Para obtener más información, consulte la biblioteca de administración de Junos OS para dispositivos de enrutamiento.
Ver también
Configuración de la redundancia de la interfaz LSQ en un solo enrutador mediante interfaces virtuales
Puede configurar la recuperación de errores en enrutadores serie M, serie MX y serie T que tengan varias PIC y DPC de AS o multiservicios con lsq- interfaces especificando una interfaz de redundancia () LSQ virtual enrlsq la que la PIC IQ de servicios de vínculo principal esté activa y una PIC secundaria esté en espera. Si se produce un error en la PIC principal, la PIC secundaria se activa y se transfiere todo el procesamiento de LSQ a ella. Para determinar qué PIC está activa actualmente, ejecute el show interfaces redundancy comando.
Esta configuración no requiere el uso de APS SONET para la tolerancia a fallos. Se pueden utilizar interfaces de red que no admiten SONET, como las interfaces T1 o E1.
En las secciones siguientes se proporciona más información:
- Configuración de interfaces LSQ emparejadas redundantes
- Restricciones en interfaces LSQ redundantes
- Configuración de la replicación del estado del vínculo para PIC de vínculo redundante
- Ejemplos: Configuración de interfaces LSQ redundantes para la recuperación de errores
Configuración de interfaces LSQ emparejadas redundantes
El tipo rlsq de interfaz física especifica los emparejamientos entre las interfaces principal y secundaria lsq para habilitar la redundancia. Para configurar una interfaz de copia de seguridad lsq , incluya la redundancy-options instrucción en el nivel de [edit interfaces rlsqnumber] jerarquía:
[edit interfaces rlsqnumber] redundancy-options { (hot-standby | warm-standby); primary lsq-fpc/pic/port; secondary lsq-fpc/pic/port; }
Para la rlsq interfaz, number puede ser del 0 al 1023. Si se produce un error en la interfaz principal lsq , el procesamiento de tráfico cambia a la interfaz secundaria. La interfaz secundaria permanece activa incluso después de que se recupere la interfaz principal. Si se produce un error en la interfaz secundaria y la interfaz principal está activa, el procesamiento cambia a la interfaz principal.
Esta hot-standby opción se utiliza con configuraciones de redundancia uno a uno, en las que una PIC funcional es compatible con una PIC de respaldo. Es compatible con configuraciones MLPPP, CRTP, FRF.15 y FRF.16 para que la interfaz LSQ logre un servicio LSQ ininterrumpido. Establece el requisito de que el tiempo de detección y recuperación de fallas sea inferior a 5 segundos. El comportamiento es inverso, pero puede cambiar manualmente entre la PIC principal y la secundaria mediante la ejecución del comando de modo request interfaces (revert | switchover) rlsqnumber operativo. También proporciona un tiempo de conmutación de 5 segundos o menos para FRF.15 y un máximo de 10 segundos para FRF.16.
La warm-standby opción se utiliza con configuraciones de redundancia en las que una PIC de respaldo admite múltiples PIC de trabajo. Los tiempos de recuperación no están garantizados, ya que la configuración debe restaurarse completamente en la PIC de respaldo después de que se detecte un error.
Ciertas combinaciones de y warm-standby configuración no están permitidas y dan como resultado un error de hot-standby configuración. Se permiten los siguientes ejemplos:
-
Interfaz
rlsq0configurada conprimary lsq-0/0/0ywarm-standby, en combinación con la interfazrlsq0:0configurada conprimary lsq-0/0/0:0 -
Interfaz
rlsq0:0configurada conprimary lsq-0/0/0:0, en combinación con la interfazrlsq0:1configurada conprimary lsq-0/0/0:1
No se permiten las siguientes combinaciones de ejemplo:
-
Interfaz
rlsq0configurada conprimary lsq-0/0/0yhot-standby, en combinación con la interfazrlsq0:0configurada conprimary lsq-0/0/0:0 -
Interfaz
rlsq0:0configurada conprimary lsq-0/0/0:0, en combinación con la interfazrlsq1:0configurada conprimary lsq-0/0/0:0 -
Interfaz
rlsq0:0configurada conprimary lsq-0/0/0:1, en combinación con la interfazrlsq1:1configurada conprimary lsq-0/0/0:1 -
Interfaz
rlsq0configurada conprimary lsq-0/0/0, en combinación con la interfazrlsq1configurada conprimary lsq-0/0/0
Además, la misma interfaz física no se puede reutilizar como interfaz principal para más de una rlsq interfaz, ni tampoco ninguna de las interfaces lógicas asociadas. Por ejemplo, la interfaz lsq-0/0/0 principal no se puede reutilizar en otra rlsq interfaz como lsq-0/0/0:0.
Restricciones en interfaces LSQ redundantes
La falla de la PIC IQ de servicios de vínculo se produce en las siguientes condiciones:
-
La PIC principal no arranca. En este caso, la
rlsqinterfaz no aparece y es necesaria la intervención manual para reiniciar o reemplazar la PIC, o para cambiar el nombre de la PIC principal a la secundaria en larlsqconfiguración. -
Si no se cumplen las siguientes condiciones al configurar una
rlsqinterfaz:-
El número de unidad asignado a la
rlsqinterfaz es menor que el número de paquetes de interfaz Multilink Frame Relay de usuario de red y de red a red (UNI-NNI) (FRF.16) asignados en la PIC de servicios de vínculo. -
El identificador de conexión de vínculo de datos (DLCI) está configurado para la
rlsqinterfaz.
Si no se cumplen estas condiciones, la
rlsqinterfaz no arranca. Cuando se ejecuta elshow interfaces redundancycomando, el estado de larlsqinterfaz se indica comoWaiting for primary MS PIC. -
-
La PIC principal se activa y después se produce un error. La PIC secundaria se encarga automáticamente del procesamiento.
-
Se produce una tolerancia a fallos en la PIC secundaria. A continuación, se produce un error en la PIC secundaria. Si la PIC principal se restauró al estado activo, el procesamiento cambia a ella.
-
Se produce un error en la FPC que contiene la PIC IQ de servicios de vínculo.
Las siguientes restricciones se aplican a las configuraciones LSQ redundantes:
-
Recomendamos que las PIC principal y secundaria se configuren en dos FPC diferentes (en chasis que no sean enrutadores M10i).
-
No puede configurar una PIC IQ de servicios de vínculo con configuraciones de paquete explícitas y como componente de una
rlsqinterfaz. -
Las configuraciones LSQ redundantes proporcionan soporte GRES completo. (Debe configurar GRES en el
[edit chassis]nivel de jerarquía; consulte la biblioteca de administración de Junos OS para dispositivos de enrutamiento. -
Si configura la
redundancy-optionsinstrucción con lahot-standbyopción, la configuración debe incluir unprimaryvalor de interfaz y un valor desecondaryinterfaz. -
Dado que se utiliza el mismo nombre de interfaz para
hot-standbyywarm-standby, si modifica la configuración para cambiar este atributo, se recomienda desactivar primero la interfaz, confirmar la nueva configuración y, luego, volver a activar la interfaz. -
No se pueden realizar cambios en una configuración activa
redundancy-options. Debe desactivar la configuración de larlsqnumberinterfaz, cambiarla y volver a activarla. -
La
rlsqnumberconfiguración se activa solo si la interfaz principal está activa. Cuando la configuración se activa por primera vez, la interfaz principal debe estar activa; De lo contrario, larlsqinterfaz espera hasta que aparezca la interfaz principal. -
No puede modificar la configuración de las interfaces después de
lsqhaberlas incluido en una interfaz activarlsq. -
Todos los comandos del modo operativo que se aplican a las
rspinterfaces también se aplican a lasrlsqinterfaces. Puede emitirshowcomandos para larlsqinterfaz o para las interfaces principal y secundarialsq. Sin embargo, las estadísticas de las interfaces de vínculo no se transfieren después de una conmutación del motor de enrutamiento. -
Las
rlsqinterfaces también admiten la configuración, descrita en Configuración de la redundancia de interfaz LSQ en varios enrutadores utilizando APS SONET.lsq-failure-optionsSi se produce un error en las PIC IQ de servicios de vínculo principal y secundario y se configura lalsq-failure-optionsinstrucción, la configuración activa una conmutación de APS SONET. -
Las configuraciones LSQ redundantes que requieren MLPPP Multilink Frame Relay (FRF.15 y FRF.16) solo se admiten con la
warm-standbyopción. -
La compatibilidad con LSQ redundante se extiende a las interfaces de red ATM.
-
Las interfaces canalizadas se utilizan con paquetes FRF-16, por ejemplo
rlsq0:0. Elrlsqnúmero y sus componentes, lasprimaryesecondaryinterfaces, deben coincidir para que la configuración sea válida: todas deben estar canalizadas o ninguna. Para obtener un ejemplo de una configuración FRF.16, consulte #id-configuring-lsq-interface-redundancia-in-a-single-enrutador-using-virtual-interfaces__d85e790. -
Cuando configure una interfaz canalizada
rlsq, debe usar un número de índice de canal del 0 al 254.
Las PIC de servicios adaptativos y multiservicios en modo de capa 2 (en ejecución de servicios de capa 2) no se reinician cuando se detecta una situación de control de flujo MAC.
Configuración de la replicación del estado del vínculo para PIC de vínculo redundante
La replicación del estado del vínculo, también llamada preservación de interfaz, es una adición a la funcionalidad de conmutación automática de protección (APS) de SONET que ayuda a promover la redundancia de las PIC de vínculo utilizadas en las configuraciones de LSQ.
La replicación del estado de vínculos proporciona la capacidad de agregar dos conjuntos de vínculos, uno de la PIC SONET activa (en funcionamiento) y el otro de la PIC SONET de respaldo (protección) al mismo paquete. Si se produce un error en la PIC SONET activa, se utilizan los vínculos de la PIC en espera sin que se produzca una renegociación de vínculos. Todo el estado negociado se replica desde los vínculos activos a los vínculos en espera para evitar la renegociación de vínculos. Para obtener más información acerca de las configuraciones de APS SONET, consulte la biblioteca de interfaces de red de Junos OS para dispositivos de enrutamiento.
Para configurar la replicación del estado del vínculo, incluya la preserve-interface instrucción en el nivel de [edit interfaces interface-name sonet-options aps] jerarquía en ambas interfaces de red:
edit interfaces interface-name sonet-options aps] preserve-interface;
Las siguientes restricciones se aplican a la redundancia de PIC de vínculo:
-
La funcionalidad de APS debe estar disponible en las PIC SONET y las configuraciones de interfaz deben ser idénticas en ambos extremos del vínculo. Cualquier error de configuración hace que se produzca un error en la operación de confirmación.
-
Esta característica solo se admite con PIC de vínculo habilitadas para APS LSQ y SONET, incluidas las PIC de cola inteligente (IQ) OC3 canalizada, OC12 canalizada y STM1 canalizada.
-
La replicación de estado de vínculo admite MLPPP y PPP sobre encapsulación Frame Relay (
frame-relay-ppp) y es totalmente compatible con GRES. -
La habilitación de traceoptions de interfaz o protocolo con un gran número de vínculos MLPPP puede desencadenar la renegociación del protocolo de control de vínculos (LCP) durante el tiempo de conmutación del vínculo.
Nota:Es más probable que esta renegociación se lleve a cabo para configuraciones con enrutadores de Juniper Networks consecutivos que en redes en las que un enrutador de Juniper Networks está conectado a un multiplexor de adición/supresión (ADM).
-
En general, las redes que conectan un enrutador de Juniper Networks a un ADM permiten una conmutación de vínculo MLPPP más rápida que aquellas con enrutadores consecutivos de Juniper Networks. La diferencia de tiempo de conmutación del vínculo MLPPP puede ser significativa, especialmente para redes con un gran número de vínculos MLPPP.
-
Una configuración agresiva del tiempo de espera de mantenimiento de LCP puede dar lugar a la renegociación de LCP durante la conmutación del vínculo MLPPP. De forma predeterminada, el intervalo del temporizador de mantenimiento de LCP es de 10 segundos y el recuento descendente de vínculos consecutivos es 3. Los vínculos MLPPP inician la negociación LCP solo después de un tiempo de espera de 30 segundos. La reducción de estos valores de configuración puede hacer que uno o más de los vínculos MLPPP se renegocien durante el tiempo de conmutación.
Nota:Es más probable que la renegociación de LCP tenga lugar para configuraciones con enrutadores consecutivos de Juniper Networks que en redes en las que un enrutador de Juniper Networks está conectado a un ADM.
Como ejemplo, la siguiente configuración muestra la configuración de replicación del estado del vínculo entre los puertos coc3-1/0/0 y coc3-2/0/0.
interfaces {
coc3-1/0/0 {
sonet-options {
aps {
preserve-interface;
working-circuit aps-group-1;
}
}
}
coc3-2/0/0 {
sonet-options {
aps {
preserve-interface;
protect-circuit aps-group-1;
}
}
}
}
Ejemplos: Configuración de interfaces LSQ redundantes para la recuperación de errores
Configuración de la redundancia de interfaz LSQ para MLPPP
La siguiente configuración muestra que lsq-1/1/0 y lsq-1/3/0 funcionan como un par y el tipo de redundancia es hot-standby, lo que establece el requisito para que el tiempo de detección y recuperación de errores sea inferior a 5 segundos:
interfaces rlsq0 {
redundancy-options {
primary lsq-1/1/0;
secondary lsq-1/3/0;
hot-standby; #either hot-standby or warm-standby is supported
}
}
En el ejemplo siguiente se muestra una configuración MLPPP relacionada:
La configuración del protocolo MLPPP es necesaria para esta configuración.
interfaces {
t1-/1/2/0 {
unit 0 {
family mlppp {
bundle rlsq0.0;
}
}
}
rlsq0 {
unit 0 {
family inet {
address 10.30.1.2/24;
}
}
}
}
En el siguiente ejemplo, se muestra una configuración de CoS relacionada:
class-of-service {
interfaces {
rlsq0 {
unit * {
fragmentation-maps fr-map1;
}
}
}
}
En el siguiente ejemplo, se muestra una configuración completa de replicación del estado de vínculos para MLPPP. En este ejemplo, se utilizan dos paquetes, cada uno con cuatro vínculos T1. Los primeros cuatro enlaces T1 (t1-*:1 a t1-*:4través ) forman el primer paquete y los últimos cuatro enlaces T1 (t1-*:5 a través t1-*:8) forman el segundo paquete. Para minimizar la duplicación en la configuración, en este ejemplo se utiliza la [edit groups] instrucción; para obtener más información, consulte la biblioteca de administración de Junos OS para dispositivos de enrutamiento. Este tipo de configuración no es necesaria; Simplifica la tarea y minimiza la duplicación.
groups {
ml-partition-group {
interfaces {
<coc3-*> {
partition 1 oc-slice 1 interface-type coc1;
}
<coc1-*> {
partition 1-8 interface-type t1;
}
}
}
ml-bundle-group-1 {
interfaces {
<t1-*:"[1-4]"> {
encapsulation ppp;
unit 0 {
family mlppp {
bundle lsq-0/1/0.0;
}
}
}
}
}
ml-bundle-group-2 {
interfaces {
<t1-*:"[5-8]"> {
encapsulation ppp;
unit 0 {
family mlppp {
bundle lsq-0/1/0.1;
}
}
}
}
}
}
interfaces {
lsq-0/1/0 {
unit 0 {
encapsulation multilink-ppp;
family inet {
address 10.1.1.1/32 {
destination 10.1.1.2;
}
}
}
unit 1 {
encapsulation multilink-ppp;
family inet {
address 10.1.2.1/32 {
destination 10.1.2.2;
}
}
}
}
coc3-1/0/0 {
apply-groups ml-partition-group;
sonet-options {
aps {
preserve-interface;
working-circuit aps-group-1;
}
}
}
coc1-1/0/0:1 {
apply-groups ml-partition-group;
}
t1-1/0/0:1:1 {
apply-groups ml-bundle-group-1;
}
t1-1/0/0:1:2 {
apply-groups ml-bundle-group-1;
}
t1-1/0/0:1:3 {
apply-groups ml-bundle-group-1;
}
t1-1/0/0:1:4 {
apply-groups ml-bundle-group-1;
}
t1-1/0/0:1:5 {
apply-groups ml-bundle-group-2;
}
t1-1/0/0:1:6 {
apply-groups ml-bundle-group-2;
}
t1-1/0/0:1:7 {
apply-groups ml-bundle-group-2;
}
t1-1/0/0:1:8 {
apply-groups ml-bundle-group-2;
}
coc3-2/0/0 {
apply-groups ml-partition-group;
sonet-options {
aps {
preserve-interface;
protect-circuit aps-group-1;
}
}
}
coc1-2/0/0:1 {
apply-groups ml-partition-group;
}
t1-2/0/0:1:1 {
apply-groups ml-bundle-group-1;
}
t1-2/0/0:1:2 {
apply-groups ml-bundle-group-1;
}
t1-2/0/0:1:3 {
apply-groups ml-bundle-group-1;
}
t1-2/0/0:1:4 {
apply-groups ml-bundle-group-1;
}
t1-2/0/0:1:5 {
apply-groups ml-bundle-group-2;
}
t1-2/0/0:1:6 {
apply-groups ml-bundle-group-2;
}
t1-2/0/0:1:7 {
apply-groups ml-bundle-group-2;
}
t1-2/0/0:1:8 {
apply-groups ml-bundle-group-2;
}
}
Configuración de la redundancia de interfaz LSQ para un paquete FRF.15
En el siguiente ejemplo, se muestra una configuración para un paquete FRF.15:
interfaces rlsq0 {
redundancy-options {
primary lsq-1/2/0;
secondary lsq-1/3/0;
warm-standby; #either hot-standby or warm-standby is supported
}
unit 0 {
encapsulation multilink-frame-relay-end-to-end;
family inet {
address 10.30.1.1/24;
}
}
}
Configuración de la redundancia de interfaz LSQ para un paquete FRF.16
En el siguiente ejemplo, se muestra una configuración para un paquete FRF.16:
interfaces rlsq0:0 {
dce;
encapsulation multilink-frame-relay-uni-nni;
redundancy-options {
primary lsq-1/2/0:0;
secondary lsq-1/3/0:0;
warm-standby; #either hot-standby or warm-standby is supported
}
unit 0 {
dlci 1000;
family inet {
address 10.50.1.1/24;
}
}
}