Sflow fait baver ton réseau
Tweet |
Ça fait pas mal de temps que je fais un peu joujou avec Sflow sur notre réseau et j’ai à peu près réussi a faire quelque chose de flexible. Voici donc quelques pistes de travail pour ceux qui se lancent :
Le principe de Sflow, c’est quoi ? Plutôt que de faire des statistiques sur l’ensemble du trafic qui traverse un routeur (par exemple en dupliquant ce trafic pour l’envoyer vers une machine qui va l’analyser, chose impossible a faire lorsqu’il commence a y avoir des Gbps de trafic) on va s’autoriser une marge d’erreur dans notre analyse en ne traitant qu’un paquet tous les X paquets.
Nos petits routeurs vont donc envoyer, par exemple, un paquet sur 1000 à la machine chargée du traitement. Evidemment, sur un trafic faible, ça ne donne rien de bon, mais lorsqu’il est conséquent, on obtient des statistiques qui, en les multipliant par 1000, donne une idée assez fiable (a 2 ou 3% près) de ce qui se passe en réalité.
J’ai très vite laissé tomber l’idée de coder un collecteur sflow moi même. Il y en a de très bons et j’ai, pour ma part, opté pour le package pmacct dans lequel on trouve sfacct. L’idée du collecteur est de faire une zone tampon entre les flux de données reçues des routeurs et le bout de code qui va l’analyser.
pmacct permet de faire une première agrégation des données reçues dans plusieurs files (IMT) stockées directement en ram. Par exemple, dans mon cas, j’ai une file qui va agreger les informations en fonction de l’AS source ou destination, me permettant d’analyser la consommation du réseau avec mes voisins, un autre également par AS source et destination mais en séparant les adresses mac destination et source, permettant de savoir, sur un lien précis, quels sont les AS source et destination qui passent par la, et enfin, une file ou je n’agrege rien pour pouvoir avoir la granularité d’information la plus fine.
Concretement, la config donne ca :
plugins: memory[dasm], memory[sadm], memory[das], memory[sas], memory[detail] aggregate[dasm]: dst_as, src_mac aggregate[sadm]: src_as, dst_mac aggregate[das]: dst_as aggregate[sas]: src_as aggregate[detail]: src_host, dst_host, src_as, dst_as, src_mac, dst_mac imt_path[dasm]: /tmp/dasm.pipe imt_path[sadm]: /tmp/sadm.pipe imt_path[das] : /tmp/das.pipe imt_path[sas] : /tmp/sas.pipe imt_path[detail]: /tmp/detail.pipe syslog: local5 pidfile: /var/run/sfacctd.pid sfacctd_renormalize: true sfacctd_port: 5476 plugin_pipe_size: 102400000 plugin_buffer_size: 102400 imt_mem_pools_number: 12800
Il faut bien prévoir les trois dernières valeurs : Trop haut, vous allez bouffer toute la mémoire dispo, trop bas, vous aller perdre des informations.
Ensuite, on récupère les données de chaque IMT avec /usr/local/bin/pmacct -s -e -p /tmp/dasm.pipe. Il suffit ensuite de les traiter, toutes les X minutes, pour en faire ce qu’on veut :
- des fichiers RRD
- des alertes opérationnelles (quand on dépasse un certain nombre de paquets par seconde, par exemple)
- de l’accounting client (quand par exemple un même client a plusieurs IP sur une machine et qu’il est question de facturer le trafic différemment par IP)
Pour ma part, trois scripts perl fournissent des stats sur :
- Le trafic global de chaque AS client situé derrière notre réseau
- Le trafic global a destination des 50 AS extérieurs au notre avec lequel nous effectuons le plus de trafic
- La ventilation détaillée par client de chaque lien de transit et de peering
- La ventilation par AS distant de chaque lien de peering
- Les IP/AS qui consomment le plus grand nombre de paquets par seconde pour faciliter la pose de nullroute en cas d’attaque
Leave your response!