ft2nfdumpのバグ

(tl;dr for english readers — Once I found a minor bug in ft2nfdump (existing in the latest 1.6.13),  and the last code shown in the bottom is how I fixed it.)

当社ではネットワークの、特にSNMPを監視していて、まれにflowを見ることがあります。昔からflow-toolsをベースにした社内開発ツールなどを利用して いましたが、ipv6や特定メーカに依存しないシステムとして新しいツールの利用などもだいぶ進んできました。とはいえ実際にはアメリカの開発チームが進めている話で、日本チームとしては、アメリカとは違った検討も進めたりしているわけです。そんな中で見つけたバグのお話。

当社ではflow-toolsベースの自社監視ツールを持っていますが、nfsenやnfdumpというツールも使用しています。これはシステム的な冗長という意味はありますが、いちいち切り替えたりして面倒です。そこで、flow-toolsとnfsen, nfdumpの結果を一緒に見られるツールが欲しくなったのです。 冗長を考えると複数ツールで監視が一番安全だと思いますが、普段使う分には統合インターフェース用意する方がいいですね。

まあ、古くて枯れてるflow-toolsと、比較的新しくて導入されることも多いnfsen/nfdumpの組み合わせについては、当然他にも考えている人がいるはずですなので、それを利用して自分で簡単なスクリプト書くのが一番早い、と考えました。というか、nfsen/nfdumpにはそのものズバリ、ft2nfdumpというflow-toolsのデータを nfdump形式に変換するツールが付属してますし。そこでまず、flow-toolsで収集されているデータをnfdumpデータに変換して、nfdumpベースで見てみればいいんじゃないかと思ったのです。

ところが変換、これが一向に上手くいかない。

試しにflowファイルをft2nfdumpでnfdump側に渡して、nfdump側で見てみましょう。

 *****@***:~$ flow-cat ./flowdata |ft2nfdump|nfdump -s dstip 'router ip *.*.*.*'

Top 10 Dst IP Addr ordered by flows:
 Date first seen Duration Proto Dst IP Addr Flows(%) Packets(%) Bytes(%) pps bps bpp

Summary: total flows: 0, total bytes: 0, total packets: 0, avg bps: 0, avg pps: 0, avg bpp: 0
 Time window:
 Total flows processed: ****, Blocks skipped: 0, Bytes read: ****
 Sys: ******s flows/second: ****** Wall: 8.429s flows/second: ******

nfdumpで表示してみると、何も表示されません。total flowsとかはちゃんと表示されているので、データ自体はある様子。おかしいなあ。
一方、flow-toolsベースの社内ツールで調べると、ちゃんと表示されてるわけです。

============================================================
ip-destination-address* flows octets packets duration
------------------------------------------------------------
61.211.1**.*** 87 290064778 203716 313280
61.211.1**.*** 49 5612100 4294 234784
61.211.1**.*** 852 3803415 55330 2199104
10.96.10.*** 26 2999210 3696 98272
10.96.11.*** 25 2858794 3523 91712
10.96.11.*** 27 2662351 3308 90880

*IPアドレスは必要最小限の範囲で、隠して表示しています。

こういう場合、「今までのflow-toolsデータが間違ってる」場合と、「変換したnfdump形式が間違ってる」場合がありえますが、挙動か ら考えたら明らかにnfdumpが間違ってるか、むしろft2nfdumpが変換ミスってますよね。まあ後からみれば一目瞭然ですが、実際はflowデータを直接見たりチェックして、やっとft2nfdumpの変換で、元のデータ形式が持っている機器に関する情報が抜けることに気づきました。

ところでオープンソースの良いところは、挙動に不審な点がある場合、直接ソースコードを確認できるところですね。なのでft2nfdumpのソースを直接見てみました。(引用したのは nfdump-1.6.13 のbin/ft2nfdump.c です)

270	case EX_ROUTER_IP_v4:
271		record.ip_nexthop.v4 = *((uint32_t*)(rec+fo.peer_nexthop));
272		break;
273	case EX_NEXT_HOP_v4:
274		record.ip_router.v4 = *((uint32_t*)(rec+fo.router_sc));
275		break;

あー、問題が２つありました。

1. ROUTER_IP_v4 の場合 になぜかnexthopに、EX_NEXT_HOP_v4の時になぜかrouterに値を代入する
2. 本来exaddrを参照するべきなのになぜかrouter_scを、nexthopを代入すべきところにpeer_nexthopを代入している。

それはバグって当然。本当はこう書くべきでした。

<bin/ft2nfdump.c>
 270		case EX_NEXT_HOP_v4:
 271			record.ip_nexthop.v4 = *((uint32_t*)(rec+fo.nexthop));
 272			break;
 273		case EX_ROUTER_IP_v4:
 274			record.ip_router.v4 = *((uint32_t*)(rec+fo.exaddr));
 275			break;

そういうわけで、ビルドしなおしたft2nfdumpが無事動作するようになったので、めでたしめでたし。 だったんですが、アメリカの同僚に「ごめんバグ見つけたから直しといて、あとそっちからnfdump側に報告しておいて」とお願いして早２年、nfdumpのソースが直ってなさそうなので今回日本語ですが公開してみました。お困りの方がいらっしゃったらソースをリビルドすれば直りますよ！