Servicios Multlink en línea

PPP multivínculo en línea (MLPPP), relé de trama multivínculo (FRF.16) y relé de trama multivínculo de extremo a extremo (FRF.15) para multiplexación por división de tiempo (TDM) Las interfaces WAN proporcionan servicios de agrupación a través del motor de reenvío de paquetes sin necesidad de PIC ni concentrador de puerto denso (DPC).

Tradicionalmente, los servicios de agrupación se utilizan para agrupar varios vínculos de baja velocidad para crear una canalización de mayor ancho de banda. Este ancho de banda combinado está disponible para el tráfico de todos los vínculos y admite la fragmentación e intercalado de vínculos (LFI) en el paquete, lo que reduce el retraso en la transmisión de paquetes de alta prioridad.

Esta compatibilidad incluye varios vínculos en el mismo paquete, así como una extensión multiclase para MLPPP. A través de este servicio, puede habilitar servicios de agrupación sin ranuras DPC adicionales para admitir DPC de servicio y liberar las ranuras para otros MIC.

Nota:

MLPPP no es compatible con el chasis virtual de la serie MX.

A partir de Junos OS versión 15.1, puede configurar interfaces MLPPP en línea en enrutadores MX80, MX104, MX240, MX480 y MX960 con MICs de emulación de circuito E1/T1 canalizadas. Se admite un máximo de hasta ocho paquetes de interfaz MLPPP en línea en las MIC de emulación de circuito E1/T1 canalizado, de manera similar a la compatibilidad con los paquetes MLPPP en línea en otras MIC con las que son compatibles.

La configuración de interfaces MLPPP para WAN en línea beneficia a los siguientes servicios:

• Vínculo CE-PE para el servicio VPN y DIA de capa 3 con redes de acceso basadas en redes telefónicas públicas conmutadas (RTC).

• Vínculo PE-P cuando se usa RTC para redes MPLS.

Los siguientes proveedores de servicios utilizan esta característica:

• Proveedores de servicios que usan RTC para ofrecer servicio VPN y DIA de capa 3 con redes de acceso basadas en RTC a clientes de medianas o grandes empresas.

• Proveedores de servicios con redes centrales basadas en SONET.

La siguiente figura ilustra el alcance de esta característica:

Para conectar muchos sitios más pequeños en VPN, agrupar los circuitos TDM junto con la tecnología MLPPP / MLFR es la única forma de ofrecer un mayor ancho de banda y redundancia de vínculo.

MLPPP le permite agrupar varios vínculos PPP en un solo paquete multivínculo y MLFR le permite agrupar varios identificadores de conexión de vínculo de datos (DLCI) de Frame Relay en un solo paquete de múltiples vínculos. Los paquetes multivínculo proporcionan ancho de banda, equilibrio de carga y redundancia adicionales al agregar vínculos de baja velocidad, como T1, E1 y vínculos serie.

MLPPP es un protocolo para agregar múltiples enlaces constituyentes en un paquete PPP más grande. MLFR permite agregar varios vínculos de Frame Relay mediante multiplexación inversa. MLPPP y MLFR ofrecen opciones de servicio entre los servicios T1 y E1 de baja velocidad. Además de proporcionar ancho de banda adicional, agrupar varios vínculos puede agregar un nivel de tolerancia a errores al servicio de acceso dedicado. Dado que puede implementar la agrupación en varias interfaces, puede proteger a los usuarios contra la pérdida de acceso cuando falla una sola interfaz.

Para configurar MLPPP en línea para interfaces WAN, consulte:

• Ejemplo: configuración de MLPPP en línea y Multilink Frame Relay de extremo a extremo (FRF.15) para interfaces WAN

• Ejemplo: configuración de inline Multilink Frame Relay (FRF.16) para interfaces WAN

La sobrecarga de la capa de enlaces puede causar caídas de paquetes en los enlaces constituyentes debido al relleno de bits en los enlaces serie. El relleno de bits se utiliza para evitar que los datos se interpreten como información de control.

De forma predeterminada, el 4 por ciento del ancho de banda total del paquete se reserva para la sobrecarga de la capa de vínculo. En la mayoría de los entornos de red, la sobrecarga media de la capa de enlace es del 1,6 %. Por lo tanto, recomendamos el 4 por ciento como salvaguardia. Para obtener más información, consulte RFC 4814, Hash and Stuffing: Overlook Factors in Network Device Benchmarking.

Para las interfaces IQ (lsq-) de servicios de vínculo, puede configurar el porcentaje de ancho de banda del paquete que se reservará para la sobrecarga de la capa de vínculo. Para ello, incluya la link-layer-overhead instrucción:

Puede incluir esta instrucción en los siguientes niveles jerárquicos:

• [edit interfaces interface-name mlfr-uni-nni-bundle-options]

• [edit interfaces interface-name unit logical-unit-number]

• [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number]

Puede configurar el valor para que sea del 0 por ciento al 50 por ciento.

Para configurar un paquete xT1 mediante MLPPP, agregue N diferentes vínculos T1 en un Npaquete. El Npaquete xT1 se denomina interfaz lógica, ya que puede representar, por ejemplo, una adyacencia de enrutamiento. Para agregar vínculos T1 en un paquete MLPPP, incluya la bundle instrucción en el nivel de [edit interfaces t1-fpc/pic/port unit logical-unit-number family mlppp] jerarquía:

Nota:

Las interfaces IQ de servicios de vínculo admiten interfaces físicas T1 y E1. Estas instrucciones se aplican a las interfaces T1, pero la configuración de las interfaces E1 es similar.

Para configurar las propiedades de la interfaz IQ de servicios de vínculo, incluya las siguientes instrucciones en el nivel de [edit interfaces lsq-fpc/pic/port unit logical-unit-number] jerarquía:

Nota:

Los enrutadores de la serie ACX no admiten las propiedades de tiempo de espera y sobrecarga de capa de vínculo.

La interfaz IQ de servicios de vínculo lógico representa el paquete MLPPP. Para el paquete MLPPP, hay cuatro colas asociadas en los enrutadores de la serie M y ocho colas asociadas en los enrutadores de las series M320 y T. Un programador elimina paquetes de las colas de acuerdo con una política de programación. Normalmente, se designa una cola para que tenga prioridad estricta y las colas restantes se atienden en proporción a los pesos que configure.

Para MLPPP, asigne una única asignación de programador a la interfaz IQ de servicios de vínculo (lsq) y a cada vínculo constituyente. Los programadores predeterminados para los enrutadores serie M y T, que asignan un ancho de banda del 95, 0, 0 y 5 por ciento para la velocidad de transmisión y el tamaño del búfer de las colas 0, 1, 2 y 3, no son adecuados cuando se configura el tráfico LFI o multiclase. Por lo tanto, para MLPPP, debe configurar un único programador con velocidades de transmisión porcentuales distintas de cero y tamaños de búfer para las colas 0 a 3, y asignar este programador a la interfaz IQ de servicios de vínculo (lsq) y a cada vínculo constituyente, como se muestra en Ejemplo: Configuración de una interfaz LSQ como un paquete NxT1 usando MLPPP.

Nota:

Para los enrutadores de las series M320 y T, la velocidad de transmisión predeterminada del programador y los porcentajes de tamaño de búfer para las colas 0 a 7 son 95, 0, 0, 5, 0, 0, 0 y 0 por ciento.

Si el vínculo miembro que pertenece a una interfaz de paquete MLPP, MLFR o MFR se mueve a otra interfaz de paquete, o los vínculos se intercambian entre dos interfaces de paquete, se requiere una confirmación entre las operaciones delete y add para garantizar que la configuración se aplica correctamente.

Si el paquete tiene más de un vínculo, debe incluir la per-unit-scheduler instrucción en el nivel de [edit interfaces lsq-fpc/pic/port] jerarquía:

Para configurar y aplicar la directiva de programación, incluya las siguientes instrucciones en el [edit class-of-service] nivel jerárquico:

Para las interfaces IQ de servicios de vínculo, una cola de prioridad alta estricta puede privar a las otras tres colas porque el tráfico en una cola de prioridad estricta alta se transmite antes de que se preste servicio a cualquier otra cola. Esta implementación es diferente de la implementación estándar de CoS de Junos en la que una cola estricta de prioridad alta realiza round-robin con colas de alta prioridad, como se describe en la Guía del usuario de clase de servicio (enrutadores y conmutadores EX9200).

Después de que el programador elimina un paquete de una cola, se realiza una determinada acción. La acción depende de si el paquete proviene de una cola encapsulada multivínculo (fragmentada y secuenciada) o de una cola no encapsulada (hash sin fragmentación). Cada cola se puede designar como encapsulada o no encapsulada multivínculo, independientemente de la otra. De forma predeterminada, el tráfico de todas las clases de reenvío está encapsulado en multivínculo. Para configurar el control de fragmentación de paquetes en una cola, incluya la fragmentation-maps instrucción en el nivel de [edit class-of-service] jerarquía:

Para Nlos paquetes xT1 que utilizan MLPPP, el equilibrio de carga en bytes que se usa en las colas encapsuladas en varios vínculos es superior al equilibrio de carga en términos de flujo utilizado en las colas no encapsuladas. Todas las demás consideraciones son iguales. Por lo tanto, le recomendamos que configure todas las colas para que estén encapsuladas en multivínculo. Para ello, incluya la instrucción en la fragment-threshold configuración. Si decide establecer el tráfico de una cola como no encapsulado en lugar de encapsulado multivínculo, incluya la no-fragmentation instrucción en el mapa de fragmentación. Utilice la multilink-class instrucción para asignar una clase de reenvío en un MLPPP multiclase (MCML). . Para obtener más información acerca de las asignaciones de fragmentación, consulte Configuración de la fragmentación de CoS mediante clase de reenvío en interfaces LSQ.

Cuando se elimina un paquete de una cola encapsulada en multivínculo, el software le da al paquete un encabezado MLPPP. El encabezado MLPPP contiene un campo de número de secuencia, que se rellena con el siguiente número de secuencia disponible de un contador. Luego, el software coloca el paquete en uno de los N diferentes enlaces T1. El vínculo se elige paquete por paquete para equilibrar la carga entre los distintos vínculos T1.

Si el paquete supera la MTU de vínculo mínimo, o si una cola tiene un umbral de fragmento configurado en el nivel de jerarquía, el software divide el paquete en dos o más fragmentos, a los que se asignan números de [edit class-of-service fragmentation-maps map-name forwarding-class class-name] secuencia multivínculo consecutivos. El vínculo saliente de cada fragmento se selecciona independientemente de todos los demás fragmentos.

Si no incluye la instrucción en la fragment-threshold asignación de fragmentación, el umbral de fragmentación establecido en el nivel de jerarquía es el predeterminado para todas las clases de [edit interfaces interface-name unit logical-unit-number] reenvío. Si no establece un tamaño máximo de fragmento en ninguna parte de la configuración, los paquetes se fragmentarán si superan la MTU más pequeña de todos los vínculos del paquete.

Aunque no establezca un tamaño máximo de fragmento en ninguna parte de la configuración, puede configurar la unidad reconstruida máxima recibida (MRRU) incluyendo la mrru instrucción en el nivel de [edit interfaces lsq-fpc/pic/port unit logical-unit-number] jerarquía. La MRRU es similar a la MTU, pero es específica de las interfaces de servicios de vínculo. De forma predeterminada, el tamaño de MRRU es de 1500 bytes y puede configurarlo para que sea de 1500 a 4500 bytes. Para obtener más información, consulte Configuración de MRRU en interfaces lógicas de multivínculo y servicios de vínculo.

Cuando se retira un paquete de una cola no encapsulada, se transmite con un encabezado PPP simple. Dado que no hay un encabezado MLPPP, no hay información de número de secuencia. Por lo tanto, el software debe tomar medidas especiales para evitar la reordenación de paquetes. Para evitar el reordenamiento de paquetes, el software coloca el paquete en uno de los N diferentes enlaces T1. El vínculo se determina mediante el hash de los valores del encabezado. Para IP, el software calcula el hash en función de la dirección de origen, la dirección de destino y el protocolo IP. Para MPLS, el software calcula el hash basado en hasta cinco etiquetas MPLS, o cuatro etiquetas MPLS y el encabezado IP.

Para UDP y TCP, el software calcula el hash en función de los puertos de origen y destino, así como de las direcciones IP de origen y destino. Esto garantiza que todos los paquetes que pertenecen al mismo flujo TCP/UDP siempre pasan por el mismo enlace T1 y, por lo tanto, no se pueden reordenar. Sin embargo, no garantiza que la carga en los diversos enlaces T1 esté equilibrada. Si hay muchos flujos, la carga suele estar equilibrada.

Las N diferentes interfaces T1 se vinculan a otro enrutador, que puede ser de Juniper Networks u otro proveedor. El enrutador en el otro extremo recoge paquetes de todos los enlaces T1. Si un paquete tiene un encabezado MLPPP, el campo de número de secuencia se utiliza para volver a colocar el paquete en orden de número de secuencia. Si el paquete tiene un encabezado PPP simple, el software acepta el paquete en el orden en que llega y no hace ningún intento de volver a ensamblar o reordenar el paquete.

Para configurar un paquete xT1 mediante FRF.16, agregue N diferentes vínculos T1 en un Npaquete. El Npaquete xT1 lleva una cantidad potencialmente grande de PVC Frame Relay, identificados por sus DLCI. Cada DLCI se denomina interfaz lógica, ya que puede representar, por ejemplo, una adyacencia de enrutamiento.

Para agregar vínculos T1 en un paquete FRF.16, incluya la instrucción en el nivel de jerarquía e incluya la mlfr-uni-nni-bundles bundle instrucción en el nivel de [edit chassis fpc slot-number pic slot-number] [edit interfaces t1-fpc/pic/port unit logical-unit-number family mlfr-uni-nni] jerarquía:

Nota:

Las interfaces IQ de servicios de vínculo admiten interfaces físicas T1 y E1. Estas instrucciones se aplican a las interfaces T1, pero la configuración de las interfaces E1 es similar.

Para configurar las propiedades de la interfaz IQ de servicios de vínculo, incluya las siguientes instrucciones en el nivel de [edit interfaces lsq- fpc/pic/port:channel] jerarquía:

El canal IQ de servicios de vínculo representa el paquete FRF.16. Cuatro colas están asociadas a cada DLCI. Un programador elimina paquetes de las colas de acuerdo con una política de programación. En la interfaz IQ de servicios de vínculo, normalmente designa una cola para que tenga prioridad estricta. Las colas restantes se atienden en proporción a los pesos que configure.

Para las interfaces IQ de servicios de vínculo, una cola de prioridad alta estricta puede privar a las otras tres colas porque el tráfico en una cola de prioridad alta estricta se transmite antes de que se preste servicio a cualquier otra cola. Esta implementación es diferente de la implementación estándar de CoS de Junos en la que una cola estricta de prioridad alta realiza round-robin con colas de alta prioridad, como se describe en la Guía del usuario de clase de servicio (enrutadores y conmutadores EX9200).

Si el paquete tiene más de un vínculo, debe incluir la per-unit-scheduler instrucción en el nivel de [edit interfaces lsq-fpc/pic/port:channel] jerarquía:

Para FRF.16, puede asignar una única asignación de programador a la interfaz IQ de servicios de vínculo (lsq) y a cada DLCI IQ de servicios de enlace, o puede asignar diferentes asignaciones de programador a los distintos DLCI del paquete, como se muestra en Ejemplo: Configuración de una interfaz LSQ como un paquete NxT1 usando FRF.16.

Para los vínculos constituyentes de un paquete FRF.16, no es necesario configurar un programador personalizado. Dado que LFI y multiclase no son compatibles con FRF.16, el tráfico de cada vínculo constituyente se transmite desde la cola 0. Esto significa que debe permitir que la cola 0 utilice la mayor parte del ancho de banda. Para los enrutadores serie M y T, la velocidad de transmisión predeterminada de los programadores y los porcentajes de tamaño de búfer para las colas 0 a 3 son 95, 0, 0 y 5 por ciento. Estos programadores predeterminados envían todo el tráfico de usuarios a la cola 0 y todo el tráfico de control de red a la cola 3 y, por lo tanto, se adaptan bien al comportamiento de FRF.16. Si lo desea, puede configurar un programador personalizado que replique explícitamente el comportamiento de cola del 95, 0, 0 y 5 por ciento, y aplicarlo a los vínculos de los componentes.

Nota:

Para los enrutadores de las series M320 y T, la velocidad de transmisión predeterminada del programador y los porcentajes de tamaño de búfer para las colas 0 a 7 son 95, 0, 0, 5, 0, 0, 0 y 0 por ciento.

Si el vínculo miembro que pertenece a una interfaz de paquete MLPP, MLFR o MFR se mueve a otra interfaz de paquete, o los vínculos se intercambian entre dos interfaces de paquete, se requiere una confirmación entre las operaciones delete y add para garantizar que la configuración se aplica correctamente.

Para configurar y aplicar la directiva de programación, incluya las siguientes instrucciones en el [edit class-of-service] nivel jerárquico:

Para configurar el control de fragmentación de paquetes en una cola, incluya la fragmentation-maps instrucción en el nivel de [edit class-of-service] jerarquía:

Para el tráfico FRF.16, solo se admiten colas encapsuladas (fragmentadas y secuenciadas) multivínculo. Este es el comportamiento de cola predeterminado para todas las clases de reenvío. FRF.16 no permite el tráfico no encapsulado porque el protocolo requiere que todos los paquetes lleven el encabezado de fragmentación. Si un paquete grande se divide en varios fragmentos, los fragmentos deben tener números secuenciales consecutivos. Por lo tanto, no puede incluir la no-fragmentation instrucción en el nivel de jerarquía para el [edit class-of-service fragmentation-maps map-name forwarding-class class-name] tráfico FRF.16. Para FRF.16, si desea transportar voz o cualquier otro tráfico sensible a la latencia, no debe usar vínculos lentos. A velocidades T1 y superiores, el retraso de serialización es lo suficientemente pequeño como para que no sea necesario usar LFI explícito.

Cuando se elimina un paquete de una cola encapsulada en multivínculo, el software le da al paquete un encabezado FRF.16. El encabezado FRF.16 contiene un campo de número de secuencia, que se rellena con el siguiente número de secuencia disponible de un contador. Luego, el software coloca el paquete en uno de los N diferentes enlaces T1. El vínculo se elige paquete por paquete para equilibrar la carga entre los distintos vínculos T1.

Si el paquete supera la MTU de vínculo mínimo, o si una cola tiene un umbral de fragmento configurado en el nivel de jerarquía, el software divide el paquete en dos o más fragmentos, a los que se asignan números de [edit class-of-service fragmentation-maps map-name forwarding-class class-name] secuencia multivínculo consecutivos. El vínculo saliente de cada fragmento se selecciona independientemente de todos los demás fragmentos.

Si no incluye la instrucción en la fragment-threshold asignación de fragmentación, el umbral de fragmentación establecido en el nivel de jerarquía o [edit interfaces interface-name mlfr-uni-nni-bundle-options] es el predeterminado para todas las clases de [edit interfaces interface-name unit logical-unit-number] reenvío. Si no establece un tamaño máximo de fragmento en ninguna parte de la configuración, los paquetes se fragmentarán si superan la MTU más pequeña de todos los vínculos del paquete.

Aunque no establezca un tamaño máximo de fragmento en ninguna parte de la configuración, puede configurar la unidad reconstruida máxima recibida (MRRU) incluyendo la mrru instrucción en el nivel de [edit interfaces lsq-fpc/pic/port unit logical-unit-number] jerarquía o[edit interfaces interface-name mlfr-uni-nni-bundle-options]. La MRRU es similar a la MTU, pero es específica para las interfaces de servicios de vínculo. De forma predeterminada, el tamaño de MRRU es de 1500 bytes y puede configurarlo para que sea de 1500 a 4500 bytes. Para obtener más información, consulte Configuración de MRRU en interfaces lógicas de multivínculo y servicios de vínculo.

Las N diferentes interfaces T1 se vinculan a otro enrutador, que puede ser de Juniper Networks u otro proveedor. El enrutador en el otro extremo recoge paquetes de todos los enlaces T1. Dado que cada paquete tiene un encabezado FRF.16, el campo de número de secuencia se utiliza para volver a colocar el paquete en orden de número de secuencia.

En este ejemplo se configura un Npaquete xT1 mediante FRF.15 en una interfaz IQ de servicios de vínculo. FRF.15 es similar a FRF.12, como se describe en Configuración de interfaces LSQ para interfaces T1 o E1 fraccionales simples mediante FRF.12. La diferencia es que FRF.15 admite múltiples enlaces físicos en un paquete, mientras que FRF.12 solo admite un enlace físico por paquete. Para la implementación de FRF.15 de Junos OS, puede configurar un DLCI por vínculo físico.

Nota:

Las interfaces IQ de servicios de vínculo admiten interfaces físicas T1 y E1. En este ejemplo se hace referencia a interfaces T1, pero la configuración de interfaces E1 es similar.

Cuando se configura una única interfaz T1 fraccionaria, se denomina interfaz lógica, ya que puede representar, por ejemplo, una adyacencia de enrutamiento.

La interfaz IQ de servicios de vínculo lógico representa el paquete MLPPP. Cuatro colas están asociadas a la interfaz lógica. Un programador elimina paquetes de las colas de acuerdo con una política de programación. Normalmente, se designa una cola para que tenga prioridad estricta y las colas restantes se atienden en proporción a los pesos que configure.

Para configurar una única interfaz T1 fraccional mediante MLPPP y LFI, asocie una interfaz DS0 (T1 fraccional) a una interfaz IQ de servicios de vínculo. Para asociar una interfaz T1 fraccionaria con una interfaz IQ de servicios de vínculo, incluya la bundle instrucción en el nivel de [edit interfaces ds-fpc/pic/port:channel unit logical-unit-number family mlppp] jerarquía:

Nota:

Las interfaces IQ de servicios de vínculo admiten interfaces físicas T1 y E1. Estas instrucciones se aplican a las interfaces T1, pero la configuración de las interfaces E1 es similar.

Para configurar las propiedades de la interfaz IQ de servicios de vínculo, incluya las siguientes instrucciones en el nivel de [edit interfaces lsq-fpc/pic/port unit logical-unit-number] jerarquía:

Para MLPPP, asigne una única asignación de programador a la interfaz IQ (lsq) de los servicios de vínculo y a cada vínculo constituyente. Los programadores predeterminados para los enrutadores serie M y T, que asignan un ancho de banda del 95, 0, 0 y 5 por ciento para la velocidad de transmisión y el tamaño del búfer de las colas 0, 1, 2 y 3, no son adecuados cuando se configura el tráfico LFI o multiclase. Por lo tanto, para MLPPP, debe configurar un único programador con velocidades de transmisión y tamaños de búfer porcentuales distintos de cero para las colas 0 a 3, y asignar este programador a la interfaz IQ (lsq) de servicios de vínculo y a cada vínculo constituyente y a cada vínculo constituyente, como se muestra en Ejemplo: Configuración de una interfaz LSQ para una interfaz T1 fraccional mediante MLPPP y LFI.

Nota:

Para los enrutadores de las series M320 y T, la velocidad de transmisión predeterminada del programador y los porcentajes de tamaño de búfer para las colas 0 a 7 son 95, 0, 0, 5, 0, 0, 0 y 0 por ciento.

Para configurar y aplicar la directiva de programación, incluya las siguientes instrucciones en el [edit class-of-service] nivel jerárquico:

Para las interfaces IQ de servicios de vínculo, una cola de prioridad alta estricta puede privar a todas las demás colas, ya que el tráfico en una cola de prioridad estricta alta se transmite antes de que se preste servicio a cualquier otra cola. Esta implementación es diferente a la implementación estándar de Junos CoS en la que una cola estricta de alta prioridad recibe créditos infinitos y realiza round-robin con colas de alta prioridad, como se describe en la Guía del usuario de clase de servicio (enrutadores y conmutadores EX9200).

Después de que el programador elimina un paquete de una cola, se realiza una determinada acción. La acción depende de si el paquete proviene de una cola encapsulada multivínculo (fragmentada y secuenciada) o de una cola no encapsulada (hash sin fragmentación). Cada cola se puede designar como encapsulada o no encapsulada multivínculo, independientemente de la otra. De forma predeterminada, el tráfico de todas las clases de reenvío está encapsulado en multivínculo. Para configurar el control de fragmentación de paquetes en una cola, incluya la fragmentation-maps instrucción en el nivel de [edit class-of-service] jerarquía:

Si necesita que la cola transmita paquetes pequeños con baja latencia, configure la cola para que no esté encapsulada incluyendo la no-fragmentation instrucción. Si necesita que la cola transmita paquetes grandes con latencia normal, configure la cola para que esté encapsulada en multivínculo incluyendo la fragment-threshold instrucción. Si necesita que la cola transmita paquetes grandes con baja latencia, se recomienda usar un vínculo más rápido y configurar la cola para que no esté encapsulada. Para obtener más información acerca de las asignaciones de fragmentación, consulte Configuración de la fragmentación de CoS mediante clase de reenvío en interfaces LSQ.

Cuando se elimina un paquete de una cola encapsulada en multivínculo, se fragmenta. Si el paquete supera la MTU de vínculo mínimo, o si una cola tiene un umbral de fragmento configurado en el nivel de jerarquía, el software divide el paquete en dos o más fragmentos, a los que se asignan números de [edit class-of-service fragmentation-maps map-name forwarding-class class-name] secuencia multivínculo consecutivos.

Si no incluye la instrucción en la fragment-threshold asignación de fragmentación, el umbral de fragmentación establecido en el nivel de jerarquía es el predeterminado para todas las clases de [edit interfaces interface-name unit logical-unit-number] reenvío. Si no establece un tamaño máximo de fragmento en ninguna parte de la configuración, los paquetes se fragmentarán si superan la MTU más pequeña de todos los vínculos del paquete.

Aunque no establezca un tamaño máximo de fragmento en ninguna parte de la configuración, puede configurar la unidad reconstruida máxima recibida (MRRU) incluyendo la mrru instrucción en el nivel de [edit interfaces lsq-fpc/pic/port unit logical-unit-number] jerarquía. La MRRU es similar a la MTU, pero es específica de las interfaces de servicios de vínculo. De forma predeterminada, el tamaño de MRRU es de 1500 bytes y puede configurarlo para que sea de 1500 a 4500 bytes. Para obtener más información, consulte Configuración de MRRU en interfaces lógicas de multivínculo y servicios de vínculo.

Cuando se elimina un paquete de una cola encapsulada en multivínculo, el software le da al paquete un encabezado MLPPP. El encabezado MLPPP contiene un campo de número de secuencia, que se rellena con el siguiente número de secuencia disponible de un contador. Luego, el software coloca el paquete en el enlace T1 fraccionario. El tráfico de otra cola puede intercalarse entre dos fragmentos del paquete.

Cuando se retira un paquete de una cola no encapsulada, se transmite con un encabezado PPP simple. El paquete se coloca en el enlace fraccional T1 tan pronto como sea posible. Si es necesario, el paquete se coloca entre los fragmentos de un paquete de otra cola.

La interfaz T1 fraccional se vincula a otro enrutador, que puede ser de Juniper Networks u otro proveedor. El enrutador en el extremo lejano recopila paquetes del vínculo T1 fraccionario. Si un paquete tiene un encabezado MLPPP, el software asume que el paquete es un fragmento de un paquete más grande y el campo de número de fragmento se utiliza para volver a ensamblar el paquete más grande. Si el paquete tiene un encabezado PPP simple, el software acepta el paquete en el orden en que llega, y el software no hace ningún intento de volver a ensamblar o reordenar el paquete.

Para configurar una única interfaz T1 fraccionaria mediante FRF.16, asocie una interfaz DS0 a una interfaz IQ (lsq) de servicios de vínculo. Cuando configura un solo T1 fraccional, el T1 fraccional lleva un número potencialmente grande de PVC Frame Relay identificados por sus DLCI. Cada DLCI se denomina interfaz lógica, ya que puede representar, por ejemplo, una adyacencia de enrutamiento. Para asociar la interfaz DS0 con una interfaz IQ de servicios de vínculo, incluya la bundle instrucción en el nivel de [edit interfaces ds-fpc/pic/port:channel unit logical-unit-number family mlfr-end-to-end] jerarquía:

Nota:

Las interfaces IQ de servicios de vínculo admiten interfaces físicas T1 y E1. Estas instrucciones se aplican a las interfaces T1, pero la configuración de las interfaces E1 es similar.

Para configurar las propiedades de la interfaz IQ de servicios de vínculo, incluya las siguientes instrucciones en el nivel de [edit interfaces lsq-fpc/pic/port unit logical-unit-number] jerarquía:

La interfaz IQ de servicios de vínculo lógico representa el paquete FRF.12. Cada interfaz lógica asocia cuatro colas. Un programador elimina paquetes de las colas de acuerdo con una política de programación. Normalmente, se designa una cola para que tenga prioridad estricta y las colas restantes se atienden en proporción a los pesos que configure.

Para FRF.12, asigne una única asignación de programador a la interfaz IQ de servicios de vínculo (lsq) y a cada vínculo constituyente. Para los enrutadores serie M y T, los programadores predeterminados, que asignan un ancho de banda del 95, 0, 0 y 5 por ciento para la velocidad de transmisión y el tamaño del búfer de las colas 0, 1, 2 y 3, no son adecuados cuando se configura el tráfico LFI o multiclase. Por lo tanto, para FRF.12, debe configurar programadores con velocidades de transmisión porcentuales y tamaños de búfer distintos de cero para las colas 0 a 3, y asignarlos a la interfaz IQ de servicios de vínculo (lsq) y a cada vínculo constituyente, como se muestra en Ejemplos: Configuración de una interfaz LSQ para una interfaz T1 fraccionaria mediante FRF.12.

Nota:

Para los enrutadores de las series M320 y T, la velocidad de transmisión predeterminada del programador y los porcentajes de tamaño de búfer para las colas 0 a 7 son 95, 0, 0, 5, 0, 0, 0 y 0 por ciento.

Para configurar y aplicar la directiva de programación, incluya las siguientes instrucciones en el [edit class-of-service] nivel jerárquico:

Para las interfaces IQ de servicios de vínculo, una cola de prioridad alta estricta puede privar a las otras tres colas porque el tráfico en una cola de prioridad alta estricta se transmite antes de que se preste servicio a cualquier otra cola. Esta implementación es diferente de la implementación estándar de CoS de Junos en la que una cola estricta de prioridad alta realiza round-robin con colas de alta prioridad, como se describe en la Guía del usuario de clase de servicio (enrutadores y conmutadores EX9200).

Después de que el programador elimina un paquete de una cola, se realiza una determinada acción. La acción depende de si el paquete proviene de una cola encapsulada multivínculo (fragmentada y secuenciada) o de una cola no encapsulada (hash sin fragmentación). Cada cola se puede designar como encapsulada o no encapsulada multivínculo, independientemente de la otra. De forma predeterminada, el tráfico de todas las clases de reenvío está encapsulado en multivínculo. Para configurar el control de fragmentación de paquetes en una cola, incluya la fragmentation-maps instrucción en el nivel de [edit class-of-service] jerarquía:

Si necesita que la cola transmita paquetes pequeños con baja latencia, configure la cola para que no esté encapsulada incluyendo la no-fragmentation instrucción. Si necesita que la cola transmita paquetes grandes con latencia normal, configure la cola para que esté encapsulada en multivínculo incluyendo la fragment-threshold instrucción. Si necesita que la cola transmita paquetes grandes con baja latencia, se recomienda usar un vínculo más rápido y configurar la cola para que no esté encapsulada. Para obtener más información acerca de las asignaciones de fragmentación, consulte Configuración de la fragmentación de CoS mediante clase de reenvío en interfaces LSQ.

Cuando se elimina un paquete de una cola encapsulada en multivínculo, se fragmenta. Si el paquete supera la MTU de vínculo mínimo, o si una cola tiene un umbral de fragmento configurado en el nivel de jerarquía, el software divide el paquete en dos o más fragmentos, a los que se asignan números de [edit class-of-service fragmentation-maps map-name forwarding-class class-name] secuencia multivínculo consecutivos.

Si no incluye la instrucción en la fragment-threshold asignación de fragmentación, el umbral de fragmentación establecido en el nivel de jerarquía es el predeterminado para todas las clases de [edit interfaces interface-name unit logical-unit-number] reenvío. Si no establece un tamaño máximo de fragmento en ninguna parte de la configuración, los paquetes se fragmentarán si superan la MTU más pequeña de todos los vínculos del paquete.

Aunque no establezca un tamaño máximo de fragmento en ninguna parte de la configuración, puede configurar la unidad reconstruida máxima recibida (MRRU) incluyendo la mrru instrucción en el nivel de [edit interfaces lsq-fpc/pic/port unit logical-unit-number] jerarquía. La MRRU es similar a la MTU, pero es específica para las interfaces de servicios de vínculo. De forma predeterminada, el tamaño de MRRU es de 1500 bytes y puede configurarlo para que sea de 1500 a 4500 bytes. Para obtener más información, consulte Configuración de MRRU en interfaces lógicas de multivínculo y servicios de vínculo.

Cuando se elimina un paquete de una cola encapsulada en multivínculo, el software le da al paquete un encabezado FRF.12. El encabezado FRF.12 contiene un campo de número de secuencia, que se rellena con el siguiente número de secuencia disponible de un contador. Luego, el software coloca el paquete en el enlace T1 fraccionario. El tráfico de otra cola puede intercalarse entre dos fragmentos del paquete.

Cuando se extrae un paquete de una cola no encapsulada, se transmite con un encabezado Frame Relay sin formato. El paquete se coloca en el enlace fraccional T1 tan pronto como sea posible. Si es necesario, el paquete se coloca entre los fragmentos de un paquete de otra cola.

La interfaz T1 fraccional se vincula a otro enrutador, que puede ser de Juniper Networks u otro proveedor. El enrutador en el extremo lejano recopila paquetes del vínculo T1 fraccionario. Si un paquete tiene un encabezado FRF.12, el software asume que el paquete es un fragmento de un paquete más grande y el campo de número de fragmento se utiliza para volver a ensamblar el paquete más grande. Si el paquete tiene un encabezado Frame Relay sin formato, el software acepta el paquete en el orden en que llega y el software no intenta volver a ensamblar o reordenar el paquete.

Un paquete completo de una cola no encapsulada se puede colocar entre fragmentos de una cola encapsulada en varios vínculos. Sin embargo, los fragmentos de una cola encapsulada en multivínculo no se pueden intercalar con fragmentos de otra cola encapsulada en multivínculo. Esta es la intención de la especificación FRF.12, Acuerdo de implementación de fragmentación de relé de marco. Si se intercalan fragmentos de dos colas diferentes, es posible que los campos de encabezado no tengan suficiente información para separarlos.

En este ejemplo se agrupa una única interfaz T3 en una interfaz IQ de servicios de vínculo con encapsulación MLPPP. El enlace de una única interfaz T3 a un paquete multivínculo permite configurar RTP comprimido (CRTP) en la interfaz T3.

Este escenario solo se aplica a los paquetes MLPPP. Junos OS no admite actualmente CRTP a través de Frame Relay. Para obtener más información, consulte Configuración de interfaces de servicios para servicios de voz.

No es necesario configurar LFI a velocidades DS3, ya que el retraso de serialización de paquetes es insignificante.

Esta configuración utiliza una asignación de fragmentación predeterminada, que da como resultado que todas las clases de reenvío (colas) se envíen con un encabezado multivínculo.

Para eliminar los encabezados multivínculo, puede configurar un mapa de fragmentación en el que todas las colas tengan la instrucción en el nivel de jerarquía y adjuntar el mapa de [edit class-of-service fragmentation-maps map-name forwarding-class class-name] fragmentación a la no-fragmentation lsq-1/3/0.1 interfaz, como se muestra a continuación:

En este ejemplo se configura una interfaz T3 u OC3 de canal claro con varias interfaces lógicas (DLCI) en el vínculo. En este escenario, cada DLCI representa un cliente. Los DLCI se configuran en la PIC de salida a una velocidad determinada (NxDS0). Esto le permite configurar LFI mediante DLCI del protocolo de extremo a extremo FRF.12 en DLCI de Frame Relay.

Para ello, configure primero las interfaces lógicas (DLCI) en la interfaz física. Luego agrupe los DLCI, de modo que solo haya un DLCI por paquete.

La interfaz física debe ser capaz de programar por DLCI, lo que le permite asociar velocidades de modelación a cada DLCI. Para obtener más información, consulte la Biblioteca de interfaces de red de Junos OS para dispositivos de enrutamiento.

Para evitar caídas de fragmentos en la PIC de salida, debe asignar una velocidad de modelación a las interfaces lógicas IQ de servicios de vínculo y a los DLCI de salida. Las velocidades de modelación de los DLCI especifican cuánto ancho de banda hay disponible para cada DLCI. La velocidad de modelación en las interfaces IQ de servicios de vínculo debe coincidir con la velocidad de modelación asignada al DLCI asociado con el paquete.

Las interfaces de salida también deben tener un mapa de programador adjunto. La cola que transmite voz debe ser de prioridad alta estricta, mientras que todas las demás colas deben ser de prioridad baja. Esto hace posible LFI.

En este ejemplo se muestra el tráfico de voz en la ef cola. El tráfico de voz se intercala con datos masivos. Como alternativa, puede utilizar MLPPP multiclase para transportar varias clases de tráfico en diferentes clases de multivínculo.

Para obtener más información acerca de cómo funciona FRF.12 con interfaces IQ de servicios de vínculos, consulte Configuración de interfaces LSQ para interfaces T1 o E1 fraccionales simples mediante FRF.12.

En este ejemplo se configura una interfaz IQ ATM2 con MLPPP incluido con interfaces IQ de servicios de vínculo. Esto le permite configurar LFI en circuitos virtuales ATM.

Para este tipo de configuración, la interfaz IQ ATM2 debe tener encapsulación LLC.

En este escenario se admiten las siguientes PIC ATM:

• OC-3/STM1 ATM2 IQ de 2 puertos

• DS3 ATM2 IQ de 4 puertos

No se admite PPP multiplexada de circuito virtual a través de AAL5. No se admite Frame Relay. No se admite la agrupación de varios VC ATM en una única interfaz lógica.

A diferencia de las interfaces DS3 y OC3, no es necesario crear un mapa de programador independiente para la PIC ATM. Para ATM, los componentes de CoS se definen en el nivel de jerarquía, como se describe en la biblioteca de interfaces de red de Junos OS para dispositivos de[edit interfaces at-fpc/pic/port atm-options] enrutamiento.

Nota:

No configure perfiles RED en interfaces lógicas ATM que estén incluidas. Las caídas no ocurren en la interfaz del cajero automático.

En este ejemplo, se configuran dos VC ATM y se agrupan en dos paquetes IQ de servicios de vínculo. Se utiliza un mapa de fragmentación para intercalar el tráfico de voz con otro tráfico multivínculo. Dado que se utiliza MLPPP, cada paquete IQ de servicios de vínculo se puede configurar para CRTP.