yunazuno.log
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
自宅のルータをAT-AR2050Vに入れ替えた & 回線をv6プラス化した - yunazuno.log
自宅マンションで光配線方式のフレッツが使えるようになったので、これを機にルータの入れ替えとv6プラス(IPv6 IPoE)化を実施したメモ。 結論から言うと、IPv4 PPPoE時代に発生していた夜間帯の輻輳が解消され、かなり快適になった。 構成変更前の環境 現住居に引っ越した時点ではフレッツのVDSL方式しか選択肢が無かったため、一旦考えるのをやめて最低限インターネットに接続できる環境だけを構築して使っていた。 回線: NTT東日本 フレッツ 光ネクスト マンションタイプ VDSL方式 ISP: Biglobe ルータ: Buffalo BBR-4MG ひかり電話契約は無し。VDSLモデムの下にルータが居て、そこでIPv4 PPPoEを終端するだけの単純な構成。 構成変更後の構成 回線が光配線方式に。また、Biglobe経由でJPNEのv6プラスも適用。 回線: NTT東日本 フレッツ
FRRはRFC5549な経路をLinuxカーネルのルーティングテーブルへどうやってインストールするのか - yunazuno.log
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
Linux VRF with L3 Master Device - yunazuno.log
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 とは別に存在し
Linuxにおける Equal Cost Multipath (ECMP) の設定方法と挙動に関するメモ - yunazuno.log
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カーネルの新機能 XDP (eXpress Data Path) を触ってみる - yunazuno.log
先日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ドライバに近い場所でフッ
ロードバランサのアーキテクチャいろいろ - yunazuno.log
少し前に，Facebookのロードバランサが話題になっていた． blog.stanaka.org このエントリを読んで，各種Webサービス事業者がどういったロードバランスアーキテクチャを採用しているのか気になったので調べてみた． ざっくり検索した限りだと，Microsoft, CloudFlareの事例が見つかったので，Facebookの例も併せてまとめてみた． アーキテクチャ部分に注目してまとめたので，マネジメント方法や実装方法，ロードバランス以外の機能や最適化手法といった部分の詳細には触れないことにする． 事例1: Microsoft Azure 'Ananta' MicrosoftのAzureで採用されている(いた？)ロードバランサのアーキテクチャは，下記の論文が詳しい． Parveen Patel et al., Ananta: cloud scale load balancing
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
