FAQ

Sí, para implementar más de 100 Gb/s en un solo servidor. Es posible usar 2.4 sockets y lograr 400 Gbps. Es preferible utilizar sistemas monoprocesador con un número suficiente de núcleos.

Para el correcto funcionamiento de SSH, debe deshabilitar Hyper-Threading. SSH funciona solo con núcleos de procesadores físicos.

Sí tu puedes. Tanto la función BRAS/BNG como DPI se pueden controlar por subred o sistema autónomo. Es todo configurable.

La base de datos SSH contiene una correspondencia de todas las direcciones con sus sistemas autónomos, para que pueda comprender a qué ASN pertenece el tráfico y correlacionarlo con la ubicación geográfica del propietario del AS. Por el momento, no existe una integración directa con los servicios de localización IP por ubicación geográfica.

Se sugiere utilizar el agente SNMP, que se instala en el servidor para enviar información al sistema existente del operador.

Muchos operadores de telecomunicaciones utilizan el sistema de monitoreo Zabbix. En este caso, zabbix-agent se instala en los servidores de la Plataforma, se realiza su configuración estándar y conexión al servidor zabbix. Como plantilla, debe usar la plantilla estándar «Template OS Linux» para monitorear los parámetros principales. Y también conecte una plantilla personalizada » Template DPI», que le permite monitorear parámetros fastDPI específicos. La disponibilidad de zabbix-agent para la Plataforma le permite utilizar todo el poder de este sistema de monitoreo.

Existen las siguientes opciones para recibir y procesar estadísticas:

• Producto gratuito NFSEN junto con NFDUMP: solo apto para recibir NetFlow v5 para analizar estadísticas por protocolo y dirección.
• Ipfixreceiver: se usa para recibir IPFIX, almacenarlo en un archivo local.
• Módulo QoE Stor junto con DPIUI2 GUI.

Recomendamos usar QoE Stor para obtener el máximo efecto de las estadísticas cargadas desde el módulo DPI.

El flujo de NetFlow se envía al recopilador desde una interfaz DPI dedicada, generalmente la interfaz mgmt, que proporciona acceso SSH, integración RADIUS, etc.

*Solo puede haber una transmisión del mismo tipo. Si es necesario enviar a varias fuentes, se utiliza la exportación desde el módulo QoE u otros recopiladores.

El ancho de banda necesario para exportar datos de NetFlow suele ser inferior al 0,5 % del consumo total de ancho de banda. Por ejemplo, si está monitoreando un enlace usando 100 Gbps, DPI usará menos de 0,5 Gbps para exportar datos de NetFlow.

DPI acumula estadísticas y las transmite al colector a una frecuencia específica. Según los principios de funcionamiento de DPI, las estadísticas siempre se cargarán con cierto retraso según los intervalos de tiempo establecidos en el archivo de configuración.

• Insertar banners publicitarios
• Bloqueo de anuncios
• Listas de sitios web permitidos y no permitidos
• Notificación de suscriptores (para solicitudes a través de HTTP)
• Almacenamiento en caché
• Protección DDoS
• Recopilación de estadísticas de NetFlow para facturación, contabilidad
• CG-NAT
• Registrar el tráfico de suscriptores en PCAP
• ACL (mini firewall)
• Desviar el tráfico a plataformas externas
• Compañía de Marketing

Si es necesario manejar más tráfico que la capacidad de una plataforma DPI (dúplex completo de 100 G), se instalan módulos DPI adicionales. Para un funcionamiento correcto, es necesario cumplir la condición para organizar la simetría del tráfico (todos los paquetes dentro de una sesión deben pasar a través de un dispositivo DPI). La simetría se puede lograr balanceando SRC/DST IP en conmutadores y enrutadores o instalando balanceadores especiales: Packet Broker.

Es posible transferir tráfico desde/hacia Suscriptores a la plataforma a través de un «espejo» usando un divisor óptico o modo SPAN en el enrutador. En este modo, la plataforma puede proporcionar filtrado por listas de bloqueo (similar al modo «asimétrico»), recopilación de estadísticas sobre el tráfico en QoE Stor, notificación de suscriptores a través de HTTP Redirect.

El monitor Radius, que carga paquetes de inicio de sesión de IP a UDR DPI, se utiliza para obtener información sobre la IP que pertenece a los inicios de sesión.

Los paquetes IP se envían a los clientes y hosts desde un puerto de respuesta que se utiliza para implementar el filtrado y las notificaciones.

*Es necesario saber que la interfaz de red de la plataforma solo funcionará para «recibir» tráfico. Entonces, por ejemplo, si en este modo se aplica un puerto de 10 Gbps, tráfico «reflejado» en la cantidad de 8 Gbps de entrada (a suscriptores) y 5 Gbps de salida (de suscriptores), entonces el tráfico total será 13 Gbps, que es claramente superior a las capacidades del puerto receptor físico.

En algunos esquemas para usar la plataforma DPI, es posible usar solo el tráfico saliente de los suscriptores. Estas opciones incluyen el modo de filtrado de sitios bloqueados.

Una característica de este modo es que el módulo DPI recibe solo tráfico de los suscriptores, y la salida de la plataforma es la formación de una respuesta «ficticia» de un recurso prohibido para el enrutador o simplemente el bloqueo de un paquete destinado a un recurso prohibido.

Este modo se usa cuando el operador no tiene la capacidad de usar la plataforma en modo simétrico o no hay necesidad de otras funciones de la plataforma. No se recomienda este modo.

Si las funciones de autorización ya están implementadas en la red, entonces DPI se habilita después de BRAS / BNG antes de NAT. Así, las IP privadas reales de los suscriptores serán visibles en el tráfico analizado.

Si la plataforma realiza las funciones de BRAS/NAT/DPI, la habilitación se realiza en el núcleo de la red entre el nivel de agregación y el enrutador de borde.

La plataforma DPI siempre tiene puertos de destino: al suscriptor, el puerto está conectado a la red de datos a Internet y el puerto que está conectado al enrutador de borde.

Así, el tráfico desde/hacia al Suscriptor debe pasar por la plataforma, esto se denomina habilitación simétrica. Este modo proporciona un uso funcional completo de la plataforma. Pero es posible que la plataforma funcione en modo «asimétrico» o «espejo».

El componente es responsable de la interacción de la plataforma con el servidor AAA del operador de telecomunicaciones a través del protocolo RADIUS. (AAA – Autenticación, Autorización, Contabilidad). Se usa cuando las funciones BRAS/BNG están habilitadas en la plataforma DPI.

Los componentes DPI y PCRF se comunican entre sí mediante un protocolo de comunicación interno a través de TCP/IP. PCRF se puede alojar en un servidor físico o virtual separado, o ejecutarse en el mismo servidor junto con DPI.

Si se utilizan varios DPI, se utiliza el esquema 1xPCRF: NxDPI.

DPI (fastDPI) es el componente principal sin el cual la plataforma en su conjunto no puede funcionar. DPI proporciona análisis y procesamiento del tráfico que pasa por la plataforma, aplicación de varios servicios al tráfico y su gestión.

Las principales tareas funcionales de DPI:

• Aplicación de políticas con tarifas a todo el tráfico o individualmente por suscriptor
• Aplicación de servicios de la plataforma (CG-NAT, Lista de permitidos, Filtro de sitios bloqueados, etc.)
• Formación de exportación de información de tráfico en varios formatos (NetFlow, IPFIX-clickstream, IPFIX-nat, IPFIX-flow, etc.)
• Funciones BRAS (IPoE, PPPoE, DHCP L2)

El SSG proporciona el análisis y el procesamiento del tráfico que pasa por la plataforma, aplicando la vigilancia y la gestión del tráfico. Mediante una combinación de tecnología DPI, software BRAS/BNG y CG-NAT, resuelve la mayoría de los retos del ISP.

El servidor DHCP se encarga de emitir direcciones privadas a los abonados. Se puede utilizar cualquier implementación compatible con CentOS. La implementación actual utiliza el servidor DHCP de Kea.

El router software es un componente que anuncia y recibe rutas a través de OSPF, BGP y otros protocolos de enrutamiento dinámico soportados por el demonio del router. La implementación actual utiliza BIRD.

El PCRF proporciona la interacción de la plataforma con el servidor AAA del operador a través del protocolo RADIUS (AAA – Authentication, Authorization, Accounting).

QoE Stor es un conjunto de aplicaciones para recoger y almacenar información de tráfico de SSG.

Sí tu puedes. Tanto la función BRAS/BNG como DPI se pueden controlar por subred o sistema autónomo. Es todo configurable.

• DHCP L3: el suscriptor recibe una dirección IP del servidor DHCP (no está conectado de ninguna manera con el SSH), y a través de la red enrutada llega al SSH. Donde, por Source IP, pasa la autorización en Facturación (vigilancia, servicios) y llega al siguiente enrutador después del SSH (la IP se puede transmitir usando CG-NAT).
• DHCP L2: el suscriptor recibe una dirección IP a través del SSH DHCP Proxy o DHCP Relay y está autorizado en Facturación. Luego, SSH lo termina y llega al enrutador que lo sigue.
• L2 estática: el suscriptor tiene una dirección IP fija, de acuerdo con los datos recibidos por SSH desde la solicitud ARP al gateway, pasa la autorización en Facturación, es rescindido por SSH y llega a la frontera.
• PPPoE: el suscriptor genera un túnel PPP desde el SSH, a través del inicio de sesión/contraseña pasa la autorización en Facturación, el SSH termina y llega a la frontera.

No. Si se reinicia el SSH, seguirá funcionando en el mismo modo.

• Por dirección IP en un paquete recibido al usar BRAS en modo L3.
• Por paquete PPPoE: un paquete para autorización (PADI) recibido desde el puerto PPPoE del suscriptor. Le permite identificar a un suscriptor por inicio de sesión, dirección MAC, tunelización Q-in-Q.
• Por paquete DHCP: a partir del paquete DHCP Discovery recibido del puerto del suscriptor en modo L2, puede obtener información para identificar al suscriptor mediante la dirección MAC o tunelización Q-in-Q.

* Opcional – esta opción se puede añadir a la licencia principal con un pago adicional.

• El router anuncia una ruta (BGP, OSPF) al NAT Pool en el momento de su creación.

• En el caso de los abonados con direcciones públicas, el anuncio se realiza después de que el abonado haya sido autorizado.

• El usuario realiza la solicitud a través de PPP (PAP, CHAP, MS-CHAPv2).
  El SSG procesa la solicitud y forma una petición de acceso al servidor Radius a través de la PCRF.

Acct-Session-Id = «001122334455667788»
User-Name = «login04»
User-Password = «password»
Calling-Station-Id = «84:16:f9:05:8b:12»
NAS-Port-Type = 5 (Virtual)
NAS-Port = 0
NAS-Port-Id = «321/654»
NAS-IP-Address = “5.5.5.5”
VasExperts-Service-Type = 3

• Radius genera una respuesta de Acceso-Aceptación especificando el nombre del grupo de servidores DHCP desde el que se asignará la dirección IP privada.

Session-Timeout = 86400
User-Name = «login04»
Framed-Pool = default
VasExperts-Policing-Profile = «rate_50mbits»
VasExperts-Service-Profile = «11:CG-NAT_pool_001»

• El servidor PCRF realiza una solicitud DHCP al servidor DHCP y recibe los parámetros para un abonado específico.
  El inicio de sesión que se recibió de Radius y la dirección IP que se recibió del servidor DHCP se unen. Los datos de vigilancia y servicio de Radius se aplican al inicio de sesión.
  Se genera una respuesta de SSG al usuario de que la conexión PPPoE se ha establecido con éxito.

Existen tres opciones de implementación:

1. comprar un servidor x86 estándar de cualquier fabricante
2. utilizar el equipo que ya tiene
3. implementar el BNG como sistema virtual (componente VNF en eSXI, KVM, servidor Hyper-V).

Aproximadamente 4 terabytes en 6 meses con una carga diaria promedio de 1 gigabit/s. Experimentalmente se pueden encontrar datos más precisos.

MPLS — sí.

GRE — sí, pero sólo si el tráfico en el túnel no está cifrado.

En la base de datos de ClickHouse.

Sí, es posible, tanto en el esquema “in-gap” como en el esquema “espejo”.

El servidor DPI actúa como un sensor. Registra información sobre el flujo en particiones y las envía al recopilador QoE Stor (el intervalo predeterminado es 1 minuto). QoE Stor, después de recibir los datos, los traduce a valores tabulares (registro sin procesar) y luego los agrega (registro agregado).

Hay 4 tipos de registros sin procesar en QoE Stor:

• NetFlow completo sin formato, generado a partir de netflow_full flow,
• flujo de clics sin procesar, formado a partir del flujo ipfix_tcp,
• Flujo GTP bruto, para redes móviles,
• Flujo de NAT sin procesar, información sobre traducciones de NAT.

4 tipos de registros agregados:

• flujo de red,
• flujo de clics,
• Flujo GTP,
• Flujo NAT.

Los registros sin procesar consisten exclusivamente en tablas con toda la información recopilada sobre flujos: inicio/fin/ID de sesión, direcciones de origen/destino IPv4/v6 antes/después de NAT, puertos de origen/destino, AC de destino, etc. La plantilla de la tabla se describe en Formatos de NetFlow .

Los registros agregados se generan en función de los datos sin procesar al combinar varios registros para una dirección IP, lo que reduce la cantidad de almacenamiento y aumenta la velocidad de los informes, pero se pierde el detalle de cada sesión.

Para un subsistema, puede utilizar hardware o máquinas virtuales con las siguientes características:

1. Procesador (CPU) 2,5 GHz — 1 ud. (requiere compatibilidad con el conjunto de instrucciones SSE 4.2. La velocidad del reloj es menos importante. Por ejemplo, 16 núcleos a 2600 MHz es mejor que 8 núcleos a 3600 MHz)
2. Memoria de acceso aleatorio (RAM): a partir de 16 GB (la memoria debe ser al menos tan grande como la cantidad de datos solicitados. Cuanta más memoria, mejor rendimiento al crear informes. Cuanta más memoria, menos carga en disco. El mínimo el requisito es de 16 GB. Desactive siempre el intercambio de archivos)
3. Disco duro (SSD altamente deseable) — desde 500 GB (espacio en disco requerido desde 16 GB por cada día de almacenamiento dependiendo del tráfico. Se estima que 10 Gb/s de tráfico diario promedio genera aproximadamente 25 GB de datos por hora en Almacenamiento QoE). La calculadora de cálculo se presenta en la Wiki.
4. Sistema operativo — CentOS 8+
5. Tarjeta de red (NIC) — desde 1 Gbps.

*El módulo para recibir y procesar estadísticas no se puede instalar en un servidor con una plataforma DPI: la preparación de informes exige recursos de la CPU, lo que puede afectar negativamente el rendimiento de la plataforma DPI.

Se utilizan cuatro componentes para trabajar con IPFIX (NetFlow v10):

1. Exportador de flujo: un dispositivo responsable de recopilar información sobre flujos y exportarla al colector de flujo: SSH DPI (módulo DPI).
2. Recopilador: la aplicación que recibe la información de flujo exportada es ipfixreceiver2 como parte de QoE Stor.
3. Flow Analyzer: una aplicación que analiza la información de flujo recopilada por el colector. La información sobre el flujo se registra para su almacenamiento y análisis en la base de datos de ClickHouse.
4. Interfaz de gestión: una aplicación que le permite visualizar de manera efectiva estadísticas sobre el flujo y administrar todo el sistema de control y análisis de tráfico (SSH DPI) – una interfaz gráfica de usuario DPIUI2.

El módulo Quality of Experience (QoE) es un producto de software para recopilar estadísticas y evaluar la calidad de percepción de los servicios.

Las estadísticas recopiladas por el módulo se superponen a métricas específicas para determinar la experiencia del usuario y responder a la pregunta de qué tan alta calidad de comunicación y servicios de acceso a Internet recibe el usuario final.

Los datos obtenidos permiten al operador tomar las acciones necesarias para mejorar la calidad de los servicios y en consecuencia, fidelizar a los suscriptores.

La rotación de archivos proporciona una copia de seguridad diaria del registro diario. Por defecto, este proceso se realiza durante las horas de menor carga en el sistema. La profundidad del almacenamiento de registros se define en la configuración /etc/logrotate.d/fastdpi parámetro maxage, el valor se especifica en días.

El flujo de NetFlow se envía al recopilador desde una interfaz DPI dedicada, generalmente la interfaz mgmt, que proporciona acceso SSH, integración RADIUS, etc.

*Solo puede haber una transmisión del mismo tipo. Si es necesario enviar a varias fuentes, se utiliza la exportación desde el módulo QoE u otros recopiladores.

El ancho de banda necesario para exportar datos de NetFlow suele ser inferior al 0,5 % del consumo total de ancho de banda. Por ejemplo, si está monitoreando un enlace usando 100 Gbps, DPI usará menos de 0,5 Gbps para exportar datos de NetFlow.

DPI acumula estadísticas y las transmite al colector a una frecuencia específica. Según los principios de funcionamiento de DPI, las estadísticas siempre se cargarán con cierto retraso según los intervalos de tiempo establecidos en el archivo de configuración.

NetFlow v5 está limitado a flujos IPv4. La selección de campos que se pueden exportar con esta versión también es limitada.

IPFIX: a veces denominado NetFlow v10. Aquí se introducen dos nuevos conceptos para el monitoreo de flujo: en primer lugar se permite el uso de plantillas , en segundo lugar el usuario tiene la oportunidad de «mirar» lo suficientemente profundo en los paquetes y seleccionar los campos que le interesan para monitorear. IPFIX permite seleccionar casi todos los campos, todos los tipos de indicadores TCP y otra información del encabezado IP, incluidas las etiquetas VLAN y las URL.

Beneficios de IPFIX sobre el tradicional NetFlow v5:

• flexibilidad, escalabilidad y agregación de datos de flujo más allá de las capacidades de NetFlow tradicional
• la capacidad de monitorear una amplia gama de información sobre paquetes IP, desde la capa 2 hasta la capa 7
• información de flujo configurable por el usuario que permite personalizar la identificación del tráfico; oportunidad de señalar y monitorear el comportamiento específico de la red.

La plataforma es completamente transparente para la aplicación del protocolo de agregación de enlaces LACP, sujeto a las siguientes condiciones:

• los puertos de procesamiento de tráfico pertenecen al mismo clúster
• los puertos están configurados simétricamente y correctamente conectados
• el tráfico desde/hacia el suscriptor (direcciones IP de origen) pasa por los mismos puertos de procesamiento de tráfico.

Como protocolo de control para LAG, se pueden utilizar tanto LACP estándar (IEEE 802.3ad) como propietarios, como PAgP.

*Los protocolos LAG tienen un tiempo de “convergencia” bastante largo, de hasta 30 segundos (sin usar configuraciones especiales), lo que puede afectar el correcto paso del tráfico a través de la plataforma.

El soporte de derivación se implementa para las tarjetas Silicom de 40 GbE, 10 GbE y 1 GbE. Las tarjetas de red multipuerto tienen un modo especial de «Bypass». Cuando este modo está habilitado en la NIC, el tráfico de la NIC se enlaza físicamente entre los dos puertos y, por lo tanto, omite el procesamiento directamente en la NIC y, en consecuencia, en la plataforma.

Este modo se usa cuando es importante mantener el tráfico incluso si el sistema falla. Por supuesto, cuando «Omitir» está habilitado, todas las funciones de la plataforma no están disponibles.

*Habilitar este modo en la tarjeta de red debe considerarse como una emergencia.

Para un subsistema, puede utilizar hardware o máquinas virtuales con las siguientes características:

1. Procesador (CPU) 2,5 GHz — 1 ud. (requiere compatibilidad con el conjunto de instrucciones SSE 4.2. La velocidad del reloj es menos importante. Por ejemplo, 16 núcleos a 2600 MHz es mejor que 8 núcleos a 3600 MHz)
2. Memoria de acceso aleatorio (RAM): a partir de 16 GB (la memoria debe ser al menos tan grande como la cantidad de datos solicitados. Cuanta más memoria, mejor rendimiento al crear informes. Cuanta más memoria, menos carga en disco. El mínimo el requisito es de 16 GB. Desactive siempre el intercambio de archivos)
3. Disco duro (SSD altamente deseable) — desde 500 GB (espacio en disco requerido desde 16 GB por cada día de almacenamiento dependiendo del tráfico. Se estima que 10 Gb/s de tráfico diario promedio genera aproximadamente 25 GB de datos por hora en Almacenamiento QoE). La calculadora de cálculo se presenta en la Wiki.
4. Sistema operativo — CentOS 8+
5. Tarjeta de red (NIC) — desde 1 Gbps.

*El módulo para recibir y procesar estadísticas no se puede instalar en un servidor con una plataforma DPI: la preparación de informes exige recursos de la CPU, lo que puede afectar negativamente el rendimiento de la plataforma DPI.

El módulo exige la cantidad de núcleos de procesador, RAM y la velocidad del subsistema de disco. Requisitos: al menos 16 GB de RAM, 4 núcleos de CPU de 2,5 GHz, un subsistema de disco para una base de datos de 1000 MB en una unidad SSD, para una aplicación de 128 MB. Cálculo de almacenamiento: en promedio, 10 Gbps de tráfico de DPI requieren alrededor de 25 GB de almacenamiento de datos en la base de datos.

Para administración: un puerto de red separado (pero no menos de 1 Gb / s) en cualquier conjunto de chips compatible con el sistema operativo. Sistema operativo: CentOS 8+, archivo de paginación deshabilitado (swap).

Si solo se utiliza un servidor con DPI, el módulo PCRF se puede colocar en el mismo servidor. En los casos en los que se utilizan múltiples DPI (para balanceo de carga/redundancia), tiene sentido mover el PCRF a un servidor separado.

Requisitos: al menos 2 GB de RAM, 2 núcleos de CPU de 2,5 GHz, espacio en disco de 128 Gb.

Para administración: un puerto de red separado (pero no menos de 100 Mbps) en cualquier conjunto de chips compatible con el sistema operativo.

Sistema operativo: CentOS 8+ (x64).

Es un módulo bastante intensivo en recursos: impone mayores requisitos en términos de CPU, velocidad y capacidad de RAM, opcionalmente un HDD rápido, pero es preferible un SSD habilitado para NVMe.

• Un procesador compatible con SSE 4.2, comenzando con Intel Nehalem y AMD EPYC Zen2 con 4 núcleos o más, velocidad de reloj base de 2,6 GHz o superior.
• Además, HyperThreading debe estar deshabilitado en el servidor.
• Mínimo 3 puertos requeridos: uno para control SSH (cualquier chipset), dos para procesamiento de tráfico – tarjetas de red basadas en chipsets con soporte de tecnología DPDK.

Se recomienda utilizar únicamente tarjetas probadas basadas en chipsets Intel1) con 2, 4 y 6 puertos):

Interfaces de 1 GbE
e1000 (82540, 82545, 82546)
e1000e (82571, 82572, 82573, 82574, 82583, ICH8, ICH9, ICH10, PCH, PCH2, I217, I218, I219)
igb (82573, 82576, 82580, I210, I211, I350, I354, DH89xx)
igc (I225)

Interfaces de 10GbE
ixgbe (82598, 82599, X520, X540, X550)

Interfaces de 10 GbE y 40 GbE
i40e (X710, XL710, X722, XXV710)
interfaces de 100GbE
mlx5 (Mellanox ConnectX-5 Ex)
ice (Intel E810) – nno recomendado, hay problemas en el firmware de Intel en la tarjeta: no permite GREtunnels

• Compatibilidad con bypass implementada para tarjetas Silicom de 40 GbE, 10 GbE y 1 GbE
• Sistema operativo: CentOS 8+ (x64)

* Opcional – esta opción se puede añadir a la licencia principal con un pago adicional.