Le plugin Netflow permet de surveiller le débit moyen généré sur une période définie par une application, une ip source ou une ip de destination et générer des alertes en cas de dépassement des seuils définis, il remonte également des données et des graphiques de performance de la même manière que les autres plugins.
Cas d’usage et bonnes pratiques d’utilisation des plugins :
Le plugin a été spécifié de sorte de pouvoir répondre à des besoins bien précis. Il présente différents champs à renseigner permettant de cibler la consommation de la bande passante
Dans l’idéal, chaque plugin instancié doit répondre à un besoin, par exemple, la mesure du débit généré par le service de messagerie. Dans ce cas, l’utilisateur renseignera les différents champs nécessaires à cette mesure (ip de destination du serveur de messagerie, port SMTP 25….).
sFlow
Introduction
SFlow permet de surveiller le trafic en temps réel des réseaux de données contenant des commutateurs et des routeurs. Il utilise le mécanisme d’échantillonnage dans le logiciel sFlow Agent sur les commutateurs et les routeurs pour surveiller le trafic et pour transmettre les données d’échantillonnage sur les ports d’entrée et de sortie au collecteur de données central, également appelé sFlow Analyzer.
Pour plus d’informations sur sFlow, voir RFC 3176.
Agent sFlow
Le sFlow Agent échantillonne périodiquement ou interroge les compteurs d’interface qui sont associés à une source de données des paquets échantillonnés. La source de données peut être une interface Ethernet, une interface EtherChannel ou une gamme d’interfaces Ethernet. L’agent sFlow interroge le gestionnaire de port Ethernet pour les informations d’appartenance EtherChannel respectives et reçoit également des notifications du gestionnaire de ports Ethernet pour les changements d’appartenance.
Lorsque vous activez l’échantillonnage sFlow, en fonction de la fréquence d’échantillonnage et du numéro aléatoire interne du matériel, les paquets d’entrée et les paquets de sortie sont envoyés à la CPU en tant que paquet échantillonné en sFlow. L’agent sFlow traite les paquets échantillonnés et envoie un datagramme sFlow à l’analyseur sFlow. En plus du paquet échantillonné d’origine, un datagramme sFlow comprend les informations sur le port d’entrée, le port de sortie et la longueur du paquet d’origine. Un datagramme sFlow peut avoir plusieurs échantillons de sFlow.
sFlow versions
Version | Commentaire |
V1 | Version initiale |
V2 | (Inconnu) |
V3 | Ajoute un support pour les informations étendues |
V4 | Ajoute les communautés BGP de soutien |
V5 | Plusieurs améliorations de protocole. Il s’agit de la version actuelle, qui est prise en charge par le monde entier. |
SFlow datagrammes
Les données échantillonnées sont envoyées sous forme de paquet UDP à l’hôte et au port spécifié. Le numéro de port officiel pour sFlow est le port 6343. Le manque de fiabilité dans le mécanisme de transport UDP n’affecte pas de manière significative la précision des mesures obtenues à partir d’un agent sFlow. Si les échantillons du compteur sont perdus, de nouvelles valeurs seront envoyées lorsque le prochain intervalle de sondage aura passé. La perte d’échantillons de flux de paquets entraîne une légère réduction du taux d’échantillonnage effectif.
La charge utile UDP contient le datagramme sFlow . Chaque datagramme fournit des informations sur la version sFlow, l’adresse IP du périphérique d’origine, un numéro de séquence, le nombre d’échantillons qu’il contient et un ou plusieurs échantillons de flux et / ou de compteur.
Paramètres par défaut pour sFlow
Paramètres | Défaut |
SFlow taux d’échantillonnage | 4096 |
SFlow échantillonnage-taille | 128 |
SFlow max datagram-size | 1400 |
SFlow collecteur-port | 6343 |
SFlow counter-poll-interval | 20 |
Architecture
Des éléments réseau (commutateurs et routeurs) établissent des statistiques sur les données des flux réseau qu’ils exportent vers des collecteurs. Ces statistiques détaillées peuvent porter sur les nombres de paquets et d’octets, les ports applicatifs, les adresses IP, les champs de qualité de service, les interfaces par lesquelles ils transitent, etc.
L’architecture permettant de collecter les informations sur le trafic du réseau IP est la suivante:
- sFlow exportateur: Observe les données par paquets, créé des enregistrements du trafic réseau surveillé et transmet ces données au sFlow Collector.
- sFlow Collector: Collecte les enregistrements envoyés par l’exportateur, les stocke dans une base de données locale.
- ServiceNav BOX: Récupère les informations collectées par le sFlow Collector: en fonction du besoin entré en paramètres du plugin sFlow
- SNP (Plateforme de supervision) permet de configurer le service sFlow est d’exploiter les données remontées par la ServiceNav BOX
Configuration des prérequis
Mise en place du sFlow Collector Storage
Si vous disposez déjà d’un NetFlow Collector, vous pouvez le mutualiser en suivant la procédure ci-dessous
En fonction de besoin d’analyse réseau, Il est possible de dédier un serveur sFlow Collector Storage ou d’utiliser une de vos ServiceNav Box déjà en service.
Dimensionnement du sFlow Collector Storage
Quelle quantité d’espace disque un déploiement sFlow moyen devrait-il consommer? L’une des plus grandes préoccupations est que l’exportation de sFlow aura un impact sur la bande passante disponible, les frais généraux du processeur sur les périphériques ou sur les disques durs qui le stockent.
Il est important de noter qu’une exportation de données de flux réseau peut contenir des enregistrements contenant jusqu’à 30 conversations ou flux . Ceci est important car le volume moyen de sFlow est directement proportionnel au nombre de sockets TCP / UDP uniques créées par les clients et les serveurs du réseau.
Quel est le volume de flux typique par PC? La réponse est: cela dépend, la tendance semble être d’environ 100 flux / minute par ordinateur, avec un pic de 350
par exemple, une entreprise compte 1000 noeuds et que chaque noeud génère 200 flux par minute. Cela équivaut à environ 200000 flux en une minute, soit environ 3300 flux par seconde. Pourquoi tant de flux ?
Les applications engendrent beaucoup de flux uniques, en particulier les navigateurs web et la plupart des applications. Voici quelques applications typiques très bavardes:
- Java, Adobe, Anti-virus, navigateurs web
- Skype est très bavard et provoque du trafic vers le DNS
- Flux de pages Web générant des images, des annonces, etc.
- Email vérifiant constamment la boîte de réception
- NetBios
Un flux stockés sur le sFlow Colletor Storage occupe 150 octets d’espace disque, il est donc préconiser de provisionner 2 Go par jour et par tranche de 100 nœuds:
Cpu(s) | 4 vCPU |
RAM | 8 Go |
Espace disque | 20 Go + 2 Go par jour et par tranche de 100 nœuds |
Interface réseau | 1 gbps |
Configuration du sFlow Collector Storage :
Si vous disposez déjà d’un NetFlow Collector, vous pouvez le mutualiser en suivant la procédure ci-dessous. Dans ce cas ne téléchargez pas de nouveau master et portez les configuration Sflow directement sur votre Collector Storage mutualisé.
Le sFlow Collector Storage sera créé à partir d’un master SNB, ce serveur doit être dédié à la collecte des exports SFlow et ne dois pas être utilisé en tant que boitier de supervision.
- Télécharger le master SNB:
- Site FTP : software.servicenav.io (contacter le support pour les identifiants d’accès)
- Sélectionner le master SNB dans le répertoire SNB-SNM – ServiceNav Box/4.0/SNM_MASTER_OVF_2019_01_24_V4_0.0.zip
- Cibler les interfaces réseau répondant à vos besoins d’analyse
- Connectez-vous en SSH au SFlow Collector Storage
- Créer un répertoire de destination des exports SFlow, par exemple vous pouvez créé un chemin générique ~/network_analysis/sflow et créé sous celui-ci autant de répertoire que d’interface réseau à monitorer, ces répertoires seront destinés à stocker les exports.
- Attention le compte ssh de supervision ssh utilisé sera le compte coadmin, il est donc recommandé de créer les répertoire s de destination avec l’utilisateur coadmin. Vous pouvez les nommer en fonction des ip d’interface ou du nom des équipements:
-
Ex : mkdir -p ~/network_analysis/sflow/ROUTEUR_A_WAN
-
- Définir un port d’écoute pour le listener par équipement réseau sur lesquels sFlow sera activ, par exemple le 6343 pour le Routeur A et 6344 pour le Routeur B
- Créer une ACL autorisant la connexion au SFlow Collector Storage sur les ports d’écoute:
-
iptables -A INPUT -p udp --dport 6343 -j ACCEPT
-
iptables -A INPUT -p udp --dport 6344 -j ACCEPT
-
- Lancer le listener via la commande suivante :
-
sfcapd -p 6343 -l /home/coadmin/network_analysis/sflow/ROUTEUR_A_WAN -D
-
sfcapd -p 6344 -l /home/coadmin/network_analysis/sflow/ROUTEUR_B_WAN -D
-
-
-
- -p fixe le port UDP d’écoute (9995 dans notre configuration du routeur Cisco)
- -l fixe le répertoire ou les données seront stockées (emplacement du collector)
- -w permet de s’assurer que la collecte sera faite toutes les n minutes (n=5 par défaut) avec des valeurs ,5,10…
- -D permet de demander à nfcapd de se lancer comme un daemon (en tache de fond)
-
- Pour affiner la granularité à la minute, ajouter l’option -t exprimée en seconde, exemple :
- Pour une granularité à la minute la commande serait :
sfcapd -p 6343 -l /home/coadmin/network_analysis/sflow/RouteurA_WAN -D -t 60
(remarque il est possible de combiner les options -w et -t)
- Pour une granularité à la minute la commande serait :
- Initialiser le sFlow Collector Storage avec la plateforme ServiceNav pour bénéficier des mises à jours : Chapitre 2.2 de la procédure suivante: https://coservit.com/servicenav/fr/documentation/mise-en-service-dune-box-servicenav/
Par défaut, les exports aux formats nfcapd.YYYYMMddhhmm sont supprimés toute les 24h via une tâche planifiée lancée tous les jours à 0h00:
/root/crontabRoot
0 0 * * * /usr/local/nagios/libexec/nfcapd_deleteCache.sh > /dev/null 2>&1
Vous devez spécifier le chemin où se trouve les données à supprimer, pour cela:
- Éditer le fichier /usr/local/nagios/libexec/nfcapd_deleteCache.sh => vi /usr/local/nagios/libexec/nfcapd_deleteCache.sh
- Modifier la ligne « find /usr/local/nagios/Network_Analysis/ -name nfcapd.\* -type f -mmin +180 ! \( -name « *.current.* » \) -delete » en remplacement /usr/local « /nagios/Network_Analysis/ » par le chemin où se trouve les données à supprimer. Exemple qui reprend la configuration ci-dessus: « find /home/coadmin/network_analysis/sflow -name nfcapd.\* -type f -mmin +180 ! \( -name « *.current.* » \) -delete » pour supprimer les données relatives aux RouteurB_WAN et RouteurA_WAN
Configuration des équipements réseaux
Se connecter sur l’équipement réseau sur lequel SFlow doit être activé et effectuer ces différentes étapes pour configurer sFlow.
Ci-dessous un exemple de configuration pour un Switch HP-220-48G:
Commande | Objectif |
|
|
|
|
|
|
Configuration sur le Switch HP-220-48G
HP-2920-48G(config)# sflow 1 destination 192.168.238.37 6343
HP-2920-48G(config)# sflow 1 sampling ethernet 47-48 128
HP-2920-48G(config)# sflow 1 polling ethernet 47-48 30
Vérification du fonctionnement de sFlow et affichage des statistiques sFlow
Vérifier que SFlow est correctement configuré.
Utiliser la commande show sflow 1 destination pour afficher les détails de la configuration SFlow:
HP-2920-48G# show sFlow 1 destination
Destination Instance : 1
sflow : Enabled
Datagrams Sent : 126822
Destination Address : 192.168.238.37
Receiver Port : 6343
Owner : Administrator, CLI-Owned, Instance 1
Timeout (seconds) : 2147403334
Max Datagram Size : 1400
Datagram Version Support :
|
Vérification que les données sFlow sont bien stockées sur le sFlow Collector Storage
Se connecter sur le sFlow Collector Storage, se positionner sur le répertoire dédié à stocker les exports nfcapd correspondant et vérifier présence de fichier au format nfcapd.YYYYMMddhhmm (nfcapd.201709181140).
Attention les fichiers nfcapd sont créés périodiquement par le processus sfcapd même si ceux-ci ne sont pas alimentés par les sFlow Exportateur (swich, routeur…).
Pour s’assurer que la configuration soit opérationnelle, ces fichiers doivent être alimentés par les sFlow Exportateur (swich, routeur…). Un fichier vide (non alimenté) a une taille de 276 octets. La présence de fichier d’une taille de 276 octets indique que les fichiers ne sont pas alimentés et que la configuration doit être revue.
Les fichiers doivent contenir de la données avec une taille supérieur à 276 octets comme le montre l’exemple ci-dessous:
Si c’est le cas, votre configuration est opérationnelle, vous pouvez passer à l’étape suivante sinon reprendre les étapes de configuration précédentes.
Mise en supervision du sFlow Collector Storage
Le sFlow Collector Storage est central dans votre architecture SFlow, il est donc essentiel de superviser la charge et les processus en cours d’exécution.
Utiliser le modèle d’équipement modèle-serveur-linux:
- CPU
- LIN-DiskIO
- LIN-Diskspace
- LIN-Network_Traffic
- LIN-RAM
- LIN-Swap
A ces modèles de service déjà intégrés au modèle d’équipement modèle-serveur-linux, utiliser les modèles de service suivant:
- LIN-DirectorySize pour surveiller la taille de vos répertoires de destination.
- Lin-ProcessName pour surveiller la bonne exécution des processus sfcapd
Enfin utiliser les modèles d’action pour relancer les processus sfcapd en cas d’interruption en suivant la procédure suivante: https://coservit.com/servicenav/fr/documentation/utilisation-des-modeles-daction/