Un graphe SNMP te dit que le lien transit sature à 8 Gbps sur les 10 disponibles. Il ne te dit pas qui consomme ces 8 Gbps. Quel AS distant, quel préfixe, quel port applicatif, quel client. Tu vois la fièvre, pas la cause. Pour décider d'ouvrir un peering, arbitrer un transit ou comprendre une anomalie de volume à 3h du matin, le compteur d'octets ne suffit pas. Il faut l'analyse de flux.
C'est la différence entre superviser un tuyau et lire ce qui passe dedans. SNMP relève des compteurs d'interface : octets in, octets out, erreurs, drops. Précieux, on en parle en détail dans LibreNMS et la supervision SNMP, mais aveugle au contenu. L'analyse de flux remonte chaque conversation : IP source, IP destination, ports, protocole, nombre de paquets, nombre d'octets, interface d'entrée, interface de sortie. Croisée avec la table BGP, elle te dit l'AS distant et le chemin. Croisée avec PeeringDB, elle te dit qui se cache derrière l'AS.
NetFlow, IPFIX, sFlow : trois façons d'exporter un flux
Le routeur observe le trafic et exporte des enregistrements vers un collecteur. Trois familles de protocoles dominent.
NetFlow v9, créé par Cisco, exporte des enregistrements basés sur des templates : le routeur envoie d'abord la structure des champs, puis les données. Template flexible, supporté large. IPFIX (RFC 7011) est sa standardisation IETF, souvent appelé NetFlow v10. Même logique de templates, champs extensibles, c'est le format vers lequel converger en 2026. sFlow, lui, ne suit pas les flux : il échantillonne des paquets bruts à un taux fixe (1 sur 1000, 1 sur 5000) et en exporte des bouts. Moins précis sur les petits flux, mais charge constante sur le routeur et bien adapté aux débits élevés.
Le piège classique : confondre flux complet et échantillonnage. NetFlow peut compter chaque flux ou échantillonner (sampled NetFlow). À haut débit, sur du 100G, l'échantillonnage devient obligatoire sous peine d'écrouler le plan de contrôle du routeur. Un taux 1:1000 reste statistiquement fiable pour de l'analyse de volume agrégée, beaucoup moins pour traquer un flux unique de quelques paquets.
Akvorado : la pile complète, pas juste un collecteur
Recevoir des flux est la partie facile. Les rendre exploitables demande une chaîne complète. Akvorado, open source sous AGPL, né chez Free et porté notamment par Vincent Bernat, assemble cette chaîne de bout en bout au lieu de te laisser câbler cinq briques à la main.
Le service inlet reçoit les flux NetFlow v9, IPFIX et sFlow, et les pousse dans Apache Kafka. Le découplage par Kafka encaisse les pics et permet de rejouer. Le service outlet consomme la file, parse chaque flux et l'enrichit. Il interroge chaque exporteur en SNMP pour résoudre le nom système, le nom et la description des interfaces, leur débit. Surtout, il ingère les routes BGP du routeur via BMP (BGP Monitoring Protocol, RFC 7854) pour rattacher chaque flux à son numéro d'AS, son AS-path et ses communautés. L'orchestrateur fournit en plus la donnée GeoIP (MaxMind ou IPinfo). Les flux enrichis atterrissent dans ClickHouse, base colonne taillée pour agréger des milliards de lignes en quelques secondes. Une interface web sert les requêtes par-dessus.
Le résultat concret : une console où tu filtres le trafic par AS source, AS destination, port, interface, pays, et où le graphe se construit en direct. Pas un dashboard figé, une vraie exploration.
Côté ops : ce que ça change pour décider un peering
Sur AS41652, l'intérêt premier est l'analyse du trafic de peering et de transit. Quelques usages qu'on tire d'une pile de flux.
Voir la répartition réelle par AS distant. Avant d'ouvrir une session de peering avec un réseau, on veut savoir combien de trafic on échange déjà avec lui via le transit. Si 2 Gbps partent vers l'AS d'un gros acteur en passant par un transit payant, le peering direct ou via un IX devient rentable. La donnée de flux chiffre l'arbitrage au lieu de le deviner. C'est l'usage qui justifie nos connexions à Nine-IX puis France-IX Paris : on ouvre les peerings que le trafic réel réclame.
Détecter une anomalie de volume. Un flux qui explose, un préfixe qui se met à recevoir dix fois son trafic habituel, une asymétrie soudaine entre in et out : la console le montre par AS et par préfixe, là où le graphe SNMP ne montre qu'une bosse globale. Pour le diagnostic fin qui suit, voir déboguer un problème réseau.
Facturer au 95e percentile. Le standard de facturation transit. On mesure le débit sur des intervalles de 5 minutes pendant le mois, on jette les 5 % de valeurs les plus hautes, et la valeur restante la plus élevée fait la facture. ClickHouse calcule ce percentile sur l'historique sans transpirer. Pratique pour vérifier une facture de transitaire ou refacturer un client au réel.
Cartographier qui passe par quel peering. Croiser l'interface de sortie avec l'AS distant montre quelle part du trafic emprunte quel IX, quel transit. Indispensable quand on rebascule du trafic d'un fournisseur vers un autre, en complément de l'inventaire de config réseau qu'on garde versionné avec Oxidized.
Enrichissement BGP et PeeringDB : le sel de l'affaire
Un flux brut donne deux IP et deux ports. Utile, mais limité. La valeur naît de l'enrichissement.
Le rattachement BGP transforme 198.51.100.42 vers 203.0.113.7 en notre AS vers AS15169, via tel AS-path, communauté tag-peering. D'un coup, on raisonne en réseaux et en relations, pas en adresses. Akvorado récupère ces routes en BMP directement depuis le routeur, donc la vue colle exactement à la table de routage en production. Si tu montes ton routeur sous FRR, le BMP s'active côté config, on couvre les bases dans routeur BGP avec FRRouting.
PeeringDB ajoute la couche humaine. L'AS15169 ne parle pas, mais sa fiche PeeringDB donne le nom de l'organisation, ses points de présence, ses politiques de peering, ses préfixes annoncés. Croiser le top des AS avec PeeringDB transforme une liste de numéros en liste d'interlocuteurs à contacter pour ouvrir une session. L'API PeeringDB sert ces données en JSON, cache rafraîchi toutes les 15 minutes.
Les alternatives, et quand les préférer
Akvorado n'est pas seul. pmacct, de Paolo Lucente, reste la référence des collecteurs unix : NetFlow, IPFIX, sFlow, mais aussi corrélation BGP, BMP, RPKI et télémétrie streaming. Plus bas niveau, plus austère, infiniment configurable. On le choisit quand on veut piloter finement l'agrégation et brancher sa propre base, sans l'interface clé en main. nfdump, avec son frontend NFsen, suit l'école classique : nfcapd collecte dans des fichiers, nfdump requête en ligne de commande, NFsen graphe via RRD. Simple, éprouvé, daté côté visualisation.
Lequel choisir, côté ops. Pour démarrer une analyse de flux d'opérateur avec enrichissement BGP et une console exploitable sans deux semaines d'intégration, Akvorado est le défaut en 2026. La pile est lourde (Kafka, ClickHouse), mais elle scale et l'enrichissement BMP colle à la réalité du routage. pmacct si on veut tout maîtriser et qu'on a la compétence pour. nfdump pour un besoin simple, ponctuel, sans BGP. Ce qu'on ne fait plus : analyser un trafic d'opérateur à l'œil sur des graphes SNMP en croisant les doigts.
Quand un transit sature et qu'il faut décider en heures, pas en semaines, qui peer, qui rester en transit et où rebasculer, la donnée de flux tranche. Lire le trafic au lieu de le deviner, c'est ce qui guide nos arbitrages de peering et de transit, et ce qu'on déploie pour les infras dont on gère le réseau. Si vos décisions de transit IP se prennent encore sans analyse de flux, on peut monter la collecte et lire le trafic avec vous.
Sources
- Akvorado, documentation officielle : architecture inlet/outlet/orchestrateur, enrichissement SNMP, BMP et GeoIP, ClickHouse.
- Akvorado: a flow collector, enricher, and visualizer (Vincent Bernat) : conception et choix techniques par l'auteur principal.
- RFC 7011 : Specification of the IPFIX Protocol : standard IETF du protocole IPFIX (NetFlow v10).
- RFC 7854 : BGP Monitoring Protocol (BMP) : protocole d'export des routes BGP utilisé pour l'enrichissement.
- pmacct project : collecteur passif NetFlow/IPFIX/sFlow avec corrélation BGP, BMP et RPKI.
- PeeringDB API documentation : accès programmatique aux données d'AS, IX et politiques de peering.
- Setting up Akvorado, APNIC Blog : retour de déploiement sur réseau IPv6-first.


