FAQ

Oui, pour implémenter plus de 100 Gbps sur un seul serveur. Il est possible d’utiliser 2,4 sockets et d’atteindre 400 Gbps. Il est préférable d’utiliser des systèmes monoprocesseurs avec suffisamment de cœurs.

Pour que le Stingray SG fonctionne correctement, il faut désactiver Hyper-Threading. Stingray SG ne fonctionne qu’avec des cœurs de processeur physiques.

Oui, c’est possible. Vous pouvez contrôler à la fois la fonction BRAS et DPI sur un sous-réseau spécifique ou un système autonome. Tout est personnalisable.

La base de données de Stingray SG contient la correspondance de toutes les adresses avec leurs systèmes autonomes, de sorte que vous pouvez comprendre à quel ASN appartient le trafic et le corréler à l’emplacement géographique du propriétaire de l’AS. En ce moment, il n’y a pas d’intégration directe avec les services de localisation IP par emplacement géographique.

Il est suggéré d’utiliser SNMP agent, qui est installé sur le serveur pour envoyer des informations au système existant de l’opérateur.

De nombreux opérateurs de télécommunications utilisent le système de surveillance Zabbix. Dans ce cas, zabbix-agent est installé sur les serveurs de la plateforme, sa configuration standard et sa connexion au serveur zabbix sont effectuées. En tant que modèle pour surveiller les principaux paramètres, il faut utiliser le modèle standard « Template OS Linux ». Et connecter également le modèle personnalisé « Template DPI » permettant d’observer les paramètres fastDPI spécifiques. La disponibilité de zabbix-agent pour la plateforme permet d’utiliser toute la puissance de ce système de surveillance.

Pour recevoir et traiter les statistiques, il existe les options suivantes:

• Produit gratuit NFSEN en conjonction avec NFDUMP convient uniquement pour recevoir NetFlow v5 pour l’analyse des statistiques sur les protocoles et les directions.
• Ipfixreceiver est utilisé pour recevoir IPFIX, le stocke dans un fichier local.
• Module QoE Stor associé à l’interface graphique DPIUI2.

Nous recommandons d’utiliser QoE Stor afin d’obtenir le maximum d’effet des statistiques téléchargées depuis le module DPI.

Le flux NetFlow est envoyé au collecteur à partir d’une interface DPI dédiée, l’interface mgmt par laquelle l’accès via SSH, l’intégration avec RADIUS, etc. est généralement effectué.

*Il ne peut y avoir qu’un seul flux du même type. S’il est nécessaire d’envoyer vers plusieurs sources, la réexportation depuis le module QoE ou d’autres collecteurs est utilisée.

La bande passante requise pour exporter des données NetFlow est généralement inférieure à 0,5% de la consommation totale de bande passante. Par exemple, si vous suivez un canal en utilisant 100 Gbps, le DPI utilisera moins de 0,5 Gbps pour exporter les données NetFlow.

Le DPI accumule les statistiques et les transmet au collecteur à une fréquence donnée. Sur la base des principes de fonctionnement DPI, les statistiques seront toujours téléchargées avec un certain retard en fonction des intervalles de temps définis dans le fichier de configuration.

• Insertion de bannières publicitaires
• Blocage des publicités
• Listes autorisées et non autorisées Listes de sites web
• Notification des abonnés (pour les requêtes via HTTP)
• Mise en cache
• Protection DDoS
• Collecte de statistiques NetFlow pour la facturation, la comptabilité
• CG-NAT
• Enregistrement du trafic de l’abonné dans PCAP
• ACL (mini firewall)
• Détourner le trafic vers des plateformes externes
• Société de marketing

S’il est nécessaire de gérer plus de trafic que la capacité d’une plateforme DPI (100G full duplex), des modules DPI supplémentaires sont installés. Pour le fonctionnement correct, il est nécessaire de remplir la condition d’organisation de la symétrie du trafic (tous les paquets d’une session doivent passer par un seul périphérique DPI). La symétrie peut être assurée en équilibrant via SRC / DST IP sur les commutateurs et les routeurs ou en installant des équilibreurs spéciaux Packet Broker.

Il est possible de transférer le trafic de/vers les Abonnés à la plateforme via le « Miroir », en utilisant un séparateur optique ou le mode SPAN sur le routeur. Dans ce mode, la plateforme peut fournir un filtrage par liste noire (similaire au mode « asymétrique »), la collecte de statistiques sur le trafic dans QoE Stor, la Notification des abonnés via HTTP Redirect.

Pour obtenir des informations sur l’appartenance de l’IP aux connexions, un moniteur Radius est utilisé, qui décharge les transmet les paquets IP-Login dans UDR DPI.

Pour implémenter le filtrage et les notifications, un port de réponse est utilisé, à partir duquel les paquets IP sont envoyés vers les clients et les hôtes.

*Il faut comprendre que l’interface réseau de la plateforme ne fonctionnera que pour la « réception » du trafic. Ainsi, par exemple, si ce mode est appliqué au port 10 Gbps, le trafic « miroir » entrant (vers les abonnés) dans le volume de 8 Gbps et le trafic sortant (des abonnés) de 5 Gbps, le trafic total sera de 13 Gbps, ce qui est clairement supérieur aux capacités du port de réception physique.

Dans certains schémas d’application de la plateforme DPI, il est possible d’utiliser uniquement le trafic provenant des abonnés. Ces options incluent le mode de filtrage des sites interdits.

La particularité de ce mode est que le module DPI ne reçoit que le trafic provenant des abonnés, et la sortie de la plateforme est soit la formation d’une réponse « fictive » d’une ressource interdite pour le routeur, soit simplement le blocage d’un paquet destiné à une ressource interdite.

Ce mode est utilisé lorsque l’opérateur n’a pas la possibilité d’utiliser la plateforme en mode symétrique ou si d’autres fonctions de la plateforme ne sont pas requis. Ce mode n’est pas recommandé.

Si des fonctions d’autorisation sont déjà implémentées sur le réseau, DPI est activé après BRAS / BNG avant NAT. Ainsi, de véritables IP privées des abonnés seront visibles dans le trafic analysé.

Dans le cas où la plateforme exécute les fonctions BRAS/NAT/DPI, l’activation est effectuée dans le noyau du réseau entre la couche d’agrégation et le routeur Edge.

La plateforme DPI a toujours des ports de destination: vers l’Abonné – port connecté au réseau de données et vers Internet — connecté au routeur Edge.

Ainsi, le trafic de / vers l’Abonné doit passer par la plateforme, c’est ce qu’on appelle la connexion symétrique. Ce mode permet une utilisation fonctionnelle complète de la plateforme. Mais il est possible d’utiliser la plateforme en mode «asymétrique» ou «miroir».

C’est un composant responsable de la communication de la plateforme avec le serveur AAA de l’opérateur de Télécommunications via le protocole RADIUS. (АAA — Authentication, Authorization, Accounting). Utilisé lorsque les fonctions BRAS/BNG sont activées sur la plateforme DPI.

Les composants DPI et PCRF communiquent entre eux par un protocole de communication interne via une pile TCP/IP. PCRF peut être hébergé sur un serveur physique ou sur celui virtuel séparé, ou fonctionner sur le même serveur avec DPI.

Si plusieurs DPI sont utilisés, le schéma 1xPCRF : NxDPI est utilisé.

DPI (fastDPI) est un composant principal, sans lequel la plateforme dans son ensemble ne peut pas fonctionner. DPI permet d’analyser et de traiter le trafic passant par la plateforme, d’appliquer et de gérer différents services au trafic.

Principales tâches fonctionnelles de DPI:

• Application des politiques tarifaires de vitesse à tout le trafic ou individuellement par abonné
• Application des services de la plateforme (CG-NAT, liste blanche, filtre de sites interdits, etc.)
• Formation d’exportation d’informations de trafic dans différents formats (NetFlow, IPFIX-clickstream, IPFIX-nat, IPFIX-flow, etc.)
• Fonctions de BRAS (IPoE, PPPoE, DHCP L2)

SSG fournit l’analyse et le traitement du trafic qui traverse la plateforme, en appliquant la police et la gestion du trafic. Grâce à une combinaison de technologie DPI, de logiciels BRAS / BNG et de CG-NAT, il résout la plupart des défis du FAI.

Serveur DHCP. Ce composant est responsable de l’émission d’adresses privées aux abonnés. Toute implémentation compatible avec CentOS peut être utilisée. L’implémentation actuelle utilise le serveur DHCP Kea.

Routeur logiciel. Un composant qui annonce et reçoit des routes via OSPF, BGP et d’autres protocoles de routage dynamique pris en charge par le démon du routeur. La mise en œuvre actuelle utilise BIRD.

PCRF. Assure l’interaction de la plateforme avec le serveur AAA de l’opérateur via le protocole RADIUS (AAA — Authentication, Authorization, Accounting).

QoE Stor est un ensemble d’applications pour collecter et stocker des informations sur le trafic à partir de SSG.

Oui, c’est possible. Vous pouvez contrôler à la fois la fonction BRAS et DPI sur un sous-réseau spécifique ou un système autonome. Tout est personnalisable.

• DHCP L3 — l’abonné reçoit une adresse IP du serveur DHCP (il n’est en aucun cas connecté au Stingray SG) et via le réseau routé il accède au Stingray SG. Où, par Source IP, il passe l’autorisation dans Facturation (police, services) et accède au routeur suivant après le Stingray SG (l’IP peut être diffusée à l’aide de CG-NAT).
• DHCP L2 — l’abonné reçoit une adresse IP via le Stingray SG DHCP Proxy ou le relais DHCP et est autorisé dans la Facturation. Ensuite, il se termine par Stingray SG et atteint le routeur qui le suit.
• Static L2 — l’abonné a une adresse IP fixe, selon les données reçues par le Stingray de la demande ARP à la passerelle, il passe l’autorisation dans la Facturation, est résilié par le Stingray SG et arrive à la frontière.
• PPPoE — l’abonné prend un tunnel PPP à partir du Stingray SG, passe l’autorisation dans la Facturation via le login / mot de passe, est résilié par le Stingray SG et arrive à la frontière.

Non, si le SSH est redémarré, il continuera à fonctionner dans le même mode.

• Par adresse IP dans un paquet reçu lors de l’utilisation de BRAS en mode L3.
• Par paquet PPPoE — un paquet d’autorisation (PADI) reçu du port PPPoE de l’abonné. Cela permet d’identifier un abonné par identifiant, adresse mac, balises qinq.
• Par paquet DHCP — vous pouvez obtenir des informations d’identification de l’abonné via l’adresse mac ou l’étiquette qinq à partir du paquet DHCP Discovery reçu du côté du port d’abonné en mode L2.

* Optional — cette option peut être ajoutée à la licence principale avec un paiement supplémentaire.

• Le routeur annonce une route (BGP, OSPF) vers le NAT Pool au moment où il est créé.

• Pour les abonnés ayant des adresses publiques, l’annonce est faite après l’autorisation de l’abonné.

• L’utilisateur effectue la demande via PPP (PAP, CHAP, MS-CHAPv2).
• SSG traite la demande et forme une demande d’accès au serveur Radius via 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 génère une réponse Access-Accept spécifiant le nom du pool de serveurs DHCP à partir duquel l’adresse IP privée sera attribuée.

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

• Le serveur PCRF fait une demande DHCP au serveur DHCP et reçoit les paramètres pour un abonné spécifique.
• Le login qui a été reçu du Radius et l’adresse IP qui a été reçue du serveur DHCP sont liés ensemble. Les données de police et de service de Radius sont appliquées à la connexion.
• Une réponse est générée de SSG à l’utilisateur que la connexion PPPoE a été établie avec succès.

Il existe trois options pour la mise en œuvre :

1. achetez un serveur x86 standard de n’importe quel Fabricant
2. utilisez l’équipement que vous avez déjà
3. déployez BNG en tant que système virtuel (composant VNF sur serveurs eSXI, KVM, Hyper-V ).

Environ 4 téraoctets en 6 mois avec une charge quotidienne moyenne de 1 gigabits / s. Des données plus précises peuvent être trouvées expérimentalement.

MPLS – oui.

GRE – oui, mais seulement si le trafic dans le tunnel n’est pas crypté.

Dans la base de données ClickHouse.

Oui, c’est possible, aussi bien dans le schéma « en rupture » que dans le schéma «Miroir».

Le serveur DPI sert de capteur. Il enregistre les informations de flux dans la partition et les envoie au collecteur QoE Stor (la fréquence par défaut est 1 min.) QoE Stor, après avoir reçu les données, les traduit en valeurs tabulaires (journal brut), puis les agrège (journal agrégé).

Il existe 4 types de journaux bruts dans QoE Stor:

• NetFlow brut complet, formé à partir du flux netflow_full,
• Clickstream brut, formé à partir du flux ipfix_tcp,
• GTP Flow brut pour les réseaux mobiles,
• NAT Flow brut — informations sur les émissions NAT.

4 types de journaux agrégés:

• NetFlow,
• Clickstream,
• GTP Flow,
• NAT Flow.

Les journaux bruts sont constitués exclusivement de tables avec toutes les informations collectées sur les flux : début/fin/ID de session, adresses source/destination IPv4/v6 avant/après NAT, ports source/destination, AC de destination, etc. Le modèle de table est décrit dans Formats NetFlow.

Les journaux agrégés sont générés sur la base des données brutes en combinant plusieurs enregistrements pour une adresse IP, ce qui réduit la quantité de stockage et augmente la vitesse de création de rapports, mais les détails de chaque session sont perdus.

Pour un sous-système, vous pouvez utiliser du matériel ou des machines virtuelles avec les caractéristiques suivantes :

1. Processeur (CPU) 2,5 GHz — 1 pc. (nécessite la prise en charge du jeu d’instructions SSE 4.2. La vitesse d’horloge n’est pas si grave. Par exemple, 16 noyaux avec 2600 MHz est mieux que 8 noyaux 3600 MHz).
2. La mémoire vive (RAM) est de 16 Gb (la mémoire ne doit pas être inférieure à la quantité de données requis. Plus il y a de mémoire, meilleures sont les performances lors de la création de rapports. Plus il y a de mémoire, moins la charge sur le disque est importante. L’exigence minimale est 16Gb. Toujours désactiver le fichier d’échange).
3. Disque dur (SSD est hautement souhaitable) – à partir de 500 Gb (espace disque requis à partir de 16 Gb pour chaque jour de stockage, en fonction du trafic. On estime que 10 Gbps de trafic quotidien moyen génère environ 25 Gb de données en une heure dans QoE Stor). La calculatrice de calcul est présentée sur le Wiki.
4. Système d’exploitation — CentOS 8+.
5. Carte réseau (NIC) — à partir de 1 Gbps.

*Le module de réception et de traitement des statistiques ne peut pas être installé sur un serveur avec une plateforme DPI : la préparation des rapports nécessite des ressources CPU, ce qui peut avoir un impact négatif sur les performances de la plateforme DPI.

Pour le fonctionnement avec IPFIX (NetFlow v10) les quatre composants suivants sont utilisés :

1. Exportateur de flux est un appareil chargé de collecter des informations sur les flux et de les exporter vers le collecteur de flux — c’est un module Stingray SG (DPI module).
2. Collecteur est une application qui reçoit les informations de flux exportées — c’est ipfixreceiver2 dans le cadre de QoE Stor.
3. Analyseur de flux est une application qui analyse les informations de flux collectées par le collecteur. Les informations de flux sont enregistrées pour le stockage et l’analyse dans la base de données ClickHouse.
4. Interface de gestion est une application qui permet de visualiser efficacement les statistiques de flux et de gérer l’ensemble du système de contrôle et d’analyse du trafic (Stingray SG) c’est une interface utilisateur graphique DPIUI2.

Le module Quality of Experience (QoE) est un logiciel permettant de collecter des statistiques et d’évaluer la qualité de la perception des services.

Les statistiques collectées par le module se superposent à des métriques spécifiques pour déterminer l’expérience utilisateur et répondent à la question de la qualité des services de communication et d’accès à Internet obtenus par l’utilisateur final.

Les données obtenues permettent à l’opérateur de prendre les mesures nécessaires pour améliorer la qualité des services et, par conséquent, pour augmenter la fidélité des abonnés.

La rotation des fichiers fournit une sauvegarde quotidienne du journal quotidien. Par défaut, ce processus est effectué aux heures où la charge du système est la plus faible. La profondeur de stockage des journaux est définie par le paramètre maxage dans la configuration /etc/logrotate.d/fastdpi, la valeur est spécifiée en jours.

Le flux NetFlow est envoyé au collecteur à partir d’une interface DPI dédiée, l’interface mgmt par laquelle l’accès via SSH, l’intégration avec RADIUS, etc. est généralement effectué.

*Il ne peut y avoir qu’un seul flux du même type. S’il est nécessaire d’envoyer vers plusieurs sources, la réexportation depuis le module QoE ou d’autres collecteurs est utilisée.

La bande passante requise pour exporter des données NetFlow est généralement inférieure à 0,5% de la consommation totale de bande passante. Par exemple, si vous suivez un canal en utilisant 100 Gbps, le DPI utilisera moins de 0,5 Gbps pour exporter les données NetFlow.

Le DPI accumule les statistiques et les transmet au collecteur à une fréquence donnée. Sur la base des principes de fonctionnement DPI, les statistiques seront toujours téléchargées avec un certain retard en fonction des intervalles de temps définis dans le fichier de configuration.

NetFlow v5 est limité aux flux IPv4. La sélection de champs pouvant être exportés à l’aide de cette version est également limitée.

IPFIX — parfois appelé NetFlow v10. Deux nouveaux concepts de surveillance de flux sont introduits ici: premièrement, l’utilisation de modèles est autorisée, et deuxièmement, l’utilisateur a la possibilité de «mettre un oeil» suffisamment en profondeur dans les packages et de sélectionner les champs qui l’intéressent pour la surveillance. IPFIX permet de choisir parmi l’en-tête IP presque tous les champs, tous les types d’indicateurs TCP et d’autres informations, y compris les balises VLAN et les adresses URL.

Avantages d’IPFIX par rapport au NetFlow V5 traditionnel:

• flexibilité, évolutivité et agrégation des données de flux au-delà des capacités du NetFlow traditionnel
• possibilité de surveiller un large éventail d’informations sur les paquets IP allant de la couche 2 jusqu’à la couche 7
• informations de flux configurables par l’utilisateur permettant de configurer l’identification du trafic (possibilité de mettre en évidence et de surveiller le comportement spécifique du réseau).

La plateforme est totalement transparente à l’application du protocole d’agrégation de liens LACP, sous réserve des conditions suivantes:

• les ports de traitement du trafic appartiennent au même cluster
• les ports sont configurés symétriquement et correctement connectés
• le trafic de / vers l’Abonné (adresses IP source) passe par les mêmes ports de traitement du trafic.

En tant que protocole de contrôle pour LAG peut être utilisé à la fois LACP standard (IEEE 802.3 ad) ainsi que des protocoles propriétaires, comme PAgP.

*Les protocoles LAG ont un temps de «convergence» assez long jusqu’à 30 secondes (sans utiliser de paramètres spéciaux), ce qui peut affecter le passage correct du trafic à travers la plateforme.

La prise en charge de Bypass est implémentée pour les cartes de Silicom 40 GbE, 10 GbE et 1 GbE. Les cartes réseau multiport ont un mode spécial «Bypass». Lorsque ce mode est activé sur la carte réseau, le trafic de la carte réseau est physiquement fermé entre les deux ports, ce qui évite le traitement directement sur la carte réseau et, par conséquent, sur la plateforme.

Ce mode est utilisé lorsqu’il est important de maintenir le trafic même en cas de défaillance du système. Bien entendu, lorsque «Bypass» est activé, toutes les fonctions de la plateforme sont indisponibles.

*L’activation de ce mode sur la carte réseau doit être considérée comme une situation d’urgence.

Pour un sous-système, vous pouvez utiliser du matériel ou des machines virtuelles avec les caractéristiques suivantes :

1. Processeur (CPU) 2,5 GHz — 1 pc. (nécessite la prise en charge du jeu d’instructions SSE 4.2. La vitesse d’horloge n’est pas si grave. Par exemple, 16 noyaux avec 2600 MHz est mieux que 8 noyaux 3600 MHz).
2. La mémoire vive (RAM) est de 16 Gb (la mémoire ne doit pas être inférieure à la quantité de données requis. Plus il y a de mémoire, meilleures sont les performances lors de la création de rapports. Plus il y a de mémoire, moins la charge sur le disque est importante. L’exigence minimale est 16Gb. Toujours désactiver le fichier d’échange).
3. Disque dur (SSD est hautement souhaitable) – à partir de 500 Gb (espace disque requis à partir de 16 Gb pour chaque jour de stockage, en fonction du trafic. On estime que 10 Gbps de trafic quotidien moyen génère environ 25 Gb de données en une heure dans QoE Stor). La calculatrice de calcul est présentée sur le Wiki.
4. Système d’exploitation — CentOS 8+.
5. Carte réseau (NIC) — à partir de 1 Gbps.

*Le module de réception et de traitement des statistiques ne peut pas être installé sur un serveur avec une plateforme DPI : la préparation des rapports nécessite des ressources CPU, ce qui peut avoir un impact négatif sur les performances de la plateforme DPI.

Le module est exigeant sur le nombre de cœurs de processeur, la RAM et la vitesse du sous-système de disque. Exigences: au moins 16 Gb de RAM, 4 cœurs CPU à partir de 2,5 GHz, sous-système de disque pour la base de données à partir de 1000 Mb sur le disque SSD, pour l’application à partir de 128 Mb. Calcul du stockage: une moyenne de 10 Gbps de trafic DPI nécessitent environ 25 Gb de stockage de données dans la base de données.

Pour la gestion — un port réseau séparé (mais pas moins de 1 Gbps) sur n’importe quel chipset pris en charge par le système d’exploitation. Système d’exploitation: CentOS 8+, fichier d’échange désactivé (swap).

Si un seul serveur avec DPI est utilisé, le module PCRF peut être hébergé sur le même serveur. Dans les cas où plusieurs DPI sont utilisés (pour l’équilibrage de charge/la redondance), il est logique de déplacer le PCRF vers un serveur séparé.

Exigences: au moins 2 Gb de RAM, 2 cœurs de processeur à partir de 2,5 GHz, espace disque à partir de 128 Gb.

Pour la gestion – un port réseau séparé (mais pas moins de 100 Mbps) sur n’importe quel chipset pris en charge par le système d’exploitation.

Système d’exploitation: CentOS 8+ (x64).

Un module assez gourmand en ressources : il impose des exigences accrues en termes de CPU, de vitesse et de capacité de RAM, un disque dur rapide, mais un SSD avec le support NVMe est préférable.

• Un processeur prenant en charge les instructions SSE 4.2, à partir d’Intel Nehalem et AMD EPYC Zen2 avec 4 cœurs ou plus, vitesse d’horloge de base de 2,6 GHz ou plus.
• De plus, HyperThreading doit être désactivé sur le serveur.
• Au minimum, 3 ports sont nécessaires : un pour le contrôle SSH (tout chipset), deux pour le traitement du trafic – cartes réseau basées sur des chipsets avec prise en charge de la technologie DPDK.

Il est recommandé d’utiliser uniquement les cartes testées sur les chipsets Intel1) avec le nombre de ports 2, 4 et 62):

Interfaces 1GbE
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 10GbE
ixgbe (82598, 82599, X520, X540, X550)

Interfaces 10GbE et 40GbE
i40e (X710, XL710, X722, XXV710)
Interfaces 100GbE
mlx5 (Mellanox ConnectX-5 Ex)
ice (Intel E810) — non recommandé, il y a des problèmes dans le Intel firmware sur la carte : il n’autorise pas les tunnels GRE

• La prise en charge de Bypass est implémentée pour les cartes de Silicom 40 GbE, 10 GbE et 1 GbE
• Système d’exploitation: CentOS 8+ (x64)

* Optional — cette option peut être ajoutée à la licence principale avec un paiement supplémentaire.