EN ESTA PÁGINA
Descripción de la administración de ancho de banda para multidifusión
Administración del ancho de banda y reinicio satisfactorio de PIM
Ejemplo: definición de máximos de ancho de banda de la interfaz
Ejemplo: configuración de multidifusión con VLAN de suscriptor
Configuración del enrutamiento de multidifusión a través de interfaces IP Demux
Ejemplos: configuración de la administración de ancho de banda
Descripción de la administración de ancho de banda para multidifusión
La administración del ancho de banda permite controlar los flujos de multidifusión que salen de una interfaz de multidifusión. Este control le permite administrar mejor el tráfico de multidifusión y reducir o eliminar las posibilidades de sobresuscripción o congestión de la interfaz.
La administración del ancho de banda garantiza que no se produzca una suscripción excesiva de tráfico de multidifusión en una interfaz. Cuando se administra el ancho de banda de multidifusión, se define la cantidad máxima de ancho de banda de multidifusión que puede utilizar una interfaz individual, así como el ancho de banda que utilizan los flujos de multidifusión individuales.
Por ejemplo, el software de enrutamiento no puede agregar un flujo a una interfaz si al hacerlo supera el ancho de banda permitido para esa interfaz. En estas circunstancias, se rechaza la interfaz. Este rechazo, sin embargo, no impide que un protocolo de multidifusión (por ejemplo, PIM) envíe un mensaje de unión aguas arriba. El tráfico sigue llegando al enrutador, aunque el enrutador no esté enviando el flujo desde las interfaces salientes esperadas.
Puede configurar el ancho de banda de flujo estáticamente especificando un valor de ancho de banda para el flujo en bits por segundo, o puede habilitar el ancho de banda de flujo para que se mida y cambie de forma adaptativa. Cuando se utiliza la opción de ancho de banda adaptable, el software de enrutamiento consulta las estadísticas de los flujos que se medirán a intervalos de 5 segundos y calcula el ancho de banda en función de las consultas. El software de enrutamiento utiliza el valor máximo medido en el último minuto (es decir, los últimos 12 puntos de medición) como ancho de banda de flujo.
Para obtener más información, consulte las secciones siguientes:
Administración del ancho de banda y reinicio satisfactorio de PIM
Cuando se utiliza el reinicio correcto PIM, después de que se reinicie el proceso de enrutamiento en el motor de enrutamiento, las interfaces admitidas anteriormente siempre se readmiten y el ancho de banda disponible se ajusta en las interfaces. Cuando se utiliza la opción de ancho de banda adaptable, la medición del ancho de banda se basa inicialmente en el ancho de banda inicial configurado o predeterminado, que puede ser inexacto durante el primer minuto. Esto significa que los nuevos flujos pueden ser rechazados incorrectamente o admitidos temporalmente. Puede corregir este problema emitiendo el comando operativo de admisión de ancho de banda de multidifusión claro .
Si no se configura un reinicio correcto PIM, después de reiniciar el proceso de enrutamiento, es posible que las interfaces admitidas o rechazadas anteriormente se rechacen o se admitan de manera impredecible.
Ver también
Administración del ancho de banda y redundancia de origen
Cuando se utiliza la redundancia de origen, pueden existir varios orígenes (por ejemplo, s1 y s2) para el mismo grupo de destino (g). Sin embargo, solo una de las fuentes puede transmitir activamente en cualquier momento. En este caso, se crean varias entradas de reenvío (s1,g) y (s2,g)— después de que cada una pase por el proceso de admisión.
Con las fuentes redundantes, a diferencia de las entradas no relacionadas, un OIF que ya está admitido para una entrada, por ejemplo, (s1,g), se admite automáticamente para otras entradas de redundancia, por ejemplo, (s2,g). El ancho de banda restante en la interfaz se deduce cada vez que se agrega una interfaz saliente, aunque solo un remitente transmite activamente. Al medir el ancho de banda, el ancho de banda deducido para las entradas inactivas se acredita cuando el enrutador detecta que no se está transmitiendo tráfico.
Para obtener más información sobre cómo definir orígenes redundantes, consulte Ejemplo: Configuración de una asignación de flujo de multidifusión.
Sobresuscripción a sistemas lógicos y ancho de banda
Puede administrar el ancho de banda tanto a nivel de interfaz física como lógica . Sin embargo, si más de un sistema lógico comparte la misma interfaz física, es posible que la interfaz tenga una suscripción excesiva. La sobresuscripción se produce si el ancho de banda total de todos los valores de ancho de banda máximos configurados por separado para las interfaces de cada sistema lógico supera el ancho de banda de la interfaz física.
Cuando se muestra información de ancho de banda de la interfaz, un valor negativo de ancho de banda disponible indica una sobresuscripción en la interfaz.
El ancho de banda de la interfaz puede sobresuscribirse cuando el ancho de banda máximo configurado disminuye o cuando algunos anchos de banda de flujo aumentan debido a un cambio de configuración o un aumento real en la velocidad de tráfico.
El ancho de banda de la interfaz puede volver a estar disponible si se produce una de las siguientes situaciones:
El ancho de banda máximo configurado aumenta.
Algunos flujos ya no se transmiten desde las interfaces y las reservas de ancho de banda para ellos ahora están disponibles para otros flujos.
Algunos anchos de banda de flujo disminuyen debido a un cambio de configuración o una disminución real en la velocidad de tráfico.
Las interfaces que se rechazan para un flujo debido a un ancho de banda insuficiente no se readmiten automáticamente, incluso cuando el ancho de banda vuelve a estar disponible. Las interfaces rechazadas tienen la oportunidad de ser readmitidas cuando se produce una de las siguientes situaciones:
El protocolo de enrutamiento de multidifusión actualiza la entrada de reenvío del flujo después de recibir un mensaje de unión, salida o poda, o después de que se produce un cambio de topología.
El protocolo de enrutamiento de multidifusión actualiza la entrada de reenvío del flujo debido a cambios de configuración.
Se vuelve a aplicar manualmente la administración de ancho de banda a un flujo específico o a todos los flujos mediante el comando operativo de admisión de ancho de banda de multidifusión claro .
Además, incluso si el ancho de banda disponible anteriormente ya no está disponible, las interfaces ya admitidas no se quitan hasta que se produce una de las siguientes situaciones:
El protocolo de enrutamiento de multidifusión quita explícitamente las interfaces después de recibir un mensaje de licencia o poda o después de que se produce un cambio de topología.
Se vuelve a aplicar manualmente la administración de ancho de banda a un flujo específico o a todos los flujos mediante el comando operativo de admisión de ancho de banda de multidifusión claro .
Ver también
Ejemplo: definición de máximos de ancho de banda de la interfaz
En este ejemplo se muestra cómo configurar el ancho de banda máximo para una interfaz física o lógica.
Requisitos
Antes de empezar:
Configure las interfaces del enrutador.
Configure un protocolo de puerta de enlace interior. Consulte la biblioteca de protocolos de enrutamiento de Junos OS para dispositivos de enrutamiento.
Configure un protocolo de multidifusión. Esta función funciona con los siguientes protocolos de multidifusión:
DVMRP
PIM-DM
PIM-SM
PIM-SSM
Visión general
La configuración de ancho de banda máximo aplica el control de admisión contra el ancho de banda de la interfaz configurada o contra la velocidad nativa de la interfaz subyacente (cuando no hay ancho de banda configurado para la interfaz).
Si configura varias interfaces lógicas (por ejemplo, para admitir VLAN o PVC) en la misma interfaz física subyacente y no se configura ningún ancho de banda para las interfaces lógicas, se supone que todas las interfaces lógicas tienen el mismo ancho de banda que la interfaz subyacente. Esto puede causar un exceso de suscripción. Para evitar la sobresuscripción, configure el ancho de banda para las interfaces lógicas o configure el control de admisión en el nivel de la interfaz física.
Solo necesita definir el ancho de banda máximo para una interfaz en la que desea aplicar la administración de ancho de banda. Una interfaz que no tiene un ancho de banda máximo definido transmite todos los flujos de multidifusión determinados por el protocolo de multidifusión que se ejecuta en la interfaz (por ejemplo, PIM).
Si especifica el ancho de banda máximo sin incluir un valor de bits por segundo, el control de admisión se habilita en función del ancho de banda configurado para la interfaz. En el ejemplo siguiente, el control de admisión está habilitado para la unidad de interfaz lógica 200 y el ancho de banda máximo es de 20 Mbps. Si el ancho de banda no está configurado en la interfaz, el ancho de banda máximo es la velocidad del vínculo.
routing-options {
multicast {
interface fe-0/2/0.200 {
maximum-bandwidth;
}
interfaces {
fe-0/2/0 {
unit 200 {
bandwidth 20m;
}
}
}
Topología
Configuración
Procedimiento
Configuración rápida de CLI
Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red, copie y pegue los comandos en la CLI en el nivel de jerarquía y, a continuación, ingrese commit desde el [edit] modo de configuración.
set interfaces fe-0/2/0 unit 200 bandwidth 20m set routing-options multicast interface fe-0/2/0.200 maximum-bandwidth set routing-options multicast interface fe-0/2/1 maximum-bandwidth 60m set routing-options multicast interface fe-0/2/1.200 maximum-bandwidth 10m
Procedimiento paso a paso
En el ejemplo siguiente es necesario navegar por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración en la Guía del usuario de CLI de Junos OS.
Para configurar un ancho de banda máximo:
Configure el ancho de banda de una interfaz lógica.
[edit interfaces] user@host# set fe-0/2/0 unit 200 bandwidth 20m
Habilite el control de admisión en la interfaz lógica.
[edit routing-options] user@host# set multicast interface fe-0/2/0.200 maximum-bandwidth
En una interfaz física, habilite el control de admisión y establezca el ancho de banda máximo en 60 Mbps.
[edit routing-options] user@host# set multicast interface fe-0/2/1 maximum-bandwidth 60m
Para una interfaz lógica en la misma interfaz física que se muestra en el paso 3, establezca un ancho de banda máximo menor.
[edit routing-options] user@host# set multicast interface fe-0/2/1.200 maximum-bandwidth 10m
Resultados
Confirme su configuración ingresando los comandos show interfaces y show routing-options .
user@host# show interfaces
fe-0/2/0 {
unit 200 {
bandwidth 20m;
}
}
user@host# show routing-options
multicast {
interface fe-0/2/0.200 {
maximum-bandwidth;
}
interface fe-0/2/1 {
maximum-bandwidth 60m;
}
interface fe-0/2/1.200 {
maximum-bandwidth 10m;
}
}
Verificación
Para comprobar la configuración, ejecute el comando show multicast interface .
Ejemplo: configuración de multidifusión con VLAN de suscriptor
En este ejemplo, se muestra cómo configurar un enrutador de la serie MX para que funcione como un enrutador de servicio de banda ancha (BSR).
Requisitos
En este ejemplo se utilizan los siguientes componentes de hardware:
Un enrutador serie MX o un conmutador serie EX con un PIC compatible con colas de perfiles de control de tráfico
Un DSLAM
Antes de empezar:
Configure un protocolo de puerta de enlace interior. Consulte la biblioteca de protocolos de enrutamiento de Junos OS para dispositivos de enrutamiento.
Configure PIM e IGMP o MLD en las interfaces.
Descripción general y topología
Cuando varias interfaces BSR reciben IGMP y MLD join y dejan solicitudes para la misma secuencia de multidifusión, BSR envía una copia de la secuencia de multidifusión en cada interfaz. Tanto los paquetes de control de multidifusión (IGMP y MLD) como los paquetes de datos de multidifusión fluyen en la misma interfaz BSR, junto con los datos de unidifusión. Dado que todo el tráfico por cliente tiene su propia interfaz en BSR, se admiten la contabilidad por cliente, el control de admisión de llamadas (CAC) y el ajuste de calidad de servicio (QoS). El ancho de banda QoS utilizado por la multidifusión reduce el ancho de banda de unidifusión.
Varias interfaces en el BSR pueden conectarse a un dispositivo compartido (por ejemplo, un DSLAM). El BSR envía la misma secuencia de multidifusión varias veces al dispositivo compartido, desperdiciando así ancho de banda. Es más eficiente enviar la secuencia de multidifusión una vez al DSLAM y replicar las secuencias de multidifusión en el DSLAM. Hay dos enfoques que puede utilizar.
El primer enfoque consiste en seguir enviando datos de unidifusión en las interfaces por cliente, pero hacer que DSLAM enrute todas las IGMP y MLD por cliente y deje solicitudes al BSR en una única interfaz dedicada (una VLAN de multidifusión). El DSLAM recibe los flujos de multidifusión del BSR en la interfaz dedicada sin replicación innecesaria y realiza la replicación necesaria para los clientes. Dado que todos los paquetes de datos y control de multidifusión utilizan una sola interfaz, solo se envía una copia de una secuencia, incluso si hay varias solicitudes. Este enfoque se denomina asignación de interfaz de salida inversa (OIF). La asignación OIF inversa permite que BSR propague el estado de multidifusión de la interfaz compartida a las interfaces de cliente, lo que permite que funcionen la contabilidad por cliente y el ajuste de QoS. Cuando un cliente cambia el canal de TV, la puerta de enlace del enrutador (RG) envía una unión IGMP o MLD y deja mensajes al DSLAM. El DSLAM pasa la solicitud al BSR de forma transparente a través de la VLAN de multidifusión. BSR asigna la solicitud IGMP o MLD a una de las VLAN de suscriptor según la dirección IP de origen o la dirección MAC de origen. Cuando se encuentra la VLAN del suscriptor, el ajuste de QoS y la contabilidad se realizan en esa VLAN o interfaz.
El segundo enfoque es que DSLAM continúe enviando datos de unidifusión y todas las solicitudes IGMP y MLD por cliente se unan y dejen al BSR en las interfaces de cliente individuales, pero que los flujos de multidifusión lleguen a una única interfaz dedicada. Si varios clientes solicitan la misma secuencia de multidifusión, la BSR envía una copia de los datos en la interfaz dedicada. El DSLAM recibe los flujos de multidifusión del BSR en la interfaz dedicada y realiza la replicación necesaria para los clientes. Dado que los paquetes de control de multidifusión utilizan muchas interfaces de cliente, la configuración en BSR debe especificar cómo asignar los paquetes de datos de multidifusión de cada cliente a la única interfaz de salida dedicada. El ajuste de QoS se admite en las interfaces del cliente. El CAC es compatible con la interfaz compartida. Este segundo enfoque se denomina mapeo OIF de multidifusión.
La asignación OIF y la asignación OIF inversa no se admiten en la misma interfaz de cliente o interfaz compartida. En este ejemplo se muestra cómo configurar los dos enfoques diferentes. Ambos enfoques admiten el ajuste de QoS y ambos enfoques admiten MLD/IPv6. El ejemplo de asignación OIF inversa se centra en IGMP/IPv4 y permite el ajuste de QoS. El ejemplo de asignación OIF se centra en MLD/IPv6 y deshabilita el ajuste de QoS.
El primer enfoque (mapeo OIF inverso) incluye las siguientes declaraciones:
flow-map: define un mapa de flujo que controla el ancho de banda de cada flujo.
ancho de banda máximo: habilita el CAC.
reverse-oif-mapping: permite que el dispositivo de enrutamiento identifique una VLAN o interfaz de suscriptor basada en una solicitud de unión o salida IGMP o MLD que recibe a través de la VLAN de multidifusión.
Después de identificar la VLAN del suscriptor, el dispositivo de enrutamiento ajusta inmediatamente la QoS (en este caso, el ancho de banda) en esa VLAN en función de la adición o eliminación de un suscriptor.
El dispositivo de enrutamiento utiliza informes de unión o salida IGMP y MLD para obtener la información de VLAN del suscriptor. Esto significa que el equipo de conexión (por ejemplo, DSLAM) debe enviar todos los informes IGMP y MLD al dispositivo de enrutamiento para que esta función funcione correctamente. El uso de la supresión de informes o un proxy IGMP puede dar como resultado que la asignación OIF inversa no funcione correctamente.
subscriber-leave-timer: introduce un retraso en la actualización de QoS. Después de recibir una solicitud de licencia IGMP o MLD, esta instrucción define un retraso de tiempo (entre 1 y 30 segundos) que el dispositivo de enrutamiento espera antes de actualizar la QoS para las interfaces de suscriptor restantes. Puede usar este retraso para reducir la frecuencia con la que el dispositivo de enrutamiento ajusta el ancho de banda general de QoS en la VLAN cuando un suscriptor envía mensajes rápidos de abandono y unión (por ejemplo, al cambiar de canal en una red IPTV).
traffic-control-profile: configura una velocidad de conformación en la interfaz lógica. La velocidad de conformación configurada debe configurarse como un valor absoluto, no como un porcentaje.
El segundo enfoque (mapeo OIF) incluye las siguientes declaraciones:
map-to-interface: en una declaración de política, permite crear el mapa OIF.
El mapa OIF es una instrucción de política de enrutamiento que puede contener varios términos. Al crear mapas OIF, tenga en cuenta lo siguiente:
Si especifica una interfaz física (por ejemplo, ge-0/0/0), se anexa un ".0" a la interfaz para crear una interfaz lógica (por ejemplo, ge-0/0/0.0).
Configure una directiva de enrutamiento para cada sistema lógico. No puede configurar las directivas de enrutamiento de forma dinámica.
La interfaz también debe tener configurado IGMP, MLD o PIM.
No se puede asignar a una interfaz asignada.
Se recomienda configurar las instrucciones de directiva para IGMP y MLD por separado.
Especifique una interfaz lógica o la palabra clave self. La palabra clave self especifica que los paquetes de datos de multidifusión se envíen en la misma interfaz que los paquetes de control y que no se produzca ninguna asignación. Si ningún término coincide, no se envía ningún paquete de datos de multidifusión.
no-qos-adjust: deshabilita el ajuste de QoS.
El ajuste de QoS disminuye el ancho de banda disponible en la interfaz de cliente por la cantidad de ancho de banda consumido por las secuencias de multidifusión que se asignan desde la interfaz de cliente a la interfaz compartida. Esta acción siempre se produce a menos que esté explícitamente deshabilitada.
Si deshabilita el ajuste de QoS, el ancho de banda disponible no se reduce en la interfaz del cliente cuando se agregan secuencias de multidifusión a la interfaz compartida.
Nota:Puede deshabilitar dinámicamente el ajuste de QoS para interfaces IGMP y MLD mediante perfiles dinámicos.
oif-map: asocia un mapa a una interfaz IGMP o MLD. A continuación, el mapa OIF se aplica a todas las solicitudes IGMP o MLD recibidas en la interfaz configurada. En este ejemplo, las VLAN de suscriptor 1 y 2 tienen MLD configurado, y cada VLAN apunta a un mapa OIF que dirige parte del tráfico a ge-2/3/9.4000, parte del tráfico a ge-2/3/9.4001 y parte del tráfico a uno mismo.
Nota:Puede asociar dinámicamente mapas OIF con interfaces IGMP mediante perfiles dinámicos.
pasivo: define IGMP o MLD para usar el modo pasivo.
La interfaz de mapa OIF normalmente no debe pasar el tráfico de control IGMP o MLD y debe configurarse como pasiva. Sin embargo, la implementación de mapas OIF admite la ejecución de IGMP o MLD en una interfaz (control y datos) además de asignar flujos de datos a la misma interfaz. En este caso, debe configurar IGMP o MLD normalmente (es decir, no en modo pasivo) en la interfaz asignada. En este ejemplo, las interfaces de mapas OIF (ge-2/3/9.4000 y ge-2/3/9.4001) se configuran como MLD pasivas.
De forma predeterminada, especificar la instrucción pasiva significa que no se envían consultas generales, consultas específicas de grupo o consultas específicas de origen de grupo a través de la interfaz y que la interfaz ignora todo el tráfico de control recibido. Sin embargo, puede activar selectivamente hasta dos de las tres opciones disponibles para la instrucción pasiva mientras mantiene las otras funciones pasivas (inactivas).
Estas opciones incluyen lo siguiente:
send-general-query: cuando se especifica, la interfaz envía consultas generales.
send-group-query: cuando se especifica, la interfaz envía consultas específicas del grupo y del origen del grupo.
allow-receive: cuando se especifica, la interfaz recibe el tráfico de control.
Topología
La figura 1 muestra el escenario.
En ambos enfoques, si varios clientes solicitan la misma secuencia de multidifusión, el BSR envía una copia de la secuencia en la interfaz VLAN de multidifusión compartida. El DSLAM recibe la secuencia de multidifusión del BSR en la interfaz compartida y realiza la replicación necesaria en los clientes.
En el primer enfoque (asignación OIF inversa), el DSLAM utiliza las VLAN de suscriptor por cliente solo para datos de unidifusión. Las solicitudes de unión y salida de IGMP y MLD se envían en la VLAN de multidifusión.
En el segundo enfoque (mapeo OIF), el DSLAM utiliza las VLAN de suscriptor por cliente para datos de unidifusión y para solicitudes de unión y salida IGMP y MLD. La VLAN de multidifusión solo se utiliza para transmisiones de multidifusión, no para solicitudes de unión y salida.
suscriptor
Configuración
Configuración de un mapa OIF inverso
Configuración rápida de CLI
Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red, copie y pegue los comandos en la CLI en el nivel de jerarquía y, a continuación, ingrese commit desde el [edit] modo de configuración. .
set class-of-service traffic-control-profiles tcp-ifl shaping-rate 20m set class-of-service interfaces ge-2/2/0 shaping-rate 240m set class-of-service interfaces ge-2/2/0 unit 50 output-traffic-control-profile tcp-ifl set class-of-service interfaces ge-2/2/0 unit 51 output-traffic-control-profile tcp-ifl set interfaces ge-2/0/0 unit 0 family inet address 30.0.0.2/24 set interfaces ge-2/2/0 hierarchical-scheduler set interfaces ge-2/2/0 vlan-tagging set interfaces ge-2/2/0 unit 10 vlan-id 10 set interfaces ge-2/2/0 unit 10 family inet address 40.0.0.2/24 set interfaces ge-2/2/0 unit 50 vlan-id 50 set interfaces ge-2/2/0 unit 50 family inet address 50.0.0.2/24 set interfaces ge-2/2/0 unit 51 vlan-id 51 set interfaces ge-2/2/0 unit 51 family inet address 50.0.1.2/24 set policy-options policy-statement all-mcast-groups from source-address-filter 30.0.0.0/8 orlonger set policy-options policy-statement all-mcast-groups then accept set protocols igmp interface all set protocols igmp interface fxp0.0 disable set protocols pim rp local address 20.0.0.2 set protocols pim interface all set protocols pim interface fxp0.0 disable set protocols pim interface ge-2/2/0.10 disable set routing-options multicast flow-map map1 policy all-mcast-groups set routing-options multicast flow-map map1 bandwidth 10m set routing-options multicast flow-map map1 bandwidth adaptive set routing-options multicast interface ge-2/2/0.10 maximum-bandwidth 500m set routing-options multicast interface ge-2/2/0.10 reverse-oif-mapping set routing-options multicast interface ge-2/2/0.10 subscriber-leave-timer 20
Procedimiento paso a paso
En el ejemplo siguiente es necesario navegar por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración en la Guía del usuario de CLI de Junos OS.
Para configurar la asignación OIF inversa:
Configure una interfaz lógica para el tráfico de datos de unidifusión.
[edit interfaces ge-2/0/0] user@host# set unit 0 family inet address 30.0.0.2/24
Configure una interfaz lógica para el tráfico de control de suscriptores.
[edit interfaces ge-2/2/0] user@host# set hierarchical-scheduler user@host# set vlan-tagging user@host# set unit 10 vlan-id 10 user@host# set unit 10 family inet address 40.0.0.2/24
Configure dos interfaces lógicas en las que se realizan ajustes de QoS.
[edit interfaces ge-2/2/0] user@host# set unit 50 vlan-id 50 user@host# set unit 50 family inet address 50.0.0.2/24 user@host# set unit 51 vlan-id 51 user@host# set unit 51 family inet address 50.0.1.2/24
Configure una directiva.
[edit policy-options policy-statement all-mcast-groups] user@host# set from source-address-filter 30.0.0.0/8 orlonger user@host# set then accept
Habilite un mapa de flujo que haga referencia a la directiva.
[edit routing-options multicast] user@host# set flow-map map1 policy all-mcast-groups user@host# set flow-map map1 bandwidth 10m adaptive
Habilite la asignación OIF en la interfaz lógica que recibe el tráfico de control del suscriptor.
[edit routing-options multicast] user@host# set interface ge-2/2/0.10 maximum-bandwidth 500m user@host# set interface ge-2/2/0.10 reverse-oif-mapping user@host# set interface ge-2/2/0.10 subscriber-leave-timer 20
Configure PIM e IGMP.
[edit protocols] user@host# set igmp interface all user@host# set igmp interface fxp0.0 disable user@host# set pim rp local address 20.0.0.2 user@host# set pim interface all user@host# set pim interface fxp0.0 disable user@host# set pim interface ge-2/2/0.10 disable
Configure el programador jerárquico configurando una velocidad de conformación para la interfaz física y una velocidad de modelación más lenta para las interfaces lógicas en las que se realizan ajustes de QoS.
[edit class-of-service interfaces ge-2/2/0] user@host# set shaping-rate 240m user@host# set unit 50 output-traffic-control-profile tcp-ifl user@host# set unit 51 output-traffic-control-profile tcp-ifl [edit class-of-service traffic-control-profiles tcp-30m-no-smap] user@host# set shaping-rate 20m
Resultados
Desde el modo de configuración, ingrese los comandos show class-of-service, show interfaces, show policy-options, show protocols y show routing-options . Si el resultado no muestra la configuración deseada, repita las instrucciones de este ejemplo para corregir la configuración.
user@host# show class-of-service
traffic-control-profiles {
tcp-ifl {
shaping-rate 20m;
}
}
interfaces {
ge-2/2/0 {
shaping-rate 240m;
unit 50 {
output-traffic-control-profile tcp-ifl;
}
unit 51 {
output-traffic-control-profile tcp-ifl;
}
}
}
user@host# show interfaces
ge-2/0/0 {
unit 0 {
family inet {
address 30.0.0.2/24;
}
}
}
ge-2/2/0 {
hierarchical-scheduler;
vlan-tagging;
unit 10 {
vlan-id 10;
family inet {
address 40.0.0.2/24;
}
}
unit 50 {
vlan-id 50;
family inet {
address 50.0.0.2/24;
}
}
unit 51 {
vlan-id 51;
family inet {
address 50.0.1.2/24;
}
}
}
user@host# show policy-options
policy-statement all-mcast-groups {
from {
source-address-filter 30.0.0.0/8 orlonger;
}
then accept;
}
user@host# show protocols
igmp {
interface all;
interface fxp0.0 {
disable;
}
}
pim {
rp {
local {
address 20.0.0.2;
}
}
interface all;
interface fxp0.0 {
disable;
}
interface ge-2/2/0.10 {
disable;
}
}
user@host# show routing-options
multicast {
flow-map map1 {
policy all-mcast-groups;
bandwidth 10m adaptive;
}
interface ge-2/2/0.10 {
maximum-bandwidth 500m;
reverse-oif-mapping;
subscriber-leave-timer 20;
}
}
Cuando haya terminado de configurar el dispositivo, escriba confirmar desde el modo de configuración.
Configuración de un mapa OIF
Configuración rápida de CLI
Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red, copie y pegue los comandos en la CLI en el nivel de jerarquía y, a continuación, ingrese commit desde el [edit] modo de configuración.
set interfaces ge-2/3/8 unit 0 family inet6 address C300:0101::/24 set interfaces ge-2/3/9 vlan-tagging set interfaces ge-2/3/9 unit 1 vlan-id 1 set interfaces ge-2/3/9 unit 1 family inet6 address C400:0101::/24 set interfaces ge-2/3/9 unit 2 vlan-id 2 set interfaces ge-2/3/9 unit 2 family inet6 address C400:0201::/24 set interfaces ge-2/3/9 unit 4000 vlan-id 4000 set interfaces ge-2/3/9 unit 4000 family inet6 address C40F:A001::/24 set interfaces ge-2/3/9 unit 4001 vlan-id 4001 set interfaces ge-2/3/9 unit 4001 family inet6 address C40F:A101::/24 set policy-options policy-statement g539-v6 term g539-4000 from route-filter FF05:0101:0000::/39 orlonger set policy-options policy-statement g539-v6 term g539-4000 then map-to-interface ge-2/3/9.4000 set policy-options policy-statement g539-v6 term g539-4000 then accept set policy-options policy-statement g539-v6 term g539-4001 from route-filter FF05:0101:0200::/39 orlonger set policy-options policy-statement g539-v6 term g539-4001 then map-to-interface ge-2/3/9.4001 set policy-options policy-statement g539-v6 term g539-4001 then accept set policy-options policy-statement g539-v6 term self from route-filter FF05:0101:0700::/40 orlonger set policy-options policy-statement g539-v6 term self then map-to-interface self set policy-options policy-statement g539-v6 term self then accept set policy-options policy-statement g539-v6-all term g539 from route-filter 0::/0 orlonger set policy-options policy-statement g539-v6-all term g539 then map-to-interface ge-2/3/9.4000 set policy-options policy-statement g539-v6-all term g539 then accept set protocols mld interface fxp0.0 disable set protocols mld interface ge-2/3/9.4000 passive set protocols mld interface ge-2/3/9.4001 passive set protocols mld interface ge-2/3/9.1 version 1 set protocols mld interface ge-2/3/9.1 oif-map g539-v6 set protocols mld interface ge-2/3/9.2 version 2 set protocols mld interface ge-2/3/9.2 oif-map g539-v6 set protocols pim rp local address 20.0.0.4 set protocols pim rp local family inet6 address C000::1 set protocols pim interface ge-2/3/8.0 mode sparse set protocols pim interface ge-2/3/8.0 version 2 set routing-options multicast interface ge-2/3/9.1 no-qos-adjust set routing-options multicast interface ge-2/3/9.2 no-qos-adjust
Procedimiento paso a paso
En el ejemplo siguiente es necesario navegar por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte el Manual del usuario de la CLI de Junos OS.
Para configurar la asignación OIF inversa:
Configure una interfaz lógica para el tráfico de datos de unidifusión.
[edit interfaces ge-2/3/8 ] user@host# set unit 0 family inet6 address C300:0101::/24
Configure interfaces lógicas para VLAN de suscriptor.
[edit interfaces ge-2/3/9] user@host# set vlan-tagging user@host# set unit 1 vlan-id 1 user@host# set unit 1 family inet6 address C400:0101::/24 user@host# set unit 2 vlan-id 2 user@host# set unit 2 family inet6 address C400:0201::/24 lo0 unit 0 family inet6 address C000::1/128 user@host# set unit 2 family inet6 address C400:0201::/24
Configure dos interfaces lógicas de asignación.
[edit interfaces ge-2/2/0] user@host# set unit 4000 vlan-id 4000 user@host# set unit 4000 family inet6 address C40F:A001::/24 user@host# set unit 4001 vlan-id 4001 user@host# set unit 4001 family inet6 address C40F:A101::/24
Configure el mapa OIF.
[edit policy-options policy-statement g539-v6] user@host# set term g539-4000 from route-filter FF05:0101:0000::/39 orlonger user@host# set then map-to-interface ge-2/3/9.4000 user@host# set then accept user@host# set term g539-4001 from route-filter FF05:0101:0200::/39 orlonger user@host# set then map-to-interface ge-2/3/9.4001 user@host# set then accept user@host# set term self from route-filter FF05:0101:0700::/40 orlonger user@host# set then map-to-interface self user@host# set then accept [edit policy-options policy-statement g539-v6-all] user@host# set term g539 from route-filter 0::/0 orlonger user@host# set then map-to-interface ge-2/3/9.4000 user@host# set then accept
Deshabilite el ajuste de QoS en las VLAN de suscriptor.
[edit routing-options multicast] user@host# set interface ge-2/3/9.1 no-qos-adjust user@host# set interface ge-2/3/9.2 no-qos-adjust
Configure PIM y MLD. Apunte las VLAN de suscriptor MLD al mapa OIF.
[edit protocols] user@host# set pim rp local address 20.0.0.4 user@host# set pim rp local family inet6 address C000::1 #C000::1 is the address of lo0 user@host# set pim interface ge-2/3/8.0 mode sparse user@host# set pim interface ge-2/3/8.0 version 2 user@host# set mld interface fxp0.0 disable user@host# set interface ge-2/3/9.4000 passive user@host# set interface ge-2/3/9.4001 passive user@host# set interface ge-2/3/9.1 version 1 user@host# set interface ge-2/3/9.1 oif-map g539-v6 user@host# set interface ge-2/3/9.2 version 2 user@host# set interface ge-2/3/9.2 oif-map g539-v6
Resultados
Desde el modo de configuración, confirme su configuración ingresando a los comandos show interfaces, show policy-options, show protocols y show routing-options . Si el resultado no muestra la configuración deseada, repita las instrucciones de este ejemplo para corregir la configuración.
user@host# show interfaces
ge-2/3/8 {
unit 0 {
family inet6 {
address C300:0101::/24;
}
}
}
ge-2/3/9 {
vlan-tagging;
unit 1 {
vlan-id 1;
family inet6 {
address C400:0101::/24;
}
}
unit 2 {
vlan-id 2;
family inet6 {
address C400:0201::/24;
}
}
unit 4000 {
vlan-id 4000;
family inet6 {
address C40F:A001::/24;
}
}
unit 4001 {
vlan-id 4001;
family inet6 {
address C40F:A101::/24;
}
}
}
user@host# show policy-options
policy-statement g539-v6 {
term g539-4000 {
from {
route-filter FF05:0101:0000::/39 orlonger;
}
then {
map-to-interface ge-2/3/9.4000;
accept;
}
}
term g539-4001 {
from {
route-filter FF05:0101:0200::/39 orlonger;
}
then {
map-to-interface ge-2/3/9.4001;
accept;
}
}
term self {
from {
route-filter FF05:0101:0700::/40 orlonger;
}
then {
map-to-interface self;
accept;
}
}
}
policy-statement g539-v6-all {
term g539 {
from {
route-filter 0::/0 orlonger;
}
then {
map-to-interface ge-2/3/9.4000;
accept;
}
}
}
user@host# show protocols
mld {
interface fxp0.0 {
disable;
}
interface ge-2/3/9.4000 {
passive;
}
interface ge-2/3/9.4001 {
passive;
}
interface ge-2/3/9.1 {
version 1;
oif-map g539-v6;
}
interface ge-2/3/9.2 {
version 2;
oif-map g539-v6;
}
}
pim {
rp {
local {
address 20.0.0.4;
family inet6 {
address C000::1;
}
}
}
interface ge-2/3/8.0 {
mode sparse;
version 2;
}
}
user@host# show routing-options
multicast {
interface ge-2/3/9.1 no-qos-adjust;
interface ge-2/3/9.2 no-qos-adjust;
}
Cuando haya terminado de configurar el dispositivo, escriba confirmar desde el modo de configuración.
Verificación
Para comprobar la configuración, ejecute los siguientes comandos:
Mostrar estadísticas IGMP
mostrar interfaz de clase de servicio
mostrar estadísticas de interfaces
Mostrar estadísticas de MLD
mostrar interfaz de multidifusión
Mostrar política
Configuración del enrutamiento de multidifusión a través de interfaces IP Demux
En una red de administración de suscriptores, los campos de los paquetes enviados desde interfaces demux IP están pensados para corresponder a un cliente específico que reside al otro lado de un dispositivo de agregación (por ejemplo, un nodo de acceso multiservicio [MSAN]). Sin embargo, los paquetes enviados desde un enrutador de servicios de banda ancha (BSR) a una MSAN no identifican la interfaz demux. Una vez que obtiene un paquete, depende del dispositivo MSAN determinar qué cliente recibe el paquete.
Dependiendo de la inteligencia del dispositivo MSAN, determinar qué cliente recibe el paquete puede ocurrir de manera ineficiente. Por ejemplo, cuando recibe tráfico de control IGMP, una MSAN puede reenviar el tráfico de control a todos los clientes en lugar del cliente previsto. Además, una vez que se establece un destino de flujo de datos, aunque una MSAN puede usar la supervisión IGMP para determinar qué hosts residen en un grupo determinado y limitar los flujos de datos solo a ese grupo, la MSAN aún debe enviar varias copias del flujo de datos a cada miembro del grupo, incluso si ese flujo de datos está destinado a un solo cliente del grupo.
Varias funciones de multidifusión, cuando se combinan, le permiten evitar las ineficiencias mencionadas anteriormente. Entre estas características se incluyen las siguientes:
La capacidad de configurar la instrucción de la familia de interfaces demux IP para usar inet para la interfaz principal numerada o no numerada.
La capacidad de configurar IGMP en la interfaz principal para enviar consultas generales para todos los clientes. La configuración demux impide que la interfaz IGMP principal reciba paquetes de control IGMP de cliente. En su lugar, todos los paquetes de control IGMP van a las interfaces demux. Sin embargo, para garantizar que no se produzcan uniones en la interfaz principal:
Para interfaces IGMP estáticas: incluya la instrucción pasiva send-general-query en la configuración IGMP en el nivel de jerarquía [edit protocols igmp interfaceinterface-name].
Para interfaces demux IGMP dinámicas: incluya la instrucción pasiva send-general-query en el nivel jerárquico [edit dynamic-profiles profile-name protocols igmp interfaceinterface-name].
La capacidad de asignar todos los grupos de multidifusión a la interfaz principal de la siguiente manera:
Para interfaces IGMP estáticas: incluya la instrucción oif-map en el nivel jerárquico [edit protocols igmp interfaceinterface-name].
Para interfaces demux IGMP dinámicas: incluya la instrucción oif-map en el nivel jerárquico [edit dynamic-profiles profile-name protocols igmp interfaceinterface-name].
Con la instrucción oif-map , puede asignar el mismo grupo IGMP a la misma interfaz de salida y enviar sólo una copia de la secuencia de multidifusión desde la interfaz.
La capacidad de configurar IGMP en cada interfaz demux. Para evitar consultas generales duplicadas:
Para interfaces IGMP estáticas: incluya la instrucción pasiva allow-receive send-group-query en el nivel jerárquico de [edit protocols igmp interfaceinterface-name].
Para interfaces demux dinámicas: incluya la instrucción pasiva allow-receive send-group-query en el nivel jerárquico [edit dynamic-profiles profile-name protocols igmp interfaceinterface-name].
Nota:Para enviar solo una copia de cada grupo, independientemente de cuántos clientes se unan, use la instrucción oif-map como se mencionó anteriormente.
Ver también
Clasificación de paquetes por interfaz de salida
En el caso de los enrutadores perimetrales multiservicio M320 de Juniper Networks y los enrutadores de núcleo de la serie T con las interfaces de cola inteligente (IQ), IQ2, IQ mejorado (IQE), colas inteligentes de servicios de vínculo multiservicios (LSQ) o PIC ATM2, puede clasificar los paquetes de unidifusión y multidifusión según la interfaz de salida. Para el tráfico de unidifusión, también puede usar un filtro de varios campos, pero solo se aplica la clasificación de interfaz de salida al tráfico de multidifusión y al tráfico de unidifusión. Si configura la clasificación de salida de una interfaz, no podrá realizar reescrituras de puntos de código de servicios diferenciados (DSCP) en la interfaz. De forma predeterminada, el sistema no realiza ninguna clasificación basada en la interfaz de salida.
En un enrutador serie MX que contiene MPC y MS-DPC, los paquetes de multidifusión se dejan caer en el enrutador y no se procesan correctamente si el enrutador contiene interfaces lógicas MLPPP LSQ que funcionan como receptores de multidifusión y si el modo de servicios de red está configurado como modo IP mejorado en el enrutador. Este comportamiento se espera con interfaces LSQ junto con el modo IP mejorado. En tal escenario, si el modo IP mejorado no está configurado, la multidifusión funciona correctamente. Sin embargo, si el enrutador contiene interfaces LSQ redundantes y el modo de servicios de red IP mejorados configurado con localización FIB, la multidifusión funciona correctamente.
Para habilitar la clasificación de paquetes mediante la interfaz de salida, primero configure un mapa de clase de reenvío y uno o varios números de cola para la interfaz de salida en el nivel jerárquico [edit class-of-service forwarding-class-map forwarding-class-map-name] :
[edit class-of-service] forwarding-classes-interface-specific forwarding-class-map-name { class class-name queue-num queue-number [ restricted-queue queue-number ]; }
Para los enrutadores de la serie T que están restringidos a sólo cuatro colas, puede controlar la asignación de cola con la restricted-queue opción, o puede permitir que el sistema determine automáticamente la cola de forma modular. Por ejemplo, un mapa que asigna paquetes a la cola 6 se asignaría a la cola 2 en un sistema de cuatro colas.
Si configura un mapa de clase de reenvío de salida asociando una clase de reenvío con un número de cola, esta asignación no se admite en las interfaces de cola inteligente (lsq-) de servicios de vínculo multiservicios.
Una vez configurada la asignación de clase de reenvío, se aplica la asignación a la interfaz lógica mediante la output-forwarding-class-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 interface-name unit logical-unit-number] output-forwarding-class-map forwarding-class-map-name;
También deben configurarse todos los parámetros relacionados con las colas y la clase de reenvío. Para obtener más información acerca de cómo configurar clases y colas de reenvío, consulte Configurar una clase de reenvío personalizada para cada cola.
En este ejemplo se muestra cómo configurar una asignación de clase de reenvío específica de la interfaz denominada FCMAP1 que restringe las colas 5 y 6 a colas diferentes en sistemas de cuatro colas y, a continuación, se aplica FCMAP1 a unit 0 la interfaz ge-6/0/0:
[edit class-of-service]
forwarding-class-map FCMAP1 {
class FC1 queue-num 6 restricted-queue 3;
class FC2 queue-num 5 restricted-queue 2;
class FC3 queue-num 3;
class FC4 queue-num 0;
class FC3 queue-num 0;
class FC4 queue-num 1;
}
[edit class-of-service]
interfaces {
ge-6/0/0 unit 0 {
output-forwarding-class-map FCMAP1;
}
}
Tenga en cuenta que sin la restricted-queue opción en FCMAP1, el ejemplo asignaría FC1 y FC2 a las colas 2 y 1, respectivamente, en un sistema restringido a cuatro colas.
Utilice el show class-of-service forwarding-class forwarding-class-map-name comando para mostrar la configuración de cola de mapa de clase de reenvío:
user@host> show class-of-service forwarding-class FCMAP2 Forwarding class ID Queue Restricted queue FC1 0 6 3 FC2 1 5 2 FC3 2 3 3 FC4 3 0 0 FC5 4 0 0 FC6 5 1 1 FC7 6 6 2 FC8 7 7 3
Utilice el show class-of-service interface interface-name comando para mostrar los mapas de clase de reenvío (y otra información) asignados a una interfaz lógica:
user@host> show class-of-service interface ge-6/0/0 Physical interface: ge-6/0/0, Index: 128 Queues supported: 8, Queues in use: 8 Scheduler map: <default>, Index: 2 Input scheduler map: <default>, Index: 3 Chassis scheduler map: <default-chassis>, Index: 4 Logical interface: ge-6/0/0.0, Index: 67 Object Name Type Index Scheduler-map sch-map1 Output 6998 Scheduler-map sch-map1 Input 6998 Classifier dot1p ieee8021p 4906 forwarding-class-map FCMAP1 Output 1221 Logical interface: ge-6/0/0.1, Index 68 Object Name Type Index Scheduler-map <default> Output 2 Scheduler-map <default> Input 3 Logical interface: ge-6/0/0.32767, Index 69 Object Name Type Index Scheduler-map <default> Output 2 Scheduler-map <default> Input 3
Gestión del ancho de banda de reciclaje
Los enrutadores ACX utilizan la interfaz de reciclaje para hacer retroceder o recircular el tráfico desde la interfaz de salida hasta la entrada para un procesamiento adicional. Esto es necesario para aplicaciones que requieren procesamiento adicional.
La interfaz de reciclaje es una interfaz interna canalizada que tiene un formador de salida que limita la velocidad de flujo del tráfico saliente. De forma predeterminada, el ancho de banda de la interfaz de reciclaje se basa en la sobresuscripción del chasis y en la FPC específica de la plataforma o en la configuración de la interfaz.
Las aplicaciones que utilizan el mecanismo de reciclaje, configuran canales o puertos virtuales según las necesidades, que a su vez pasan por un formador de aplicaciones similar al formador de salida en la interfaz de reciclaje. La interfaz de reciclaje puede admitir un máximo de 256 canales o puertos lógicos virtuales. Todos los canales de reciclaje funcionan con la misma prioridad. A continuación, el tráfico reciclado se reenvía utilizando la ranura de calendario en función del peso que se le haya asignado. Otros tipos de interfaces como la interfaz NIF reenvían el tráfico ocupando otras ranuras en el calendario proporcionales a su ancho de banda.
La figura 1 ilustra el mecanismo de reciclaje y sus componentes.
de reciclaje
-
Sh1 – Moldeador de interfaz de reciclaje
-
SA1 – Moldeador de aplicaciones #1 sobre el canal de reciclaje 1
-
SAn – Aplicación #n modelador sobre el canal de reciclaje n (máx. 256)
-
B1 – Peso de la ranura del calendario para el tráfico de la interfaz de reciclaje. Esto refleja el valor de ancho de banda del calendario asignado a la interfaz de reciclaje.
-
B2: peso de la ranura del calendario para el tráfico de interfaces distintas de la interfaz de reciclaje. Por ejemplo, la interfaz NIF.
El mecanismo de reciclaje tiene dos modos de operación:
-
Modo de ancho de banda de reciclaje predeterminado
-
Modo de ancho de banda de reciclaje configurable
Modo de ancho de banda de reciclaje predeterminado
Como su nombre indica, el modo de ancho de banda de reciclaje predeterminado está habilitado de forma predeterminada y no es necesaria la configuración del usuario. A la interfaz de reciclaje se le asigna una parte determinada del ancho de banda total del calendario. Este ancho de banda de reciclaje está garantizado y, por lo tanto, es estable en tiempos de congestión de tráfico. Las aplicaciones recicladas comparten este ancho de banda con el mejor esfuerzo, lo que significa que no hay un ancho de banda garantizado por aplicación.
Los beneficios del ancho de banda de reciclaje predeterminado incluyen:
-
Utilización eficiente del ancho de banda de reciclaje. En caso de que no se estén ejecutando aplicaciones de reciclaje, el ancho de banda no utilizado se puede compartir entre aplicaciones en ejecución de otras interfaces.
-
Utilización eficiente del ancho de banda del chip. En caso de que las otras interfaces que no sean la interfaz de reciclaje no transporten tráfico, las aplicaciones de reciclaje pueden utilizar el ancho de banda no utilizado.
Modo de ancho de banda de reciclaje configurable
Al configurar la interfaz de reciclaje en función de los perfiles, el ancho de banda de la aplicación se vuelve administrable. Puede garantizar la asignación del ancho de banda de reciclaje para una aplicación definiéndola en un perfil.
Los beneficios del ancho de banda de reciclaje configurable incluyen:
-
Asignación de ancho de banda garantizada para una aplicación de reciclaje definida.
-
Flexibilidad para cambiar la asignación de ancho de banda, lo que le ayuda a priorizar el ancho de banda de las aplicaciones.
Ejemplo: configuración del ancho de banda de reciclaje
RESUMEN En este ejemplo se muestra cómo administrar el ancho de banda de reciclaje por aplicación.
Visión general
Las aplicaciones 1, 2, 3 y 4 son aplicaciones de reciclaje que utilizan la interfaz de reciclaje. La Tabla 1 muestra nuestros requisitos de ancho de banda. En este caso, queremos una asignación garantizada del 10% del ancho de banda de la interfaz de reciclaje para la aplicación 1 y del 20% para la aplicación 2. Las aplicaciones 3 y 4 no son prioritarias y no es necesaria ninguna garantía.
| Aplicación de reciclaje | Valor de ancho de banda de reciclaje requerido en porcentaje |
|---|---|
| Aplicación 1 | 10% |
| Aplicación 2 | 20% |
| Aplicación 3 | indefinido |
| Aplicación 4 | indefinido |
Configurar el ancho de banda de la interfaz de reciclaje
set system packet-forwarding-options recycle-bandwidth profile profile1set system packet-forwarding-options recycle-bandwidth-profile profile1 application1 10 application2 20
Verificación
| Tarea de comprobación de | comandos |
|---|---|
show system packet-forwarding-options recycle-bandwidth-profile |
Desde el modo operativo, ejecute el |
Verificación del ancho de banda de reciclaje por aplicación
Propósito
Verificar la asignación de ancho de banda de reciclaje por aplicación.
Acción
user@router> show system packet-forwarding-options recycle-bandwidth-profile Recycle Interface details: Total Bandwidth : 300 Gbps/Core PFE : 0 Application-Name | Core | Bandwidth(Kbps) | Port | VoQ | Profile ----------------------------------------------------------------------------- application1 0 30000000 234 1336 profile1 application2 0 60000000 242 1400 profile1 application3 0 105000000 243 1408 profile1 application4 0 105000000 245 1424 profile1 PFE : 1 Application-Name | Core | Bandwidth(Kbps) | Port | VoQ | Profile ----------------------------------------------------------------------------- application1 0 30000000 234 2880 profile1 application2 0 60000000 242 2944 profile1 application3 0 105000000 243 2952 profile1 application4 0 105000000 245 2968 profile1
Significado
El resultado muestra la asignación de ancho de banda de reciclaje por aplicación tal como se configuró en la sección anterior.
| de aplicación | configurado | Resultado |
|---|---|---|
| Aplicación1 | 10 | 300 Gbps x 10% = 30 Gbps |
| aplicación2 | 20 | 300 Gbps x 20 % = 60 Gbps |
| aplicación3 | no configurado | Ancho de banda no utilizado/número de aplicaciones de reciclaje no configuradas. (300 x 70 %) / 2 = 105 Gbps |
| Aplicación4 | no configurado | (300 x 70 %) / 2 = 105 Gbps |