Re hbstudy #4 での OpenVZ の話 (ARP response が遅い件について)
hbstudy #4 で id:fujya さんが OpenVZ についてお話されました。FreeBSD の jail 大好きっこだった自分も OpenVZ を使っているので、興味深く拝聴させていただきました。ありがとうございました。(スライドは Open VZ)。
その中で、
「venetを超えてrt_cacheにエントリを登録する時に遅延する」
というのが気になったので、少し調べてみました。
まず、手元の物理サーバから、イーサネットを経由して別サーバ上の OpenVZ コンテナ (xx.xx.xx.25) に ping を打ってみます。
$ sudo arp -d xx.xx.xx.25 $ sudo ip route flush cache $ ping xx.xx.xx.25 PING xx.xx.xx.25 (xx.xx.xx.25) 56(84) bytes of data. 64 bytes from xx.xx.xx.25: icmp_seq=1 ttl=64 time=132 ms 64 bytes from xx.xx.xx.25: icmp_seq=2 ttl=64 time=0.129 ms --- xx.xx.xx.25 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 0.129/66.333/132.538/66.205 ms $ sudo ip route flush cache $ ping xx.xx.xx.25 PING xx.xx.xx.25 (xx.xx.xx.25) 56(84) bytes of data. 64 bytes from xx.xx.xx.25: icmp_seq=1 ttl=64 time=0.132 ms 64 bytes from xx.xx.xx.25: icmp_seq=2 ttl=64 time=0.163 ms --- xx.xx.xx.25 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 0.132/0.147/0.163/0.019 ms $ sudo arp -d xx.xx.xx.25 $ ping xx.xx.xx.25 PING xx.xx.xx.25 (xx.xx.xx.25) 56(84) bytes of data. 64 bytes from xx.xx.xx.25: icmp_seq=1 ttl=64 time=763 ms 64 bytes from xx.xx.xx.25: icmp_seq=2 ttl=64 time=0.139 ms --- xx.xx.xx.25 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1002ms rtt min/avg/max/mdev = 0.139/381.978/763.817/381.839 ms $
ARP cache にエントリがない場合のみ遅延しているようです。そこで、arping を使って確認。
$ sudo arping -b -I eth0 -c 10 xx.xx.xx.25 ARPING xx.xx.xx.25 from xx.xx.xx220 eth0 Unicast reply from xx.xx.xx.25 [00:12:3F:xx:xx:xx] 368.549ms Unicast reply from xx.xx.xx.25 [00:12:3F:xx:xx:xx] 126.425ms Unicast reply from xx.xx.xx.25 [00:12:3F:xx:xx:xx] 698.251ms Unicast reply from xx.xx.xx.25 [00:12:3F:xx:xx:xx] 799.124ms Unicast reply from xx.xx.xx.25 [00:12:3F:xx:xx:xx] 116.990ms Sent 5 probes (5 broadcast(s)) Received 5 response(s)
やはり、原因は ARP broadcast へのレスポンスが遅いためです。
そこで、OpenVZ (のvenet) は linux カーネルのIPフォワードを使っているので、ARP パケットの無駄な転送を防ぐために、意図的な遅延を入れているのかもしれません。じゃあ arp_proxy をオンにしたらいいのかな... と思ったけど、うまくいかない。proxy_arp の設定が正しいのかどうかわからない... ってあたりであきらめた。
中途半端で恐縮ですが、とりあえず原因は routing cache じゃなく arp のレスポンスt遅延が原因なら、IIRC 定期的にパケットを流しておけば問題ないんじゃないかなーと思いました。
