Redundancia de interfaz de servicios de vínculo
Capacidades e interfaces del paquete de servicios de capa 2
Como se describe en Habilitación de paquetes de servicio, puede configurar el PIC de 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 se habilita el paquete de servicios de capa 2, el PIC de AS o multiservicios admite servicios de vínculo. En el AS o PIC multiservicios y el ASM, los servicios de vínculo incluyen lo siguiente:
Componentes de CoS de Junos: al configurar colas de programación de CoS en interfaces LSQ lógicas, se describe cómo funcionan los componentes de CoS de Junos en interfaces IQ (
lsq) de servicios de vínculo. Para obtener información detallada acerca de los componentes de Junos CoS, 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 multivínculo 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 un mapa 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 del entrelazado de paquetes sensibles a retrasos y Configuración de la fragmentación de CoS mediante clase de reenvío en interfaces LSQ.Intercalado 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, End-to-End Multilink Frame Relay Implementation Agreement.
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 Multilink Frame Relay UNI/NNI.
MLPPP: el estándar para MLPPP se define en la especificación RFC 1990, El protocolo multivínculo (MP) PPP.
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 PIC multiservicios, la sintaxis de configuración es casi la misma que para las PIC de servicios multivínculo y vínculo. La principal diferencia es el uso del descriptor lsq de tipo interfaz en lugar de ml o ls. Cuando se habilita el paquete de servicios de capa 2 en el AS o en la PIC 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 grde interfaz , , , , y son interfaces de túnel estándar que están disponibles en el AS o en la PIC multiservicio, vt ipmtpdpeindependientemente de que habilite el paquete de servicios de capa 2 o de capa 3. Estas interfaces de túnel funcionan de la misma manera para ambos paquetes de servicios, excepto que el paquete de servicios de capa 2 no admite algunas funciones de túnel, como se muestra en la tabla 5 de 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 Junos OS lo necesita. Para el paquete de servicios 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 a través lsq-fpc/pic/port:N representan 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 Configuración de colas de programación de CoS en interfaces LSQ lógicas.
En las interfaces DS0, E1 o T1 en 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 las franjas horarias, la trama y la codificación de bytes de la interfaz. Para obtener más información acerca de estas propiedades, consulte la Biblioteca de interfaces de red de Junos OS para dispositivos de enrutamiento.
Configuración de la redundancia de interfaz LSQ en varios enrutadores mediante SONET APS
Las interfaces IQ () de servicios de vínculo emparejadas con PIC SONET pueden utilizar la configuración de conmutación de protección automática (lsq-APS) ya disponible en las redes SONET para proporcionar recuperación de errores. SONET APS proporciona recuperación de fallos sin estado si se configura en interfaces SONET en chasis separados y cada PIC SONET está emparejado con un AS o PIC multiservicio en el mismo chasis. Si se cumple una de las siguientes condiciones para un error de APS, la PIC SONET asociada desencadena la recuperación en el circuito de respaldo y su PIC de multiservicio o AS asociada. Las condiciones de fallo son:
Error de PIC IQ de servicios de vínculo
Error de FPC que hospeda la PIC IQ de servicios de vínculo
Error del motor de reenvío de paquetes
Fallo del chasis
Las directrices para configurar SONET APS 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 conmutación por error:
- Configuración de la asociación entre interfaces LSQ y SONET
- Configuración de la interoperabilidad de SONET APS 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 AS o PIC multiservicios que hospedan 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/0archivos .El enrutador de respaldo incluye interfaces
oc3-2/2/0ylsq-3/2/0archivos .
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 el trigger-link-failure error a las PIC de 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 es compatible con el enrutador de reserva.
Para impedir que el enrutador envíe mensajes de solicitud de terminación PPP al host remoto si se produce un error en la PIC IQ de Link Services, 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 es compatible con las PIC de enlace. Para impedir que el enrutador envíe mensajes de solicitud de terminación PPP al host remoto si se produce un error en 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 sólo se admite con las configuraciones MLPPP y SONET APS, y funciona únicamente 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 SONET APS 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 jerárquico [edit interfaces lsq-fpc/pic/port mlfr-uni-nni-bundle-options] :
[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 vínculo de eliminación del Protocolo de integridad de vínculos cuando recibe un mensaje de rechazo de agregar vínculo.
Restricciones en la redundancia de APS para interfaces LSQ
Las siguientes restricciones se aplican a la recuperación de errores de LSQ:
Solo se aplica a las PIC IQ de servicios de vínculo instaladas en enrutadores de la serie M, excepto en el caso de 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 a las 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 entre chasis e intrachasis
La recuperación de errores no tiene estado; como resultado, se espera que la oscilación de la ruta y la pérdida del estado de vínculo en la recuperación entre chasis, lo que requiere la renegociación del PPP. En la recuperación intrachasis, no se prevé ningún impacto en el tráfico con la conmutación por error del motor de enrutamiento, pero la conmutación por error de PIC da como resultado la renegociación de PPP.
El cambio no es revertivo: cuando el hardware original se restaura al servicio, el tráfico no vuelve automáticamente a él.
El cambio normal de APS y el cambio de APS activado por PIC solo se pueden distinguir comprobando 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 automático del núcleo y el 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 capa 3.
Ver también
Configuración de la redundancia de interfaz LSQ en un único enrutador mediante SONET APS
El cambio sin estado de una PIC IQ de servicios de vínculo a otro dentro del mismo enrutador se puede configurar utilizando el mecanismo SONET APS descrito en Configuración de la redundancia de interfaz LSQ en varios enrutadores mediante SONET APS. Cada PIC IQ de servicios de vínculo debe estar asociado a una PIC de vínculo SONET especificada dentro del mismo enrutador.
Para una recuperación completa del intrachasis, incluida la recuperación de la conmutación por error del motor de enrutamiento, el cambio correcto del motor de enrutamiento (GRES) debe estar habilitado 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 interfaz LSQ en un único enrutador mediante interfaces virtuales
Puede configurar la recuperación de errores en enrutadores serie M, MX y T que tengan varias PIC y DPC de AS o multiservicios con lsq- interfaces especificando una interfaz de redundancia LSQ virtual (rlsq) en la que la PIC IQ principal de Link Services 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 le transfiere todo el procesamiento LSQ. Para determinar qué PIC está activo actualmente, ejecute el show interfaces redundancy comando.
Esta configuración no requiere el uso de SONET APS para la conmutación por error. 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 de estado de vínculo para PIC de vínculo redundantes
- Ejemplos: configuración de interfaces LSQ redundantes para 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, incluya la redundancy-options instrucción en el nivel de lsq [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 de 0 a 1023. Si se produce un error en la interfaz principal lsq , el procesamiento del tráfico cambia a la interfaz secundaria. La interfaz secundaria permanece activa incluso después de que la interfaz principal se recupera. Si se produce un error en la interfaz secundaria y la interfaz principal está activa, el procesamiento cambia a la interfaz principal.
La hot-standby opción se utiliza con configuraciones de redundancia uno a uno, en las que un PIC de trabajo es compatible con un PIC de respaldo. Es compatible con las 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 revertivo, pero puede cambiar manualmente entre las PIC principal y secundaria emitiendo el comando de request interfaces (revert | switchover) rlsqnumber modo 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 varias PIC en funcionamiento. Los tiempos de recuperación no están garantizados, ya que la configuración debe restaurarse completamente en el PIC de copia de seguridad después de que se detecte un error.
Ciertas combinaciones de y configuración no están permitidas y warm-standby dan lugar a un error de hot-standby configuración. Se permiten los siguientes ejemplos:
-
Interfaz
rlsq0configurada con ywarm-standby, en combinación con interfazrlsq0:0configurada conprimary lsq-0/0/0primary lsq-0/0/0:0 -
Interfaz
rlsq0:0configurada con , en combinación con interfazrlsq0:1configurada conprimary lsq-0/0/0:0primary lsq-0/0/0:1
No se permiten las siguientes combinaciones de ejemplo:
-
Interfaz
rlsq0configurada con yhot-standby, en combinación con interfazrlsq0:0configurada conprimary lsq-0/0/0primary lsq-0/0/0:0 -
Interfaz
rlsq0:0configurada con , en combinación con interfazrlsq1:0configurada conprimary lsq-0/0/0:0primary lsq-0/0/0:0 -
Interfaz
rlsq0:0configurada con , en combinación con interfazrlsq1:1configurada conprimary lsq-0/0/0:1primary lsq-0/0/0:1 -
Interfaz
rlsq0configurada con , en combinación con interfazrlsq1configurada conprimary lsq-0/0/0primary lsq-0/0/0
Además, no se puede reutilizar la misma interfaz física como interfaz principal para más de una rlsq interfaz, ni tampoco ninguna de las interfaces lógicas asociadas. Por ejemplo, la interfaz principal no se puede reutilizar en otra rlsq interfaz lsq-0/0/0 como lsq-0/0/0:0.
Restricciones en interfaces LSQ redundantes
El error de PIC IQ de los servicios de vínculo se produce en las siguientes condiciones:
-
El PIC principal no arranca. En este caso, la interfaz 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 la
rlsqrlsqconfiguración. -
Si no se cumplen las siguientes condiciones al configurar una
rlsqinterfaz:-
El número de unidad asignado a la interfaz es menor que el número de paquetes de interfaz de red a red (UNI-NNI) (FRF.16) de Multilink Frame Relay asignados en la
rlsqPIC 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. Al ejecutar elshow interfaces redundancycomando, el estado de larlsqinterfaz se indica comoWaiting for primary MS PIC. -
-
El PIC principal se activa y luego falla. La PIC secundaria se hace cargo automáticamente del procesamiento.
-
Se produce una conmutación por error al PIC secundario. A continuación, se produce un error en el PIC secundario. Si el PIC principal se ha restaurado al estado activo, el procesamiento cambia a él.
-
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:
-
Se recomienda que las PIC primarias y secundarias 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 nivel jerárquico
[edit chassis]; consulte la Biblioteca de administración de Junos OS para dispositivos de enrutamiento. -
Si configura la instrucción con la opción, la
redundancy-optionshot-standbyconfiguración debe incluir un valor de interfaz y unprimaryvalor desecondaryinterfaz. -
Dado que se utiliza el mismo nombre de interfaz para y , si modifica la configuración para
hot-standbycambiar este atributo, se recomienda desactivar primero la interfaz, confirmar la nueva configuración ywarm-standby, a continuación, reactivar la interfaz. -
No puede realizar cambios en una configuración activa
redundancy-options. Debe desactivar la configuración de larlsqnumberinterfaz, cambiarla y reactivarla. -
La
rlsqnumberconfiguración solo se activa si la interfaz principal está activa. Cuando se activa la configuración por primera vez, la interfaz principal debe estar activa; Si no es así, la interfaz espera hasta que aparezca larlsqinterfaz principal. -
No puede modificar la configuración de las interfaces después de
lsqque se hayan incluido en una interfaz activarlsq. -
Todos los comandos del modo operativo que se aplican a las interfaces también se aplican a
rsprlsqlas interfaces. 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 un cambio de motor de enrutamiento. -
Las
rlsqinterfaces también admiten la configuración, descrita en Configuración de la redundancia de interfaz LSQ en varios enrutadores mediante SONET APS.lsq-failure-optionsSi las PIC IQ de servicios de vínculo principales y secundarias fallan y se configura la instrucción, lalsq-failure-optionsconfiguración desencadena un cambio 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 redundante con LSQ 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, lasprimaryinterfaces ysecondary, deben coincidir para que la configuración sea válida: todos deben estar canalizados o ninguno. Para obtener un ejemplo de una configuración FRF.16, consulte #id-configuring-lsq-interface-redundancy-in-a-single-router-using-virtual-interfaces__d81e788. -
Al configurar una interfaz canalizada
rlsq, debe utilizar un número de índice de canal del 0 al 254.
Las PIC de servicios adaptativos y multiservicios en modo de capa 2 (que ejecutan servicios de capa 2) no se reinician cuando se detecta una situación de control de flujo de MAC.
Configuración de la replicación de estado de vínculo para PIC de vínculo redundantes
La replicación del estado del vínculo, también denominada conservación de interfaz, es una adición a la funcionalidad de conmutación de protección automática (APS) SONET que ayuda a promover la redundancia de las PIC de vínculo utilizadas en las configuraciones de LSQ.
La replicación del estado del vínculo permite agregar dos conjuntos de vínculos, uno desde la PIC SONET activa (en funcionamiento) y el otro desde la PIC SONET de copia de seguridad (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 provocar 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 del vínculo. Para obtener más información acerca de las configuraciones de SONET APS, consulte la Biblioteca de interfaces de red de Junos OS para dispositivos de enrutamiento.
Para configurar la replicación de estado de vínculo, incluya la preserve-interface instrucción en el nivel de jerarquía en ambas interfaces de [edit interfaces interface-name sonet-options aps] red:
edit interfaces interface-name sonet-options aps] preserve-interface;
Se aplican las siguientes restricciones a la redundancia PIC de vínculo:
-
La funcionalidad APS debe estar disponible en las PIC SONET y las configuraciones de interfaz deben ser idénticas en ambos extremos del vínculo. Cualquier falta de coincidencia de configuración hace que se produzca un error en la operación de confirmación.
-
Esta función solo se admite con las 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 encapsulación MLPPP y PPP a través de Frame Relay (
frame-relay-ppp) y es totalmente compatible con GRES. -
La habilitación de las 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 cambio de vínculo.
Nota:Es más probable que esta renegociación 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 multiplexor de adición o colocación (ADM).
-
En general, las redes que conectan un enrutador de Juniper Networks a un ADM permiten un cambio de vínculo MLPPP más rápido que aquellas con enrutadores de Juniper Networks consecutivos. La diferencia de tiempo de cambio de 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 keepalive de LCP puede llevar a la renegociación de LCP durante el cambio de vínculo MLPPP. De forma predeterminada, el intervalo del temporizador keepalive LCP es de 10 segundos y el recuento descendente de vínculos consecutivos es de 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 desencadenar la renegociación de uno o varios vínculos MLPPP 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 de estado de 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 recuperación de errores
Configuración de la redundancia de interfaz LSQ para MLPPP
La siguiente configuración muestra que y funciona como un par y lsq-1/3/0 el tipo de redundancia es hot-standby, lo que establece que el requisito para que lsq-1/1/0 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 de 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 ejemplo siguiente se muestra una configuración de CoS relacionada:
class-of-service {
interfaces {
rlsq0 {
unit * {
fragmentation-maps fr-map1;
}
}
}
}
En el ejemplo siguiente se muestra una configuración completa de replicación de estado de vínculo para MLPPP. En este ejemplo se utilizan dos paquetes, cada uno con cuatro vínculos T1. Los primeros cuatro enlaces T1 ( a ) forman el primer paquete y los últimos cuatro enlaces T1 (t1-*:1t1-*:5 a t1-*:4t1-*:8) forman el segundo paquete. Para minimizar la duplicación en la configuración, en este ejemplo se utiliza la instrucción; para obtener más información, consulte la [edit groups] 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 ejemplo siguiente 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 ejemplo siguiente 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;
}
}
}