EN ESTA PÁGINA
Descripción general de las interfaces de servicios de vínculo
Descripción general de la configuración de servicios de vínculo
Descripción de la configuración LSQ-0/0/0 de interfaz interna
Ejemplo: Actualización de ls-0/0/0 a lsq-0/0/0 para servicios multivínculo
Solución de problemas de la interfaz de servicios de vínculo
Configuración de interfaces de servicios de vínculo
Los dispositivos de Juniper Networks admiten servicios de vínculo en la interfaz de cola de servicios de lsq-0/0/0 vínculo, lo que incluye servicios multivínculo como MLPP, MLFR y CRTP. Los temas siguientes tratan la descripción general de los servicios de vínculo, los detalles de configuración y la verificación de los servicios de vínculo.
Descripción general de las interfaces de servicios de vínculo
Los servicios de vínculo incluyen los servicios multivínculos, el protocolo punto a punto multivínculo (MLPPP), Multilink Frame Relay (MLFR) y el protocolo de transporte comprimido en tiempo real (CRTP). Los dispositivos de Juniper Networks admiten servicios de vínculo en la interfaz de cola de servicios de lsq-0/0/0 vínculo.
Configure la interfaz de cola de servicios de vínculo (lsq-0/0/0) en un dispositivo de Juniper Networks para que admita servicios multivínculo y CRTP.
La interfaz de cola de servicios de vínculo consta de servicios proporcionados por las siguientes interfaces: interfaz de servicios multivínculo (ml-fpc/pic/port ), interfaz de servicios de vínculo (ls-fpc/pic/port ) e interfaz de cola inteligente de servicios de vínculo (lsq-fpc/pic/port ). Aunque los servicios multivínculo, los servicios de vínculo y las interfaces de cola inteligente (IQ) de servicios de vínculo están instalados en tarjetas de interfaz física (PIC), la interfaz de cola de servicios de vínculo es solo una interfaz interna y no está asociada con un medio físico ni con un módulo de interfaz física (PIM).
(ls-fpc/pic/port ) no es compatible.
Esta sección contiene los siguientes temas.
- Servicios disponibles en una interfaz de servicios de vínculo
- Excepciones de servicios de vínculo
- Configuración de MLPPP multiclase
- Cola con LFI
- Descripción general del protocolo de transporte comprimido en tiempo real
- Configuración de la fragmentación por clase de reenvío
- Configuración de la sobrecarga de la capa de vínculo
Servicios disponibles en una interfaz de servicios de vínculo
La interfaz de servicios de vínculo es una interfaz lógica disponible de forma predeterminada. En la Tabla 1 se resumen los servicios disponibles en la interfaz.
| Servicios |
Propósito |
Más información |
|---|---|---|
| Paquetes multivínculo mediante encapsulación MLPPP y MLFR |
Agrega varios enlaces constituyentes en un paquete lógico más grande para proporcionar ancho de banda, equilibrio de carga y redundancia adicionales.
Nota:
Las configuraciones de control dinámico de admisión de llamadas (DCAC) no se admiten en las interfaces de servicios de vínculo. |
|
| Fragmentación e intercalación de vínculos (LFI) |
Reduce la demora y la fluctuación en los vínculos al dividir los paquetes de datos grandes e intercalar paquetes de voz sensibles a la demora con los paquetes más pequeños resultantes. |
Descripción de la fragmentación de vínculos y la configuración de intercalación |
| Protocolo de transporte en tiempo real comprimido (CRTP) |
Reduce la sobrecarga causada por el protocolo de transporte en tiempo real (RTP) en paquetes de voz y video. |
Descripción general del protocolo de transporte comprimido en tiempo real |
| Clasificadores de clase de servicio (CoS), clases de reenvío, programadores y asignaciones de programador, y velocidades de modelación |
Proporciona una mayor prioridad a los paquetes sensibles a la demora, mediante la configuración de CoS, como la siguiente:
|
Excepciones de servicios de vínculo
La implementación de servicios de vínculo y multivínculo es similar a la implementación en otras plataformas de enrutamiento, con las siguientes excepciones:
-
La compatibilidad con servicios de vínculo y multivínculo se encuentran en la
lsq-0/0/0interfaz en lugar de , yls-fpc/pic/portlasml-fpc/pic/portlsq-fpc/pic/portinterfaces. -
Cuando LFI está habilitado, los paquetes fragmentados se ponen en cola de forma rotativa en los vínculos que lo componen para habilitar el equilibrio de carga por paquete y por fragmento. Consulte Colas con LFI.
-
La compatibilidad con la programación por unidad se encuentra en todos los tipos de vínculos de componentes (en todos los tipos de interfaces).
-
La compatibilidad con el protocolo de transporte en tiempo real comprimido (CRTP) es tanto para MLPPP como para PPP.
Configuración de MLPPP multiclase
Para lsq-0/0/0 en un dispositivo de Juniper Networks, con encapsulación MLPPP, puede configurar MLPPP multiclase. Si no configura MLPPP multiclase, no se pueden intercalar fragmentos de diferentes clases. Se deben enviar todos los fragmentos de un solo paquete antes de enviar los fragmentos de otro paquete. Los paquetes no fragmentados se pueden intercalar entre fragmentos de otro paquete para reducir la latencia que ven los paquetes no fragmentados. De hecho, el tráfico sensible a la latencia se encapsula como tráfico PPP regular y el tráfico masivo se encapsula como tráfico multivínculo. Este modelo funciona siempre que haya una sola clase de tráfico sensible a la latencia y no haya tráfico de alta prioridad que tenga prioridad sobre el tráfico sensible a la latencia. Este enfoque de LFI, utilizado en la PIC de servicios de vínculo, sólo admite dos niveles de prioridad de tráfico, lo que no es suficiente para transportar las cuatro a ocho clases de reenvío.
La MLPPP multiclase permite tener varias clases de tráfico sensible a la latencia que se transportan a través de un solo paquete multivínculo con tráfico masivo. De hecho, la MLPPP multiclase permite que diferentes clases de tráfico tengan diferentes garantías de latencia. Con MLPPP multiclase, puede asignar cada clase de reenvío a una clase multivínculo independiente, conservando así las garantías de prioridad y latencia.
No es necesario configurar tanto LFI como MLPPP multiclase en el mismo paquete, ni es compatible, ya que MLPPP multiclase representa un superconjunto de funcionalidad. Cuando se configura MLPPP multiclase, LFI se habilita automáticamente.
La implementación de PPP de Junos OS no admite la negociación de las opciones NCP PPP de compresión de campo de dirección y compresión de campo de protocolo, lo que significa que el software siempre envía un encabezado PPP completo de 4 bytes.
La implementación de MLPPP multiclase en Junos OS no admite la compresión de bytes de encabezado comunes.
La MLPPP multiclase simplifica enormemente los problemas de orden de paquetes que se producen cuando se usan varios vínculos. Sin MLPPP multiclase, todo el tráfico de voz que pertenece a un solo flujo se convierte en un único vínculo para evitar problemas de orden de paquetes. Con MLPPP multiclase, puede asignar tráfico de voz a una clase de prioridad alta y puede usar varios vínculos.
Para configurar MLPPP multiclase en una interfaz IQ de servicios de vínculo, debe especificar cuántas clases multivínculo se deben negociar cuando un vínculo se une al paquete y debe especificar la asignación de una clase de reenvío a una clase MLPPP multiclase.
Para especificar cuántas clases de multivínculo se deben negociar cuando un vínculo se une al paquete, incluya la multilink-max-classes instrucción:
multilink-max-classes number;
Puede incluir esta instrucción en los siguientes niveles de jerarquía:
-
[edit interfaces interface-name unit logical-unit-number] -
[edit logical-routers logical-router-name interfaces interface-name unit logical-unit-number]
El número de clases de multivínculo puede ser de 1 a 8. El número de clases multivínculo para cada clase de reenvío no debe exceder el número de clases multivínculo que se negociarán.
Para especificar la correlación de una clase de reenvío en una clase MLPPP multiclase, incluya la multilink-class instrucción en el nivel de [edit class-of-service fragmentation-maps forwarding-class class-name] jerarquía:
edit class-of-service fragmentation-maps forwarding-classclass-namemultilink-class number
El número de índice de clase multivínculo puede ser del 0 al 7. La multilink-class declaración y la no-fragmentation declaración son mutuamente excluyentes.
Para ver el número de clases de multivínculo negociadas, ejecute el show interfaces lsq-0/0/0.logical-unit-number detail comando.
Cola con LFI
Los paquetes LFI o no LFI se colocan en colas en los vínculos que los componen en función de las colas a las que llegan. No se producen cambios en el número de cola mientras los paquetes fragmentados, no fragmentados o LFI están en cola.
Por ejemplo, supongamos que la cola Q0 está configurada con el umbral de fragmentación 128, Q1 está configurada sin fragmentación y Q2 está configurada con el umbral de fragmentación 512. Q0 recibe flujo de tráfico con tamaño de paquete 512. Q1 recibe tráfico de voz de 64 bytes y Q2 recibe flujo de tráfico con paquetes de 128 bytes. A continuación, la transmisión en Q0 se fragmenta y se pone en cola en Q0 de un vínculo constituyente. Además, todos los paquetes en Q2 se ponen en cola en Q0 en el vínculo constituyente. La secuencia en Q1 se considera LFI porque no se configura ninguna fragmentación. Todos los paquetes de Q0 y Q2 se ponen en cola en Q0 del vínculo constituyente. Todos los paquetes de Q1 se ponen en cola en Q2 del vínculo constituyente.
El uso de lsq-0/0/0, CRTP se puede aplicar en paquetes LFI y no LFI. No habrá cambios en sus números de cola debido a CRTP.
Cola en Q2 de enlaces de componentes
Cuando se utiliza la clase de servicio en un paquete de multivínculos, todo el tráfico Q2 del grupo de multivínculos se pone en cola en Q2 de los vínculos constituyentes según un hash calculado a partir de la dirección de origen, la dirección de destino y el protocolo IP del paquete. Si la carga IP es tráfico TCP o UDP, el hash también incluye el puerto de origen y el puerto de destino. Como resultado de este algoritmo hash, todo el tráfico que pertenece a un flujo de tráfico se pone en cola en Q2 de un vínculo constituyente. Este método de entrega de tráfico al vínculo constituyente se aplica en todo momento, incluso cuando el paquete no se ha configurado con LFI.
Descripción general del protocolo de transporte comprimido en tiempo real
El protocolo de transporte en tiempo real (RTP) puede ayudar a lograr la interoperabilidad entre diferentes implementaciones de aplicaciones de audio y video en red. Sin embargo, en algunos casos, el encabezado, que incluye los encabezados IP, UDP y RTP, puede ser demasiado grande (alrededor de 40 bytes) en redes que utilizan líneas de baja velocidad, como módems de acceso telefónico. El protocolo de transporte en tiempo real comprimido (CRTP) se puede configurar para reducir la sobrecarga de red en enlaces de baja velocidad. CRTP reemplaza los encabezados IP, UDP y RTP por un ID de contexto (CID) de 2 bytes, lo que reduce considerablemente la sobrecarga del encabezado.
En la figura 1, se muestra cómo CRTP comprime el encabezado RTP en un paquete de voz al reducir un encabezado de 40 bytes a un encabezado de 2 bytes.
Puede configurar CRTP con encapsulación de interfaz lógica MLPPP o PPP en interfaces de servicios de vínculo. Consulte Ejemplo: Configuración de un paquete MLPPP.
Las tramas de datos en tiempo real y no real se transportan juntas en enlaces de menor velocidad sin causar retrasos excesivos en el tráfico en tiempo real. Consulte Descripción de la fragmentación de vínculos y la configuración del entrelazado.
Configuración de la fragmentación por clase de reenvío
Para lsq-0/0/0 puede especificar propiedades de fragmentación para clases de reenvío específicas. El tráfico en cada clase de reenvío puede ser encapsulado de múltiples vínculos (fragmentado y secuenciado) o no encapsulado (con hash sin fragmentación). De forma predeterminada, el tráfico en todas las clases de reenvío está encapsulado multivínculo.
Cuando no se configuran las propiedades de fragmentación para las colas en las interfaces MLPPP, el umbral de fragmentación que se establece en el [edit interfaces interface-name unit logical-unit-number fragment-threshold] nivel de jerarquía es el umbral de fragmentación para todas las clases de reenvío dentro de la interfaz MLPPP. Para las interfaces MLFR FRF.16, el umbral de fragmentación que se establece en el [edit interfaces interface-name mlfr-uni-nni-bundle-options fragment-threshold] nivel de jerarquía es el umbral de fragmentación para todas las clases de reenvío dentro de la interfaz MLFR FRF.16.
Si no establece un tamaño máximo de fragmento en ninguna parte de la configuración, los paquetes se seguirán fragmentando si superan la unidad máxima de transmisión (UMT) o la unidad máxima recibida reconstruida (MRRU) de todos los vínculos del paquete. Un flujo no encapsulado utiliza solo un vínculo. Si el flujo supera un único vínculo, la clase de reenvío debe estar encapsulada con varios vínculos, a menos que el tamaño del paquete supere la UMT/MRRU.
Incluso si no establece un tamaño máximo de fragmento en ninguna parte de la configuración, puede configurar la MRRU incluyendo la instrucción mrru en el [edit interfaces lsq-0/0/0 unit logical-unit-number] nivel de jerarquía o [edit interfaces interface-name mlfr-uni-nni-bundle-options] . La MRRU es similar a la UMT, pero es específica para las interfaces de servicios de vínculo. De forma predeterminada, el tamaño de MRRU es de 1504 bytes y puede configurarlo para que sea de 1500 a 4500 bytes.
Para configurar las propiedades de fragmentación en una cola, incluya la instrucción fragmentation-maps en el nivel de [edit class-of-service] jerarquía:
[edit class-of-service]
fragmentation-maps {
map-name {
forwarding-class class-name {
fragment-threshold bytes;
multilink-class number;
no-fragmentation;
}
}
}
Para establecer un umbral de fragmentación por clase de reenvío, incluya la fragment-threshold instrucción en el mapa de fragmentación. Esta instrucción establece el tamaño máximo de cada fragmento de multivínculo.
Para establecer que el tráfico en una cola no esté encapsulado en lugar de multivínculo, incluya la no-fragmentation instrucción en el mapa de fragmentación. Esta instrucción especifica que no se antepone un encabezado de fragmentación adicional a los paquetes recibidos en esta cola y que se usa el equilibrio de carga de vínculos estáticos para garantizar la entrega de paquetes en orden.
Para una clase de reenvío dada, puede incluir la fragment-threshold instrucción or no-fragmentation ; son mutuamente excluyentes.
Utilice la multilink-class instrucción para asignar una clase de reenvío a una MLPPP multiclase. Para una clase de reenvío dada, puede incluir la multilink-class instrucción or no-fragmentation ; son mutuamente excluyentes.
Para asociar un mapa de fragmentación con una interfaz PPP multivínculo o un DLCI MLFR FRF.16, incluya la fragmentation-map instrucción en el nivel de [edit class-of-service interfaces interface-name unit logical-unit-number] jerarquía:
[edit class-of-service interfaces]
lsq-0/0/0 {
unit logical-unit-number { # Multilink PPP
fragmentation-map map-name;
}
}
lsq-0/0/0:channel { # MLFR FRF.16
unit logical-unit-number
fragmentation-map map-name;
}
}
Configuración de la sobrecarga de la capa de vínculo
La sobrecarga de la capa de vínculo puede causar caídas de paquetes en los vínculos constituyentes debido al relleno de bits en los vínculos en 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 promedio de la capa de vínculo es del 1,6 %. Por lo tanto, recomendamos el 4 por ciento como salvaguarda.
Para lsq-0/0/0 en un dispositivo de Juniper Networks, 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 instrucción link-layer-overhead :
link-layer-overhead percent;
Puede incluir esta instrucción en los siguientes niveles de jerarquía:
-
[edit interfaces interface-name mlfr-uni-nni-bundle-options] -
[edit interfaces interface-name unit logical-unit-number] -
[edit logical-routers logical-router-name interfaces interface-name unit logical-unit-number]
Puede configurar el valor para que esté del 0 al 50 por ciento.
Descripción general de la configuración de servicios de vínculo
Antes de empezar:
Instale el hardware del dispositivo.
Establezca una conectividad básica. Consulte la Guía de introducción para su dispositivo.
Tener conocimientos básicos de las interfaces físicas y lógicas y de las convenciones de interfaz de Juniper Networks. Consulte Descripción de las interfaces
Planifique cómo va a usar la interfaz de servicios de vínculo en su red. Consulte Descripción general de interfaces de servicios de vínculo.
Para configurar servicios de vínculo en una interfaz, realice las siguientes tareas:
- Configure la fragmentación e intercalación de vínculos (LFI). Consulte Ejemplo: Configuración de la fragmentación y entrelazado de vínculos.
- Configure clasificadores y clases de reenvío. Consulte Ejemplo: definir clasificadores y clases de reenvío.
- Configure las asignaciones del programador. Consulte Descripción de cómo definir y aplicar asignaciones de programador.
- Configure las velocidades de modelado de interfaces. Consulte Ejemplo: configuración de velocidades de modelado de interfaces
- Configure un paquete MLPPP. Consulte Ejemplo: Configuración de un paquete MLPPP.
- Para configurar CRTP, consulte Ejemplo: Configuración del protocolo de transporte comprimido en tiempo real
Comprobación de la interfaz de servicios de vínculo
Confirme que la configuración funcione correctamente.
- Verificar estadísticas de interfaz de servicios de vínculo
- Verificar la configuración de la CoS de los servicios de vínculo
Verificar estadísticas de interfaz de servicios de vínculo
Propósito
Compruebe las estadísticas de la interfaz de servicios de vínculo.
Acción
El resultado de ejemplo proporcionado en esta sección se basa en las configuraciones proporcionadas en Ejemplo: Configuración de un paquete MLPPP. Para comprobar que los vínculos constituyentes se agregan correctamente al paquete y que los paquetes se fragmentan y transmiten correctamente, realice las siguientes acciones:
En los dispositivos R0 y R1, los dos dispositivos utilizados en este ejemplo, configure MLPPP y LFI como se describe en Ejemplo: Configuración de un paquete MLPPP.
Desde la CLI, ingrese el
pingcomando para comprobar que se establece una conexión entre R0 y R1.Transmita 10 paquetes de datos, de 200 bytes cada uno, de R0 a R1.
En R0, desde la CLI, ingrese el
show interfaces interface-name statisticscomando.
user@R0> show interfaces lsq-0/0/0 statistics detail
Physical interface: lsq-0/0/0, Enabled, Physical link is Up
Interface index: 134, SNMP ifIndex: 29, Generation: 135
Link-level type: LinkService, MTU: 1504
Device flags : Present Running
Interface flags: Point-To-Point SNMP-Traps
Last flapped : 2006-06-23 11:36:23 PDT (03:38:43 ago)
Statistics last cleared: 2006-06-23 15:13:12 PDT (00:01:54 ago)
Traffic statistics:
Input bytes : 0 0 bps
Output bytes : 1820 0 bps
Input packets: 0 0 pps
Output packets: 10 0 pps
...
Egress queues: 8 supported, 8 in use
Queue counters: Queued packets Transmitted packets Dropped packets
0 DATA 10 10 0
1 expedited-fo 0 0 0
2 VOICE 0 0 0
3 NC 0 0 0
Logical interface lsq-0/0/0.0 (Index 67) (SNMP ifIndex 41) (Generation 133)
Flags: Point-To-Point SNMP-Traps 0x4000 Encapsulation: Multilink-PPP
Bandwidth: 16mbps
Bundle options:
...
Drop timer period 0
Sequence number format long (24 bits)
Fragmentation threshold 128
Links needed to sustain bundle 1
Interleave fragments Enabled
Bundle errors:
Packet drops 0 (0 bytes)
Fragment drops 0 (0 bytes)
...
Statistics Frames fps Bytes bps
Bundle:
Fragments:
Input : 0 0 0 0
Output: 20 0 1920 0
Packets:
Input : 0 0 0 0
Output: 10 0 1820 0
Link:
se-1/0/0.0
Input : 0 0 0 0
Output: 10 0 1320 0
se-1/0/1.0
Input : 0 0 0 0
Output: 10 0 600 0
...
Destination: 10.0.0.9/24, Local: 10.0.0.10, Broadcast: Unspecified, Generation:144
En este resultado, se muestra un resumen de la información de la interfaz. Verifique la información siguiente:
Physical interface—La interfaz física esEnabled. Si la interfaz se muestra comoDisabled, realice una de las siguientes acciones:En el editor de configuración de la CLI, elimine la
disableinstrucción en el nivel de la[edit interfaces interface-name]jerarquía de configuración.En el editor de configuración de J-Web, desactive la casilla de
Disableverificación de laInterfaces>interface-namepágina.
Physical link—El vínculo físico esUp. Un estado de vínculo de indica un problema con el módulo de interfaz, el puerto deDowninterfaz o la conexión física (errores de capa de vínculo).Last flapped—ElLast Flappedtiempo es un valor esperado. LaLast Flappedhora indica la última vez que la interfaz física dejó de estar disponible y, a continuación, volvió a estar disponible. La oscilación inesperada indica probables errores de capa de vínculo.Traffic statistics—Número y velocidad de bytes y paquetes recibidos y transmitidos en la interfaz. Compruebe que el número de bytes y paquetes entrantes y salientes coincida con la transferencia de datos esperada para la interfaz física. Para borrar las estadísticas y ver solo los cambios nuevos, use elclear interfaces statistics interface-namecomando.Queue counters—El nombre y el número de colas son los configurados. Este resultado de ejemplo muestra que se transmitieron 10 paquetes de datos y no se descartó ningún paquete.Logical interface—Nombre del paquete multivínculo que configuró—lsq-0/0/0.0.Bundle options: el umbral de fragmentación está configurado correctamente y la intercalación de fragmentos está habilitada.Bundle errors: cualquier paquete o fragmento que haya caído del paquete.Statistics: el dispositivo recibe y transmite correctamente los fragmentos y paquetes. Todas las referencias a la dirección del tráfico (entrada o salida) se definen con respecto al dispositivo. Los fragmentos de entrada recibidos por el dispositivo se ensamblan en paquetes de entrada. Los paquetes de salida se segmentan en fragmentos de salida para su transmisión fuera del dispositivo.En este ejemplo, se transmitieron 10 paquetes de datos de 200 bytes. Dado que el umbral de fragmentación se establece en 128 bytes, todos los paquetes de datos se fragmentaron en dos fragmentos. El resultado de ejemplo muestra que 10 paquetes y 20 fragmentos se transmitieron correctamente.
Link: los vínculos constituyentes se agregan a este paquete y reciben y transmiten fragmentos y paquetes correctamente. El número combinado de fragmentos transmitidos en los vínculos constituyentes debe ser igual al número de fragmentos transmitidos desde el paquete. Este resultado de ejemplo muestra que el paquete transmitió 20 fragmentos y los dos enlacesse-1/0/0.0constituyentes yse-1/0/1.0.0transmitió10+10=20fragmentos correctamente.DestinationyLocal—Dirección IP del lado remoto del paquete multivínculo y del lado local del paquete multivínculo. Este resultado de ejemplo muestra que la dirección de destino es la dirección en R1 y la dirección local es la dirección en R0.
Verificar la configuración de la CoS de los servicios de vínculo
Propósito
Compruebe las configuraciones de CoS en la interfaz de servicios de vínculo.
Acción
Desde la CLI, ingrese los siguientes comandos:
show class-of-service interface interface-nameshow class-of-service classifier name classifier-nameshow class-of-service scheduler-map scheduler-map-name
El resultado de ejemplo proporcionado en esta sección se basa en las configuraciones proporcionadas enEjemplo: Configuración de un paquete MLPPP.
user@R0> show class-of-service interface lsq-0/0/0
Physical interface: lsq-0/0/0, Index: 136
Queues supported: 8, Queues in use: 4
Scheduler map: [default], Index: 2
Input scheduler map: [default], Index: 3
Chassis scheduler map: [default-chassis], Index: 4
Logical interface: lsq-0/0/0.0, Index: 69
Object Name Type Index
Scheduler-map s_map Output 16206
Classifier ipprec-compatibility ip 12
user@R0> show class-of-service interface ge-0/0/1
Physical interface: ge-0/0/1, Index: 140
Queues supported: 8, Queues in use: 4
Scheduler map: [default], Index: 2
Input scheduler map: [default], Index: 3
Logical interface: ge-0/0/1.0, Index: 68
Object Name Type Index
Classifier classfy_input ip 4330
user@R0> show class-of-service classifier name classify_input
Classifier: classfy_input, Code point type: inet-precedence, Index: 4330
Code point Forwarding class Loss priority
000 DATA low
010 VOICE low
user@R0> show class-of-service scheduler-map s_map
Scheduler map: s_map, Index: 16206
Scheduler: DATA, Forwarding class: DATA, Index: 3810
Transmit rate: 49 percent, Rate Limit: none, Buffer size: 49 percent, Priority:low
Drop profiles:
Loss priority Protocol Index Name
Low any 1 [default-drop-profile]
Medium low any 1 [default-drop-profile]
Medium high any 1 [default-drop-profile]
High any 1 [default-drop-profile]
Scheduler: VOICE, Forwarding class: VOICE, Index: 43363
Transmit rate: 50 percent, Rate Limit: none, Buffer size: 5 percent, Priority:high
Drop profiles:
Loss priority Protocol Index Name
Low any 1 [default-drop-profile]
Medium low any 1 [default-drop-profile]
Medium high any 1 [default-drop-profile]
High any 1 [default-drop-profile]
Scheduler: NC, Forwarding class: NC, Index: 2435
Transmit rate: 1 percent, Rate Limit: none, Buffer size: 1 percent, Priority:high
Drop profiles:
Loss priority Protocol Index Name
Low any 1 [default-drop-profile]
Medium low any 1 [default-drop-profile]
Medium high any 1 [default-drop-profile]
High any 1 [default-drop-profile]
En estos ejemplos de salida, se muestra un resumen de los componentes de CoS configurados. Verifique la información siguiente:
Logical Interface: nombre del paquete multivínculo y de los componentes CoS aplicados al paquete. El resultado de prueba muestra que el paquete multivínculo eslsq-0/0/0.0y se le aplica la asignacións_mapde programador de CoS.Classifier: puntos de código, clases de reenvío y prioridades de pérdida asignadas al clasificador. En el resultado de ejemplo se muestra que se aplicó un clasificador predeterminado,ipprec-compatibility, a lalsq-0/0/0interfaz y que el clasificadorclassify_inputse aplicó a lage-0/0/1interfaz.Scheduler: velocidad de transmisión, tamaño de búfer, prioridad y prioridad de pérdida asignadas a cada programador. La salida de ejemplo muestra los programadores de datos, voz y control de red con todos los valores configurados.
Descripción de la configuración LSQ-0/0/0 de interfaz interna
La interfaz de servicios de vínculo es solo una interfaz interna. No está asociado con un medio físico o PIM. Los paquetes se enrutan a esta interfaz para la agrupación o compresión de vínculos.
Puede ser necesario actualizar la configuración para usar la interfaz interna lsq-0/0/0 como interfaz de cola de servicios de vínculo en lugar de ls-0/0/0, que está en desuso. También puede revertir su configuración modificada para usar ls-0/0/0.
Ejemplo: Actualización de ls-0/0/0 a lsq-0/0/0 para servicios multivínculo
En este ejemplo, se muestra cómo actualizar de ls-0/0/0 a lsq-0/0/0 (o revertir el cambio) para servicios multivínculo.
Requisitos
Este procedimiento solo es necesario si todavía usa ls-0/0/0 en lugar de lsq-/0/0/0 o si necesita volver a la interfaz anterior.
Visión general
En este ejemplo, cambia el nombre de la interfaz interna de servicios de vínculo de ls-0/0/0 a lsq-0/0/0 o viceversa. Cambie el nombre de todas las ocurrencias de ls-0/0/0 en la configuración a lsq-0/0/0 y configure el mapa de fragmentación sin agregar fragmentación. No se especifica fragmentación después del nombre de la cola 2, si la cola 2 está configurada o después del reenvío garantizado. Luego, adjunte la asignación de fragmentación configurada en el paso anterior a lsq-0/0/0 y especifique el número de unidad como 6 del paquete multivínculo para el cual está configurado intercalar fragmentos.
A continuación, revierte la configuración de lsq-0/0/0 a ls-0/0/0. Cambie el nombre de todas las ocurrencias en la configuración de lsq-0/0/0 a ls-0/0/0. Elimine la asignación de fragmentación si está configurada en la jerarquía [class-of-service] y elimine la asignación de fragmentación si está asignada a lsq-0/0/0. Puede eliminar multilink-max-classes si está configurado para lsq-0/0/0 en la jerarquía [interfaces]. A continuación, elimine link-layer-overhead si está configurado para lsq-0/0/0 en la jerarquía [interfaces].
Si no se configura ninguna fragmentación en ninguna clase de reenvío y la asignación de fragmentación está asignada a lsq-0/0/0, configure fragmentos de intercalación para la interfaz ls-0/0/0. Por último, configure el clasificador para los paquetes LFI para que hagan referencia a la cola 2. (La interfaz ls-0/0/0 trata la cola 2 como la cola LFI).
Configuración
Procedimiento
Configuración rápida de CLI
Para actualizar rápidamente de ls-0/0/0 a lsq-0/0/0 (o revertir el cambio), copie los siguientes comandos y péguelos en la CLI:
For interfaces ls-0/0/0 to lsq-0/0/0 [edit] rename interfaces ls-0/0/0 to lsq-0/0/0 set class-of-service fragmentation-maps map6 forwarding-class assured-forwarding no-fragmentation set class-of-service interfaces lsq-0/0/0 unit 6 fragmentation-map map6
For interfaces lsq-0/0/0 to ls-0/0/0 [edit] rename interfaces lsq-0/0/0 to ls-0/0/0 delete class-of-service fragmentation-maps map6 delete class-of-service interfaces lsq-0/0/0 unit 6 fragmentation-map map6 delete interfaces lsq-0/0/0 unit 6 link-layer-overhead delete interfaces lsq-0/0/0:0 mlfr-uni-nni-bundle-options link-layer-overhead set interfaces ls-0/0/0 unit 6 interleave-fragments
Procedimiento paso a paso
En el ejemplo siguiente, debe explorar por varios niveles en la jerarquía de configuración. Para obtener instrucciones sobre cómo hacerlo, consulte Uso del editor de CLI en el modo de configuración.
Para actualizar de ls-0/0/0 a lsq-0/0/0 o para revertir ese cambio:
Cambie el nombre de todas las ocurrencias de ls-0/0/0 en la configuración.
[edit] user@host# rename interfaces ls-0/0/0 to lsq-0/0/0
Configure el mapa de fragmentación.
[edit class-of-service fragmentation-maps] user@host# set map6 forwarding-class assured-forwarding no-fragmentation
Especifique el número de unidad del paquete de multivínculo.
[edit class-of-service ] user@host# set interfaces lsq-0/0/0 unit 6 fragmentation-map map6
Revierta la configuración para todas las ocurrencias en la configuración.
[edit] user@host# rename interfaces lsq-0/0/0 to ls-0/0/0
Eliminar mapa de fragmentación en clase de servicio.
[edit] user@host# delete class-of-service fragmentation-maps map6
Eliminar la asignación de fragmentación si está asignada a la interfaz lsq-0/0/0.
[edit class-of-service interfaces] user@host# delete lsq-0/0/0 unit 6 fragmentation-map map6
Elimine las clases máximas de multivínculo si está configurado para lsq-0/0/0.
Nota:Multilink-max-classes no es compatible y lo más probable es que no esté configurado.
Elimine link-layer-overhead si está configurado para lsq-0/0/0.
[edit interfaces] user@host# delete lsq-0/0/0 unit 6 link-layer-overhead
Elimine link-layer-overhead si está configurado para lsq-0/0/0:0.
[edit interfaces] user@host# delete lsq-0/0/0:0 mlfr-uni-nni-bundle-options link-layer-overhead
Configure fragmentos de intercalación para la interfaz ls-0/0/0.
[edit interfaces] user@host# set ls-0/0/0 unit 6 interleave-fragments
Resultados
Desde el modo de configuración, ingrese el comando para confirmar la show class-of-service configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones de configuración de este ejemplo para corregirla.
[edit]
user@host# show class-of-service
interfaces {
lsq-0/0/0 {
unit 6 {
fragmentation-map map6;
}
}
}
fragmentation-maps {
map6 {
forwarding-class {
assured-forwarding {
no-fragmentation;
}
}
}
}
Cuando termine de configurar el dispositivo, ingrese commit desde el modo de configuración.
Verificación
Confirme que la configuración funcione correctamente.
Solución de problemas de la interfaz de servicios de vínculo
Para resolver problemas de configuración en una interfaz de servicios de vínculo:
- Determinar qué componentes de CoS se aplican a los enlaces constituyentes
- Determinar qué causa la fluctuación y la latencia en el paquete multivínculo
- Determinar si la LFI y el equilibrio de carga funcionan correctamente
- Determine por qué los paquetes se caen sobre un PVC entre un dispositivo de Juniper Networks y un dispositivo de terceros
Determinar qué componentes de CoS se aplican a los enlaces constituyentes
Problema
Descripción
Está configurando un paquete de multivínculos, pero también tiene tráfico sin encapsulación MLPPP que pasa a través de los vínculos constituyentes del paquete de multivínculos. ¿Aplica todos los componentes de CoS a los vínculos constituyentes o es suficiente aplicarlos al paquete de enlaces múltiples?
Solución
Puede aplicar una asignación de programador al grupo de multivínculos y los vínculos que lo componen. Aunque puede aplicar varios componentes CoS con la asignación del programador, configure solo los que sean necesarios. Le recomendamos que mantenga sencilla la configuración de los vínculos constituyentes para evitar retrasos innecesarios en la transmisión.
En el Cuadro 2 se muestran los componentes de CoS que deben aplicarse a un haz de enlaces múltiples y sus enlaces constituyentes.
Componente Cos |
Paquete multivínculo |
Enlaces de los constituyentes |
Explicación |
|---|---|---|---|
Clasificador |
Sí |
No |
La clasificación de CoS tiene lugar en el lado entrante de la interfaz, no en el lado de transmisión, por lo que no se necesitan clasificadores en los vínculos que lo componen. |
Clase de envío |
Sí |
No |
La clase de reenvío está asociada a una cola y la cola se aplica a la interfaz mediante una asignación de programador. La asignación de cola está predeterminada en los vínculos constituyentes. Todos los paquetes de Q2 del grupo de multivínculos se asignan a Q2 del vínculo constituyente, y los paquetes de todas las demás colas se ponen en cola a Q0 del vínculo constituyente. |
Mapa del programador |
Sí |
Sí |
Aplique las asignaciones del programador en el paquete multivínculo y el vínculo constituyente de la siguiente manera:
|
Velocidad de modelación para un programador por unidad o un programador a nivel de interfaz |
No |
Sí |
Dado que la programación por unidad solo se aplica en el punto final, aplique esta velocidad de modelación solo a los vínculos que lo componen. Cualquier configuración aplicada anteriormente se sobrescribe con la configuración del vínculo constituyente. |
Velocidad de transmisión exacta o moldeado a nivel de cola |
Sí |
No |
La modelación a nivel de interfaz aplicada en los vínculos constituyentes anula cualquier modelación en la cola. Por lo tanto, aplique la configuración exacta de la velocidad de transmisión únicamente en el haz de enlaces múltiples. |
Reescritura de reglas |
Sí |
No |
Los bits de reescritura se copian automáticamente del paquete en los fragmentos durante la fragmentación. Por lo tanto, lo que configure en el paquete de multivínculos se transporta en los fragmentos a los vínculos que lo componen. |
Grupo de canales virtuales |
Sí |
No |
Los grupos de canales virtuales se identifican mediante reglas de filtro de firewall que se aplican en los paquetes solo antes del paquete de multivínculos. Por lo tanto, no es necesario aplicar la configuración del grupo de canales virtuales a los vínculos que lo componen. |
Ver también
Determinar qué causa la fluctuación y la latencia en el paquete multivínculo
Problema
Descripción
Para probar las fluctuaciones y la latencia, se envían tres secuencias de paquetes IP. Todos los paquetes tienen la misma configuración de precedencia IP. Después de configurar LFI y CRTP, la latencia aumentó incluso en un vínculo no congestionado. ¿Cómo puede reducir la fluctuación y la latencia?
Solución
Para reducir las fluctuaciones y la latencia, haga lo siguiente:
Asegúrese de haber configurado una velocidad de modelación en cada vínculo constituyente.
Asegúrese de no haber configurado una velocidad de modelación en la interfaz de servicios de vínculo.
Asegúrese de que el valor de la velocidad de modelación configurado sea igual al ancho de banda de la interfaz física.
Si las velocidades de modelación están configuradas correctamente y las fluctuaciones persisten, comuníquese con el Centro de asistencia técnica de Juniper Networks (JTAC).
Determinar si la LFI y el equilibrio de carga funcionan correctamente
Problema
Descripción
En este caso, tiene una sola red que admite múltiples servicios. La red transmite datos y tráfico de voz sensible a los retrasos. Después de configurar MLPPP y LFI, asegúrese de que los paquetes de voz se transmitan a través de la red con muy poco retraso y fluctuación. ¿Cómo puede averiguar si los paquetes de voz se tratan como paquetes LFI y si el equilibrio de carga se realiza correctamente?
Solución
Cuando LFI está habilitado, los paquetes de datos (no LFI) se encapsulan con un encabezado MLPPP y se fragmentan en paquetes de un tamaño especificado. Los paquetes de voz (LFI) sensibles al retraso están encapsulados en PPP y se intercalan entre fragmentos de paquetes de datos. La cola y el equilibrio de carga se realizan de forma diferente para los paquetes LFI y los que no lo son.
Para comprobar que LFI se realiza correctamente, determine que los paquetes estén fragmentados y encapsulados como están configurados. Después de saber si un paquete se trata como un paquete LFI o como un paquete que no es LFI, puede confirmar si el equilibrio de carga se realizó correctamente.
Solution Scenario: suponga que dos dispositivos de Juniper Networks, R0 y R1, están conectados por un paquete lsq-0/0/0.0 multivínculo que agrega dos vínculos se-1/0/0 en serie y se-1/0/1. En R0 y R1, MLPPP y LFI están habilitados en la interfaz de servicios de vínculo y el umbral de fragmentación se establece en 128 bytes.
En este ejemplo, usamos un generador de paquetes para generar flujos de voz y datos. Puede utilizar la función de captura de paquetes para capturar y analizar los paquetes en la interfaz entrante.
Se enviaron los dos flujos de datos siguientes en el paquete multivínculo:
100 paquetes de datos de 200 bytes (mayores que el umbral de fragmentación)
500 paquetes de datos de 60 bytes (menores que el umbral de fragmentación)
Se enviaron las siguientes dos transmisiones de voz en el paquete multivínculo:
100 paquetes de voz de 200 bytes desde el puerto de origen 100
300 paquetes de voz de 200 bytes desde el puerto de origen 200
Para confirmar que LFI y el equilibrio de carga se realizan correctamente:
En este ejemplo, solo se muestran y describen las partes significativas de la salida del comando.
Compruebe la fragmentación de paquetes. Desde el modo operativo, escriba el
show interfaces lsq-0/0/0comando para comprobar que los paquetes grandes se fragmentan correctamente.user@R0#> show interfaces lsq-0/0/0 Physical interface: lsq-0/0/0, Enabled, Physical link is Up Interface index: 136, SNMP ifIndex: 29 Link-level type: LinkService, MTU: 1504 Device flags : Present Running Interface flags: Point-To-Point SNMP-Traps Last flapped : 2006-08-01 10:45:13 PDT (2w0d 06:06 ago) Input rate : 0 bps (0 pps) Output rate : 0 bps (0 pps) Logical interface lsq-0/0/0.0 (Index 69) (SNMP ifIndex 42) Flags: Point-To-Point SNMP-Traps 0x4000 Encapsulation: Multilink-PPP Bandwidth: 16mbps Statistics Frames fps Bytes bps Bundle: Fragments: Input : 0 0 0 0 Output: 1100 0 118800 0 Packets: Input : 0 0 0 0 Output: 1000 0 112000 0 ... Protocol inet, MTU: 1500 Flags: None Addresses, Flags: Is-Preferred Is-Primary Destination: 9.9.9/24, Local: 9.9.9.10Meaning: el resultado muestra un resumen de los paquetes que transitan por el dispositivo en el paquete de multivínculo. Verifique la siguiente información en el paquete de multivínculo:El número total de paquetes en tránsito = 1000
El número total de fragmentos en tránsito = 1100
Número de paquetes de datos fragmentados =100
La cantidad total de paquetes enviados (600 + 400) en el paquete multivínculo coincide con la cantidad de paquetes en tránsito (1000), lo que indica que no se descartó ningún paquete.
La cantidad de fragmentos en tránsito supera en 100 la cantidad de paquetes en tránsito, lo que indica que 100 paquetes de datos grandes se fragmentaron correctamente.
Corrective Action: si los paquetes no están fragmentados correctamente, compruebe la configuración del umbral de fragmentación. Los paquetes menores que el umbral de fragmentación especificado no se fragmentan.Compruebe la encapsulación de paquetes. Para averiguar si un paquete se trata como un paquete LFI o no LFI, determine su tipo de encapsulación. Los paquetes LFI están encapsulados en PPP y los paquetes que no son LFI están encapsulados con PPP y MLPPP. Las encapsulaciones PPP y MLPPP tienen diferentes sobrecargas, lo que da como resultado paquetes de diferentes tamaños. Puede comparar los tamaños de los paquetes para determinar el tipo de encapsulación.
Un pequeño paquete de datos no fragmentado contiene un encabezado PPP y un solo encabezado MLPPP. En un paquete de datos fragmentado grande, el primer fragmento contiene un encabezado PPP y un encabezado MLPPP, pero los fragmentos consecutivos contienen solo un encabezado MLPPP.
Las encapsulaciones PPP y MLPPP agregan el siguiente número de bytes a un paquete:
La encapsulación PPP agrega 7 bytes:
4 bytes de encabezado + 2 bytes de secuencia de comprobación de tramas (FCS) + 1 byte que está inactivo o contiene un indicador
La encapsulación MLPPP agrega entre 6 y 8 bytes:
4 bytes de encabezado PPP + 2 a 4 bytes de encabezado multivínculo
La Figura 2 muestra la sobrecarga agregada a los encabezados PPP y MLPPP.
Figura 2: Encabezados
PPP y MLPPP
En el caso de los paquetes CRTP, la sobrecarga de encapsulación y el tamaño del paquete son incluso menores que en el caso de un paquete LFI. Para obtener más información, consulte Ejemplo: Configuración del protocolo de transporte comprimido en tiempo real.
En la Tabla 3 se muestra la sobrecarga de encapsulación para un paquete de datos y un paquete de voz de 70 bytes cada uno. Después de la encapsulación, el tamaño del paquete de datos es mayor que el tamaño del paquete de voz.
Tabla 3: Sobrecarga de encapsulación PPP y MLPPP Tipo de paquete
Encapsulación
Tamaño inicial del paquete
Sobrecarga de encapsulación
Tamaño del paquete después de la encapsulación
Paquete de voz (LFI)
PPP
70 bytes
4 + 2 + 1 = 7 bytes
77 bytes
Fragmento de datos (no LFI) con secuencia corta
MLPPP
70 bytes
4 + 2 + 1 + 4 + 2 = 13 bytes
83 bytes
Fragmento de datos (no LFI) con secuencia larga
MLPPP
70 bytes
4 + 2 + 1 + 4 + 4 = 15 bytes
85 bytes
Desde el modo operativo, escriba el
show interfaces queuecomando para mostrar el tamaño del paquete transmitido en cada cola. Divida el número de bytes transmitidos por el número de paquetes para obtener el tamaño de los paquetes y determinar el tipo de encapsulación.Compruebe el equilibrio de carga. Desde el modo operativo, ingrese el
show interfaces queuecomando en el paquete multivínculo y sus vínculos constituyentes para confirmar si el equilibrio de carga se realiza en consecuencia en los paquetes.user@R0> show interfaces queue lsq-0/0/0 Physical interface: lsq-0/0/0, Enabled, Physical link is Up Interface index: 136, SNMP ifIndex: 29 Forwarding classes: 8 supported, 8 in use Egress queues: 8 supported, 8 in use Queue: 0, Forwarding classes: DATA Queued: Packets : 600 0 pps Bytes : 44800 0 bps Transmitted: Packets : 600 0 pps Bytes : 44800 0 bps Tail-dropped packets : 0 0 pps RED-dropped packets : 0 0 pps … Queue: 1, Forwarding classes: expedited-forwarding Queued: Packets : 0 0 pps Bytes : 0 0 bps … Queue: 2, Forwarding classes: VOICE Queued: Packets : 400 0 pps Bytes : 61344 0 bps Transmitted: Packets : 400 0 pps Bytes : 61344 0 bps … Queue: 3, Forwarding classes: NC Queued: Packets : 0 0 pps Bytes : 0 0 bps …user@R0> show interfaces queue se-1/0/0 Physical interface: se-1/0/0, Enabled, Physical link is Up Interface index: 141, SNMP ifIndex: 35 Forwarding classes: 8 supported, 8 in use Egress queues: 8 supported, 8 in use Queue: 0, Forwarding classes: DATA Queued: Packets : 350 0 pps Bytes : 24350 0 bps Transmitted: Packets : 350 0 pps Bytes : 24350 0 bps ... Queue: 1, Forwarding classes: expedited-forwarding Queued: Packets : 0 0 pps Bytes : 0 0 bps … Queue: 2, Forwarding classes: VOICE Queued: Packets : 100 0 pps Bytes : 15272 0 bps Transmitted: Packets : 100 0 pps Bytes : 15272 0 bps … Queue: 3, Forwarding classes: NC Queued: Packets : 19 0 pps Bytes : 247 0 bps Transmitted: Packets : 19 0 pps Bytes : 247 0 bps …user@R0> show interfaces queue se-1/0/1 Physical interface: se-1/0/1, Enabled, Physical link is Up Interface index: 142, SNMP ifIndex: 38 Forwarding classes: 8 supported, 8 in use Egress queues: 8 supported, 8 in use Queue: 0, Forwarding classes: DATA Queued: Packets : 350 0 pps Bytes : 24350 0 bps Transmitted: Packets : 350 0 pps Bytes : 24350 0 bps … Queue: 1, Forwarding classes: expedited-forwarding Queued: Packets : 0 0 pps Bytes : 0 0 bps … Queue: 2, Forwarding classes: VOICE Queued: Packets : 300 0 pps Bytes : 45672 0 bps Transmitted: Packets : 300 0 pps Bytes : 45672 0 bps … Queue: 3, Forwarding classes: NC Queued: Packets : 18 0 pps Bytes : 234 0 bps Transmitted: Packets : 18 0 pps Bytes : 234 0 bpsMeaning: el resultado de estos comandos muestra los paquetes transmitidos y en cola en cada cola de la interfaz de servicios de vínculo y sus vínculos constituyentes. En la Tabla 4 se muestra un resumen de estos valores. (Dado que el número de paquetes transmitidos es igual al número de paquetes en cola en todos los vínculos, esta tabla solo muestra los paquetes en cola).Tabla 4: Número de paquetes transmitidos en una cola Paquetes en cola
Paquete lsq-0/0/0.0
Enlace del constituyente se-1/0/0
Enlace del constituyente se-1/0/1
Explicación
Paquetes en Q0
600
350
350
La cantidad total de paquetes que transitan por los vínculos constituyentes (350+350 = 700) superó la cantidad de paquetes en cola (600) en el paquete multivínculo.
Paquetes en el segundo trimestre
400
100
300
La cantidad total de paquetes que transitan por los vínculos constituyentes es igual a la cantidad de paquetes del paquete.
Paquetes en el tercer trimestre
0
19
18
Los paquetes que transitan por Q3 de los vínculos constituyentes son para mensajes de keepalive intercambiados entre vínculos constituyentes. Por lo tanto, no se contaron paquetes en Q3 del paquete.
En el paquete multivínculo, verifique lo siguiente:
El número de paquetes en cola coincide con el número transmitido. Si los números coinciden, no se descartó ningún paquete. Si se ponían en cola más paquetes de los que se transmitían, se descartaban porque el búfer era demasiado pequeño. El tamaño de búfer en los vínculos constituyentes controla la congestión en la etapa de salida. Para corregir este problema, aumente el tamaño del búfer en los vínculos constituyentes.
La cantidad de paquetes que transitan por Q0 (600) coincide con la cantidad de paquetes de datos grandes y pequeños recibidos (100+500) en el paquete multivínculo. Si los números coinciden, todos los paquetes de datos transitaron correctamente por Q0.
La cantidad de paquetes que transitan por Q2 en la agrupación multivínculo (400) coincide con la cantidad de paquetes de voz recibidos en la agrupación multivínculo. Si los números coinciden, todos los paquetes de LFI de voz transitaron correctamente Q2.
En los vínculos que lo componen, compruebe lo siguiente:
La cantidad total de paquetes que transitan por Q0 (350+350) coincide con la cantidad de paquetes de datos y fragmentos de datos (500+200). Si los números coinciden, todos los paquetes de datos después de la fragmentación transitaron correctamente por Q0 de los vínculos que lo componen.
Los paquetes transitaron por ambos vínculos constituyentes, lo que indica que el equilibrio de carga se realizó correctamente en paquetes que no son LFI.
La cantidad total de paquetes que transitan por Q2 (300+100) en enlaces constituyentes coincide con la cantidad de paquetes de voz recibidos (400) en el paquete de multivínculo. Si los números coinciden, todos los paquetes de LFI de voz transitaron correctamente Q2.
Los paquetes LFI del puerto
100de origen transitaronse-1/0/0y los paquetes LFI del puerto200de origen transitaronse-1/0/1. Por lo tanto, todos los paquetes LFI (Q2) se cifraron según el puerto de origen y transitaron correctamente por ambos enlaces constituyentes.
Corrective Action: si los paquetes transitaron solo por un vínculo, siga estos pasos para resolver el problema:Determine si el vínculo físico está
up(operativo) odown(no disponible). Un vínculo no disponible indica un problema con el PIM, el puerto de interfaz o la conexión física (errores de capa de vínculo). Si el vínculo está operativo, continúe con el paso siguiente.Compruebe que los clasificadores están definidos correctamente para los paquetes que no son LFI. Asegúrese de que los paquetes que no son LFI no estén configurados para ponerse en cola en Q2. Todos los paquetes en cola para Q2 se tratan como paquetes LFI.
Compruebe que al menos uno de los siguientes valores es diferente en los paquetes LFI: dirección de origen, dirección de destino, protocolo IP, puerto de origen o puerto de destino. Si se configuran los mismos valores para todos los paquetes LFI, todos los paquetes se cifran en el mismo flujo y transitan por el mismo vínculo.
Utilice los resultados para comprobar el equilibrio de carga.
Determine por qué los paquetes se caen sobre un PVC entre un dispositivo de Juniper Networks y un dispositivo de terceros
Problema
Descripción
Está configurando un circuito virtual permanente (PVC) entre las interfaces T1, E1, T3 o E3 en un dispositivo de Juniper Networks y un dispositivo de terceros, y se caen los paquetes y se produce un error en el ping.
Solución
Si el dispositivo de terceros no tiene la misma compatibilidad con FRF.12 que el dispositivo de Juniper Networks o admite FRF.12 de una manera diferente, la interfaz de dispositivos de Juniper Networks en el PVC podría descartar un paquete fragmentado que contiene encabezados FRF.12 y contarlo como un "descarte vigilado".
Como solución alternativa, configure grupos de multivínculos en ambos pares y configure umbrales de fragmentación en los grupos de multivínculos.