From owner-freebsd-users-jp@FreeBSD.ORG Sat Nov 22 09:09:35 2014 Return-Path: Delivered-To: freebsd-users-jp@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 68DB95BB for ; Sat, 22 Nov 2014 09:09:35 +0000 (UTC) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.allbsd.org", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 56C0A7F0 for ; Sat, 22 Nov 2014 09:09:34 +0000 (UTC) Received: from alph.d.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=56) by mail.allbsd.org (8.14.9/8.14.8) with ESMTP id sAM99Cak064070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 22 Nov 2014 18:09:23 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.9/8.14.8) with ESMTP id sAM99AZ5015821 for ; Sat, 22 Nov 2014 18:09:11 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sat, 22 Nov 2014 18:07:03 +0900 (JST) Message-Id: <20141122.180703.1256967741828538087.hrs@allbsd.org> To: freebsd-users-jp@freebsd.org From: Hiroki Sato In-Reply-To: <20141115101119.bacccd7953f5562ab5820224@puyo.org> References: <20141115101119.bacccd7953f5562ab5820224@puyo.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.6 on Emacs 24.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sat_Nov_22_18_07_03_2014_416)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Sat, 22 Nov 2014 18:09:27 +0900 (JST) X-Spam-Status: No, score=-96.5 required=13.0 tests=CONTENT_TYPE_PRESENT, FAKEDWORD_ONE, FAKEDWORD_VERTICALLINE, FAKEDWORD_ZERO, ISO2022JP_BODY, RDNS_NONE, SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Subject: [FreeBSD-users-jp 95357] Re: =?iso-2022-jp?b?ZXBhaXIqGyRCJE4bKEJNQUMbJEIlIiVJJWwlOSQsGyhC?= =?iso-2022-jp?b?GyRCPUVKIyQ5JGsbKEI=?= X-BeenThere: freebsd-users-jp@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion relevant to FreeBSD communities in Japan List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 09:09:35 -0000 ----Security_Multipart(Sat_Nov_22_18_07_03_2014_416)-- Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit TOGAWA Satoshi wrote in <20141115101119.bacccd7953f5562ab5820224@puyo.org>: to> 戸川です。 to> to> FreeBSD 10.0-Rを使って、jailを複数立ち上げていました。 to> 10.1-Rに上げたところ、起動時にこんなメッセージが出るようになりました。 ... to> 確かにepair2bとepair4bのMACアドレスが重複するので、そこから生成される to> IPv6アドレスが重複しているようです。 to> to> Webを調べてみたところ、 http://demon-lord.com/doku.php?id=vps:vps_01 にて to> ---- to> epairを一つ作成してjailerからprisonerに割り当ててから次のepairを作成すると to> MACアドレスが重複する場合がある。この場合、それぞれのepairを同じbridgeに to> 接続するとMACアドレスが重複して通信が行えなくなる。問題を回避する為、 to> epairの作成は同時期に行う。 to> ---- to> という記述がありましたが、現在の /etc/rc.d/jail の仕組みを使って、 to> この問題を解決するには、どうすれば良いのでしょうか? epair(4) の MAC アドレスは、if_index の値が使われます。 if_index は、インタフェースに付けられた連番です。 02:ff:00:00:05:0a の場合、0x05 が if_index です。上位から 0 バイト目は固定ですが 1, 2 バイト目はどういう値が入るか決まっていません。 この連番は、vnet jail 単位で管理されています。つまり、 1. ホスト環境で ifconfig epair0 create する 2. ホスト環境の if_index が 2 増える 3. ホスト環境で ifconfig epair0b vnet 1 する 4. jail 1 の if_index が 1 増え、ホスト環境の if_index が 1 減る という動作をします。ここで再度ホスト環境で ifconfig epair1 create すると、epair1a は epair0b の if_index を再利用する 可能性が生じます。 メールにあるログを具体的にたどると、次のようになると思います。 to> epair1a: Ethernet address: 02:ff:00:00:04:0a to> epair1b: Ethernet address: 02:ff:50:00:05:0b epair1a の if_index == 4 epair1b の if_index == 5 to> epair2a: Ethernet address: 02:ff:00:00:06:0a to> epair2b: Ethernet address: 02:ff:50:00:07:0b to> epair3a: Ethernet address: 02:ff:00:00:08:0a to> epair3b: Ethernet address: 02:ff:50:00:09:0b epair2a の if_index == 6 epair2b の if_index == 7 epair3a の if_index == 8 epair3b の if_index == 9 ここまでで、epair1b, 2b, 3b はまだホスト環境にあります。 to> epair4a: Ethernet address: 02:ff:00:00:05:0a epair4a の if_index == 5 この時点で、epair1b が vnet jail に移動して if_index が 再利用されています。 to> epair4b: Ethernet address: 02:ff:50:00:07:0b これも epair2b の if_index == 7 が再利用されて epair4b に付いています。したがって、 to> epair4b: DAD detected duplicate IPv6 address fe80:2::ff:50ff:fe00:70b: NS in/out=0/0, NA in=0 epair4b と epair2b に同じ MAC アドレスが付くため、 ブリッジすると通信できません。 if_index の再利用は、epair に限らず clone に対応した インタフェースであればどれでも発生します。 解決方法は 2 つあります。 a) ホスト環境から vnet jail にインタフェースを移動させる操作と、 clone の操作を並行で行なわない。 たとえばホスト環境で cloned_interfaces を定義するなどして epair をあらかじめ作成しておき、jail.conf に vnet.interface を定義することで ホスト環境から vnet jail へ移動させる。 b) "ifconfig epair0b ether 02:ff:10:10:10:0a" などを実行し、 リンク層アドレスを手動で固定してしまう。 epair の MAC アドレスは安定していませんので、a) であっても固定するほうが 扱いやすいと思います。 -- Hiroki ----Security_Multipart(Sat_Nov_22_18_07_03_2014_416)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlRwUjcACgkQTyzT2CeTzy0VCACfcmvdcJrNP0pwbzF+YP7Ixv7g NUAAoNQqPWW6neeIXB9b9T9NWedOzm0e =sVqP -----END PGP SIGNATURE----- ----Security_Multipart(Sat_Nov_22_18_07_03_2014_416)----