Políticas configuradas
Las políticas configuradas localmente se seleccionan mediante reglas que combinan perfiles con políticas:
- Los perfiles clasifican el tráfico en función de algunos criterios (por ejemplo, un perfil de acceso identifica todo el tráfico procedente de abonados dentro de un conjunto de rangos de direcciones IP).
- Las reglas relacionan políticas y perfiles. Por ejemplo, una regla puede especificar que algún perfil de acceso específico está limitado por una política de tarifas, es decir, que los abonados cuya dirección IP se encuentre en alguna subred tendrán un límite de velocidad específico.
Perfiles
Los perfiles clasifican el tráfico y, cuando son utilizados por las reglas de política, determinan la política a aplicar a un abonado o a un flujo. Existen diferentes tipos de perfiles, según las propiedades que se utilicen para la clasificación del tráfico. La versión actual soporta los siguientes tipos de perfiles:
- Perfil de interfaz: identifica los flujos o abonados cuyo primer paquete de datos entra por una interfaz de red del perfil.
- Perfil VLAN: identifica los flujos o abonados cuyo primer paquete de datos utiliza una etiqueta VLAN dentro del conjunto de etiquetas VLAN (o la ausencia de cualquier etiqueta) del perfil.
- Perfil de la política de planes: identifica el nombre de la política de planes de abonado. El perfil puede contener patrones con comodines. Por ejemplo, un perfil de planes que contenga el patrón "premium-*" coincidirá con el tráfico de abonados con políticas de planes denominadas "premium-gold" y "premium-platinum".
- Perfil de Internet: identifica el tráfico que implica direcciones IP, puertos o protocolos L4 en el lado de Internet.
- Perfil de Acceso: identifica el tráfico que involucra direcciones IP, puertos o protocolos L4 en el lado de Acceso.
- Grupo de abonados Perfil: identifica el nombre del grupo de abonados. El perfil puede contener patrones con comodines. Por ejemplo, un nombre de grupo de abonados que contenga el patrón "inalámbrico*" coincidirá con el tráfico de abonados con políticas de tarifas denominadas "inalámbrico-norte" e"inalámbrico-sur".
- Perfil de ID de abonado: identifica el ID de abonado. El perfil puede contener patrones con comodines. Por ejemplo, un patrón de ID de abonado "100 " coincidirá con el tráfico de abonados con ID "100123" y"100435".
- Perfil horario: define rangos horarios. Opcionalmente, los rangos pueden restringirse sólo a algunos días de la semana.
- Perfil de caudal : identifica todos los flujos que se crearon mientras el tráfico total de bajada a través del BQN estaba por encima del umbral especificado por el perfil.
- Perfil DPI (Deep Packet Inspection): identifica los flujos que tienen un dominio DPI que coincide con uno de los patrones de dominio (firmas) del perfil. Hay un conjunto de firmas DPI predefinidas, que incluyen las firmas de las aplicaciones más populares (como las aplicaciones de streaming de vídeo más importantes o las actualizaciones de software más comunes). Consulta al final de esta sección cómo añadir firmas personalizadas.
Los perfiles se configuran en la opción de menú Configuration->Profiles.
Perfil de interfaz
Un perfil de interfaz contiene una lista de interfaces de red que forman parte de un wire. El perfil es verdadero si el primer paquete es recibido por una de las interfaces del perfil. Una interfaz de red sólo puede formar parte de un perfil al mismo tiempo.
En el siguiente ejemplo, se define un perfil para uno de los dos wires del servidor BQN y otro perfil para un segundo wire:
Perfil VLAN
Un perfil VLAN es una lista de etiquetas VLAN. El perfil es verdadero si el tráfico tiene alguna de las etiquetas VLAN definidas por el perfil.
El siguiente ejemplo define dos perfiles para dos áreas de red y un tercer perfil para el tráfico sin etiqueta VLAN.
Perfil de politica de planes
Este perfil se utiliza para seleccionar las políticas de flujo basadas en la política de planes de abonado. Se trata de una lista de nombres de politicas de planes, o de patrones con comodines. Ejemplos:
Las prioridades en los perfiles de tarifa política resuelven qué perfil tomar cuando hay solapamientos (dos o más perfiles de tarifa política que coinciden con el tráfico). La prioridad se interpreta como orden de prioridad (un perfil de prioridad 10 tendrá prioridad sobre un perfil de prioridad 20). No se suele utilizar porque los perfiles de tarifa política deben definirse evitando tales solapamientos.
Perfiles de acceso e Internet
Los perfiles de Internet comprueban algunas propiedades del tráfico de los puntos finales del lado de Internet (servidores de contenidos). Los perfiles de acceso hacen lo mismo con los puntos finales del lado del acceso (abonados). Las posibles propiedades del tráfico son:
- Direcciones IP.
- Rangos de direcciones IP.
- Número de protocolo de capa 4 (por ejemplo, ICMP, TCP, UDP,OSPF, etc.).
- Números de puerto (para protocolos TCP y UDP).
A continuación se muestra un ejemplo de perfil de acceso que contiene todos los rangos de IP v4 privadas:
Para añadir una entrada, haga clic en la opción de menú Añadir entrada... de la parte superior derecha. A continuación se muestra una entrada de dirección IP, que coincide con cualquier protocolo:
A continuación, algunos ejemplos de perfiles de Internet:
El perfil my-voip incluye el rango IP de un servicio VoIP que utiliza los puertos TCP y UDP 5001 y 5002.
Los pings de perfil coincidirán con el tráfico ICMP a cualquier destino IPv4 o IPv6 (0.0.0.0/0 coincide con cualquier dirección IPv4 y ::/0 con cualquier dirección IPv6).
El perfil web coincide con cualquier tráfico IPv4 o IPv6 a los puertos TCP 80, 8080 y 443.
Para añadir una entrada, haga clic en la opción de menú Añadir entrada... de la parte superior derecha.
Y una entrada que coincida con cualquier tráfico IPv4 al puerto TCP 80:
Es posible cargar una lista de direcciones IP desde un fichero de texto. El formato del fichero de texto tiene una dirección IP o un rango de direcciones por línea. Para cargar un archivo, edite el perfil y seleccione, en el menú superior derecho, la opción Reemplazar usando archivo... (el perfil refleja la lista de direcciones del archivo) o la opción Fusionar usando archivo... (el contenido del archivo se añade a las direcciones existentes en el perfil).
Perfil de grupo de abonados
Este perfil se utiliza para seleccionar Políticas de Flujo, Tasa o Monitorización basadas en el grupo del abonado. Es una lista de nombres de grupos de abonados, o patrones con comodines. Ejemplos:
Las prioridades en los perfiles de grupos de abonados resuelven qué perfil tomar cuando hay solapamientos (dos o más perfiles de grupos de abonados que coinciden con el tráfico). La prioridad se interpreta como orden de prioridad (un perfil de prioridad 10 tendrá preferencia sobre un perfil de prioridad 20). No se suele utilizar porque los perfiles de grupos de abonados deben definirse evitando dichos solapamientos.
Perfil de identificación del abonado
Este perfil se utiliza para seleccionar políticas de baja, tasa o monitorización basadas en el ID del abonado. Es una lista de ID de abonado, o patrones con comodines. Ejemplos:
Las prioridades en los perfiles de ID de abonado resuelven qué perfil tomar cuando hay solapamientos (dos o perfiles de ID de abonado que coinciden con el tráfico). La prioridad se interpreta como orden de prioridad (un perfil de prioridad 10 tendrá prioridad sobre un perfil de prioridad 20). No suele utilizarse porque los perfiles de ID de abonado deben definirse evitando tales solapamientos.
Perfiles temporales
Activa la regla durante un periodo. Un perfil de tiempo es una lista de rangos de tiempo, y es verdadero si cualquiera de los rangos es verdadero. Los rangos dentro del mismo perfil no pueden superponerse.
Una franja puede aplicarse a todos los días de la semana o sólo a determinados días.
El siguiente ejemplo muestra:
- Un perfil de hora punta al final de un día cualquiera (nótese cómo definimos el intervalo de 20:00 a 1:00 usando dos periodos).
- Un perfil de fin de semana durante el sábado y el domingo.
- Un perfil de tiempo para las horas de trabajo, con dos rangos, válido sólo de lunes a viernes
Perfiles de Caudal
Un perfil de caudal define un umbral del tráfico total de bajada a través del BQN. Es verdadero cuando se supera el umbral. El siguiente ejemplo define un umbral de 9 Gbps.
Perfiles DPI
Un perfil DPI es una colección de firmas para identificar en la información obtenida a través de la inspección profunda de paquetes. Las firmas pueden tener diferentes tipos en función de la información DPI:
- HTTP-Host: el nombre de host en el tráfico HTTP
- HTTPS-SNI: la indicación del nombre del servicio en el tráfico HTTPS.
- QUIC-SNI: la indicación de nombre de servicio en el tráfico QUIC.
- QUIC-MVFST: presencia de tráfico MVFST (una variante de QUIC).
- P2P-FILESHARING: presencia de tráfico P2P (BitTorrent).
- SPEEDTEST-OOKLA: presencia de tráfico Speedtest.
Las firmas del tipo HTTP-Host, HTTPS-SNI y QUIC-SNI deben tener un patrón que indique el contenido esperado de la información DPI. Los patrones pueden contener hasta dos comodines. Ejemplos: "prefijo*", "*sufijo", "*subcadena*".
Se puede cargar un conjunto de firmas predefinidas en el perfil DPI seleccionando en el menú ...
Algunosde los conjuntos predefinidos son:
- Transmisión de vídeo: YouTube, Netflix, Facebook, Instagram, Amazon Video, HBO, Hulu, Apple TV, Disney+, Twitch, Tiktok, Magis TV, Start+, Peacock TV, Pluto TV, Roku, Filmin, DAZN, Magis, Perseo.
- Descargas de software: Actualizaciones de MS windows, Mac OS y Android, descargas de PlayStation, Xbox, Epic Games y Steam Games.
- Pruebas de velocidad: Ookla, fast.com, cloudflare,waveform, m-lab, nperf.
Un perfil DPI puede ser llenado con firmas personalizadas usando la opción Add Custom Signature....
Las firmas personalizadas pueden cargarse desde un archivo utilizando la opción Add Signature File... Un archivo de firma es un archivo de texto con una línea por firma, con el siguiente formato:
<pattern> <pattern-type>
donde:
- <pattern> is a domain with wildcards (example: *domain-one.com)
- <pattern-type> is one of the following values: HTTPS-SNI, HTTP-host, QUIC-SNI
Por ejemplo:
*dominio-uno.com HTTPS-SNI
*dominio-uno.com HTTP-host
prefijo*dominio-dos.com HTTPS-SNI
Las prioridades en los perfiles DPI resuelven qué perfil tomar cuando hay solapamientos (dos o más perfiles DPI que coinciden con el tráfico). La prioridad se interpreta como orden de prioridad (un perfil de prioridad 10 tendrá prioridad sobre un perfil de prioridad 20). No suele utilizarse porque los perfiles DPI deben definirse evitando tales solapamientos.
Políticas de flujo de abonados
Cuando se crea un nuevo flujo, se le asigna una política de flujo de abonado, que especifica cómo tratar todos los flujos dentro de ese abonado. Las acciones que se pueden definir en una política de flujo de abonado son:
- Optimización de TCP. Mejora el rendimiento del tráfico TCP. Especifica si se aplica la optimización al tráfico TCP. Se recomienda habilitarla (el valor por defecto).
- Shaping por abonado. Limita la velocidad combinada de los flujos de un abonado a un valor determinado. Es posible limitar en sentido descendente y/o ascendente. El límite se aplica a todos los flujos que coincidan con la política perteneciente al mismo abonado. Por ejemplo, si se asignan flujos de streaming de vídeo a una política con un límite de abonado de 6 Mbps, y el abonado tiene tres flujos de streaming de vídeo al mismo tiempo, los tres flujos compartirán el límite de 6 Mbps (obteniendo alrededor de 2 Mbps cada uno). Es posible definir ráfagas que permitan a los flujos superar temporalmente el límite (véase el final de esta sección).
- Shaping por flujo. Limita la velocidad de un flujo a un valor determinado. Es posible limitar en sentido descendente y/o ascendente. El límite se aplica a cualquier flujo que coincida con la política. Por ejemplo, si a los flujos de streaming de vídeo se les asigna un límite por flujo de 2 Mbps, un flujo de vídeo no podrá superar esos 2 Mbps. El moldeado por flujo puede combinarse con el moldeado por abonado: por ejemplo, si hay un límite de 6 Mbps por abonado y 2 Mbps por flujo, un abonado con cuatro flujos los tendrá limitados al máximo de 6 Mbps (alrededor de 1,5 Mbps cada uno). El conformado por flujo no tiene opción de ráfaga. Dado que la conformación por flujo no se aplica por abonado, puede utilizarse incluso cuando hay un NAT entre la BQN y los abonados finales.
- Bloqueo. Bloquea todos los flujos que entran en la política de bloqueo, en ambas direcciones, y no los deja continuar. Debe usarse con cuidado, para evitar que afecte a un tráfico diferente al previsto.
- Bloquea las conexiones entrantes. Bloquea sólo los flujos que se inician desde el lado de Internet, pero no los flujos iniciados desde los abonados.
- Omitir abonado limitación de velocidad. Si se activa, el tráfico de los flujos con esta política ya no se verá afectado por la limitación de velocidad especificada en la política de tarifas de este abonado.
- Skip subscriber-group limitación de velocidad. Si se activa, el tráfico de los flujos con esta política ya no se verá afectado por la limitación de velocidad especificada en las políticas de tarifas de los grupos a los que pertenece el abonado.
- Shaping Priority. Define la prioridad relativa de los flujos que coinciden con la política frente a otros flujos del mismo abonado, cuando hay un limitación de velocidad.
- Limitación de cuotas y recuento. Esta sección especifica cómo tratar los flujos que coinciden con la política en relación con las cuotas de tiempo y volumen. Consulte la sección Cuotas de abonados para obtener más información.
Estas políticas se configuran en la opción de menú Configuration->Subscriber Flows, seleccionando la pestaña POLICIES.
Shaping por abonado
El siguiente ejemplo define un límite de velocidad de bajada de 10 Mbps, un límite de subida de 8 Mbps y ráfagas de 3 segundos del doble de la velocidad normal.
Opciones de ráfaga
En cuanto a las ráfagas, se configuran en Burst Options de la dirección correspondiente. La política de ráfagas se define mediante cuatro parámetros:
- Velocidad de ráfaga: es la velocidad máxima durante la ráfaga, normalmente mayor que la velocidad máxima de conformación normal (por ejemplo, permitir ráfagas de 20 Mbps para flujos normalmente limitados a 10 Mbps).
- Duración de la ráfaga es la duración de la ráfaga, es decir, durante cuánto tiempo se puede mantener la tasa de ráfaga.
- Umbral de ráfagaUmbral de ráfaga: es una velocidad media que, si se supera, impide que se produzca una nueva ráfaga. Es la forma de controlar cuándo se puede conceder una nueva ráfaga. Por ejemplo, para un límite de 10 Mbps con ráfagas de 20 Mbps, un umbral de ráfaga de 5 Mbps requerirá que los flujos del abonado bajen la velocidad a la mitad de su límite normal antes de permitir una nueva ráfaga.
- Ventana del umbral de ruptura: es el periodo, en segundos, utilizado para calcular la velocidad media que se comprueba frente al umbral. Cuanto más larga sea la ventana, mayor será el peso de la actividad pasada del abonado en la decisión de realizar una nueva ráfaga.
Shaping por flujo
El siguiente ejemplo es una política con un límite por flujo de 4 Mbps en cualquier dirección.
Es posible añadir un shaping por abonado. Los límites de shaping por flujo y por abonado actuarán al mismo tiempo, el shaping por flujo limita la velocidad de los flujos individuales y el shaping por abonado limita la velocidad de flujo combinada por abonado.
Prioridad relativa del flujo
Por defecto, las políticas definen una prioridad de 0. Es posible definir un valor de prioridad como un número entero entre -5 y 5. Cuando se aplica un límite de velocidad al tráfico de un abonado (por ejemplo, debido a una política de tarifas), la prioridad relativa entre los flujos influirá en cómo se repartirá el límite de velocidad entre los flujos, obteniendo los flujos con mayor prioridad velocidades más altas que los de menor prioridad. No se garantiza un reparto exacto de las velocidades en función de las prioridades de los flujos.
Bloqueo del tráfico entrante
Es posible bloquear el tráfico entrante, iniciado desde Internet (conexiones TCP, flujos UDP u otro tráfico IP como pings ICMP). Para ello, existe la sección Drop Incoming Connections como parte de una política de flujo de abonados.
Políticas de planes de abonados
Las políticas de planes se aplican por abonado. Las acciones posibles son:
- Velocidad máxima de bajada. Es la velocidad máxima en la dirección descendente para todo el tráfico que va hacia la dirección IP del abonado.
- Velocidad máxima de subida. Es la velocidad máxima en el sentido ascendente para todo el tráfico que sale de la dirección IP del abonado.
- En Advanced Parameters, puede encontrar las mismas opciones de ráfagas que para las políticas de flujo de abonados.
- Existe una opción de Gestión Automática de Congestión (ACM ), que detectará la congestión y seleccionará un límite de velocidad automáticamente (activada por defecto).
- Límite de número de flujos. Si se activa, un abonado no podrá tener más del número especificado de flujos concurrentes.
Estas políticas se configuran en la opción de menú Configuration->Subscriber Rates, seleccionando la pestaña POLICIES.
Vea en la sección Identificación de abonados cómo se identifica todo el tráfico del mismo abonado.
Las políticas de planes de abonado también pueden crearse dinámicamente a través de las interfaces externas de BQN (RADIUS, API REST o una interfaz a un sistema de facturación externo). En ese caso, los parámetros de la política, y las asociaciones de la política a los suscriptores se controlan desde las interfaces externas y son independientes de las reglas configuradas por BQN (las reglas configuradas se aplican a los suscriptores sin una política asignada por la interfaz externa).
Cuando se asocia una política de tarifas a un grupo de abonados, sólo se aplica límites de velocidad . Los demás parámetros avanzados (ACM, ráfaga, límite de número de flujo, etc.) se ignoran.
Activar/desactivar ACM
El ACM está activado por defecto.
Para activar o desactivar ACM en una política configurada, cambie el campo "Automatic Congestion Management" en la ventana de la velocidad de abonado:
Las políticas de planes dinámicas creadas por RADIUS, REST o una facturación externa también tienen capacidades ACM, y están activadas por defecto.
Para activar o desactivar ACM en una política dinámica, cambie el campo "Gestión automática de congestión" en la configuración del sistema RADIUS/REST/Facturación. Por ejemplo, para las políticas de tarifas RADIUS:
ACM mejora la calidad de la red sin necesidad de realizar ajustes de configuración, por lo que se recomienda mantenerlo activado en todo momento. Sin embargo, es posible deshabilitar ACM para todas las políticas yendo a Configuración->TCPO/ACM Settings y cambiar el interruptor de Global ACM Status a off.
Límite de caudal
Es posible definir en una política de tarifas un límite al número total de flujos del abonado. Un flujo que supere el límite será bloqueado. El siguiente ejemplo establece un límite de 1000 flujos:
Política de monitorización de abonados
Las políticas de monitorización se aplican por abonado. Sólo determinan la cantidad de muestreo de registros DPI para cada abonado. Por defecto, el BQN viene con una política de monitorización por defecto que se aplica a todos los abonados, la cual determina automáticamente el número de registros DPI (llamados UDRs, o Usage Data Records) a producir, para que las estadísticas DPI sean significativas y no tomen demasiado CPU y disco para producirse, y ese es el modo de operación recomendado:
Es posible ajustar la cantidad de UDRs para ciertos abonados creando una política de monitorización que especifique el porcentaje de flujos con UDRs (por ejemplo, 0% o 100%). Los UDRs para el 100% de los flujos producirán una descripción precisa de las estadísticas de uso de los abonados, pero por razones de rendimiento, se recomienda establecer una política de monitorización del 100% de los UDRs sólo en unos pocos abonados a la vez, ya que estas políticas pueden producir un gran número de registros que podrían utilizar todo el espacio disponible en el disco y también podrían hacer que la producción de estadísticas DPI sea muy lenta y consuma la CPU.
Reglas
Las reglas especifican qué políticas configuradas deben asignarse a cada abonado y flujo, en función de los perfiles de la regla.
Existen conjuntos de reglas independientes para cada tipo de política: las reglas de flujo de abonado seleccionan la política de flujo de abonado adecuada para cada flujo, las reglas de planes de abonado seleccionan la política de planes adecuada para cada abonado y, de forma similar, las reglas de monitorización de abonado seleccionan la política de monitorización adecuada para cada abonado.
Una regla puede utilizar un perfil de cada tipo (o, alternativamente, utilizar la opción any, si el tipo de perfil es indiferente), y define una y sólo una política a aplicar.
Cada conjunto de reglas puede tener muchas reglas, pero sólo se seleccionará la que mejor coincida con cada flujo o abonado. Para evaluar las reglas de forma que se maximice el rendimiento, los perfiles se comprueban por orden. Este orden predefinido determina qué regla se selecciona finalmente. Una vista de árbol de las reglas ayuda a identificar qué regla se selecciona en cada caso. Consulte las secciones sobre el árbol de decisiones para obtener detalles sobre los árboles y el orden de evaluación de los perfiles.
No se emplean prioridades configuradas manualmente debido a las penalizaciones de rendimiento que conllevan y a la carga que supone para el operador mantener la coherencia de las prioridades.
Las reglas de flujo de abonado se configuran en la opción de menú Configuration-> Subscriber Flows, seleccionando la pestaña RULES TREE-VIEW o RULES TABLE-VIEW.. Del mismo modo, las reglas de planes de abonados son configurables en Configuration->Subscriber Rates y las reglas de monitorización de los abonados en Configuration->Subscriber Monitoring.
Árbol de decisión de los flujos de abonados
La evaluación de las reglas de flujo de abonado es la siguiente: cuando se crea un nuevo flujo de tráfico (por ejemplo, una conexión TCP), los perfiles del conjunto de reglas de flujo de abonado se cotejan con ese nuevo flujo, se selecciona una regla coincidente y con ella la política de flujo a aplicar.
En aras de la eficiencia, los perfiles se evalúan en este orden predefinido:
- Interfaz (Interface)
- VLAN
- Política de plan (Policy-rate)
- Internet
- Acceso (Access)
- Grupo de abonados
- ID de abonado
- Tiempo
- Caudal (Throughput)
- DPI
El orden de evaluación del perfil define un árbol de decisión, cuyos nodos son los diferentes perfiles y con las políticas como hojas. El árbol determina qué regla se selecciona finalmente, ya que una regla puede ser excluida si pertenece a una rama que el árbol de decisión no sigue. Puede darse el caso de que un flujo coincida con más de una regla. En ese caso, el orden del tipo de perfil es importante: por ejemplo, una regla que coincida con el perfil de interfaz tendría prioridad sobre la regla que coincida con el perfil de VLAN, y así sucesivamente en el orden especificado anteriormente.
Si dos reglas tienen una coincidencia con el mismo tipo de perfil, el perfil más restrictivo tendría prioridad. Por ejemplo, un flujo procedente de un abonado con la dirección IP 192.168.0.1 coincidiría tanto con un perfil de acceso con el rango 192.168.0.0/24 como con otro perfil de acceso con el rango 192.168.0.0/16, pero se seleccionaría la primera regla, con un rango más estrecho (/24 vs/16), y por tanto más restrictiva.
Para facilitar la comprensión de este orden, la interfaz gráfica de usuario incluye una representación gráfica del árbol de decisión, en la que el mejor camino de coincidencia llevaría a la política seleccionada (excepto cuando hay más de una coincidencia en el mismo nivel de perfil, cuando ganaría la más restrictiva). Es accesible en Configuration->Subscriber Flows->Rules haciendo clic en la pestaña Tree View.
Si hay elementos comunes en dos perfiles del mismo tipo y, por tanto, un conflicto de reglas, el árbol de decisión lo señalará para que el operador pueda revisar las reglas y corregir el conflicto. En el siguiente ejemplo, dos perfiles de acceso tienen un solapamiento (ambos contienen el mismo rango de IPs). Esto se señalará con una ventana de advertencia y, además, una de las reglas en conflicto tendrá su número en amarillo. Eliminando el solapamiento (por ejemplo, haciendo que uno de los perfiles tenga un rango más específico), el conflicto desaparecerá.
Árbol de decisión de los planes de abonados
La evaluación de las reglas de planes de abonados se produce cada vez que se detecta una nueva sesión de abonado (cuando se recibe tráfico de una nueva dirección IP de acceso). Los perfiles se cotejan con la sesión de abonado y se encuentra una regla coincidente, que especificará la política de plan a aplicar. Para mayor eficacia, los perfiles se evalúan en el siguiente orden predeterminado:
- Interfaz (Interface)
- VLAN
- Acceso (Access)
- Grupo de abonados
- ID de abonado
- Tiempo
No se pueden utilizar otros tipos de perfiles en las reglas de planes de abonados. Por ejemplo, los perfiles de Internet y los perfiles DPI aplicarían a algunas de las aplicaciones de los abonados y no a otras. Otro ejemplo es el perfil de caudal, porque las reglas de planes se evalúan al inicio de la sesión del abonado y el caudal cambia continuamente.
El árbol de decisiones es similar al árbol de reglas de flujo de abonados. Está disponible en Configuration->Subscriber Rate->Rules seleccionando la pestaña RULES-TREE VIEW..
Árbol de decisiones para monitorización de abonados
La evaluación de las reglas de monitorización de abonados se produce siempre que se detecta una nueva sesión de abonado (cuando se recibe tráfico de una nueva dirección IP de acceso). Los perfiles se cotejan con la sesión de abonado y se encuentra una regla coincidente, que especificará la política de planes a aplicar. Para mayor eficacia, los perfiles se evalúan en el siguiente orden predeterminado:
- Interfaz (Interface)
- VLAN
- Acceso (Access)
- Grupo de abonados
- ID de abonado
No se pueden utilizar otros tipos de perfiles en las reglas de planes de abonados. Por ejemplo, los perfiles de Internet y los perfiles DPI aplicarían a algunas de las aplicaciones de los abonados y no a otras. Otro ejemplo es el perfil de caudal, ya que las reglas de planes se evalúan al inicio de la sesión del abonado y el throughput cambia continuamente.
El árbol de decisiones es similar al árbol de reglas de flujo de abonados. Está disponible en Configuration->Subscriber Monitoring->Rules seleccionando la pestaña RULES TREE-VIEW.
Perfil Prioridad explícita
Como se ha explicado en secciones anteriores, los perfiles se evalúan en un orden de prioridad basado en el tipo de perfil (algunos tipos tienen prioridad sobre otros) y, para perfiles del mismo tipo, en qué perfiles son más específicos. La mayoría de los conjuntos de reglas pueden definirse basándose en este orden de prioridad implícito.
Sin embargo, algunos perfiles utilizan patrones de cadena con caracteres comodín, como *youtube* o mysubscriberId*, para los que no es fácil decidir qué perfil es más específico. Por esa razón, esos tipos de perfil tienen un número de prioridad si las reglas tienen que decidir cuál tendrá prioridad sobre otro perfil coincidente del mismo tipo. Cuanto menor sea el número, mayor será la prioridad del perfil.
Por ejemplo, un perfil con prioridad 10 tendrá prioridad sobre otro perfil del mismo tipo con prioridad 20.
Los tipos de perfil que tienen prioridad anumérica son:
- Perfil de los tipos de interés oficiales
- Perfil del grupo de abonados
- Perfil de identificación del abonado
- DPI
Los perfiles de este tipo se crean con un valor por defecto de 9999 (la prioridad más baja posible, lo que significa que ninguno tiene prioridad a menos que se cambie el valor a un número inferior).
Ejemplos de políticas
A continuación se presentan varios ejemplos de políticas comunes.
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 común), 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 los planes de velocidad es utilizar las interfaces RADIUS, REST o de facturación (ver las secciones correspondientes). Las políticas de velocidad serán entonces asignadas por un sistema externo para cada suscriptor. El sistema externo puede crear directamente esas políticas, o puede asignar políticas de planes configuradas desde la GUI de BQN.
Si no se puede utilizar un sistema externo, se pueden crear políticas de planes, una política de acceso con todas las direcciones IP de los abonados (o rangos) asignados a cada plan y, a continuación, una regla que vincule los perfiles de acceso y las políticas de planes correspondientes. El siguiente es un ejemplo del á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 el nivel de tráfico a partir de la cual se va a empezar a limitar(por encima de 5Gbps en este ejemplo). A continuación, se crea una política de flujo de abonado(flow-10Mbps 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 caudal y la política de flujo de abonado se unen en una regla de flujo de 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 una política de shaping por flujo.
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 planes 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 de VoIP alojado por el ISP, un perfil de policy-rate y una política de flujo (con la limitación de la tasa de abonado seleccionada en On). A continuación, el perfil de Internet y los perfiles de policy-rate se vinculan a la política mediante una regla de flujo de abonados.
Bloqueo de aplicaciones
En este escenario, es necesario bloquear algunas aplicaciones, 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 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.
Excluir el tráfico de la optimización TCP
El objetivo es que el BQN no optimice cierto tráfico. 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, después, se combinan el perfil de acceso y la política de flujo de abonados 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.
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.