netflow # 1.5

ピーピング・トムにならなかった方、卒業した方。ようこそ、続きです。

tcpdump などキャプチャするもの大抵は libpcap を用います。キャプチャする linux box の性能とネットワークの流量に依存してしまいますが、linux でのノーマルの libpcap は性能が芳しくないために結構なパケットを取りこぼしてしまいます。もっと効率良くキャプチャをっ。と

1. カーネルパッチとユーザランド。勿論 libpcap 込みのPF_RING


2. vanilla カーネルに組み込まれている CONFIG_PACKET_MMAP を用いた A libpcap version which supports MMAP mode on


3. 2 にイタズラして環境変数付けなくても良い悪趣味 libpcap

などがあります。PF_RING にしても CONFIG_PACKET_MMAP にしても、受信したパケットをユーザランドとカーネルスペースで共有した領域にコピーするようです。

1 か 2 がお勧めですが、ドキュメント眺めたり Google様に尋ねながら so name がディストリビューション標準の libpcap と同じ名前になるよう shared library 作ってみて下さい。適当な...例えば /home/jot/lib に置いて、なかなか難かしい条件ですが、一定の量。あるいはフルフルの量を機器に通して

• tcpdump -ni any > /dev/null

• LD_LIBRARY_PATH=/home/jot/lib tcpdump -ni any > /dev/null

同じ程度の時間経った後 Ctrl-C で終了した後の統計

# tcpdump -ni any > /dev/null
tcpdump: WARNING: Promiscuous mode not supported on the "any" device
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
^Ctcpdump: pcap_loop: 
n packets captured
n packets received by filter
#### packets dropped by kernel

#### の箇所、結構な数減っていません?

おぉっと唸った。かつ、置き換えた事実を忘れない。かつ、ちょっと位の不具合とは戦える。という方。置き換えましょう。

余談ですがトラヒック負荷かけるのであれば CONFIG_NET_PKTGEN を Documentation/networking/pktgen.txt 眺めたり、こちらを参照したりで pktgen.sh。あるいは PF_RING の方は stream.c なるものを使っていたらしい。その当時は無かったカーネルスペースの pktgen の方がキョーレツ。