概要

これはBBSakura Networks アドベントカレンダー2022の15日目の記事です。

どうも、最近インターネット業界に入ってきたネットワーク初心者です。
netflow / sflow を触る機会があったので今回はその辺りについて書こうと思います。
「OSSにコントリビュートした」と言うとプルリクあげたんだなってなりそうですけど、そんなレベルではなくてイシューあげたことで機能追加に貢献できたかもなって話です。

そもそも netflow / sflow って？

一言で言うと、トラフィックの内訳情報をもつ「フローデータ」のことです。
このフローデータをうまくデコード・パースすることによって自身の欲しいトラフィック情報を取得していく感じになります。

OSSにイシューを投げて解決するまでの流れ

↑の netflow / sflow をパースするライブラリとして今回使ったのが以下のpmacctというもので、実際にnetflowを処理するのをnfacctd、sflowを処理するのをsfacctdと言います。

ほとんどPaoloさんひとりでメンテしているっぽい？です（すごい！）
JANOG36に登壇されていたらしいのでネットワーク業界の人は知っている人も多いんですかね。。。？
https://www.janog.gr.jp/meeting/janog36/program/opnet

とりあえずトラフィックデータ見てみる！

スイッチにsflowの設定を入れて、サーバー側でsfacctdを使って雑にcsvにトラフィックデータを吐かせたのが始まりです。
このとき初めて知ったんですけど、netflowと違ってsflowはすーごい量のパケット（フローデータ）が飛んでくるんですよね。

それで、ここからが今回の話

csvを眺めていると「特定のポートだけトラフィックデータがない」ことに気づきます。

初めはsflowの設定が間違っていてうまくフローを投げられていないのかな〜くらいに考えてました。
ただ、sflowを受け付けているサーバー側のパケットをWiresharkで覗いてみると、問題のポートのsflow自体はサーバーまで到達していることが確認できたので、「じゃあsfacctdでパケットの中身をパースするときに何か問題起きてるのかな？」となりました。
ちなみに、パケットキャプチャの中身を見ていて気づいたのですが、トラフィックデータをcsv化してくれないポートではQ-in-Qのトラフィックが流れていたんですよね。他のポートではQ-in-Q使ってなかったのでこいつをパースするときに問題があるのでは？と。

ということで実際にソースの中身を見に行ってQ-in-Qの処理（VLANタグの処理）がどうなってるかいざ確認！

どういうふうに処理しているか確認しよー
あわよくば初めてプルリクとか投げてみよー
投げてみよー
みよー、
、、、
orz

はい。僕の実力ではどの辺でVLANタグの処理をしているかくらいまでしか分からず、どう処理を追加したらいいかが分かりませんでした。。。

ということで、プルリク出してみたいという気持ちを抑えつつもイシューに投げました！

結果

イシューあげたら割とすぐ返事が来まして、メールでパケットの詳細を送りつつ少しやりとりしただけで爆速で直してもらえました！（Paoloさん優しい！！）
一人でうじうじ悩んだりコードを読んだりしていたのがあほらしくなるくらい爆速でしたね。。。

コミット履歴見ると、処理するEtherTypeの変数を追加してその中でC-TAGのVLANまで処理できるようにした感じかな、と。
もうちょっと（いやかなり）頑張ってコード読みこんだら初プルリクあげれたかもなあ。。。とか思ってみたりw

ただまあ、OSSに関わること自体はそこまでハードル高くないと感じた（大規模でなければ）ので、これからもプルリクとかイシュー上げていこうと思えた良い経験でした！
また、それなりのOSSをメンテしている人は技術的にも人間的にも優れてる人多いんだろうなあとも感じられたのは良かったですね。サンプル数1ですが。
ということで次こそはOSSにプルリク出してみたい！！