はてなブックマーク

Linux kernel 4.4以降には，eBPF map/programを"永続化"する仕組みが実装されている．ここではその概要を説明しつつ，iovisor/bccを使って実際にその動作を確かめてみる． Background: eBPF objectを複数プロセスで共有したい eBPFにmapというデータ構造があることはXDPの紹介エントリのサンプルコード内で軽く触れた． 通常，mapはそれを作成したプロセスからのみ読み書き可能である．しかし，いくつかのユースケースにおいては，mapを複数のプロセスから読み書きできると都合が良いことがある．たとえば何からの統計情報(例えばパケットカウンタ)をmapに保存してそれを外部に転送したい場合，「統計情報をmapに保存するプロセス」と「収集された統計情報を加工して外部に転送するプロセス」とに分割したほうが，実装の見通しの観点から望ましい．また，ma

eBPFには BPF_PROG_TEST_RUN と呼ばれる機能がある。これを活用すると、XDPやtc-bpf(8)向けに実装したパケット処理プログラムの挙動をテストすることができる。 BPF_PROG_TEST_RUN? BPF_PROG_TEST_RUNはbpf syscall経由で使用できる1機能。テストしたいeBPFプログラムとパケットのバイト列を入力として与えると、実行結果の返り値と処理後のパケットバイト列、および処理にかかった時間が出力として得られる。このとき、テスト対象のプログラムは実際にネットワークインタフェースにアタッチされるわけではないので、実行環境に影響を与えることなくテストを遂行できる。 lwn.net libbpfに bpf_prog_test_run() というラッパ関数が用意されているので、実用上はこれを経由して使用するのが便利。 libbpf/bpf.c a

Linuxのtcには、指定した条件にマッチしたパケットをドロップしたりヘッダを書き換えたりするためのflowerフィルタが存在する。 tc-flower(8) - Linux manual page 最近のNICの中にはこの処理をハードウェアにオフロードできるものがあり、通常のソフトウェア処理と比較して高スループットを実現しつつCPU使用率低減が期待できる。ここではtc flowerのNICハードウェアオフロード機能の動作を試してみる。 対応するNICドライバ Linuxカーネル4.16.7のソースコード上で確認する限り、以下のNICドライバでtc flowerハードウェアオフロードに対応しているようである。ちなみに対応状況はTC_SETUP_CLSFLOWERないしTC_SETUP_BLOCK*1といったキーワードで検索するとおおよそ掴める。 Broadcom bnxt (BCM573x

FRRouging (FRR)という、Quaggaからフォークしたルーティングデーモンがある。 github.com FRRはRFC 5549に対応しており、bgpdで受信したIPv6ネクストホップを持つIPv4経路をzebra経由でLinuxカーネルのルーティングテーブルへインストールすることができる。しかし、Linuxカーネルのルーティングテーブルにそのような経路をインストールすることは通常できないはずである。正確に言うと最近のiproute2ではip routeコマンドでそのような指定自体は可能だか、実際には反映されない。 $ ip -V ip utility, iproute2-ss170905 $ sudo ip route add 192.168.254.0/24 via inet6 fe80::a00:27ff:fe25:4c23 dev eth1 $ ip route 19

最近のNICの中にはTCハードウェアオフロード機能を持っているものがあり、これを使えばNICハードウェア上でパケット転送処理に手を加えられることは以前のエントリで簡単に紹介した。 yunazuno.hatenablog.com 今回はこれを応用し、NICハードウェア上でL3スイッチングを実現できないか検討してみる。 前置き: tcを用いたレイヤ3パケットスイッチング tcを用いたL3スイッチ動作表現の具体例 本題: SR-IOV switchdev mode + TCハードウェアオフロードによる、NICハードウェア上でのL3スイッチング SR-IOV switchdev modeでNICハードウェアの挙動を制御する SR-IOV switchdev modeの設定方法 TCでFIBをハードウェアにオフロード まとめ 前置き: tcを用いたレイヤ3パケットスイッチング L3スイッチの動作はお

今更ながら，GoogleのMaglev論文で提案されているMaglev Hashingを手元で実装してみた． Maglev: A Fast and Reliable Software Network Load Balancer Maglev Hashingとは 所謂Consitent Hashの一種．Maglevロードバランサにおけるリアルサーバ選択に使用されている． 上記論文のSection 3.4で詳細が説明されている．NSDI'16での発表スライドも併せて眺めると分かりやすい． Maglev: A Fast and Reliable Software Network Load Balancer | USENIX Slide: https://www.usenix.org/sites/default/files/conference/protected-files/nsdi16_sli

Linuxのネットワークスタックでmultipathを使用する場合の設定方法と挙動に関するメモ。 設定方法 設定自体は ip route add コマンドで nexthop を複数指定するだけ。src の指定は必要に応じて。 # ip route add 10.1.1.0/24 src 10.0.0.3 \ nexthop via 192.168.11.1 weight 1 \ nexthop via 192.168.12.1 weight 1 $ ip route (snip) 10.1.1.0/24 src 10.0.0.3 nexthop via 192.168.11.1 dev eth1 weight 1 nexthop via 192.168.12.1 dev eth2 weight 1 なお、カーネルが CONFIG_IP_ROUTE_MULTIPATH=y でコンパイルされて

Linux kernel 4.4から登場した、L3 Master Device (l3mdev) によるVirtual Routing and Forwading (VRF) を軽く触ってみたメモ。 そもそも何をするためのものなのか Linuxのネットワーク廻りを触っていると、たまに「特定のネットワークインタフェースから入ってきた通信に、特定のルーティングルールを適用したい」といった場面がある。こうしたケースでは、以前より Routing Policy Database (RPDB) を利用して Policy Based Routing (PBR) を行う方法が知られている。 d.hatena.ne.jp 一方、ネットワーク機器の世界では一般的に、L3ドメインを分割する手段として Virtual Routing and Forwarding (VRF) という機能が PBR とは別に存在し

4月に開催されたnetdev 2.1で面白いセッションがあったのでメモ。 Facebookが使用しているレイヤ4のロードバランサに関する発表で、従来はIPVS (LVS) を使用していたが、XDPベースで自ら開発したものに移行しつつある、という内容。 XDP Production Usage: DDoS Protection and L4LB (slide) www.youtube.com XDP (eXpress Data Path) については以前のエントリで簡単に紹介した。 yunazuno.hatenablog.com XDPを改めて簡単に紹介すると、Linuxカーネルのネットワークスタックの最下部 (NICに一番近い場所) でパケット処理を行う仕組みのことで、オーバーヘッドが非常に小さい高速パケット処理の実現を目的としている。XDPはeBPFを用いており、eBPFが提供するmap

先日netdev 1.2に参加してみたところ，XDP(eXpress Data Path)の話題で持ち切りといった感じだった． というわけで，XDPについて一通り調べつつ，実際に触ってみた． XDPとは何か？ 誤解を恐れずに一言で言うと，「Intel DPDKのような高速パケット処理基盤をLinuxカーネル自身が用意したもの」であると理解している．このスライドでは A programmable, high performance, specialized application, packet processor in the Linux networking data path と言っている． DPDKはユーザランドアプリケーションがNICを直接叩く(=カーネルのネットワークスタックをバイパスする)ことで高速処理を実現している．一方XDPは，カーネル内の最もNICドライバに近い場所でフッ

少し前に，Facebookのロードバランサが話題になっていた． blog.stanaka.org このエントリを読んで，各種Webサービス事業者がどういったロードバランスアーキテクチャを採用しているのか気になったので調べてみた． ざっくり検索した限りだと，Microsoft, CloudFlareの事例が見つかったので，Facebookの例も併せてまとめてみた． アーキテクチャ部分に注目してまとめたので，マネジメント方法や実装方法，ロードバランス以外の機能や最適化手法といった部分の詳細には触れないことにする． 事例1: Microsoft Azure 'Ananta' MicrosoftのAzureで採用されている(いた？)ロードバランサのアーキテクチャは，下記の論文が詳しい． Parveen Patel et al., Ananta: cloud scale load balancing

ISC DHCP serverでDHCPサーバを運用するとき，IPアドレスをリースするタイミングで任意のコマンドを実行したいことがある．例えば，クライアントのMACアドレスとリースしたIPアドレスのペアをデータベースに入れておきたい，といった場合． こういった場合，on commit/on release/on expiryが使える．dhcpd.confに次のような設定を書いておくと，それぞれのタイミングで外部のコマンドが実行される． on commit { execute("/path/to/script", "arg1", "arg2", "arg3"); } on release { execute("/path/to/script", "arg1", "arg2", "arg3"); } on expiry { execute("/path/to/script", "arg1",

去年のJANOGで別の方が発表された内容とダダ被りではあるものの，折角なのでメモ程度に書いておく． 概要 データセンタネットワークやバックボーンネットワークの運用をやっていると，インターネットに出入りするトラフィックの内訳 (どのISP向けのトラフィックが多いのか，どの回線にトラフィックが乗っているか，等) を見たいことがよくある NetFlowをNorikraで解析し，その結果をGrowthForecastに流し込むと，トラフィックの内訳をそこそこ手軽に見ることができる 定常的なモニタリング用途以外に，突発的なトラブルシューティングにも使えていろいろ便利 背景 自前でAS (Autonomous System) を運用している事業者では，トラフィックのコントロールの観点から，「どのAS向けのトラフィックがどのくらいあるのか」「このASとはどの回線を使って通信しているか」といった情報を知り

NetFlowまわりの諸々を触りたいとき，VyOSだとハードウェアを別途用意しなくても手軽に色々試せて便利． VyOSの設定 PlixerとManageEngineの記事を見つつ，下の設定さえあればとりあえず動く．Timeout値まわりは環境に合わせて要調整．バージョンはVyOS 1.0.4. set system flow-accounting netflow version 5 set system flow-accounting interface eth0 set system flow-accounting netflow server 192.168.56.1 port 2055 # system flow-accounting netflow timeout以下は必要に応じて設定 set system flow-accounting netflow timeout expir

先日googleとakamaiは仲良し？というエントリを読んだとき，恐らくEDNS Client Subnet Optionだろうとは思った*1ものの，EDNS Client Subnet Optionの動作をきちんと把握してはいなかったので，この機会にdraftを読んでみた． 概要 DNS権威サーバの中には，クエリ送信元のDNSキャッシュサーバのIPアドレスによって応答を変えるものが存在する クライアントとキャッシュサーバのネットワーク的な距離が離れている場合，権威サーバは適切でない応答を返す恐れがある キャッシュサーバから権威サーバへのクエリ内にクライアントのIPアドレスの一部を含めることで，権威サーバがより適切な応答を返すことを実現する 利用にはキャッシュサーバと権威サーバの対応が必要 (クライアントの対応は不要) 問題: Public DNSと"不適切"な応答の発生 CDN事業者や

あるファイルに含まれるIPアドレスをgrepしたいとき，/32なり/128なりのIPアドレスそのものではなく，サブネットでgrepできると便利な場面が多々ある．それらしき物が無いか探したところ，grepcidrというツールがあったのでメモ． 導入 単純にソースコードをダウンロードして make & make install するだけ． $ wget http://www.pc-tools.net/files/unix/grepcidr-2.0.tar.gz $ tar xvf grepcidr-2.0.tar.gz $ cd grepcidr-2.0 $ make # make install 使い方 たとえば下のようなファイルがあるとする． $ cat ipaddr.txt 192.0.2.0/24 192.0.2.0/25 192.0.2.128/25 192.0.2.254/32 2

最近Norikraを触っていて，ある程度使い方が分かってきたのと，丁度v1.0.0もリリースされたので，忘れないうちにこのタイミングでメモしておく． 本来Norikraはリアルタイムなログ等に対して処理をするものであるけども，今回は過去に蓄積されたログに対して集計処理を行ってみることにする*1． 今回のキーポイントは， win:ext_timed_batchを使って，ログの発生時刻を指定する LOOPBACKを使って，あるクエリで発生したeventを別のtargetに直接流し込む の2点． やりたいこと 下のような，2台のホストで1分毎に生成されたデータがあるとする． # host1.csv timestamp, metric1, metric2, ... 1396278000, 0, 0 1396278060, 1, 2 1396278120, 2, 4 1396278180, 3, 6