Dans le même esprit que ce que Arnaud à fait, j’ai aussi produit une stack avec PMACCT :
http://www.pragma-innovation.fr/cas-dusage-telemetrie-ip/ En Front j’utilise superset (https://github.com/apache/incubator-superset), en backend influxdb va bien pour de petit besoin mais scale difficilement, j’utilise clickhouse (Yandex). Attention à mettre un Kafka entre ton ingest et ton backend, sinon tu risques aussi d’avoir de petits soucis. A voir en fonction du nombre de messages à traiter par seconde. Et comme toujours avec les systèmes et les open-sources, attention aux compatibilités notamment Kafka qui a changé son API, je déconseille la 2.0.0 pour l’instant ! Je vois avec plaisir que le sujet est toujours chaud et que nous devrions avoir de bonnes discussions pour le prochain FRnOG :-) ! Matt. Matthieu Texier, Founder, PRAGMA SECURITY/INNOVATION. Mob: +33 6 85 83 66 89. > On 27 Sep 2018, at 12:43, Arnaud Fenioux <afeni...@gmail.com> wrote: > > Je n'ai pas eu de probleme pour les champs que tu mentionnes... > As tu vérifié que tu as toutes les infos dans les paquets sFlow que tu > recois (avec wireshark or sflowtool > https://github.com/sflow/sflowtool) ? > > J'utilise aussi le lookup par pmacct, car il me donne plus d'info dans > certains cas, je donne la conf, si ca peut servir : > coté arista : > ``` > sflow sample xxxx > sflow destination 10.11.12.13 > sflow source-interface Loopback0 > sflow run > sflow extension bgp > > router bgp xxxx > neighbor 10.11.12.13 description PMACCT > neighbor 10.11.12.13 update-source Loopback0 > neighbor 10.11.12.13 route-reflector-client > # eviter add-path avec pmacct, ca marchait mal dans mes tests > no neighbor 10.11.12.13 additional-paths send any > ``` > > sfacctd.conf : > ``` > ! we need all of this to get the peer_map working (even if we do not > setup a BGP session) > bgp_daemon: true > bgp_daemon_ip: 10.11.12.13 > bgp_daemon_as: xxxxx > bgp_daemon_max_peers: 10 > bgp_peer_src_as_map: /etc/pmacct/peers.map > bgp_peer_src_as_type: map > > ! sfacctd populate 'src_as', 'dst_as', 'peer_src_as' and 'peer_dst_as' > primitives from information in bgp > ! 'longest' behaves : networks_file < sFlow/NetFlow < <= BGP > sfacctd_as: longest > sfacctd_net: longest > ``` > > Je dérive sur pmacct, si ca peut aider d'autres lecteurs : > Le PEER_SRC_AS n'est pas toujour correct (si asymetrie de trafic), > j'ai préféré générer le peers.map a avec mactopeer (un wrapper napalm) > : https://github.com/pierky/mactopeer > Concernant pmacct, la doc n'est plus du tout a jour sur pmacct.net > mieux vaut se baser sur https://github.com/pmacct/pmacct/wiki (et > encore...) je comptais en parler avec Paolo au FRnOG. > > Last but not least, j'ai rédigé un bout de doc sur pmacct / sfacct + > influxdb + grafana avec l'aide de @CorsoAlexandre : > http://afenioux.fr/blog/article/pmacct-sfacct-influxdb-grafana > > Arnaud > On Thu, Sep 27, 2018 at 11:53 AM Raphael Mazelier <r...@futomaki.net> wrote: >> >> >> Bonjour, >> >> Merci pour ces retours constructifs. >> >> Je peux comprendre la logique même si cela me complique la vie dans le >> cas présent. >> >> En attendant en appliquant la configuration tel que présenté par Arnaud >> il me manque les informations as_src, as_dst et as_path :/ J'ai >> l'interface out donc c'est presque bon. >> >> >> Je me demande s'il n'y a pas un bug sur ces modèles en particulier. >> Dans le pire des cas je vais faire le boulot par pmactt en peerant mais >> c'est moins propre. >> >> Merci à tous. >> >> PS : je suis impatient de voir Paolo IRL, car online il est vraiment top. >> >> -- >> Raphael Mazelier >> >> >> >> On 26/09/2018 23:49, Matthieu Texier wrote: >>> Bonjour Raphael, >>> >>> Je me permets d’intervenir dans la discussion ayant quelques années de >>> pratique sur ces sujets. >>> >>> La “best practice” veut que l’on configure netflow ou sflow ingress sur >>> tous les ports de la machine. Cette "best practice" est essentiellement due >>> au fait que tu ne dois pas, à priori, configurer ton netflwo/sflow par >>> rapport aux résultats finals qui tu attends. Il faut le configurer pour que >>> tu es une vue fidèle de ton trafic dans tout ton routeur. La raison cachée >>> de cette best practice est qu’un routeur fait son IP lookup sur son port >>> ingress (calcul de la best route et port de sortie, etc ..). Demander à un >>> routeur, sur son port de sortie de savoir sur quel port le paquet est entré >>> est souvent (pour ne pas dire toujours) compliqué (d’autant plus lorsque tu >>> fais du link bundling). >>> >>> C’est le travail du collecteur de te donner les vues qui t’intéresse et qui >>> pourra, grace a cette best practice, te donner les vues auxquelles tu >>> n’aurais peut-être pas pensée initialement. C’est en particulier vrai >>> lorsque tu te sers de tes flow pour la detection d’anomalies. >>> >>> J’avais fait une petite video sur le sujet il y a quelques années à >>> l’assemblée FranceIX: https://www.youtube.com/watch?v=Vds3ibaCpIU >>> >>> Pour ce qui est du software et de la collecte: l’open source PMACCT offre >>> de nombreuses options intéressantes. Paolo Lucente mon ami et partenaire >>> (auteur du SW viendra au prochain FRnOG en parler). Il sera disponible >>> aussi pour répondre aux questions et moi aussi :-). >>> >>> My 2 cents, >>> Matthieu. >>> > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/
signature.asc
Description: Message signed with OpenPGP
