Esta sección describe algunos ejemplos de uso de BQN.
Implantación de planes de abonados
El objetivo es aplicar los límites de velocidad en el plan de datos de cada abonado.
El BQN aplica estos límites mejor que un elemento de shaping convencional porque, para el tráfico TCP (el más habitual), no necesita descartar paquetes. Además, utiliza colas independientes por flujo y eso hace que las latencias de las aplicaciones sean independientes entre sí, lo que mejora mucho la experiencia de las aplicaciones interactivas. La siguiente imagen muestra la estructura de colas, con una cola por flujo y control de políticas a nivel de flujo y abonado.
La forma más sencilla de implementar planes de velocidad es utilizar la interfaz RADIUS, la API REST o los sistemas de facturación (véanse las secciones correspondientes). Las políticas de tarifas serán entonces asignadas por un sistema externo a cada abonado. El sistema externo puede crear directamente esas políticas, o puede asignar políticas de tarifas configuradas desde la GUI de BQN.
Si no se puede utilizar un sistema externo, puede crear una política de tarifas para cada plan, un perfil de acceso con todas las direcciones IP (o rangos) de abonados asignadas a ese plan y, a continuación, una regla que vincule los perfiles de acceso y las políticas de tarifas correspondientes.
En el siguiente ejemplo, creamos tres políticas de tarifa de abonado: rate-10Mbps, rate-20Mbps y rate-30Mbps:
Definimos perfiles de acceso con los rangos IP de los abonados asignados a cada política:
Y vinculamos perfiles y políticas en un árbol de reglas:
También es posible definir estas reglas sólo para una dirección IP de prueba que se utiliza durante un piloto para ver el rendimiento de BQN como gestor de ancho de banda:
Limitación de la velocidad de algunas aplicaciones
El objetivo es reducir el caudal máximo de la red para mitigar la congestión en la hora punta. Para ello, se define un perfil DPI (vídeo en el ejemplo) para identificar las aplicaciones a limitar. Este ejemplo hace uso de las firmas predefinidas de streaming de vídeo. Para incluirlas, en Add DPI profile , seleccione Add Predefined Signatures y elija la firma predefinida Video Streaming .
Además, se crea un perfil de caudal con la carga de tráfico a partir de la cual empezar a limitar(superior a 5 Gbps en este ejemplo). A continuación, se crea una política de flujo de abonados(flujo-10 Mbps en el ejemplo) con un límite de enlace descendente(Downlink shaping per Subscriber) fijado en 10 Mbps. Por último, el perfil DPI, el perfil de rendimiento y la política de flujo por abonado se unen en una regla de flujo por abonado.
Limitación de la velocidad de algunas aplicaciones con NAT
El objetivo es reducir el caudal máximo de la red para mitigar la congestión en la hora punta. En este escenario hay un NAT entre el servidor BQN y los abonados finales y, por tanto, no es posible un shaping por abonado.
Utilizaremos los mismos perfiles de Throughput y DPI del ejemplo anterior, pero utilizaremos la política de shaping aper-flow.
Servicios no limitados por la política de planes
El objetivo es preservar la calidad de la experiencia de algunos servicios concediéndoles caudal incluso cuando el plan de velocidad del abonado está totalmente utilizado. Un ejemplo podría ser un servicio de voz sobre IP (VoIP) alojado por el ISP. La política se limita a los abonados con planes oro. Se crea con un perfil de Internet(voip) con la dirección IP y el puerto del servicio VoIP alojado por el ISP, un perfil de política-tarifa y una política de flujo (con Skip subscriber limitación de velocidad seleccionado en On). A continuación, el perfil de Internet y los perfiles de política de tarifas se vinculan a la política mediante una regla de flujo de abonados.
Bloqueo de aplicaciones
En este escenario, algunas aplicaciones se bloquean a hurtadillas, por ejemplo, los servidores que son fuente de ataques. Para ello, se crea un perfil de Internet(malicious-apps en el ejemplo) para identificar las direcciones IP a bloquear. A continuación, se define una política de flujo de abonados con acción de bloqueo (con el nombre flow-block en este ejemplo) y, por último, el perfil de Internet y la política de flujo de abonados se combinan en una regla de flujo de abonados.
Nota: el producto Bequant está diseñado para mejorar la calidad de las redes, no para bloquear contenidos específicos, por lo que no se garantiza que sus firmas DPI predefinidas coincidan con todos los flujos de un contenido específico. Además, la opción de bloqueo de flujos puede no estar disponible en determinados países debido a restricciones a la exportación.
Excluir el tráfico de la optimización TCP
El objetivo es que el BQN no optimice determinados tráficos. Por ejemplo, algunos abonados. Para ello, se define un perfil de acceso(subs-no-tcpo en el ejemplo), con las direcciones IP de los abonados a excluir. A continuación, se define una política de flujo de abonados con la optimización desactivada(flow-no-tcpo en el ejemplo) y, a continuación, el perfil de acceso y la política de flujo de abonados se combinan en una regla de flujo de abonados.
Esta configuración es equivalente a la lista negra de direcciones IP del software BQN versión 3.
Otro ejemplo sería utilizar un perfil de Internet para excluir algunas aplicaciones por puerto TCP.
Priorizar el tráfico de teleconferencias
Necesita BQN R4.25 o posterior.
Para tratar el tráfico de teleconferencia con mayor prioridad que el resto, es necesario definir un DPI y perfiles de Internet. Zoom, Microsoft Teams y Google Meet son compatibles. La siguiente imagen muestra las reglas:
La política se define con una prioridad superior a cero:
Un ejemplo de configuración está disponible aquí, con la lista completa de direcciones IP y puertos del perfil teleconf-ip-ports y la lista de firmas DPI del perfil teleconf-tcp. Guarde el archivo en su máquina local utilizando la opción Guardar como... del navegador y aplíquelo yendo a Administración->Copia de seguridad->Cargar y seleccionando la opción Fusionar .
Ejemplo de reglas de política de flujos
Necesita BQN R4.25 o posterior.
A continuación se presenta un ejemplo de un conjunto completo de reglas que aplican criterios razonables de gestión del ancho de banda, en particular:
- Se da prioridad al tráfico de teleconferencia.
- Las actualizaciones de software tienen menos prioridad y, durante las horas punta, incluso menos.
- Las pruebas de velocidad se dan abonado completo límite de velocidad.
- El streaming de vídeo impide aprovechar todo el límite de velocidad.
Mirando las políticas:
La política flow-teleconf tiene prioridad 1, superior a la predeterminada (0) e incluso superior a flow-updates-offpeak (-1) y flow-updates-peak(-2). Esto significa que el tráfico de teleconferencia tiene la mayor prioridad y las actualizaciones de software la menor (incluso menor durante los periodos de mayor tráfico).
Speedtest se limita a la velocidad máxima del plan (100%), y se le permite alcanzar esa velocidad incluso cuando, combinada con otro tráfico, supera el límite del plan(Skip Rate "yes").
La política de flujo de vídeo limita el streaming de vídeo al 90% del límite de velocidad. La razón es dejar algo de ancho de banda para otros servicios. Además, la velocidad de un solo flujo está limitada a 10 Mbps.
Además de tener menor prioridad, las descargas de SW están restringidas al 90% del plan de velocidad y al 80% en horas punta.
Siéntase libre de ajustar los porcentajes de límite de velocidad y las prioridades relativas a su caso particular.
Un ejemplo de configuración está disponible aquí. Guarde el archivo en su máquina local utilizando la opción Guardar como... del navegador y aplíquelo yendo a Administración->Copia de seguridad->Cargar y seleccionando la opción Fusionar.
Doble pila IPv4/IPv6
Dual stack en este contexto es someter el tráfico IPv4 e IPv6 del mismo abonado a un límite de velocidad compartido.El producto BQN soporta dual stack IPv4/IPv6 en RADIUS y en varios sistemas de facturación, pero siempre es posible soportar dual stack usando BQN REST API. La pila dual se implementa creando un grupo de abonados por abonado, con las direcciones IPv4 e IPv6 como miembros, y la política de tarifas del abonado como política de grupo.
Por ejemplo, para un abonado X con IPs 10.0.0.1 y 2001:abcd:ef00:1001::/64y política de tarifas "Plan-100Mbps":
Se creará un grupo de abonados con el nombre "DS-Cliente-X". La política de tarifas "Plan-100Mbps" debe haberse creado mediante la API REST o configurado directamente en las políticas de tarifas de abonados de BQN.
Tenga en cuenta que, para las direcciones IPv6, la máscara de subred está implícita en la lista "subscriberMembers". Este prefijo implícito se configura en Administración->ConfiguraciónGeneral y es 64 por defecto.
Si algunos abonados tienen subredes IPv6 con un prefijo diferente al resto, se admite. Utilice el campo "subscriberRanges":
Al igual que con otras operaciones de la API REST, puede modificar el grupo con un PUT:
Portal cautivo
Hemos hablado de los portales cautivos en el contexto de la gestión de cuotas. En este ejemplo, utilizaremos ese mecanismo para implementar redirecciones genéricas de portales cautivos. Por genérico queremos decir que un sistema externo podrá activar o desactivar las redirecciones del portal cautivo por abonado, utilizando la API REST de BQN.
En primer lugar, definimos reglas para excluir el tráfico del portal cautivo de los bloques de cuotas y de los límites de los grupos de abonados:
Configuramos el portal cautivo en las opciones de Cuota:
Necesitamos perfiles para caracterizar dos tipos de tráfico:
- Tráfico del portal cautivo: en el ejemplo utilizamos el perfil DPI, pero si se conoce la dirección IP del portal cautivo, también se puede utilizar un perfil de Internet.
- Tráfico DNS para resolver la dirección del portal cautivo: utilizamos un perfil de Internet.
Asociamos esos perfiles a una política no sujeta a bloqueo de cuotas, por lo que el tráfico del portal cautivo pasará:
Utilizaremos un grupo de suscriptores donde colocaremos aquellos suscriptores con el portal cautivo habilitado, por ejemplo captive-group.
Ahora, todo lo que tenemos que hacer para habilitar el portal cautivo es colocar al abonado en el grupo cautivo y establecer una cuota de cero:
Tenga en cuenta que la asignación debe realizarse en función de la dirección IP del abonado (10.0.0.1 en este ejemplo).
Para desactivar el portal cautivo en ese abonado, elimine la cuota y la pertenencia al grupo:
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.