La Fibre
Télécom => Peering Transit (appairage) => 
BGP (technique, questions générales) => Discussion démarrée par: max1330 le 25 janvier 2017 à 21:56:30
-
Bonsoir,
J'ai un routeur de bordure avec lequel je suis connecté à un transitaire. Comment puis-je monitorer l'utilisation de la bande passante par AS ?
Exemple : comment savoir le trafic échangé avec l'AS16276 d'OVH ?
Une des possibilité serait de récupérer les IP en sniffant le réseau puis en comparant à une base de donnée en ligne mais ça me parait bricolage
Merci pour vos pistes
-
Il me semble que K-Net utilise RRDtool (http://oss.oetiker.ch/rrdtool/index.en.html) pour faire ses graphes (disponibles publiquement (https://as24904.kwaoo.net/as-stats/top.php))
-
Il me semble que K-Net utilise RRDtool (http://oss.oetiker.ch/rrdtool/index.en.html) pour faire ses graphes (disponibles publiquement (https://as24904.kwaoo.net/as-stats/top.php))
RRDtool fait les graph mais ne récupère pas les données, si ?
-
Quel modèle le routeur ?
-
Quel modèle le routeur ?
Cisco ASR
-
Avec AS-Stats : https://github.com/manuelkasper/AS-Stats ;)
-
Il faut que ton routeur exporte du Netflow que tu rentre dans un collecteur NetFlow (https://www.cisco.com/c/en/us/products/ios-nx-os-software/ios-netflow/networking_solutions_products_genericcontent0900aecd805ff72b.html)
-
http://nfsen.sourceforge.net/ est souvent utilisé
Un exemple pour AS-Stats chez K-Net : https://as24904.kwaoo.net/as-stats/top.php
Dans tous les cas qu'on te présente, c'est toujours des Netflow qui sont collectés par une machine, puis mis en forme pour être présentés.
-
Merci pour ces réponses!
AS-Stats à l'air pas mal dutout! K-Net l'a un peu modifié ou c'est tel qu'on le voit sur leur site ?
-
Très peu de modifications, vu que je me suis amusé a en mettre en place.
Par défaut c'est un top 20 pas un top 550.
Par contre des fonctionnalités ont été limitées pour la partie public.
-
Il a l'avantage d'être simple dans la forme comme dans le fonctionnement.
Perso je l'ai modifié pour mettre directement un pool de XX ports et qu'un port nommé "NONE" ne soit pas affiché sur les graphs. Parce que les bases RRD sont peuplée avec les ports en données et en ajouter/supprimer est plutôt galère je trouve.
Faut voir qu'il y a un fichier RRD par AS et qu'avec le trafic on se retrouve rapidement à un volume important de RRD (plus de 50 000 fichiers chez moi) et pas mal de place utilisée sur la partition. Ajouter un port est donc assez lourd vu qu'il faut altérer la structure de tous les fichiers RRD.
-
La solution payante (mais pas très chere) qui va bien : wanguard.
Sinon en opensource : le collecteur *flow de reference : pmacct.
Avec pmacct tu collecte et tu export dans a peu près peu tout ce que tu peux imaginer.
Perso je me suis fait une gui (https://github.com/ut0mt8/phpflow) qui tape dans mysql + export dans influxdb et graph dans grafana (https://github.com/ut0mt8/flow2influx).
-
Synack, tu veux dire qu'il crée un RRD par AS, même si tu n'a échangé qu'un paquet avec cet AS et que tu n'aura plus d'autres échange ensuite ?
Avec les mises à jour toutes les 5 minutes, cela doit générer pas mal d'E/S.
Avec un RRD de 1 Mo, cela fait 50 Go écrit toutes les 5 minutes, j'ai bon ? (a moins qu'il soit possible de mettre à jour le RRD sans le ré-écrire complètement ?)
-
Non mais les gars faut arreter avec RRDs. C'est so 2000 :)
-
Vivien: y'a un fichier rrd par AS vu: 28607 fichiers chez moi actuellement. De plus, rrdtool a une taille de fichier fixe, qui ne change donc pas de taille après la création; J'en ai 12GB actuellement
ut0mt8: remballe tes trucs de hipster stp, merci :)
-
Quelqu'un a déjà fait tourner AS-Stats sur un Windows ?
Je pense que tout est compatible en tout cas:
Perl, RRDTools & PHP. Vous y croyez ?
-
Quelle drôle d'idée !
-
Hugues, tu n'utilises pas WAMP en prod' ? ;D ;D ;D
D'ailleurs PHP sur du IIS c'est une misère...
-
Non mais les gars faut arreter avec RRDs. C'est so 2000 :)
C'est quoi l'autre méthode ?
-
C'est quoi l'autre méthode ?
Sinon en opensource : le collecteur *flow de reference : pmacct.
Avec pmacct tu collecte et tu export dans a peu près peu tout ce que tu peux imaginer.
Perso je me suis fait une gui (https://github.com/ut0mt8/phpflow) qui tape dans mysql + export dans influxdb et graph dans grafana (https://github.com/ut0mt8/flow2influx).
-
InfluxDB vs RRDtool : ce n'est pas la même chose, et je pense InfluxDB sera beaucoup plus lourd.
RRDtool moyenne, ce que Influx ne fait pas (comme le dit Jack, la taille est fixe) ?
Quand InfluxDB gobe beaucoup de données et que tu lui demandes une requête assez complexe il se retrouve vite en "Out of memory".
-
J'en ai 12GB actuellement
Donc 12 Go écrits toutes les 5 minutes où le flux en écriture est plus faible ?
Avec les SSD, on regarde de plus en plus le volume écrit.
12 Go/5min, cela fait 144 Go/h ou 3,5 To/jour en écriture, c'est breauop pour un SSD, même un "write intensive"
-
Donc 12 Go écrits toutes les 5 minutes où le flux en écriture est plus faible ?
Avec les SSD, on regarde de plus en plus le volume écrit.
12 Go/5min, cela fait 144 Go/h ou 3,5 To/jour en écriture, c'est breauop pour un SSD, même un "write intensive"
Beaucoup plus faible !
12GB, c'est la taille totale de mon répertoire, donc ~30k ASN sur 2 ans (avec 10 lignes de transit/peering)
-
Vivien : Avec le SSD, on regarde le volume écrit, mais du coup forcèment quand tu as une machine qui poll des données régulièrement ça en fait pas mal, que ce soit logging ou base de données. Sinon oui, il suffit d'un ping d'un AS qui se retrouver dans l'échantillonnage netflow pour créer son RRD.
Raphael : C'est vieux mais ça fait le job pas mal avec un volume maitrisé. C'est pas l'outil d'analyse idéal, mais c'est un outil assez simple et pas trop gourmand pour avoir une vue synthétique de ta répartition. Après si on veut aller plus loin, entre ELK et Wanguard il y a des choses intéressantes à faire, notamment dans le détail des infos qui ne se limitera pas aux AS.
-
Raphael : C'est vieux mais ça fait le job pas mal avec un volume maitrisé. C'est pas l'outil d'analyse idéal, mais c'est un outil assez simple et pas trop gourmand pour avoir une vue synthétique de ta répartition. Après si on veut aller plus loin, entre ELK et Wanguard il y a des choses intéressantes à faire, notamment dans le détail des infos qui ne se limitera pas aux AS.
Par rapport à du rrd, pmacct + database + whatever, ça permet notamment de voir autre chose que "tel AS fait tel traf et ça passe par tel IX", ce qui est bien mais insuffisant.
En l'occurrence on pourra voir qui a lancé un DDoS avec quel protocole vers quels clients depuis quels IPs et/ou quels AS, avoir des infos détaillées par IP, protocoles, tailles de paquets, quel est l'AS avec lequel il serait intéressant de peerer (pas l'AS source ni destination, mais celui du milieu), bref tout ce qu'on n'a pas dans un rrd mais qui peut s'extraire en SQL avec des SELECT.
Quand InfluxDB gobe beaucoup de données et que tu lui demandes une requête assez complexe il se retrouve vite en "Out of memory".
Évidemment ce n'est pas forcèment pertinent pour une beigebox hébergée sous la table de la cuisine, ça dépend du besoin.
Et bien sûr il y a les solutions payantes ; voire externalisées (Kentik ou autres Deepfield).
-
Ce n'est pas les mêmes outils :)
D'un côté, tu as un truc qui récupère les flow, et en fait un traitement qui est connu a priori
De l'autre, tu as un truc qui récupère et stock les flow, et qui appliquent des traitements a posteriori
L'un est spécifique et efficace, l'autre est beaucoup plus onéreux mais générique
quel est l'AS avec lequel il serait intéressant de peerer (pas l'AS source ni destination, mais celui du milieu)
J'ai commit un truc pour ça dans l'as-stats, c'est pratique pour le sortant, mais pifométrique pour l'entrant :s
Évidemment ce n'est pas forcèment pertinent pour une beigebox hébergée sous la table de la cuisine, ça dépend du besoin.
Avec ou sans choucroute, la cuisine ? ;D ;D
-
Synack, tu veux dire qu'il crée un RRD par AS, même si tu n'a échangé qu'un paquet avec cet AS et que tu n'aura plus d'autres échange ensuite ?
Des qu'il detecte du trafic avec un AS, il cree le RRD correspondant a l'AS.
Avec les mises à jour toutes les 5 minutes, cela doit générer pas mal d'E/S.
Pas tant que ca. Il met a jour uniquement les RRD correspondant aux AS avec lesquels il y a eu du trafic echange dans l'intervale.
Avec un RRD de 1 Mo, cela fait 50 Go écrit toutes les 5 minutes, j'ai bon ? (a moins qu'il soit possible de mettre à jour le RRD sans le ré-écrire complètement ?)
Pas tout a fait (voir plus haut).
J'ai mis en place mon AS-stats des que j'ai eu du netflow utilisable (nouveaux routeurs "internet border"), il y a environ 3 mois. Depuis, le nombre de RRD n'arrete pas d'augmenter. Je n'ai pas encore touche les 50K de Synack, mais je ne suis pas loin. Selon bgp.potaroo.net ca devrai plafonner vers 55K.
-
Pour être plus précis j'en suis à 55690 RRD à ce jour (en un peu plus d'un an), donc ça doit être ça effectivement.
-
InfluxDB vs RRDtool : ce n'est pas la même chose, et je pense InfluxDB sera beaucoup plus lourd.
RRDtool moyenne, ce que Influx ne fait pas (comme le dit Jack, la taille est fixe) ?
Quand InfluxDB gobe beaucoup de données et que tu lui demandes une requête assez complexe il se retrouve vite en "Out of memory".
Alors ce n'est pas la meme chose dans le sens ou rrdtool est un outil à la fois de stockage de tsdb et de rendering de graph.
Il permet aussi l'aggregation à la volée.
Influxdb (ou prometheus) c'est une bdd orienté tsdb. Evidement c'est aberrant de mettre toutes les données brutes de flow dedans.
Il faut mettre des métriques :) et après cela se passe niquel (surtout que c'est fait pour) . A noter que Influx gere aussi l'historisation ou aggregation via les continuous query.
L'immense avantage de ces outils moderne c'est :
- une vrai gui avec grafana qui permet de créer des graphs ultra simplement, de les templater, etc...
- le fait que tu n'as pas besoin de définir tes métriques à l'avance;
Donc oui dans un sens ca peut etre plus long à mettre en place (encore que c'est surtout l'habitude) que rrd, mais après quel confort.
(et franchement celui qui a déjà essayer de faire des graph dans rrd ne peux pas me dire le contraire, c'est long et relou)
-
Raphael : C'est vieux mais ça fait le job pas mal avec un volume maitrisé. C'est pas l'outil d'analyse idéal, mais c'est un outil assez simple et pas trop gourmand pour avoir une vue synthétique de ta répartition. Après si on veut aller plus loin, entre ELK et Wanguard il y a des choses intéressantes à faire, notamment dans le détail des infos qui ne se limitera pas aux AS.
ELK clairement mauvaise idée. Stocker des flows dans un moteur d'indexation ?!. Le E et L de ELK sont une vaste blague. Elastisearch est utlisé comme bdd, et Logstash (du ruby dans du java qu'est ce qui pourrais mal se passer ?) est juste un truc affreux et pas performant.
Wanguard c'est super bien pour avoir une vue rapide de ton réseau quand tu as zero temps (et c'est pas cher). Par contre l'immense probleme c'est que cela stocke dans rrd et que tu ne peux pas exporter / utiliser les données collectés ou aggréges (des fois que tu veuilles faire de l'alerting ou autre).
Bref pas la solution pour moi.
-
Par rapport à du rrd, pmacct + database + whatever, ça permet notamment de voir autre chose que "tel AS fait tel traf et ça passe par tel IX", ce qui est bien mais insuffisant.
En l'occurrence on pourra voir qui a lancé un DDoS avec quel protocole vers quels clients depuis quels IPs et/ou quels AS, avoir des infos détaillées par IP, protocoles, tailles de paquets, quel est l'AS avec lequel il serait intéressant de peerer (pas l'AS source ni destination, mais celui du milieu), bref tout ce qu'on n'a pas dans un rrd mais qui peut s'extraire en SQL avec des SELECT.
Voila bien gentiment. Et influx/prometheus sont tres tres performant, il faut faire juste attention a ce que l'on mets dedans :) comme une BDD quoi.
A refaire d'ailleurs je ferais du prometheus car cela gère l'alerting directement.
-
ELK clairement mauvaise idée. Stocker des flows dans un moteur d'indexation ?!. Le E et L de ELK sont une vaste blague. Elastisearch est utlisé comme bdd, et Logstash est juste un truc affreux et pas performant. Bref.
Wanguard c'est super bien pour avoir une vue rapide de ton réseau quand tu as zero temps (et c'est pas cher). Par contre l'immense probleme c'est que cela stocke dans rrd et que tu ne peux pas exporter / utiliser les données collectés ou aggréges (des fois que tu veuilles faire de l'alerting ou autre).
Bref pas la solution pour moi.
Pour être franc j'ai pas vraiment creusé le sujet encore pour ELK & co, c'est dans la pile des projets après d'autres choses plus prioritaires.
-
Influxdb (ou prometheus) c'est une bdd orienté tsdb. Evidement c'est aberrant de mettre toutes les données brutes de flow dedans.
Il faut mettre des métriques :) et après cela se passe niquel (surtout que c'est fait pour) . A noter que Influx gere aussi l'historisation ou aggregation via les continuous query.
Bof, j'suis en train d'essayer les outils, grandement motivé par ton retour d'expérience
Je suis plutôt déçu par influxdb : j'essaie de faire de stats par IP, il semble incapable de gérer une telle cardinalité .. :s
(j'ai monté les limites, mais du coup il oom avec 10GB dédié ..)
M'enfin
-
Si tu injecte toutes les couples d'IPs oui ca va faire trop de métriques.
Ce n'est pas fait pour. J'ai bien dit de ne pas mettre tout les flows dedans :)
Ceci dit maintenant je suis plutôt prometheus. Ca fait la meme chose mais le langage est encore plus puissant (par contre moins optimisé retention, mais qui a envie de conserver ses métriques de flows longtemps ?)
Je vais poster mes scripts pmacct => amqp => prometheus. => tjours grafana parce que c'est bien.